10분 피처 예측: 코드가 가장 먼저 깨질 곳을 미리 찾아내는 작은 플래닝 의식

기능을 빨리 배포하는 건 쉽습니다.

3시 새벽 인시던트 알람 없이 기능을 빨리 배포하는 건 훨씬 어렵습니다.

대부분의 팀은 이미 테스트, 코드 리뷰, CI 같은 기본 장비를 갖추고 있습니다. 그런데도 버그는 늘 비슷한 곳에서 빠져나갑니다. 까다로운 비즈니스 로직, 약한 연동 지점, 실제 트래픽을 받아보기 전엔 아무도 신경 쓰지 않는 퍼포먼스 엣지 케이스들 말이죠.

문제는 보통 도구가 아닙니다. 코드를 치기 직전에 필요한, 짧지만 의도적인 생각의 시간이 빠져 있을 뿐입니다.

여기서 등장하는 게 바로 10분 피처 예측(Ten-Minute Feature Forecast) 입니다. 코드를 시작하기 전에 새 기능이 어디서 가장 먼저 깨질 가능성이 높은지 예측하는 아주 작은 플래닝 의식입니다.

10분 피처 예측이란?

피처 예측(feature forecast) 은 짧고 타임박스(time‑boxed)된 플래닝 연습입니다.

• 새 기능이나 변경을 코딩하기 직전 약 10분을 씁니다.
• 설계와 주변 코드를 빠르게 훑어봅니다.
• 일부러 이렇게 묻습니다: “이게 깨진다면, 가장 먼저 어디서 깨질까?”
• 가장 위험한 부분을 메모하고, 그걸 어떻게 테스트/보호/단순화할지 정리합니다.

1인(또는 둘이서) 하는 가벼운 아키텍처 리뷰라고 생각하면 됩니다. 회의도, 다이어그램도, 거대한 문서도 필요 없습니다. “일단 코드부터 쳐 보고 생각하자”에서 “이 기능이 스트레스를 받을 때 어떻게 버티게 만들지 의식적으로 설계하자”로 모드를 전환하는 의도적인 멈춤입니다.

왜 굳이 해야 할까? 그냥 코딩부터 할 때의 숨은 비용

바로 구현에 들어가면 굉장히 생산적인 느낌이 듭니다. 에디터는 열려 있고, 테스트는 돌아가고, 프로그레스 바는 초록색입니다.

하지만 사전 플래닝을 완전히 건너뛰면 이런 일들이 반복됩니다.

• 복잡한 엣지 케이스를 구현 도중에야 발견하고, 급하게 땜질합니다.
• 외부 연동·계약(API 계약 등) 을 잊고 있다가, 스테이징에서 API가 payload를 거절하면서 비로소 깨닫습니다.
• 퍼포먼스가 문제라는 걸 부하 테스트가 깨지거나 실제 트래픽이 몰릴 때에서야 알게 됩니다.
• 테스트는 구현이 끝난 뒤에야 쓰게 되고, 그 결과 대부분 해피 패스만 테스트하고 이상한 케이스는 놓칩니다.

피처 예측은 이 문제를 이렇게 해결합니다.

• 리스크를 재작업이 되기 전에 수면 위로 끌어냅니다.
• 가장 가치 있는 테스트를 먼저 어디에 쓸지 가리켜 줍니다.
• 시스템을 단순히 확장하는 데서 그치지 않고, 보호하도록 유도합니다.

거창한 설계가 아닙니다. 피할 수 있었던 고통을 피할 만큼의, 딱 그 정도 수준의 의도적인 생각일 뿐입니다.

미니 아키텍처 리뷰로서의 피처 예측

정식 아키텍처 리뷰는 분명 유용하지만, 대부분의 일상적인 티켓에 쓰기엔 너무 무겁습니다. 10분짜리 예측은 5% 노력으로 80% 효과를 주는 버전입니다.

그 10분 동안 사실상 리뷰 보드가 물을 법한 것들을 축소판으로 스스로 묻고 답합니다.

• 무엇을 바꾸는가? (범위와 경계)
• 무엇을 깨뜨릴 수 있는가? (의존성과 파급 효과)
• 복잡성은 어디에 있는가? (로직, 상태, 동시성, 데이터 형태)
• 뭐가 비싸거나 깨지기 쉬운가? (성능, 외부 서비스, 공유 인프라)

정식 회의 대신, 이건 내 자리에서 반복적으로 수행하는 프리플라이트 루틴입니다. 큰 설계 문서를 쓰는 게 아니라, 코딩하고 테스트할 때 실제로 참고할 몇 개의 불릿만 적어 둡니다.

