레벨 3가 끝나고 잠깐의 방학까지 지나니 어느새 마지막 레벨인 레벨 4가 시작됐다.
레벨 4는 새 프로젝트를 시작하는 과정이 아니었다. 레벨 3에서 검증한 사용자 문제와 fit을 바탕으로, 같은 제품을 네 번의 2주 스프린트 동안 계속 고도화하는 과정이었다.
매 스프린트마다 기술 요구사항 하나, 제품 가설 사이클 하나, 소프트스킬 활동 하나를 수행한다. 그리고 데모데이에서 동작하는 제품, 가설과 결과, 기술 적용 전후의 변화, 다음 스프린트 계획을 보여준다.
한마디로 제품 고도화와 실제 서비스 운영, 팀 협업을 한꺼번에 경험하는 레벨이었다.
1. 스프린트 준비 기간
준비 주간의 목표는 기능을 많이 만드는 것이 아니었다. 레벨 3에서 무엇을 확인했는지, 지금 제품·기술·협업의 상태는 어떤지 돌아보고 레벨 4의 방향과 스프린트 1의 우선순위를 정하는 시간이었다.
우리 팀은 담당 코치인 검프와 이야기를 나눈 뒤 아래와 같은 흐름을 반복하기로 했다.
최소 기능으로 빠르게 배포 → 직접 사용 → 문제와 불편 발견 → 필요한 기능과 기술 적용 → 개선
처음부터 필요한 기능을 전부 상상해서 만드는 대신, 우리가 먼저 DAYNOMY를 사용하면서 불편을 발견하고 개선해 나가자는 방향이었다. 스프린트 1에서도 별도의 기능 확장을 고민하기보다, 핵심 가치가 잘 드러나는 퓨어한 상태를 완성하는 데 집중하기로 했다.
협업 방식도 함께 손봤다. 기존 데일리 스크럼과 회고에서는 진행 상황을 짧게 맞추고, 매주 목요일에는 각자 한 일을 깊게 공유하는 시간을 따로 갖기로 했다.
| 시간 | 무엇을 공유하나 | 깊이 |
|---|---|---|
| 데일리 스크럼 | 어제 한 일, 오늘 할 일, 막힌 점 | 빠르고 간단하게 |
| 회고 | 좋았던 점, 아쉬웠던 점, 다음에 바꿀 점 | 짧게 돌아보기 |
| 목요일 공유 | 왜 이렇게 구현했는지, 어떤 선택지를 버렸는지, 문제를 어떻게 풀었는지 | 제대로 깊게 |
단순히 무엇을 했는지만 말하는 데서 끝내지 않고, 왜 그렇게 구현했는지와 어떤 문제가 있었는지까지 공유하는 시간이었다.
2. 스프린트 1 본격 시작
레벨 4부터 한 스프린트는 2주다. 다만 첫 주에 추석 연휴가 있어 실제로 일할 수 있는 날은 더 짧았다.
이번 스프린트에서 해야 할 일은 크게 세 가지였다.
| 요구사항 | 스프린트 1에서 한 일 |
|---|---|
| 제품 | 가설·실험·관측·결론을 갖춘 사이클과 유저 데이터 리포트 만들기 |
| 기술 | Dev/Prod 환경에서 로그·메트릭·알림을 관찰하고 실제 장애 한 건 기록하기 |
| 소프트스킬 | 레벨 4 그라운드 룰을 만들고 이번 스프린트에 지켜볼 약속 정하기 |
제품 쪽에서는 DAYNOMY의 핵심을 다시 한 문장으로 정리했다.
경제 이슈가 내 포트폴리오에 미치는 영향을 확인할 수 있는 서비스
투자 중이지만 경제 이슈와 내 자산의 관계를 해석하기 어려운 사용자를 대상으로, 10명 중 6명 이상이 실제 사용 후 “영향을 이해하는 데 도움이 됐다”고 답하는지를 확인하기로 했다. 다만 레벨 4의 제품 요구사항은 계획을 세우는 데서 끝나지 않는다. 실제 관측 결과와 결론, 활성 사용자와 리텐션 같은 유저 데이터까지 이어져야 한 사이클이 완성된다.
구체적인 가설과 실험 설계는 캡처로 대신한다.
프론트엔드
포트폴리오 대시보드와 분석 화면을 개선하고, 뉴스 목록과 검색 UI를 다듬었다.
백엔드·인프라
Dev와 Prod 환경을 분리하고, 각 환경에 맞는 CI/CD 파이프라인을 구성했다. AWS SSM을 적용하고 CloudWatch에서 로그와 메트릭을 확인할 수 있도록 했으며, 장애 조건이 발생하면 SNS를 통해 팀에 알림이 도착하도록 만들었다.
제품·협업
제품 가설과 실험 방법, 성공 기준을 노션에 정리했다. 레벨 4 그라운드 룰을 만들고, 데일리 스크럼과 회고에서는 진행 상황을 짧게 공유하되 목요일에는 각자의 작업을 깊게 설명하기로 했다.
기술 요구사항의 주제는 운영 관찰과 대응이었다. 로그·메트릭·알림이 Dev와 Prod 양쪽에서 동작해야 했고, 각각의 배포 파이프라인도 필요했다. 여기에 실제로 겪은 장애나 성능 문제 한 건의 원인과 조치까지 기록해야 했다.
우리는 dev 브랜치는 개발 환경에, main 브랜치는 운영 환경에 배포되도록 나눴다. EC2 상태와 애플리케이션 로그를 관찰하고 장애 조건이 발생하면 팀 메일로 알림을 받을 수 있게 했다.
자세한 구성은 아래 노션 캡처에 양보한다. 본문에 다 적기 시작하면 갑자기 AWS 기술 블로그가 되기 때문이다.
3. 스프린트 1 데모데이 준비
데모데이는 완성된 화면만 자랑하는 자리가 아니었다. 2주 동안 실제로 달라진 제품, 가설과 관측 결과, 기술 요구사항을 적용한 이유와 변화, 다음 스프린트 계획까지 보여주는 자리였다.
별도의 발표 슬라이드는 만들지 않았다. 대신 스프린트 동안 제품·기술 요구사항을 노션에 정리했고, 그 기록과 배포된 서비스를 바탕으로 발표 흐름을 준비했다. 데모데이에서는 발표자가 아닌 팀원에게도 질문할 수 있어, 누구나 팀의 결정과 근거를 설명할 수 있어야 했다.
우리는 사용자가 포트폴리오를 등록하고 관련 경제 이슈를 확인한 뒤, 그 이슈가 내 자산에 왜 긍정적이거나 부정적인 영향을 주는지 보여주는 흐름을 준비했다.
그리고 데모데이 직전 새벽 2시, 개발 서버에 CI/CD를 돌렸다가 실패했다.
새벽 2시에 배포 버튼을 누르면 실패할 수 있다.
새벽 2시에 배포 버튼을 누른 우리:
왜 실패하지? 정말 알 수 없는 일이다
진짜 너무 졸린 와중에 우리를 반겨준 빨간 X…
원인은 생각보다 단순했다.
AWS 콘솔: EBS 8GB → 20GB 확장 완료
EC2 내부: 저는 아직 8GB인데요?
EBS 볼륨만 늘리고 EC2 내부의 루트 파티션과 파일시스템은 확장하지 않았던 것이다. 남은 공간이 부족해지자 Self-hosted Runner가 빌드 결과물을 쓰지 못했고, 배포는 계속 실패했다.
파티션과 파일시스템까지 확장한 뒤 다시 배포하니 정상적으로 완료됐다. 실패한 작업이 반복되면서 CPU 사용률이 올라가 우리가 만들어둔 CloudWatch 경보도 울렸는데, 덕분에 이상 상태는 빨리 알 수 있었다.
덕분이라고 해야 할지는 모르겠지만, 백엔드 요구사항에 있던 ‘실제로 겪은 장애 한 건의 원인과 조치 기록하기’도 아주 생생하게 채웠다.
다만 CPU 경보만 보고 디스크 부족까지 바로 알아내기는 어려웠다. 이후에는 디스크 사용률도 함께 관찰하고 별도의 경보를 두기로 했다.
데모 전날 새벽에 배우기에는 조금 빡센 교훈이었다.
4. 스프린트 1 데모데이 당일
데모데이 첫 번째 순서는 우리 팀이었다.
담당 코치 그룹 안에서 스프린트 1의 결과를 최대한 컴팩트하게 설명했다. 포트폴리오를 등록하고 경제 이슈가 내 자산에 미치는 영향을 확인하는 흐름과, 그 서비스를 운영하기 위해 구성한 Dev/Prod 환경과 모니터링을 보여드렸다.
발표와 피드백을 거치며 한 가지가 분명해졌다.
우리 서비스, 기능이 너무 없었다.
바로 전 글의 주제가 ‘퓨어하게 가져가기’였고, 이번에도 핵심 가치를 흐리지 않으려고 했다. 문제는 그 말을 너무 강조한 나머지, 사용자가 서비스 안에서 할 수 있는 행동까지 퓨어해졌다는 것이었다.
스프린트 초반에는 기능을 더 넣을지 고민하지 않았다. 이전에 정한 방향대로 퓨어한 상태를 만드는 데 집중했다. 하지만 데모데이를 지나고 나니, 핵심 가치를 지키는 것과 사용자가 할 수 있는 기능을 만드는 일은 함께 가야 한다는 생각이 들었다.
데모데이가 끝난 뒤에야 등장한 두 버튼
기능 더 넣기 / 핵심 가치 퓨어하게 지키기 · 출처: Imgflip, Two Buttons
결론은 기능을 추가하는 것이었다. 데모데이 이후 기능 추가 회의를 열었고, 네 가지 방향을 정했다.
맞춤형 상품 추천, 초보 투자 가이드, 투자 실적 발표 일정 캘린더, 투자 리그. DAYNOMY를 분석 결과만 보여주는 서비스에서 끝내지 않고, 금융생활을 시작하고 다음 행동으로 이어지는 서비스로 확장하기로 했다.
협업에서는 스프린트 초반에 정한 공유 방식을 계속 가져갔다.
매일은 짧게 맞추고, 목요일에는 깊게 이해하기.
데일리 스크럼과 회고에서는 각자 무엇을 했는지 빠르게 공유했다. 목요일에는 왜 그렇게 구현했는지, 어떤 문제가 있었는지, 무엇을 배웠는지까지 더 깊게 나눴다. 짧은 진행 공유만으로는 알기 어려웠던 서로의 작업을 이해하기 위한 시간이었다.
새 기능들이 실제로 어떻게 만들어졌는지는 스프린트 2 회고에서 이어서 풀어보려고 한다. 궁금하시죠?? 궁금하다면 저희 DAYNOMY Velog를 팔로우해 주세요.
그리고 서비스도 한 번 이용해보세요! daynomy.com
