안녕하세요! 트랜잭션서비스개발팀 주문결제 스쿼드의 따끈따끈한 입사자 써니입니다!
지난 1분기, 올리브영 주문결제 시스템은 급변하는 고객 요구와 복잡한 운영 이슈 속에서 분주한 시간을 보냈습니다.
간편 결제 연동, 장바구니 로직 최적화 등 굵직한 프로젝트들을 성공적으로 완수했지만, 스쿼드 내부적으로는 '휴먼 에러'로 인한 잦은 장애와 개선되지 않는 스쿼드 문화라는 고민을 안고 있었습니다.
특히 도메인 규모가 크고 복잡한 주문결제 영역 특성상, 스쿼드원들이 각자의 업무에만 몰입하기 쉬웠고, 그 과정에서 코드 리뷰가 형식적이 되거나, 사소한 실수가 큰 장애로 이어지는 경우가 종종 발생했습니다. 바쁜 일정 속에서 스쿼드원들의 피로도는 누적되었고, 단순히 '회상'에 그치는 기존의 회고 방식으로는 이러한 근본적인 문제들을 해결하기 어렵다는 것을 깨달았습니다.
올리브영 주문결제 스쿼드, KPT를 만나다
우리는 이 문제들을 직시하고, 지속 가능한 성장을 위한 해결책을 모색했습니다. 단순히 '회상'에 그치는 회고가 아닌, 구체적인 실행 과제를 도출하는 강력한 도구가 필요했죠.
그 해답으로 우리는 KPT(Keep, Problem, Try) 회고를 선택했습니다.
KPT는 'Keep(지속할 점)', 'Problem(개선할 점)', 'Try(시도할 점)'이라는 단순한 3단계 구조를 가집니다. 이 패턴은 복잡한 도메인 속에서 스쿼드의 경험을 명확히 정리하고, 히스토리 기반의 인사이트를 담아 실질적인 개선으로 이어지게 합니다.
우리 스쿼드는 '더 빠르게, 더 안전하게, 더 편리하게'라는 명확한 비전을 바탕으로, 회고를 진행하기전 다음과 같은 4가지 원칙을 도입해 보았습니다.
1. 회고 주제 사전 공유: 깊이 있는 논의를 준비하기:
회고 3일 전, 스쿼드원들에게 가볍게 생각해볼 수 있는 질문을 미리 공유하여 깊이 있는 논의를 유도했습니다. 이는 각자가 지난 분기를 충분히 돌아볼 시간을 제공하여, 회고 당일 더욱 풍성한 인사이트가 나올 수 있는 기반을 마련했습니다.
2. 시니어-주니어 페어링 디스커션: 침묵을 깨고 핵심 문제 파고들기
단순히 의견을 모으는 것을 넘어, 우리는 시니어와 주니어 개발자가 한 팀을 이루어 주문결제 고객 여정 속 숨어있는 문제점을 각자의 시각에서 정의하고 끈질기게 고민하는 디스커션 세션을 진행했습니다. 초기에는 주니어 개발자들이 시니어 앞에서 의견을 내는 것을 부담스러워하는 경향이 있었습니다.
이러한 장벽을 해소하기 위해, 우리는 '답을 찾는 것보다 질문을 던지는 것이 중요하다'는 원칙을 강조하고, 모든 의견이 존중받는다는 분위기를 조성하는 데 집중했습니다. 예를 들어, 한 주니어 개발자는 "레거시 코드 때문에 신기능 구현에 항상 시간이 더 걸린다"는 문제를 제기했고, 이에 시니어 개발자는 해당 레거시 코드가 과거 어떤 배경으로 만들어졌는지 설명하며 함께 개선 방안을 모색하는 의미 있는 대화가 오고 갔습니다. 이는 주니어의 시각에서 놓칠 수 있는 문제점을 발굴하고, 시니어의 경험으로 현실적인 해결책을 찾는 시너지로 이어졌습니다.
3. 타임 박싱으로 효율 높이기: 핵심에 집중하는 기술
주제별 발표와 논의 시간을 엄격하게 제한하는 타임 박싱을 적용해 회고의 효율성을 극대화했습니다. 초기에는 시간을 초과하는 경우가 잦았지만, 퍼실리테이터의 능숙한 개입과 스쿼드원들의 적극적인 참여로 점차 핵심에 집중하는 문화가 정착될 수 있었습니다. 이 덕분에 우리는 불필요한 논쟁을 줄이고, 가장 중요한 문제와 해결책에 대한 깊이 있는 토론에 집중할 수 있었습니다.
4. "이번 분기엔 이것 하나만!" 집중할 항목 선정: 모두의 실행력을 높이는 전략
KPT 회고를 통해 개선할 점(Problem)은 항상 많았지만, 모든 것을 한 번에 해결하려는 욕심은 오히려 스쿼드의 실행력을 저해한다는 것을 경험했습니다. 그래서 우리는 이번 분기엔 가장 임팩트 있는 것 하나만! 이라는 원칙을 세웠습니다.
예를 들어, 지난 회고에서는 장바구니/주문 영역의 복잡한 로직으로 인한 로딩 시간 증대 및 DB 커넥션풀 과다 사용 문제가 큰 'Problem'으로 지목되었습니다. 처음에는 '전면적인 시스템 개편'과 같은 큰 목표가 나왔지만, 이를 쪼개어 가장 시급하고 파급력이 큰 장바구니 캐싱 도입을 첫 번째 'Try' 항목으로 선정했습니다.
KPT 회고로 얻은 놀라운 변화들
우리는 앞으로 무엇을 해야하는가? 어떻게 달성할수 있는가?
이번 1분기 회고 워크숍에서는 이전의 워크숍과는 달리 조금 특별한 시도를 도입했습니다.
시니어와 주니어 개발자가 한 팀을 이루어, 주문결제 고객 여정 속 숨어있는 문제점을 각자의 시각에서 정의하고,
- 무엇이 문제인지 (What)
- 왜 그것이 문제인지 (Why)
- 어떻게 해결할 수 있을지 (How)
함께 끈질기게 고민하는 디스커션 세션을 진행했습니다.
이렇게 머리를 맞대어 도출된 소중한 액션 아이템들은 다음 분기 실행의 밑거름이 되었고, 실제로 2분기에는 눈에 보이는 변화로 이어졌습니다.
🌟 KPT 회고로 얻은 놀라운 변화들 🌟
🛠 코드 품질
Problem: '휴먼 에러'로 인한 인시던트 발생
Try: PR 템플릿 정의 및 코드 리뷰 활성화
Result: 코드리뷰 퀄리티 향상 → 코드 이해도 증대 및 실수 감소
🤝 스쿼드 문화
Problem: 과중한 업무로 인한 피로 누적 및 소통 부재
Try: 데일리스크럼 문화 정착
Result: 업무 가시성 증대 & 협업 만족도 상승
💳 서비스 경험
Problem: 결제 직전 복잡한 코드로 쿼리 과다 호출/에러 증가
Try: 장바구니/주문 영역 전면 개편 논의 및 초기 개선
Result: 장바구니 캐싱 도입으로 DB 부하 감소
PR 템플릿의 도입
저번 분기에는 '휴먼 에러'로 인한 인시던트가 발생했습니다. 코드 리뷰를 진행했음에도, 핵심 변경 사항이 명확하게 공유되지 않아 문제가 발생했습니다. 따라서 '코드 리뷰를 열심히 하자'는 의지뿐만 아니라, 체계적인 PR 템플릿을 정의하여 코드 리뷰를 더 쉽고 효과적으로 만들자는 방안을 논의했습니다.
새로운 PR 템플릿은 코드 리뷰의 비효율을 해결하기 위해 다음과 같은 필수 항목들을 담았습니다.
## 작업명 / JIRA
[CJOYPG-0000] 결제 실패 시 재시도가 안 되는 버그 수정
## 변경 요약 (1~3줄)
- 실패 시 즉시 종료 → 최대 3회 재시도 후 실패 처리 로직으로 변경
## 영향 범위 ⚠️
- 결제 로직의 실패 부분 (OrderServiceImpl A메서드)
- 주문 상태 변경 로직
## 리뷰어가 꼭 봐야 할 부분 👀 (선택)
- PaymentRetryHandler.java 45-47 라인: 재시도 로직
- 레거시 호환을 위해 A방법 대신 B방법 사용
## 특이사항 (선택)
- 공통코드 ORD032에 88 추가
[파일 10개 이상 또는 ±400라인 이상 변경 시]
- 상세 설명
- 로직 설명 또는 관련 문서 링크
- 플로우차트나 다이어그램 링크
이 템플릿은 리뷰어가 변경 사항의 의도를 빠르게 파악하고, 영향 범위를 정확히 예측하며, 중요하게 검토할 지점을 놓치지 않도록 도왔습니다. 특히 '리뷰어가 꼭 봐야 할 부분' 항목은 핵심 로직에 대한 집중적인 검토를 유도하여, 과거에 놓쳤던 잠재적 버그나 비효율적인 코드를 사전에 발견하는 데 결정적인 역할을 했습니다.
PR 템플릿 도입 후 코드 리뷰의 퀄리티가 눈에 띄게 좋아졌습니다. 핵심 변경 사항에 대한 이해도가 증대되었고, 이번 분기에는 휴먼에러의 90% 이상이 배포 전 조기 발견되는 성과를 이루었습니다.
데일리 스크럼 문화 정착
그러나 PR 템플릿만으로 모든 문제가 해결되지는 않았습니다. 바쁜 일정 속에서 스쿼드원들의 피로도가 누적되고, 서로의 업무 상황을 파악하기 어려워 소통이 부족해지는 문제가 있었습니다. 우리는 '서로 잘 도와줄 수 있는 환경을 만들자'는 목표 아래, Slack 내에 데일리 스크럼 봇을 도입하여 매일 아침 간단하게 업무 진행 상황을 공유하는 문화를 정착시켰습니다.
도입 이후 업무의 가시성이 크게 향상되었고, 여러 커뮤니케이션을 하나의 스레드에서 통합 관리하면서 협업 비용이 줄었습니다. 서로의 업무를 더 잘 이해하게 되면서 문제 발생 시 빠르게 해결책을 찾고 부담을 나눌 수 있게 되었습니다. 중간 점검 설문에서도 전원 긍정적인 평가를 주었고, 이후 데일리 스크럼은 스쿼드의 자연스러운 문화로 자리잡았습니다.
장바구니 캐싱 도입
PR 템플릿과 데일리 스크럼을 통해 협업 방식은 개선되었지만, 기술적인 문제 역시 남아 있었습니다. 장바구니/주문 영역의 복잡한 로직으로 인해 로딩 시간 증가와 DB 커넥션 풀 과다 사용 문제가 심각했기 때문입니다. 전면 개편 논의 끝에, 가장 시급하고 효과가 큰 첫 단계로 장바구니 캐싱을 도입했습니다.
그 결과 장바구니 조회 쿼리 사용량이 54% 이상 감소하며 성능 개선 효과를 입증했습니다. 특히 9월 세일 기간에도 DB 커넥션풀 부하가 완화되어 안정적인 운영이 가능했습니다.
마무리: 3개월 후, 우리가 깨달은 것들
KPT 회고를 시작하기 전엔 "회고에 시간만 낭비하는 건 아닐까?", "바쁜데 또 하나의 루틴만 추가되는 건 아닐까?" 하고 걱정했던 게 사실입니다. 하지만 3개월을 돌아보니 예상보다 훨씬 실용적이고 의미 있는 변화들이 많았다는 것을 깨달았습니다. 가장 크게 느낀 변화는 다음과 같습니다.
장애 대응 시간이 확실히 줄었습니다. 새로 도입한 PR 템플릿 덕분에 코드 리뷰가 꼼꼼해지면서 배포 전 휴먼 에러의 90% 이상을 조기에 잡아내는 경우가 늘었습니다. 결과적으로 쿼리 과다 호출로 인한 DB 부하도 54% 이상 감소하면서 안정적인 서비스 운영에 큰 도움이 되었습니다.
"이거 누가 알고 있지?"라는 말이 줄어들었습니다. Slack 데일리 스크럼 봇 덕분에 스쿼드원 각자가 어떤 업무를 진행하고 있는지 명확히 알게 되면서, 업무의 투명성과 가시성이 크게 향상되었습니다.
주니어 개발자인 저의 입장에서도, 질문을 어떻게/누구에게 해야 할지에 대한 고민이 줄고 질문이 쉬워졌습니다. 시니어-주니어 페어링 디스커션 이후로 서로에 대한 이해가 깊어지고 신뢰가 쌓이면서 자연스럽게 소통이 활발해진 것 같습니다. 이는 스쿼드 전체의 코드 이해도 증대로 이어지는 선순환을 만들었습니다.
물론, 아직 완벽하지 않습니다. 바쁠 때는 여전히 코드 리뷰가 충분히 깊지 못하게 넘어갈 때도 있고, 회고에서 정한 액션 아이템을 미처 실행하지 못하고 다음 분기로 미루는 경우도 있습니다. 하지만 가장 중요한 건, 우리가 과거에는 단순히 '불편함'에 적응하고 있었던 문제들에 대해, 이제는 "이 불편함을 어떻게 해소할 수 있을까?"라는 질문을 던지게 되었다는 점입니다. 이것이 KPT 회고가 올리브영 주문결제 스쿼드에 가져다준 가장 크고 본질적인 변화라고 생각합니다. 앞으로도 완벽한 스쿼드가 되려는 욕심보다는, 조금씩이라도 함께 나아지려는 스쿼드가 되고 싶습니다.
이번 회고를 통해 얻은 실행력을 바탕으로, 앞으로도 스쿼드원 모두가 문제의 원인을 함께 찾고 해결하는 문화를 더욱 공고히 하며 진화해 나갈 예정입니다.
앞으로도 주문결제 여정을 더 빠르게, 더 안정적으로, 더 편리하게 만들어가겠습니다. 읽어주셔서 감사합니다! 🚀