한 분기를 닫으며 — 우리가 다음에 거절할 것들

거절 목록이 전략 문서인 이유

무엇을 할지보다 무엇을 하지 않을지가 팀의 성격을 더 명확하게 드러낸다. 이 말은 스타트업 격언처럼 들리지만, 결제·정산·자동화를 직접 운영하는 작은 팀에게는 추상적 원칙이 아니라 생존 도구다. 우리가 5개월 동안 쌓은 실수의 대부분은 "거절했어야 하는 것을 수락한" 데서 시작됐다. 그리고 그 대가는 단순한 시간 낭비가 아니었다.

결제 도메인에서 잘못된 수락은 복리(compound)로 악화되는 구조를 갖는다. 요구사항이 불명확한 상태에서 정산 자동화를 시작하면 중간에 로직이 바뀌고, 바뀐 로직에 맞춰 이미 처리된 트랜잭션을 소급해야 하는 상황이 생긴다. 이건 개발 공수 두 배의 문제가 아니라 운영 신뢰의 문제로 번진다. 그래서 이번 분기를 닫으면서 우리가 한 일은 다음 분기에 거절할 목록을 명시적으로 문서화하는 것이었다.

결제·정산 현장에서 '거절 실패'의 비용

일반적인 소프트웨어 프로젝트에서 범위 확장은 납기 지연과 추가 비용을 낳는다. 결제·정산 컨텍스트에서는 그 위에 하나가 더 붙는다 — 금전 오류와 감사 추적 문제다. 납기가 협의 불가인 상태에서 정산 배치를 설계하면, 마감을 맞추기 위해 예외 처리를 "나중에 추가"하는 결정을 하게 된다. 실제로 우리 팀이 겪은 케이스에서, 부분 취소 처리 예외를 후순위로 미뤘다가 정산 불일치가 발생했고, 이를 수동으로 대사(reconciliation)하는 데 이틀이 걸렸다.

수치로 보면 더 명확해진다. 우리 규모인 3인 팀에서 이틀의 비정상 운영 대응은 전체 팀 가용 공수의 약 30%를 소진한다. 같은 기간 예정돼 있던 기능 개발 두 건은 다음 주로 밀렸고, 고객사에게 상황을 설명하는 커뮤니케이션 비용까지 합치면 해당 프로젝트의 실질 마진은 절반 이하로 떨어졌다. 처음에 거절했더라면 발생하지 않았을 손실이었다.

우리가 다음에 거절할 것들 — 구체적으로

납기가 협의 불가인 프로젝트. "런칭일이 이미 공지됐다"는 말이 가장 위험한 신호다. 우리가 범위를 조정할 수 없는 상태에서 마감만 고정되면, 품질 조정이 유일한 변수가 된다. 결제 흐름에서 품질을 조정한다는 건 곧 예외 케이스를 덜 다룬다는 뜻이고, 그 예외는 나중에 반드시 실제 오류가 돼서 돌아온다.

요구사항이 미확정인 상태에서 계약을 강요하는 경우. "일단 시작하고 나중에 구체화하자"는 패턴은 3인 팀에서 가장 치명적이다. 우리가 경험한 사례에서, 초기 계약에 명시되지 않았던 멀티 커런시 처리 요건이 개발 3주 차에 등장했고, 이미 짜여진 정산 로직의 70%를 재설계해야 했다. 이 패턴은 거의 예외 없이 '추가 요건'이라는 이름으로 돌아온다.

처음 써보는 기술 스택을 실서비스에 투입하는 경우. 새 기술은 내부 프로젝트에서 먼저 검증한다는 원칙을 한 번 어겼다. 특정 PG사 웹훅 처리를 새로운 이벤트 드리븐 아키텍처로 구현했는데, 운영 환경에서 재시도 로직이 예상대로 작동하지 않아 중복 정산이 발생했다. 테스트 환경에서는 재현이 안 됐고 원인 파악에 사흘이 걸렸다. 실서비스에서 처음 써보는 기술의 비용은 학습 비용이 아니라 장애 대응 비용이다.