단순한 10분 체크리스트

팀과 상황에 맞게 바꿔도 좋지만, 약 10분 안에 돌릴 수 있는 구체적인 체크리스트 예시는 이렇습니다.

1. 변경을 명확히 하기 (2분)

• 이 기능이 가져야 할 정확한 동작은 무엇인가?
• 입력과 출력은 무엇인가?
• 어떤 기존 인터페이스를 건드리는가? (API, DB 테이블, 큐, UI 플로우 등)

성공이 어떤 모습인지를 구체적인 불릿 3–5개로 적어 둡니다.

2. 고위험 영역 스캔하기 (4분)

설계나 고수준 접근을 보면서 이렇게 자문합니다.

• 복잡한 로직:
  • 조건문, 분기, 상태가 많지 않은가?
  • 여러 규칙이나 설정을 한데 조합하고 있지 않은가?
• 연동(Integrations):
  • 외부 API, 서비스, 공유 라이브러리를 호출하는가?
  • 그것들이 느리거나, 일관성이 없거나, 예상치 못한 데이터를 돌려주면 어떻게 되는가?
• 데이터와 계약(Contracts):
  • 데이터 마이그레이션, 스키마 변경, 애매한 필드 재사용이 있는가?
  • 문서화되지 않은 동작이나 가정에 의존하고 있지 않은가?
• 퍼포먼스 핫스팟:
  • 로그인, 결제, 검색처럼 크리티컬 패스에 있는 기능인가?
  • 큰 데이터셋에 대해 루프, 조인, N+1 쿼리 위험을 추가하고 있지 않은가?
• 동시성(Concurrency)과 상태(State):
  • 여러 사용자/프로세스가 동시에 이 코드를 칠 수 있는가?
  • 인메모리 상태나 호출 순서 같은 가정에 기대고 있지 않은가?

앞으로 골칫덩이가 될 것 같은 영역 2–4개 정도에 동그라미를 치거나 하이라이트합니다.

3. 어디서 먼저 깨질지 예측하기 (2분)

고위험 영역마다 이 문장을 완성합니다.

“문제가 난다면, 가장 가능성 높은 이유는 ___ 때문이다.”

예시:

• “외부 빌링 API가 타임아웃 나거나 부분 응답만 줄 수 있기 때문이다.”
• “이 룰 엔진에서 null이나 빈 값을 잘못 처리할 수 있기 때문이다.”
• “큰 데이터셋에서 이 쿼리가 너무 느릴 수 있기 때문이다.”
• “이 레코드에 대한 동시 업데이트가 서로 덮어써 버릴 수 있기 때문이다.”

모든 실패 가능성을 다 나열하려는 게 아닙니다. 발생 가능성과 영향도가 모두 높은 실패를 순위 매기는 겁니다.

4. 어떻게 보호·테스트할지 정하기 (2분)

예측한 실패마다 다음을 결정합니다.

• 보호 장치(Safeguards):
  • 타임아웃, 재시도, 폴백(fallback)
  • 입력 검증, 스키마 체크, 합리적인 기본값
  • 피처 플래그, rate limit, 서킷 브레이커(circuit breaker)
• 타깃 테스트:
  • 복잡한 분기·조건 조합에 대한 단위 테스트(Unit Test)
  • API 계약·데이터 플로우를 검증하는 통합 테스트(Integration Test)
  • 의심되는 핫스팟에 대한 성능·부하 테스트

각 항목마다 “어떤 테스트를 쓸지, 어떤 보호 장치를 넣을지”를 1–2개의 불릿으로 적습니다.

이제 단순히 기능을 구현하는 계획이 아니라, 기능을 형성하고 보호하는 미니 플랜이 생겼습니다.

코드 커버리지와 엣지 케이스 사고는 어떻게 맞물릴까

피처 예측은 코드 커버리지(code coverage), 그리고 엣지 케이스(Edge Case) 사고와 궁합이 좋습니다.

• 커버리지는 확인용:

  • 구현이 끝난 뒤, 커버리지는 앞에서 고위험으로 찍어 둔 경로가 실제로 테스트에 의해 실행되는지 확인하는 도구가 됩니다.
  • 100% 커버리지를 쫓기보다, 먼저 치명적이거나 깨지기 쉬운 경로가 커버되는지부터 보는 겁니다.

