미리보기

도메인 중심 아키텍처 적용 및 레거시 마이그레이션 경험

• .NET 기반의 레거시 백오피스 API를 Spring Boot로 전환하며, 도메인 계층 중심의 구조 재설계

• 의존성 흐름을 명확히 구분하고, 각 계층 간 결합도 최소화를 위한 구조 설계 및 구현 주도

• 실 서비스 환경에서의 구조적 변경에도 도메인 안정성과 코드 유연성 확보 경험

이벤트 기반 아키텍처 표준화 및 보일러플레이트 구축 주도

• Google Pub/Sub 기반 이벤트 발행 구조 설계 및 보일러플레이트 코드 개발

• 데이터 무결성을 위한 발행 규칙 정의 및 팀 전반에 표준화 적용

서비스 장애 대응 및 병목 원인 분석 경험

• Redis 장애로 인한 서비스 전체 다운(SPOF) 이슈를 발견하고 문제 원인(비효율적인 Redis 명령어 사용) 분석 및 구조 개선

• 성능 병목 구간의 코드를 개선하여 데이터 정합성과 시스템 안정성 확보

신규 시스템 설계 및 구축 경험(온보딩)

• Golang, gRPC, WebSocket, Google Pub/Sub, Redis 등을 활용한 실시간 채팅 서비스 백엔드 및 프론트엔드 개발

• 처음 접하는 기술 스택(Golang, Docker 등) 기반으로 3주 내 전체 시스템 개발 및 배포 완료

프로젝트 개요

오랜 기간 .NET과 MSSQL Stored Procedure 기반으로 운영되던 백오피스 API 서버를 Spring Boot 기반으로 재구성하며, 도메인 중심 아키텍처를 도입

담당 역할

• 프로젝트 초기 세팅부터 개발 전반을 단독 수행

• 도메인 계층 중심의 구조 설계를 통해 각 계층 간 결합도 최소화

기술적 도전 및 해결

• 각 계층 간 의존성 방향을 유지하기 위해 presentation → application → infrastructure 구조 수립

• 각 계층에서는 도메인을 의존하여 JPA Entity, 요청 DTO가 application계층으로 침투하지 않도록 도메인 객체로 변환하여 주고받는 로직 구성

• application은 흐름 조정, domain은 비즈니스 로직 담당으로 역할을 명확히 구분

성과 및 배운 점

• 최소기능으로 배포한 후 계속해서 마이그레이션을 진행중

• DB 수직 분할 시 infrastructure만 수정하고도 전체 시스템이 정상 작동을 경험

• 아키텍처 설계가 장기 유지보수성과 변화 대응력에 직접적으로 기여함을 실무에서 경험

프로젝트 개요

• 이벤트 발행 실패 이슈를 해결하기 위해 Google Pub/Sub 구조를 재설계하고, 팀 공통으로 사용하는 보일러플레이트 코드 작성

담당 역할

• 데이터 속성 구조(data vs attribute) 정리 및 사용 정책 수립

• 발행 구조를 코드로 일반화하고, 모든 팀원이 사용할 수 있도록 공통 패키지화

기술적 도전 및 해결

• attribute 용량 초과로 인한 전송 실패 사례를 줄이기 위해 attribute는 이벤트 속성 전용, 본문은 data 필드 전용으로 역할 분리

• attribute의 속성으로 data의 구조체를 명확히 구분할 수 있도록 enum으로 관리

• 발행자와 수신자가 같은 구조체를 사용할 수 있도록 공통 스키마 관리

• 이벤트 처리 시점의 정합성을 위해 최소한의 데이터만 발행하고, 수신 측에서 조회하는 구조 채택

성과 및 배운 점

• 전체 백엔드 파트에서 공통적으로 사용하는 이벤트 처리 기반 마련

• 단일한 정답은 없다는 점을 경험하고, 유지보수성과 확장성을 고려한 절충안 설계 능력 향상

프로젝트 개요

• Redis 장애로 인해 유저 서비스가 수 시간 동안 중단된 사고 발생. 직접 담당자는 아니었지만 장애 대응에 참여하여 구조 개선에 기여

담당 역할