한 명만 담당자로 고정되길 요구하는 계약. 계약서에 "담당자 A"를 명시하는 조항이 있었던 프로젝트에서, 해당 담당자가 이틀 연속 몸이 좋지 않았을 때 팀 전체가 대응 불가 상태가 됐다. 결제·정산 시스템에서 단일 장애점(SPOF)은 인프라 수준의 문제로 다뤄야 하는데, 그것을 계약 조항으로 팀 구조에 심어두는 건 본질적으로 같은 위험이다.

거절이 어려운 이유 — 트레이드오프를 솔직하게

거절이 어려운 이유는 단 하나다. 돈이 걸려 있기 때문이다. 프로젝트 파이프라인이 얇은 달에 납기 고정 프로젝트가 들어오면, 거절은 원칙이 아니라 사치처럼 느껴진다. 5개월 동안 그 압박을 몇 번 겪었고, 그때마다 목록은 흐릿해졌다.

그러나 우리가 실제로 기록한 데이터는 다르다. 수락했다가 후회한 횟수 대 거절해서 후회한 횟수의 비율은 약 4:1이었다. 우리는 매 프로젝트 종료 후 소요 공수와 예상 공수를 비교하는 간단한 테이블을 유지하는데, 공수가 50% 이상 초과된 프로젝트들의 공통점은 항목 하나 이상이 위의 거절 목록에 해당했다는 것이었다. 이건 체감이 아니라 기록된 회고 데이터다.

다음 분기에 팀이 실제로 적용할 방식

추상적인 거절 원칙을 실제로 작동시키려면 프로세스에 심어야 한다. 첫 번째는 **인테이크 체크리스트(intake checklist)**다. 클라이언트가 프로젝트를 처음 제안할 때, 다섯 가지 질문에 모두 답하지 않으면 견적 단계로 넘어가지 않는다. 납기 협의 가능 여부, 요구사항 확정 시점, 사용 기술 스택의 팀 경험 수준, 담당자 구조, 정산·결제 관련 컴플라이언스 요건 여부다. 이 체크리스트는 거절을 위한 도구가 아니라 수락 가능성을 빠르게 판단하기 위한 도구다.

두 번째는 거절 이후 기록이다. 거절한 프로젝트도 간단히 남겨둔다. 왜 거절했는지, 어느 항목에 걸렸는지, 이후 그 프로젝트가 어떻게 됐는지(파악 가능한 경우). 6개월 후에 이 기록을 보면 거절 목록의 유효성을 다시 검증할 수 있다. 목록이 시장 현실과 맞지 않으면 업데이트해야 하고, 계속 유효하면 더 자신 있게 적용할 수 있다. 원칙도 버전 관리가 필요하다.

지금 당장 써먹을 수 있는 실행 시사점

결제·정산·자동화를 운영하는 소규모 팀이라면 지금 바로 적용할 수 있는 세 가지를 정리한다.

1. 거절 목록을 팀 공용 문서로 만들어라. 머릿속에 있는 원칙은 압박이 오면 증발한다. Notion이든 Google Doc이든, 팀이 함께 볼 수 있는 곳에 "우리는 이걸 하지 않는다"를 명시해라. 업데이트 날짜를 포함시키면 더 좋다.

2. 문제 프로젝트의 공통 패턴을 소급 분석하라. 과거 6~12개월 프로젝트 중 공수가 예상을 50% 이상 초과한 것들을 골라라. 그 프로젝트들에 어떤 신호가 있었는지를 역추적하면 거절 목록의 항목들이 자연스럽게 도출된다. 분석해 보면 납기 고정과 요구사항 미확정이 거의 항상 함께 등장한다는 걸 발견할 것이다.

3. 결제·정산 도메인 특화 리스크를 별도로 명시하라. 일반 소프트웨어 프로젝트 관리 프레임워크는 이 도메인의 고유 리스크를 잘 다루지 않는다. "부분 취소·환불 플로우가 명세 없이 시작하는 프로젝트", "PG사 연동 스펙이 계약 시점에 미확정인 경우"처럼 현장에서 실제로 자주 문제가 되는 항목을 거절 목록에 명시적으로 추가해야 한다. 오류의 비용이 다른 도메인에서, 거절 기준도 그 도메인에 맞게 구체화돼야 한다.

— by slecs