2차 데모데이 회고

 

기획을 주로 했던 1차 데모데이가 끝나고 2차 데모데이를 준비하기 위해 개발을 시작하게 되었다.
 
개발을 시작하기 전에 해야 할 일들이 많았다. 
테이블 설계, 엔티티 설계, 구현할 기능들에 대한 API 명세 정하기를 해야 했는데.. 2차 스프린트 일정을 맞추기 위해 백엔드는 2차 스프린트 첫 주는 9시까지 출근해서 1시간 동안 해야 할 일을 했고 그래서 일정을 맞출 수 있었다.

기획의 빈 구멍을 채우자

기획은 충분히 했다고 생각했는데도 실제로 기능을 구현하고 테이블을 설계하려다보니 기획을 수정해야 할 필요성을 느꼈다. 특히 유효기간을 설정하고, 바꿀 수 있는 기능에 대해서 이런저런 의견들이 많이 오고 갔었다. 
우리는 서비스의 고객인 사장님에게 선택권을 많이 주기 위해서 유효기간을 쿠폰 혹은 스탬프에 설정할 수 있게 만들고 심지어 유효기간 정책을 변경할 수 있는 기능도 기획했었다. 하지만 기능을 실제로 구현하려다보니 너무 생각해야 할 사항이 많아 복잡도가 크고, 예외 케이스들도 많다는 사실을 깨달았다. 그래서 유효기간을 쿠폰/스탬프 중 하나에만 설정할 수 있게 기획을 바꾸는 것에 모두가 동의하였지만 정책을 변경했을 때 소급 적용 관련해서 의견이 통일이 안되는 일이 발생했다. 그래서 담당 코치인 토미에게 의견을 물었고 아주 좋은 피드백을 들었다. 우리 서비스의 핵심가치를 우선으로 생각하면 됐던 거였다. 우리 서비스는 종이쿠폰의 감성을 유지하면서도, 카페의 개성을 살린 쿠폰을 제작할 수 있게 하여 사장님이 마케팅 도구로 유용하게 활용할 수 있는 서비스를 제공하려고 했던 것이다. 사장님이 유효기간 정책을 쿠폰 기준으로 설정할지, 스탬프 기준으로 설정할지는 정말 부가적인 부분이었다. 이런 정책의 복잡성이 중요한게 아니라 어떻게 쿠폰을 예쁘게 만들지, 스탬프를 커스터마이징할 것인지, 어떻게 이 서비스를 통해서 고객을 끌어올 것인지가 중요했던 것이다. 그래서 현실 종이쿠폰을 그대로 서비스에 옮겨오는 방향으로 기획을 수정했다. 

 
우리 팀에서 최종으로 결정된 유효기간 정책이다.

쿠폰에만 유효기간을 설정할 수 있게 하고, 정책이 변경되더라도 그 이전에 발행된 쿠폰은 그때의 정책을 지켜야 한다
(정책이 바뀐 후 이전의 쿠폰을 가진 고객은 새로운 쿠폰에 스탬프를 찍을지, 가지고 있는 쿠폰에 스탬프를 찍을지 결정 가능하다)

이렇게 유효기간 정책말고도 자잘한 논의들이 있을 때 우리 서비스의 핵심 가치인 부분인지를 기준으로 생각하면 지금 해야 할 일인지, 아니면 나중으로 우선순위를 미뤄도 되는지 판단이 가능했다. 그래서 1차 데모데이 때 고객의 페인포인트를 잘 정하고 그 페인포인트에 진통제가 될 핵심 가치를 명확히 정하는 것을 그렇게 중요시했던 거 같다.

개발 시작! (테이블 설계/ API 명세 작성)

테이블 설계 관련해서도 많은 논의가 있었다. 우리가 2차 데모데이때 구현할 기능들을 정할땐 백엔드는 개발 관련해서 아무것도 결정한 것이 없었다. 그래서 그때 와이어프레임 기반으로 3등분해서 이정도면 되겠지 하고 구현할 기능들을 정했었는데 그게 살짝 실수였었다. 만드려는 기능들을 위해서 어떤 테이블들이 필요한가 살펴봤을 때 도메인에 존재하는 모든 테이블이 필요했었고, 결론적으로 봤을 때 2차 데모데이때 구현한 기능들은 모든 테이블에 CRUD 중 C 대부분과 R 약간을 뚫어두는(?) 기능들이었다. 
우리 서비스의 도메인은 Cafe, Coupon 을 중심에 두고 서로 얽혀있는 부분들이 많아서 설계 관련해서 논의도 많이 했었고 지금 상황에서는 이게 최선이다! 라는 결론을 가진 테이블을 설계했었다 (사실 나는 그동안 테이블 설계할때 많은 생각을 하지 않았어서 이번에 의견을 많이 못냈다. 깃짱 레오 하디가 양질의 의견을 많이 내줘서 그동안 해보지 않았던 고민들을 할 수 있어서 좋았다. ) 테이블 설계 관련해서는 따로 글을 작성할 예정이다. 
 
