아이디어를 7일 안에 돌리는 사이드 프로젝트 룰

결제·정산 현장에서 아이디어가 더 잘 죽는 이유

결제·정산·자동화를 직접 운영하는 팀의 아이디어 대화는 대체로 이렇게 끝난다. "그거 좋은데, 근데 PG사 API 먼저 확인해야 하고, 오류 처리 없이는 절대 못 올리지." 이 문장이 시작을 막는다. 금융 데이터를 다루는 팀은 완성의 기준이 일반 웹 서비스보다 훨씬 높게 설정되어 있다. 정합성이 틀리면 안 되고, 자동화가 잘못 돌면 실제 돈이 영향을 받는다. 이 감각은 프로덕션 시스템에서는 맞는 감각이다. 문제는 그 기준이 내부 도구와 사이드 프로젝트에도 그대로 이식될 때다.

우리 팀은 한 분기 동안 "만들면 어때?" 대화가 열 번 이상 있었는데, 실제 코드로 이어진 건 두 건이었다. 나머지 여덟 개는 Notion 페이지로 남았다가 조용히 사라졌다. 공통점이 있었다. 처음부터 프로덕션 수준의 완성도를 상상하고 시작했다는 것. 에러 처리, 재시도 로직, 포맷 통일, 멀티 PG사 대응까지 머릿속에서 이미 설계하다가 첫 커밋이 무거워졌다. 결제 팀 특유의 신중함이, 시작 자체를 막는 방어 기제가 된 것이다.

7일 데모 기준이 실제로 하는 일

"7일 뒤에 무엇을 보여줄 수 있는가"라는 질문은 단순하지만, 실제 작용은 꽤 외과적이다. 이 질문은 범위를 자동으로 잘라낸다. 정산 불일치 탐지 도구를 만들고 싶다고 가정하자. 처음 아이디어는 이렇다: PG사 원장 데이터를 API로 가져오고, 내부 DB와 비교해서, 차이가 있는 건을 Slack으로 알리고, 히스토리 대시보드도 있고, 팀별 알림 설정도 가능하고. 7일 안에 가능한가? 아니다. 그러면 7일 안에 가능한 핵심은 무엇인가: PG사 API를 호출해서 오늘 정산 데이터를 가져오는 스크립트 하나, 그리고 그것을 내부 DB 숫자와 비교해서 터미널에 출력하는 것. 이것이면 충분하다.

이 기준의 트레이드오프는 명확하다. 7일 데모는 완성품이 아니다. 에러 처리가 없고, 예외 케이스를 못 잡고, UI도 없다. 하지만 핵심 가설 — "PG사와 우리 DB 숫자가 실제로 자주 다른가, 그 차이를 프로그램으로 잡을 수 있는가" — 은 검증할 수 있다. 만약 7일 데모에서 숫자 차이가 실제로 발견되지 않는다면, 그 도구는 만들 필요가 없는 것이다. 7일은 투자 결정을 내리기 위한 최소 증거를 만드는 기간이다. 기획 문서로 논쟁하는 대신, 실제로 돌아가는 것으로 증명한다.

기술 결정 30분 룰: 배포 가능성이 속도다

7일이라는 제약에서 기술 선택에 이틀을 쓰면 5일밖에 남지 않는다. 우리는 이 교훈을 직접 겪었다. 정산 자동화 스크립트를 만들 때 "이참에 Go로 짜보면 어떨까"라는 말이 나왔다. 논의가 반나절로 이어졌고, 결론은 Python이었다. 시간이 아까웠다. 이제 우리 기준은 하나다: 팀 셋 중 한 명이라도 최근 3개월 안에 써본 스택이 있으면 그것을 쓴다. 새 기술 탐구는 사이드 프로젝트 이후, 관심 있는 사람이 별도로 한다.

결제 현장에는 이 룰을 더 유리하게 쓸 수 있는 자산이 있다. 우리 팀에는 PG사별 API 연동 코드, CSV 파싱 유틸, 금액 검증 함수, Slack 알림 래퍼가 이미 내부에 쌓여 있다. 7일 사이드 프로젝트는 이 기존 코드를 조립하는 방식으로 훨씬 빠르게 출발할 수 있다. "처음부터 다시 짜는 것"은 7일 프로젝트에서 거의 항상 과잉이다. 기존 코드 자산 조립 + 30분 기술 결정, 이 조합이 첫날을 실제로 구현하는 날로 만든다.

4시간 막힘 룰: 정보 고립이 일정을 죽인다

혼자 막히는 시간은 사이드 프로젝트의 조용한 킬러다. 특히 결제 연동에서는 공식 문서가 오래됐거나, 샌드박스 환경이 실제와 다르게 동작하거나, API 응답 스펙이 문서와 다른 경우가 실제로 자주 있다. 이런 문제는 혼자 파고드는 것으로 해결되지 않을 때가 많고, 같은 팀원이 이미 같은 문제를 겪었을 가능성이 높다.

