1.
이력서 내 주요 경험과 관련한 문제 해결 과정 위주로 구성된 포트폴리오입니다.
이력서 웹으로 보기: https://choo.oopy.io/resume 포트폴리오 웹으로 보기: https://choo.oopy.io/portfolio2.
이런 개발자의 포트폴리오입니다.
요구사항을 꼼꼼하게 분석하는 것을 중시하고, 유지보수하기 좋게 설계하고 개발하는 것을 좋아합니다. 테스트와 리팩토링을 좋아하고, 클린 아키텍처에 관심이 많습니다. 개발자는 문제해결자라고 생각하고, 문제 해결을 위해선 인과관계를 따지는 게 가장 중요하다 생각합니다.[Index]
총대마켓 - 지역기반 공동구매 서비스
▷ 프로젝트 설명
총대마켓은 지역 기반으로 공동구매에 관심 있는 사람들을 연결해, 원하는 물품을 대량 구매가 아닌 소량으로도 저렴하게 구입할 수 있도록 돕는 서비스입니다. 이를 통해 사용자는 비싼 배송비나 대량 구매의 부담 없이, 효율적이고 합리적인 소비를 할 수 있습니다.
기술적, 기획적으로 고민이 많았던 프로젝트입니다. 공동구매 서비스를 제공하는 여러 회사들의 사례를 찾아보며 분명 공동구매에 대한 니즈는 분명한 걸 확인했지만, C2C로 제공하긴 어렵단 점을 깨달았습니다. 작은 집단에서부터 성공해야겠다 생각했고, 현재 속한 집단 내에서부터 공동구매를 활성화하기 위해 끊임없이 도전했습니다.
앱에 대한 애정 속에 직접 물건도 팔아보고, 이벤트나 광고도 해보며 커머스/광고 도메인에 대한 관심이 커졌습니다. 그 과정속에 자연스레 앱이 폭발적으로 확장하는 걸 기대하며 클린 아키텍처나 고가용성에 대한 관심도 키워나갈 수 있었습니다.
▷ 협업 진행 방법
백엔드(3인), 안드로이드(3인) 총 6인이 매일 코어 타임을 정하고 대면으로 진행했습니다.
▷ 사용 기술
Java, Spring, SpringData / MySQL / AWS EC2, S3, CloudFront, RDS, CloudWatch, ELB / Docker / GithubActions
▷ 프로젝트 내 나의 파트 : 백엔드
•
인증 인터셉터 구현 → 관련PR
관련PR•
공동구매 참여 유저 관리 로직을 도메인으로 분리하며 클린 아키텍처 도입 → 관련PR
관련PR•
DB 초기화 고려한 통합 테스트 환경 세팅 → 관련PR
관련PR•
RestDocs 기반 OAS 추출 및 Swagger 렌더링 → 관련PR
관련PR•
AOP 기반 읽기/쓰기용 dataSource 분리 → 관련PR
관련PR•
로깅 프레임워크 적용 및 모니터링 대시보드 구성 → 관련PR
관련PR•
가용성 고려해 인프라 아키텍처 개선
기술적 고민
▷ 고민 1 : 데이터베이스 주도 설계 탈피할 방법 없을까? (feat. 클린 아키텍처)
[문제 분석]
초기 개발 시, 익숙한 Controller, Service, Repository, Entity 구조로 진행했습니다. Entity는 JpaEntity와 DB 테이블이자 도메인 역할을 했으며, 점점 Service와 Entity가 비대해졌습니다. 테이블을 분리하려고 하자 코드 전반에 영향을 미치는 문제가 있었습니다.
[해결 과정]
먼저, JpaEntity에서 Domain을 반환하는 방식으로 리팩토링하여 도메인 로직은 다른 레이어에 의존하지 않게 만들었지만, 여전히 Service는 JpaRepository에 의존했습니다. 그러던 중 클린 아키텍처를 알게 되었고, 매료되었습니다. 우리 팀이 마주한 문제를 “데이터베이스는 세부사항이다!" 란 말로 명료하게 설명했고, 해결책에 대한 아이디어도 제시했기 때문입니다.
유튜브에 올라온 외국인 영상들까지 클린 아키텍처에 관한 내용이라면 전부 찾아볼 정도로 매료되었고, “클린 아키텍처는 따라야할 스타일이 아니라, 지향해야 할 규칙이다”라는 개인적인 철학도 정립할 수 있었습니다. 그 과정 중에 항상 모호하다 느꼈던 의존성 역전 원칙과 단일 책임 원칙에 대해서도 명확히 이해할 수 있었습니다.
팀원들을 설득하기에 앞서, 클린 아키텍처의 규칙에 기반해 팀의 데이터베이스에 의존적인 코드를 리팩토링할 방법을 먼저 정리했습니다. 팀원들 뿐만 아니라 최대한 많은 개발자에게 이를 공유하고 싶은 욕구가 생겨, 우아한테크코스 내에서 자체적으로 발표 세션을 따로 열어 “클린 아키텍처에서 코드 품질 향상의 근거 찾기”라는 주제로 발표를 진행했습니다.
발표 이후, 팀원들의 동의 하에 팀의 기존 아키텍처에 “소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다”라는 클린 아키텍처의 대전제를 적용해 리팩토링했습니다. 이를 통해 데이터베이스 변경이 핵심 모듈에 영향을 주지 않도록 구조를 개선했고, 이후 알림이나 소셜 로그인 등 다른 세부사항들이 변경될 때도 영향을 최소화할 수 있었습니다.
▷ 고민 2 : 공동구매 서비스 특성을 고려해 높은 트래픽과 가용성을 충족할 방법 없을까?
[문제 분석]
총대마켓 팀은 공동구매 유저 유치를 위해 선착순 할인 이벤트, 페이백 이벤트 등 다양한 프로모션을 기획했습니다. 현재는 하나의 커뮤니티 내에서 운영되어 유저 수가 20~30명 남짓으로 큰 문제는 없지만, 이후 전국적으로 서비스를 확장할 때에도 안정적인 서비스를 제공하고 싶은 욕구가 생겼습니다.
기존엔 “Nginx Tomcat(WAS) MySQL(DBMS)” 꼴의 구조였습니다. WAS가 단일 인스턴스로 운영되었기 때문에 OOM, 디스크 용량 초과 등으로 인해 의도치 않은 장애가 발생한 이력이 있었습니다. 또한 DBMS 역시 부하가 커지거나 디스크 용량이 커질 때 장애가 발생할 가능성이 큰 상황이었습니다.
Tomcat(WAS) MySQL(DBMS)” 꼴의 구조였습니다. WAS가 단일 인스턴스로 운영되었기 때문에 OOM, 디스크 용량 초과 등으로 인해 의도치 않은 장애가 발생한 이력이 있었습니다. 또한 DBMS 역시 부하가 커지거나 디스크 용량이 커질 때 장애가 발생할 가능성이 큰 상황이었습니다. [해결 과정]
SPOF를 최소화하고 가용성 측면에서 인프라 아키텍처를 개선하기로 했습니다. 우선, WAS는 서로 다른 AZ에 하나씩 배치하고, 그 앞단에 ELB를 두어 요청을 분산 처리하기로 했습니다. 이 과정에서, 기존에 Nginx가 담당하던 프록시 패스 역할을 ELB가 대신 수행하면서 Nginx는 자연스럽게 구조에서 제외되었습니다. WAS 서버가 여러 대로 늘어나면서 자연스레 무중단 배포에 대한 욕구도 생겼고, 처음엔 단순하게 직렬로 배포하는 방식으로 무중단 배포를 표방했다가, 점차 블루 그린 방식을 섞어 온전한 무중단 배포를 달성했습니다.
다음으로 DBMS는 가용성을 높이기 위해 replication을 적용하기로 했습니다. replication을 통해 writer db와 reader db를 분리함으로써, 가용성을 높였고 write 보다 많은 read 요청을 유연하게 처리할 수 있게 되었습니다.
결론적으로 단일 장애 발생 지점을 고려해 고가용성의 확장 가능한 시스템 설계를 경험한 좋은 문제 해결 과정이었습니다. 그 과정에서 VPC 내 프라이빗 서브넷과 퍼블릿 서브넷을 구분해 보안성까지 함께 강화할 수 있었습니다.
•
변경 전
•
변경 후
.svg&blockId=11bb1a37-2b95-8055-ade3-f6e4de49a7ad)
▷ 그 외 고민
•
JAR 파일에 OAS 파일이 누락되는 문제 어떻게 해결할까? → 관련포스팅
관련포스팅•
기획적 고민
▷ 고민 1 : 어떻게 해야 공동구매 참여자 간 분쟁을 해결할 수 있을까? (feat. CS)
[문제 분석]
지역 기반 공동구매 서비스를 설계하면서 가장 큰 문제로 예상된 부분은 노쇼 관리였습니다. 이에 대해 실제로 유사한 서비스를 제공했던 회사의 테크 리드분과 이야기를 나눴습니다. 해당 회사에선 작은 지역에서 시범 운영했을 때도 노쇼 문제가 빈번하게 발생해, 이를 전국적으로 확장하면 CS 관리가 불가능할 것이라 판단해 사업을 철수했단 이야기를 전해 들을 수 있었습니다.
[해결 과정]
중간 개입자 없이 익명성이 보장되지 않은 N명이 물건을 나누며 노쇼가 발생하지 않는 것은 이상적이라는 점을 깨달았습니다. 이에 따라, 동일한 커뮤니티(회사, 학교 등)를 우선 타겟팅하기로 했습니다. 노쇼를 최소화한 상태에서 C2C 공동구매 서비스를 검증하는 것이 중요하다고 판단했기 때문입니다. 커뮤니티 내에서 공동구매가 활발히 진행된다면, 이후 중간 개입자를 도입하는 방향으로 확장하기로 했습니다. 이를 위해 우리가 속한 우아한테크코스에서 공동구매라는 새로운 도메인을 제공하기 시작했습니다.
▷ 고민 2 : 어떻게 해야 공동구매 참여자를 모을 수 있을까? (feat. 장사 재밌네..?)
[문제 분석]
공동구매에 대한 수요를 조사하기 위해 앱 런칭 전 145명이 속한 우아한테크코스 슬랙 채널에서 총 10회에 걸쳐 공동구매를 진행했습니다. 이때 가격과 물건 정보가 불분명하게 인지되는 공동구매는 실패하는 걸 확인해, A/B 테스트를 통해 가격과 물건 정보가 확실하게 인지되는 UI를 만들었습니다. 앱이 런칭되고 효과적인 UI만으론 유저를 모을 수 없고, 결국엔 이벤트와 광고가 필요하단 점을 깨달았습니다.
[해결 과정]
앱 다운로드를 처음부터 기대하기보단, 일단 유저를 최대한 늘리고자 별도의 채널을 열고 주문을 받는 것부터 시작했습니다. 2주라는 한정된 기간동안 첫 3일은 참여자 유치에 힘 썼고, 남은 일수동안엔 총대 유치에 힘썼습니다. 선착순 할인 이벤트와 추천인 이벤트를 열어 3일이란 단기간에 채널 유저를 30명 이상 유치했습니다.
성공한 거래를 10건 이상 확보한 후엔 총대 유치에 힘썼습니다. 거래 성공 시 최대 3000원을 페이백 해주는 이벤트를 진행했고 총대 10명을 모으는 데 성공했습니다. 이는 현재 진행형으로 총대들의 거래 결과는 아직 나오지 않은 상태입니다. 총대들의 거래 결과까지 수합된다면 CS 발생률을 계산하고 서비스의 지속 가능성을 검증할 수 있으리라 기대합니다.