테이블 설계를 완료하고 나서 프론트엔드와 함께 API 명세를 작성했다. 테이블 설계하면서 기획의 빈 구멍들을 많이 채웠다고 생각했는데 API 명세를 작성하다보니 기획에 빈 부분들이 또 많이 보였다. API 명세를 작성할 때는 고객이 이 서비스를 사용할 때의 흐름을 생각하는 것이 중요한 거 같다. 우리 서비스가 전화번호를 입력해서 고객을 조회하고 -> 고객이 없으면 임시 가입 유저 생성/ 고객이 있으면 고객의 쿠폰 조회 -> 리워드 사용/ 스탬프 적립 등으로 분기가 나눠지고 그에 따라 다른 API 호출이 되야 해서 정리가 안되는 상황이 있었는데 하디가 그 흐름을 화이트보드에 잘 정리해줘서 API 명세도 생각보다 빨리 작성할 수 있었다. 
 
이렇게 테이블 설계, 엔티티 생성, API 명세 작성을 하다보니 한 주가 가버렸다. 기능 개발은 하지도 못해서 백엔드 4인이 우리 서비스의 핵심 기능인 쿠폰 생성과 스탬프 적립을 제외한 나머지 기능을 각각 2개씩 맡아서 주말간 구현을 했었다.
 
그리고 2차 데모데이 2주차에는 주말간 구현한 코드를 서로 리뷰하면서 리팩터링하고 코드를 합치는 시간을 가졌다. 또 권장 요구사항이던 CI/CD 를 설정하고 개발 서버에 배포를 진행해야 했다. 시간이 부족해서 2팀으로 나뉘어서 핵심 기능(쿠폰 생성, 스탬프 적립)을 구현하는 팀, CI/CD 를 설정하는 팀으로 나눠서 스프린트를 진행했다.

인프라 구성과 자동 배포 설정

나는 CI/CD 를 설정하였는데 젠킨스를 이용해서 develop 브랜치에 푸시가 일어났을 때 빌드를 하고 개발 서버로 .jar 파일을 이동시키고 실행시키는 파이프라인을 구성하였다 (지금은 Test stage 를 젠킨스에서 제거하였고 Test 는 develop 브랜치에 푸시되기 전 풀리퀘스트 이벤트가 일어날때 github action workflows 로 돌아가게끔 설정을 바꾸었다)

또 개발 서버 하나에 프론트, 백엔드 어플리케이션을 함께 돌려야 했고 외부로 뚫려있는 포트는 80번 포트밖에 없는 상황이어서 NGINX 를 이용해서 로케이션 패턴 매칭을 통해 /api prefix 가 달려있는 요청은 8080 포트로, 그렇지 않으면 3000 포트로 요청이 전달되게끔 리버스 프록시 설정을 해두었다.

마무리

다시 돌아보니 2차 데모데이 때 진행한 일들이 정말 많았던 듯 싶다.
2차 데모데이 발표는 나와 윤생이 하였는데 긴장이 많이 됐지만 나름대로 잘 마무리 할 수 있고 피드백도 나쁘지 않았다.
우리가 한 방식이 애자일이 아니라 워터폴이었다는 사실을 깨달았다ㅎㅎ 사장님이 서비스의 주 고객이다 보니 고객 모드보다 사장 모드를 먼저 개발했는데 그래서 프로그램이 한 사이클이 돌아가지는 못했었다. (여기서 한 사이클이란 '사장님이 쿠폰 발급과 스탬프 적립을 해주고 고객은 고객모드에서 자신의 쿠폰 리스트를 확인할 수 있다' 를 뜻한다, 실제 사용을 확인할 수 있는 플로우) 
카페 정책의 많은 부분(유효기간, 리워드 설정, 최대 스탬프 개수 설정 등) 을 한번에 다 구현하고 넘어가기 보다는 하나 정도만 구현하고 고객 모드를 개발해서 한 사이클이 돌아가는 걸 확인을 하고, 카페 정책을 하나하나 추가하면서 사이클을 계속 돌려가면서 구현하는 방식이 애자일이었다. 그래서 3차 데모데이 때는 한 사이클을 돌아가게끔 하는 것을 목적으로 구현할 기능을 정하고 2차 데모데이를 마무리할 수 있었다.