2분짜리 실패 예측: 버그를 코드 쓰기 전에 미리 짚어내는 프리코딩 의식

새 코드를 쓰기 직전, 딱 그 순간이 있습니다. 티켓은 열려 있고, 스펙 문서는 눈앞에 있고, 에디터도 준비 완료. 대부분은 곧장 키보드부터 두드립니다.

만약 그 첫 120초를 아직 존재하지도 않는 다음 버그를 예측하는 데 쓴다면 어떨까요?

이게 바로 2분짜리 실패 예측(two-minute failure forecast) 의 핵심 아이디어입니다. 코드를 쓰기 직전에 하는, 작지만 구조화된 미니 프리모텀입니다. 테스트나 코드 리뷰, 도구를 대체하는 게 아닙니다. 사고를 날카롭게 만들고, 스펙과 머릿속을 정렬해 주며, 실패 지점을 충분히 일찍 발견하게 해 주는 가벼운 의식에 가깝습니다. 이때는 아직 고치기 싸고 쉬운 시점이죠.

포스트모텀에서 프리모텀으로: 질문을 거꾸로 던지기

우리는 포스트모텀(postmortem) 에 익숙합니다. 프로덕션에서 문제가 터지면, 사고를 분석하고, 근본 원인을 문서화하고, “다음엔 잘하자”고 다짐하는 방식이죠.

프리모텀(premortem) 은 이 흐름을 거꾸로 뒤집습니다.

실패한 뒤에 “뭐가 잘못됐지?”라고 묻는 대신, 시작하기 전에 “뭐가 잘못될 수 있을까?”를 묻습니다.

프리모텀에서는 프로젝트나 기능, 릴리스가 이미 spectacular하게 망했다고 가정하고, 그럴 수 있었던 이유를 가능한 한 많이 떠올립니다. 그러면:

숨은 리스크가 드러나고
잘못된 가정이 노출되며
시스템의 약점을 두고 솔직하게 이야기할 수 있습니다.

이 아이디어를 더 작은 단위로 적용할 수 있습니다. 코딩 단위로 줄인 프리코딩 프리모텀 이고, 여기에 2분만 쓰면 됩니다.

2분짜리 실패 예측이란 무엇인가?

2분짜리 실패 예측 은 코드를 새로 작성하거나 리팩터링하기 전에 하는 짧은 의식입니다.

지금 막 쓰려는 코드가 이미 프로덕션에서 실패했다고 가정합니다.
가장 가능성이 높은 실패 이유들을 나열합니다.
그 리스크를 지금 당장 줄이기 위해 할 수 있는 간단한 일을 1~2개 정합니다.

끝입니다. 문서도, 긴 회의도 필요 없습니다. 딱 120초의 집중된, 구조화된 비관주의일 뿐입니다.

이 짧은 멈춤이 작업 접근 방식을 바꿔 줍니다. *“이걸 어떻게 동작하게 만들지?”*에서 멈추지 않고, *“이건 어디서 어떻게 망가질 수 있지?”*까지 함께 생각하게 만듭니다.

간단한 스크립트: 2분짜리 실패 예측을 실행하는 방법

혼자 머릿속으로 조용히 해도 되고, 페어/모브 프로그래밍 중 짧은 대화 형식으로 해도 됩니다. 다음은 그대로 따라 할 수 있는 구체적인 스크립트입니다.

1단계: 스펙에 닻을 내리기 (30초)

실패를 상상하기 전에, 먼저 성공이 어떤 상태인지를 알아야 합니다.

스스로에게 물어보세요.

이 코드는 정확히 무엇을 해야 하는가? (입력, 출력, 제약 조건)
엣지 케이스는 무엇인가? (빈 리스트, null 값, 타임아웃, 매우 큰 페이로드 등)
다른 시스템이나 데이터에 대해 내가 어떤 가정을 하고 있는가?

스펙이 모호하다면, 그게 첫 번째 레드 플래그입니다. 짧은 스펙을 쓰거나 명확히 하는 것(티켓에 몇 줄 정리하거나, docstring에 적는 정도여도 충분합니다)은 실패 예측을 위한 기준점을 만들어 줍니다.

명확한 스펙이 없으면 → 실패를 예측하거나 감지할 명확한 기준도 없습니다.

2단계: 이미 실패했다고 상상하기 (45초)

이제 새 코드가 배포되었고, 실제 문제를 일으켰다고 가정해 봅니다. 데이터 손실, 잘못된 출력, 성능 폭주, 깨진 유저 플로우 같은 것들입니다.

다음 질문을 던져보세요.

이건 어디서 실패할 가능성이 가장 클까?
- 입력 검증(input validation)?
- 경계 조건(boundary condition: off-by-one, 인덱스 오류 등)?
- 동시성 문제나 레이스 컨디션?
- 통합 지점(APIs, DB, 메시지 큐 등)?
- 에러 처리와 재시도 로직?
가장 창피하거나 비용이 클 버그는 무엇일까?
나중에 포스트모텀을 쓴다면, 근본 원인(root cause)에 뭐라고 적힐까?