• 엣지 케이스 증폭기:

  • 위험한 조건문이나 분기를 볼 때마다 이렇게 자문합니다: “여기서 가장 기괴한 입력이나 상황은 뭘까?”
  • 빈 리스트, null, 범위를 벗어난 값, 엄청 긴 문자열, 잘못된 상태, 느린 응답, 부분 실패 같은 것들을 떠올립니다.
  • 이걸 단순한 머릿속 메모가 아니라 구체적인 테스트 케이스로 옮깁니다.

이 의식은 다음과 같은 꽉 찬 루프가 됩니다.

1. 리스크를 예측한다.
2. 그 리스크를 염두에 두고 구현한다.
3. 그 리스크를 겨냥한 테스트를 작성한다.
4. 커버리지로 그 테스트가 정말 의도한 코드 경로를 치고 있는지 확인한다.

이제 테스트를 대충 뿌려두는 게 아니라, 정말 중요한 지점에 조준해서 쏘게 됩니다.

일회성 트릭이 아니라 프리플라이트 루틴처럼 대하기

파일럿은 이륙 전에 감(“vibes”)만 믿지 않습니다. 반드시 프리플라이트 체크리스트를 밟습니다.

10분 피처 예측은 여러분의 코딩 프리플라이트입니다.

• 반복 가능합니다: 작은/중간 크기 기능에 늘 같은 의식.
• 단순합니다: 포스트잇이나 메모 앱에 넣어둘 수 있는 짧은 체크리스트.
• “코드를 빨리 치자”에서 “시스템을 의도적으로 설계하자”로 뇌 상태를 전환해 줍니다.

기존 책상 앞 루틴에 자연스럽게 끼워 넣을 수 있습니다.

• 티켓을 처음 잡은 직후, 에디터를 열기 전에.
• 점심이나 회의 후에 다시 기능 작업으로 돌아오기 직전.
• 페어 프로그래밍 시작 시: 각자 5분씩 리스크를 말해 보고, 그다음에 합쳐 보기.

타임박스가 되어 있기 때문에, 끝없는 설계 토론으로 번지지 않습니다. 10분이 끝나면, 더 선명한 방향성과 더 적은 놀라움을 가진 상태로 바로 구현을 시작합니다.

작고 실용적으로, 타임박스를 지키는 법

이 의식의 힘은 작고, 꾸준하다는 데서 나옵니다.

• 목표는 10분, 45분이 아닙니다.
• 과하게 고민하는 편이라면 타이머를 쓰세요.
• 예측 내용을 짧고 구조화된 노트로 남기세요. 예를 들면:

Feature Forecast – [티켓 ID]

Scope: [2–3 불릿]
High‑risk areas: [3 불릿]
Likely failures: [3 불릿]
Safeguards & tests: [4–6 불릿]

예측을 하다 보니 이 기능이 사실 크고 위험하다는 게 드러난다면, 그것 역시 가치 있는 정보입니다.

• 정식 설계 문서가 필요할지도 모릅니다.
• 티켓을 더 작은 여러 개로 쪼개야 할 수도 있습니다.
• 처음엔 피처 플래그 뒤에 숨겨야 할지도 모릅니다.

그래도 그 사실을 알아내는 데 쓴 건 이틀치 반쯤 만든 코드가 아니라 고작 10분입니다.

결론: 예측 가능한 버그는 선택 사항이다

프로덕션에서 가장 지독한 버그를 솔직하게 되짚어 보면, 대부분 사실 놀랄 일이 아니었다는 걸 깨닫습니다. 조금만 집중해서 생각했더라도 예측할 수 있었던 것들입니다.

• “그 서비스가 느려지면 어떻게 될지 한 번도 생각 안 해봤다.”
• “동시 업데이트에 대해 고려하지 않았다.”
• “저 조건 조합은 테스트해 보지 않았다.”

10분 피처 예측은 이런 종류의 생각을, 첫 줄의 코드를 쓰기 전에 할 수 있도록 공간을 마련해 주는 작은 의식입니다.

설계 문서, 코드 리뷰, 테스트 프레임워크를 대체하려는 게 아닙니다. 오히려 실패가 가장 먼저 시작될 지점을 가리켜 줌으로써, 그 모든 걸 증폭시켜 줍니다.

프리플라이트 루틴으로 받아들이세요. 짧게 유지하세요. 단순하게 유지하세요. 그러면 “예상치 못한” 프로덕션 이슈 상당수가 조용히 사라질 겁니다. 여러분이 코드가 어디서 깨질지 미리 예측했고, 그 부분부터 먼저 보호하기로 선택했기 때문입니다.