• Redis에 부하를 유발한 공통 코드 분석 및 수정 제안

• Redis keys 명령어의 성능 문제(O(N))를 발견하여 데이터 저장 방식을 변경

기술적 도전 및 해결

• 장애 당시 로그가 남지 않아 디버깅이 어려운 상황에서, 과거 WebSocket 관련 경험을 바탕으로 빠르게 병목 코드 파악

• keys 명령어를 사용하는 공통 코드가 빈번히 호출되며 전체 Redis를 다운시킨 원인으로 분석, 성능 안정적인 구조로 교체

성과 및 배운 점

• 실제 장애 상황에서 직접 분석과 개선을 주도하며 서비스 전체 안정성 향상에 기여

• Redis 명령어 선택 하나가 시스템 전반에 영향을 줄 수 있다는 사실을 체감, 기술 선택의 중요성을 학습

프로젝트 개요

• Golang 기반으로 실시간 채팅 서비스를 온보딩 프로젝트로 설계, 개발, 배포까지 단독 수행. 이후 업무 외 시간에 쿠버네티스 환경 배포 및 CI/CD 파이프라인 구성까지 확장

담당 역할

• WebSocket, Google Pub/Sub, gRPC, MySQL, Redis, Elasticsearch 기반으로 엔드 투 엔드 전체 채팅 시스템 구현

• 프론트엔드도 함께 개발하여 전체 서비스 구조에 대한 깊은 이해 확보

기술적 도전 및 해결

• 데이터베이스를 제외한 대부분의 기술을 처음 접한 상태에서 기능 예제를 Java로 먼저 구현 후 Golang으로 포팅하는 방식으로 빠르게 적응

• WebSocket 전송 직전에 서버가 죽을 경우 발생하는 데이터 정합성 문제를 정의후 프론트엔드 측에서의 재요청 구조로 해결

성과 및 배운 점

• 회사 온보딩 과제에서 모든 옵션 기술을 실제 적용해 완성한 첫 사례로 평가

• 다양한 기술을 빠르게 습득하고 실전 배포까지 연결하는 과정에서 학습 속도와 문제 해결 역량을 입증

awsome-mcp-servers (한글 번역 문서 Anchor 기능 추가) - PR link

Spring-Framework (Deprecate JUnit4) - PR link

이펙티브 자바 스터디 / 6인 스터디

• 책에서 제시하는 모범 사례를 학습하여 실무에 적용하여 코드의 가독성을 높임

• 팀 내 코드리뷰에서 리뷰의 근거로 활용

쿠버네티스 입문 스터디 / 4인 스터디

• 업무에서 사용중이던 쿠버네티스를 익히기 위한 스터디로 K8S API에 대한 공부와 kubectl 커멘드를 익혀 업무에 적용

시나리오 기반 백엔드 어플리케이션 개발 (Blog)

• 2025.05 ~ 진행중

• Java21, SpringBoot3, MySQL, Redis

• 서비스를 개발하는 사이드 프로젝트를 위주로 해왔으나, 완성 자체가 목적이 되어 개발 완료 이후 더 깊은 학습을 하기 어렵다고 판단하여 새로 시작한 프로젝트

• 전체 서비스를 개발하는 프로젝트가 아닌, 각 시나리오별로 필요한 부분만 구현하며 문제를 직접 정의하고 풀어나가는 방식으로 진행하며 블로그에 과정을 정리해 나가는 프로젝트

번개 모임 플랫폼

• 2025.02 ~ 2025.04

• Java21, SpringBoot 3, MySQL, SpringSecurity, STOMP

• 백엔드 1명, 프론트 4명, 디자이너 1명 6명이 한 팀으로 프로젝트를 진행

• Spring Security와 JWT를 사용하여 인증 및 인가를 구현

• 촉박한 시간동안 많은 기능을 문제 없이 구현하는데 집중

축의금 관리 플랫폼

• 2024.05

• Golang, gin-framework, MySQL

• 백엔드 2명, 프론트 1명, 디자이너 2명, 기획 1명

• 백엔드 리드를 맡아 Python을 사용하는 팀원과 MSA 형태의 서버(gateway, user, invitation 서버)를 구현