가능성이 높은 실패 모드 3~5개를 종이에 적거나 머릿속에 메모하세요. 완벽을 노리지 말고 속도를 우선하세요. 현실적인 시나리오면 충분합니다.

3단계: 값싼 방어책 고르기 (45초)

각 실패 가능성마다, 빠르게 스스로에게 물어봅니다.

지금 당장, 이 리스크를 줄이기 위해 할 수 있는 가장 작은 일은 무엇인가?

자주 나오는 답은 이런 것들입니다.

특정 엣지 케이스를 위한 단위 테스트(unit test) 를 추가하거나 확장하기
guard clause 나 입력 검증을 추가하기
튀는 트릭 대신 검증된 패턴을 쓰기
지금은 못 고치는 리스크를 주석이나 TODO로 남겨두기
“특히 날짜 계산 부분을 잘 봐 주세요”처럼, 코드 리뷰에서 집중해서 봐 달라 표시하기

지금 바로 실행하겠다고 약속할 행동 1~2개만 고르세요. 작게 유지하는 게 핵심입니다. 이 의식이 무거워지면 금방 안 하게 됩니다.

코딩 컨벤션과 린터가 예측을 현실로 만드는 방법

실패 예측이 효과를 내려면, 결국 실행이 뒷받침돼야 합니다. 여기서 코딩 컨벤션(coding convention) 과 자동화 도구가 힘을 발휘합니다.

다음과 같은 실패 모드를 예측했다고 해 보죠.

“여기서 누군가 null 처리를 깜빡할 거다.”
“모듈마다 날짜 포맷이 제각각일 거다.”
“이 함수는 점점 읽을 수 없는 괴물이 될 거다.”

이런 문제는 종종 컨벤션을 강제함으로써 줄일 수 있습니다. 방법은:

수동: 코드 리뷰에서 합의된 스타일/신뢰성 체크리스트를 기준으로 확인하거나
자동: ESLint, Pylint, Prettier, Checkstyle 같은 린터와 포매터로 저수준 불일치와 안티패턴을 잡도록 하거나

컨벤션과 린터는 당신의 예측을 단순한 “희망 목록”이 아니라 시스템적인 안전망으로 바꿔 줍니다.

사람들이 방금 떠올린 것들을 일일이 기억해 주길 기대하는 대신:

규칙으로 제도화하고,
가능하다면 자동으로 강제합니다.

이렇게 하면 미리 예측했던 실패들이 실제로 터질 확률이 크게 줄어듭니다.

스펙: 실패 예측을 위한 지도

2분짜리 예측은 이 질문에 매여 있습니다.

“무엇을 기준으로 실패라고 볼 것인가?”

명확한 스펙이 없다면, 다음 둘 중 하나로 흐르기 쉽습니다.

사소한(중요하지 않은) 실패만 예측하거나,
진짜 중요한 “기대와 실제 동작의 불일치”를 놓치거나.

명확하지만 최소한의 프로그램 스펙을 적어 두는 것만으로도 좋습니다. 예를 들어:

입력 타입과 제약 조건에 대한 짧은 목록
예시 테이블: 입력 → 기대 출력
동작 규칙 (예: “API가 다운이면, 마지막 값만 5분간 캐시해서 사용한다”)

이렇게 해 두면 다음과 같은 질문을 할 수 있습니다.

“이 스펙이 애매한 부분은 어디지?”
“내 코드가 이 스펙과 어긋날 수 있는 지점은 어디지?”
“이 스펙 규칙 중에서 가장 실수하기 쉬운 건 무엇이지?”

이 질문들이 바로 효과적인 실패 예측의 핵심입니다.

사람과 도구: 컴파일 전에 버그를 예측하기

요즘 개발 도구는 점점 프리모텀의 자동화된 코파일럿처럼 행동합니다.

IntelliCode, GitHub Copilot 같은 도구는 방대한 코드베이스를 기반으로 패턴을 제안합니다. 잘 동작해 온 패턴을 암묵적으로 담고 있고, 때로는 수상해 보이는 코드를 드러내기도 합니다.
정적 분석 도구(static analysis)와 IDE 인스펙션은 컴파일이나 테스트 전에 버그 가능성이 높은 패턴(null 역참조, 사용되지 않는 변수, 수상한 비교 등)을 표시해 줍니다.

이 도구들을 당신의 2분짜리 예측에 참여한 자동화된 팀원이라고 생각해 보세요. 이들은:

다른 개발자들이 역사적으로 많이 실수했던 부분을 강조해 주고
코드를 치는 순간 위험한 패턴을 표시해 줍니다.

당신의 역할은 도구의 피드백과 사람의 판단을 결합하는 것입니다.

