가장 큰 난관은 결제 도메인 자체의 이해였습니다. 간편결제를 써보기만 했지, 앱 뒤에서 PG사·카드사를 거치며 어떤 정보가 오가고 어떻게 암호화되며 어디에 무엇이 저장되는지 전혀 몰랐습니다. 오프라인 결제와 온라인 결제의 처리 과정이 다르다는 사실부터 바닥까지 공부해야 했고, 팀 전체가 같은 그림을 보도록 기획에 충분한 시간을 들였습니다. 그 덕분에 개발은 오히려 빠르게 끝났습니다.

팀 OS가 맥과 윈도우로 섞여 있어 "내 컴퓨터에선 되는데 왜 안 돼?"가 생기기 쉬운 환경이었습니다. 그래서 각자 서비스 개발 후 반드시 Dockerfile로 이미지를 만들어 컨테이너로 띄워 통신을 검증한 뒤 배포하도록 지침을 정했고, 환경 차이로 인한 에러 없이 수월하게 배포할 수 있었습니다.

13개 마이크로서비스를 도메인별 담당자로 나누고, 팀장으로서 전체 아키텍처 방향과 일정을 정리해 팀이 큰 그림을 보게 했습니다. Jira 칸반과 Git을 연동해 브랜치·커밋·PR에 이슈 키만 넣으면 진척이 자동 추적되게 했고, 에러 코드·주석·API/Kafka 명세서 컨벤션을 표준화해 MSA에서도 어디서 무슨 일이 있었는지 추적할 수 있게 했습니다. 개발 중반부터 CI/CD를 미리 구축해 둔 덕분에 이후 배포가 정말 편했습니다.

무엇보다 "몰라서 못 하는 상황"을 막는 데 집중했습니다. 제가 개발을 처음 시작할 때 이런 것도 질문해도 되나 싶은 무지함 때문에 질문을 잘 못 했던 경험이 있어서, 막힘없이 질문하는 분위기를 만들고 싶었습니다. MSA 온보딩 가이드와 환경 구축 문서를 먼저 작성해 공유했더니 팀원들도 각자 공부한 내용을 문서로 남기기 시작했고, 우려와 달리 이해가 안 되면 교육이 끝난 후에도 남아서 끝까지 이해하고 가는 문화가 만들어졌습니다.

단순 기능 구현을 넘어, 결제라는 복잡한 도메인을 깊이 이해하고 MSA 기반 분산 시스템의 설계·배포·운영 전 과정을 직접 경험하고 싶었습니다. 모놀리식이었다면 고민하지 않았을 분산 트랜잭션, 상태 일관성, 데이터 소유권을 실제로 부딪히며 풀어보고, IaC·GitOps·관측성·카오스 엔지니어링까지 운영 안정성을 끝까지 검증하는 것이 목표였습니다.

개발 기간이 약 2.5주로 매우 짧은 상황에서, MSA에 익숙하지 않은 팀원들이 각자의 서비스를 빠르게 이해하고 개발해야 했습니다. MSA 개념부터 도메인 설계, 동기/비동기 통신 판단 기준, Docker/Kubernetes 운영 방식까지 개발하면서 바로 참고할 수 있는 온보딩 가이드 문서를 직접 작성해 공유했고, 개인 메시지로도 자유롭게 질문할 수 있는 분위기를 만들어 기술적 막힘을 최소화했습니다. 이후 팀원들로부터 실질적인 도움이 됐다는 피드백을 받았습니다.

개발 지식과 프로젝트 자료를 정리한 NotebookLM 세션을 팀에 공유해 스스로 질문하며 이해하도록 돕고, React 클라이언트 구현에는 Claude 에이전트를 활용해 프론트-백 연결 작업을 자동화하는 등 AI 도구를 온보딩과 생산성에 적극 활용했습니다.

서비스 도메인별로 담당자를 지정하고, 매일 회의로 진행 상황을 공유하며 회의록을 노션에 기록했습니다. MSA 구조에서는 서비스 간 통신 테스트를 하려면 상대 서비스가 어디까지 완성됐는지 알아야 하기 때문에, 진행 상황을 수시로 공유하는 문화에 특히 신경 썼습니다. 오류가 장기간 해결되지 않으면 함께 디버깅했고, Docker Compose로 전체를 로컬 통합 테스트한 뒤 EKS에 배포해 환경 차이 문제를 사전에 줄였습니다.

MSA와 클라우드 네이티브 환경에서의 실전 개발·배포 경험을 쌓기 위해 진행했습니다. 서비스 간 통신 방식 설계(동기/비동기 분리), Database per Service 패턴, AWS EKS 기반 오케스트레이션 운영까지 전체 MSA 라이프사이클을 직접 경험하는 것이 목표였습니다.

팀원 각자가 동일한 E-ON 레포를 Fork해 개인 환경에서 독립적으로 CI/CD를 구축하는 방식으로 진행했습니다. 팀장으로서 전체 파이프라인의 방향성과 아키텍처를 설계했고, Jenkins 설정부터 GitHub Webhook 연동, 배포 절차까지 따라 할 수 있는 CI/CD 구축 가이드라인을 작성해 공통 기준을 마련했습니다. 매주 진행 상황을 공유하며 특정 이슈가 오래 해결되지 않으면 함께 디버깅했고, 제가 먼저 해결한 이슈(OOM · 이미지 캐싱 · Ingress 라우팅)를 정리해 공유해 팀이 같은 문제를 반복하지 않도록 했습니다.