4시간 룰을 도입하고 나서 실제로 달라진 사례가 있다. 팀원 한 명이 특정 PG사의 웹훅 서명 검증 로직에서 막혔을 때, 예전이라면 하루를 쓰고 나서야 채팅창에 올렸을 것이다. 이제는 3시간 반 만에 올렸고, 다른 팀원이 "그거 Content-Type: application/x-www-form-urlencoded로 들어오는 경우야, 이 코드 그대로 써"라고 10분 안에 해결해줬다. 하루치 시간이 절약됐다. "내가 해결해야 한다"는 감각은 개인 프로젝트에서는 미덕이지만, 7일 안에 데모를 내야 하는 팀 프로젝트에서는 일정을 갉아먹는 자존심이다.

HEDVION 실제 시나리오: 정산 리포트 자동화 7일

구체적 사례를 공유한다. 우리 팀은 매일 오전, 전날 PG사 정산 데이터를 포털에서 수동으로 내려받아 스프레드시트에 붙여넣고, 합계를 맞춰 정리한 뒤 내부 채널에 공유하는 루틴이 있었다. 한 번에 30~40분, 주 5일이면 주당 약 3시간이 드는 작업이었다. "이거 자동화하면 어때?"라는 말은 여러 번 나왔지만, 매번 "여러 PG사 포맷을 어떻게 통일할지, API 인증은 어떻게 할지, 혹시 숫자 틀리면 어떡하지"가 같이 딸려왔다. 대화는 세 번쯤 반복되다 흐지부지됐다.

7일 룰을 적용하면 이렇게 재정의된다. 7일 뒤 데모 목표: PG사 A 하나에서만 데이터를 가져와 Slack 메시지로 보내는 스크립트. 포맷 통일, 다른 PG사, 에러 처리는 7일 데모에 없다. Day 1에 PG사 A API 인증 코드 작성, Day 2~~3에 응답 파싱과 금액 집계, Day 4~~5에 Slack 메시지 포맷 결정과 전송 구현, Day 6에 실제 데이터로 테스트, Day 7에 팀 앞에서 실행. 결과적으로 스크립트는 6일 만에 완성됐고, 7일째에 데모했다. 에러 처리가 없어서 처음 2주는 가끔 수동 재실행이 필요했지만, 이후 조금씩 보강해서 지금은 매일 아침 7시에 자동으로 돌아간다. 주당 3시간 절감, 연간으로 150시간이다. 그리고 이 스크립트가 베이스가 돼서 PG사 B, C 연동은 각각 하루 만에 추가됐다. 처음부터 "모든 PG사, 에러 처리, 포맷 통일"을 잡고 시작했다면 아직도 Notion에 기획 문서로 남아있을 것이다.

바로 써먹는 실행 체크리스트

이 룰들은 추상적인 원칙이 아니다. 아이디어가 나온 당일 바로 적용할 수 있는 행동 목록이다.

아이디어가 나온 당일, 30분 안에:

"7일 뒤 데모에서 딱 하나만 보여준다면 무엇인가"를 채팅이나 화이트보드에 한 문장으로 적는다.
그 한 문장이 7일 안에 실제로 가능한지 팀 중 한 명이 즉석에서 판단한다. 가능하면 시작, 불가능하면 더 자른다. "가능할 것 같다"는 통과다.
기술 스택을 그 자리에서 결정한다. 팀원 중 최근 3개월 내에 써본 것이 있으면 그것. 없으면 팀에서 가장 익숙한 언어 + 기존 내부 코드 재활용.

7일 동안:

Day 1이 끝날 때 API 하나라도 호출이 되어 있어야 한다. 안 됐으면 그날 팀에 공유한다.
막힌 시간이 4시간을 넘기 전에 채팅창에 올린다. 메시지 형식은 "막힘: [문제 한 줄 요약] / 시도한 것: [두 줄]"로 충분하다.
7일 이후 확장 계획은 데모 전에 입 밖으로 꺼내지 않는다. 꺼내는 순간 범위가 다시 커진다.

데모 당일:

"계속 키운다" 또는 "버린다"를 당일 결정한다. 유보는 없다. 유보는 두 번째 Notion 문서다.
계속 키우기로 했다면 다음 7일 데모 목표를 그날 정한다.
버리기로 했다면 왜 안 됐는지 두 줄로 기록하고 실제로 지운다. 기록은 다음 아이디어에 쓰인다.

결제·정산 현장에서 내부 자동화 도구의 생산성 회수는 생각보다 빠르다. 주당 3시간짜리 수작업 하나를 자동화하면 1년이면 150시간이다. 7일을 투자할 가치가 충분히 있다. 그리고 이 경험이 반복될수록, 아이디어를 꺼내는 것도 시작하는 것도 점점 가벼워진다. 만드는 속도가 생각하는 속도를 따라가기 시작할 때, 팀이 달라진다.

— by slecs