예측을 통해 어디에서 속도를 늦추고 더 깊이 생각해야 할지 결정하고,
도구를 통해 기계적·저수준 이슈를 대규모로 잡아냅니다.

이 둘을 합치면, 잠재적 실패에 대한 더 풍부하고 더 이른 시점의 시야를 얻을 수 있습니다.

실제 팀에서 굴러가게 만들기: 가볍게, 관료적이지 않게

산업 환경에서 “새로운 프로세스”라는 말은 그 자체로 리스크입니다. 속도만 늦추는 건 아닐까? 두어 스프린트 지나면 아무도 안 지키는 건 아닐까?

핵심은 실패 예측을 가볍고, 기존 흐름에 녹아들게 만드는 것입니다.

Definition of Ready나 PR 템플릿에 체크리스트 항목 하나만 추가하세요.
- “2분짜리 실패 예측을 했는가? 상위 3개 리스크를 적어라.”
코드 리뷰의 대화 시작점으로 활용하세요.
- “코딩 전에 어떤 실패를 예상했나요? 그중 어떤 건 이미 대응했나요?”
페어 프로그래밍에 녹여 넣으세요.
- 세션 시작 2분을 화이트보드나 공유 문서에서 함께 실패 예측을 하는 데 씁니다.

매우 작은 조직을 대상으로 한 ISO 29110 같은 표준은 경량 프로세스 개선을 분명히 가치 있게 봅니다. 예측 가능성과 품질을 높이되, 팀을 문서 작업으로 질식시키지 않는 단순한 단계들 말이죠.

2분짜리 실패 예측은 이 기준에 딱 맞습니다.

구조적이고, 반복 가능하며, 쉽게 가르칠 수 있고
팀에 규율과 리스크 인식을 심어 주면서도
린·애자일 프로세스와 잘 맞물립니다.

무거운 의식 없이도 프로세스 성숙도를 끌어올릴 수 있습니다.

한눈에 보는 예시: 실전 2분 마이크로 의식

새 티켓을 잡은 개발자가 실제로 이렇게 해 볼 수 있습니다.

스펙 명료화 (30초)
- “나는 할인 금액을 계산하는 함수를 작성한다. 입력: 고객 타입, 장바구니 총액, 쿠폰. 출력: 최종 가격. 규칙: 총액은 음수가 될 수 없고, VIP 규칙이 쿠폰보다 우선한다.”
실패 예측 (45초)
- “가장 가능성 높은 실패: 반올림 오류, 총액이 0일 때 엣지 케이스 누락, VIP와 쿠폰 규칙 충돌, tight loop에서 호출될 때 성능 문제.”
방어 계획 (45초)
- 총액 0일 때와 최대 할인 케이스에 대한 단위 테스트 추가.
- 주석과 테스트에 우선순위 규칙을 명확히 표기 (VIP > 쿠폰).
- 직접 구현 대신 기존의 money/decimal 유틸리티 사용.
- PR 설명에 “할인 우선순위 로직 sanity-check 부탁드립니다”라고 명시.
도구와 컨벤션으로 보강
- 린터/포매터로 스타일 일관성 확보.
- 정적 분석으로 빠진 분기나 위험한 브랜치가 없는지 경고 받기.

이렇게 2분을 투자하면, 앞으로 몇 시간의 작업 방향이 훨씬 안전한 쪽으로 궤도를 틀게 됩니다.

결론: 영웅적인 한 방이 아니라, 습관으로 만드는 실패 예측

대부분의 버그는 개발자가 똑똑하지 않아서 생기지 않습니다. 의도적인 선견지명(deliberate foresight) 이 부족해서 생깁니다.

코드를 쓰기 전에 2분짜리 실패 예측을 추가하면:

막연한 불안을 구체적이고 실행 가능한 리스크로 바꾸고
작업을 명확한 스펙에 더 단단히 연결하고
코딩 컨벤션과 도구를 활용해 반복되는 실패를 줄이고
바쁜 산업 현장 속에서도 의미 있는 리스크 관리 관행을 녹여 넣을 수 있습니다.

새 위원회도, 무거운 프로세스도, 두꺼운 절차서도 필요 없습니다. 필요한 건 120초짜리 솔직한 비관주의와, 거기서 보인 것에 조금이나마 실제로 행동하겠다는 의지뿐입니다.

다음번에 새 작업을 위해 에디터를 열면, 잠깐 멈춰 보세요. 첫 줄을 치기 전에, 스스로에게 이렇게 물어보는 겁니다.

“이게 이미 프로덕션에서 실패했다고 치면, 무엇이 잘못됐을까? 그리고 그걸 지금 당장 막기 위해 내가 할 수 있는 일은 무엇일까?”

그리고 나서 코드를 치기 시작하세요. 그러면, 미래의 포스트모텀은 지금보다 조금 덜 고통스러울 가능성이 큽니다.