실제 서비스에 CI/CD 파이프라인을 직접 설계·구축하며 코드 변경부터 자동 배포까지의 전체 DevOps 흐름을 경험하고, VM 기반 배포에서 쿠버네티스 오케스트레이션까지 인프라를 단계적으로 발전시키는 과정을 학습하고자 했습니다.

팀원들이 서로 무엇을 알고 무엇을 모르는지 파악하기 어려웠고, 질문을 주저하는 분위기도 있었습니다. 단톡방뿐 아니라 개인 메시지로도 자유롭게 물어볼 수 있도록 장려해 질문 장벽을 낮췄습니다. 기술적으로는 마이크로서비스 간 통신에서 어려움이 많았는데, Docker Compose로 로컬에서 컨테이너 간 통신을 먼저 검증하는 방식을 적용해 문제 원인을 환경 설정이 아닌 애플리케이션 로직으로 좁힐 수 있게 했습니다.

user 도메인을 user/auth 서비스로 분리하며 JWT 인증을 도입했는데, 일부 서비스는 쿠키로, 일부는 헤더로 토큰을 전달하고 있었습니다. MSA의 stateless 원칙을 근거로 헤더 기반 전달 방식으로 통일할 것을 제안했고, 쿠키와 헤더 방식이 얽혀 있던 코드를 직접 디버깅하며 수정했습니다.

도메인별로 소규모 세부 팀을 구성하고, 단기 목표(도커파일 작성 → 서비스 단독 실행 → 도메인 내 통신 확인)를 주차별로 설정했습니다. 매주 회의로 진행 상황을 공유하고 노션에 기록했으며, 특정 팀에서 오류가 오래 해결되지 않으면 다른 팀이 지원하는 교차 협력으로 함께 성장하는 환경을 만들었습니다.

기존 모놀리식 애플리케이션을 MSA로 분리하는 실습을 통해, 단일 서버 구조와는 다른 분산 환경에서의 서비스 설계·배포·운영을 직접 경험하고자 했습니다. 이때 겪은 분산 장애 추적의 어려움이 이후 카오스 엔지니어링(LitmusChaos)에 관심을 갖게 된 계기가 됐습니다.

초기에는 GCP 환경에서 팀 개발을 진행하며 IAM 권한을 부여했지만, 네트워크 환경 차이로 로컬호스트 접근이 원활하지 않아 테스트가 반복적으로 실패했습니다. SSH 터널링을 시도했고, 이후에는 공통 개발 환경을 로컬로 맞추어 문제를 극복했습니다.

또한 GitHub 사용에 미숙해 충돌이 자주 발생했는데, 레포 관리자를 지정해 무분별한 push를 제한하고 PR 기반 협업과 브랜치 전략을 도입했습니다. 그 결과 코드 충돌이 크게 줄고 버전 관리가 체계화되었습니다.

프론트엔드/백엔드로 나누어 개발했고, 매주 대면 회의로 진행 상황을 공유하며 기능 우선순위를 조율했습니다. 개발 중 발생한 오류나 질문은 디스코드 채널에서 실시간으로 공유하며 빠르게 대응했습니다.

일상 속 다양한 제품의 소비기한 관리 불편에서 출발했습니다. 식품뿐 아니라 화장품에도 소비기한이 존재한다는 점에서, 이를 한 번에 관리할 수 있는 서비스가 있으면 편리하겠다고 생각했습니다. 학기가 끝난 뒤에도 그대로 끝내기 아쉬워 방학 동안 리팩토링해 대회에 다시 도전했고, '실패 → 회고 → 재도전'을 처음 경험한 프로젝트가 됐습니다.

프로젝트 초반에는 GitHub를 제대로 활용하지 못해 메신저로 소스 코드를 주고받는 비효율적인 방식을 썼습니다. 파일이 덮어 써지거나 버전이 달라 충돌이 잦았고, 백엔드-프론트 간 API 통신 기준이 없어 같은 기능을 두고도 해석이 달라 혼란이 있었습니다.

GitHub의 Pull/Push 개념을 처음 배우고 적용하면서 각자의 코드를 한 저장소에 통합할 수 있게 됐습니다. 브랜치 전략이나 코드 리뷰 같은 체계는 아직 없었지만, 최소한의 협업 도구를 익혔다는 점에서 의미가 컸습니다. API 명세서도 직접 찾아보며 처음 작성해봤는데, 요청/응답 형식·필수 파라미터·에러 코드 같은 기본 요소를 정리해야 한다는 걸 배웠고, 덕분에 다음 프로젝트부터 문서화를 자연스럽게 이어갈 수 있었습니다.

2023 소프트웨어 경진대회 참가를 위해 팀을 구성했고, 당시 식사 기록 공유 트렌드를 앱으로 확장해 일반 SNS의 잡음 없이 식사 기록·회고에 집중하는 경험을 제공하고자 했습니다.