구현에서 드러나는 요구사항과 ADR 피드포워드

들어가며: 결과를 봐야 요구가 나온다

여기까지 잘 왔다고 하자. 인터뷰로 암묵지를 캐고(1편), 현행 업무를 포착하고(2편), 인테이크 양식으로 굳히고(3편), 위임 경계를 정하고(4편), 데이터까지 갖췄다(5편). 그래도 막힌다. 사양은 100%를 못 덮고, 구현에 들어가면 미처 생각 못 한 게 쏟아진다.

특히 AX에서는 두 모양으로 터진다. 고객은 결과물을 보고 나서야 "어 이것도 돼요? 저건 왜 안 돼요?"를 쏟아낸다. 뭐가 가능한지 미리 몰랐으니 깊게 생각할 수가 없었던 것이다. 그러면 개발자는 반대편 함정에 빠진다. "그럼 나중에 뭐가 나올지 모르니 다 되게 설계해야 하나?" 그런데 다 되게 만들면 느려지고, 답이 일관되지 않는다.

좋은 소식은, 이게 새 문제가 아니라는 것이다. Barry Boehm은 2000년에 이걸 IKIWISI(I'll Know It When I See It)라고 이름 붙였다. "요구사항을 말해 달라고 하면 사람들은 '어떻게 말해야 할지 모르겠지만 보면 안다'고 한다."¹ 25년 된 법칙이다. 그래서 이 글의 결론은 이렇다.

• 사양이 못 덮는 건 결함이 아니라 소프트웨어의 성질이고, 요구사항은 구현을 거치며 출현한다.
• 그러니 빈틈을 싸게, 일부러 드러낸다. 프로토타입을 발굴 도구로 쓴다.
• "다 되게 만들자"는 함정이고, 좁은 코어에 변화가 싼 구조를 더하는 게 취향이 아니라 법칙적 답이다.
• 빈틈과 경계 결정을 ADR로 흡수하고, 그걸 다음 인터뷰의 입력으로 되먹인다.

사양이 못 덮는 건 결함이 아니라 성질이다

Fred Brooks가 1986년 "No Silver Bullet"에서 이미 못을 박았다. "소프트웨어에서 가장 어려운 건 무엇을 지을지 정하는 것이고, 고객은 자기가 뭘 원하는지 정확히 모르므로, 요구사항을 뽑아내는 가장 좋은 방법은 동작하는 소프트웨어를 지어 보는 것이다."² 그는 이걸 본질적 복잡성(essential complexity)이라 불렀다. 코딩 같은 우연적 복잡성(accidental complexity)과 달리, 무엇을 지을지 정하는 어려움은 도구로 없앨 수 없다.

여기 AI 시대의 반전이 있다. 코딩 에이전트가 우연적 복잡성(타이핑)을 거의 공짜로 만들수록, 본질적 복잡성(무엇을 지을지)의 비중은 오히려 커진다. 빈틈 찾기가 덜 중요해지는 게 아니라 더 중요해진다.

왜 사전 계획이 안 통하는지는 Cone of Uncertainty가 정량적으로 말한다. 불확실성은 프로젝트 시작에 가장 크고, 일이 진행되며 미지가 풀려야 좁아진다.³ 시작 시점에 고해상도 사양을 못 갖는 건 당연하다. Korzybski의 표현으로 "지도는 영토가 아니다." 사양은 지도이고, 돌아가는 시스템과 고객의 진짜 필요가 영토다. 80% 시간을 계획에 써도 빈틈이 남는 건, 지도가 영토가 아니기 때문이다.

빈틈을 일부러, 싸게 드러내라

"결과를 봐야 요구가 나온다"가 IKIWISI라면, 처방은 분명하다. 결과를 빨리, 싸게 보여줘서 요구가 납품 후가 아니라 발견 단계에 나오게 한다. 도구는 이미 다 있다.

AI 맥락에서 특히 강한 건 Wizard-of-Oz다. 가장 어려운 한 태스크를 뒤에서 사람이 처리하고 앞은 AI처럼 보이게 한 뒤, 사용자가 AI에게 실제로 무엇을 요구하는지 관찰한다. 그 대화록은 곧 범위 정의이자 학습 데이터가 된다.⁶

그리고 2025~2026년의 결정적 변화. LLM/바이브 코딩이 프로토타입을 거의 공짜로 만든다. 실무자 Sophia Sun의 말처럼 "문서는 모호한 생각을 숨겨 주지만 프로토타입은 디테일을 건너뛰게 두지 않는다." 같은 플로우의 버전 셋을 만들면 그 대비가 토론을 일으킨다("demo > memo").⁸ 버려도 되는 데모가 공짜라면, 인테이크에서 능력의 경계를 일부러 시연할 수 있다. "이건 됩니다 / 이건 지금은 안 합니다"를 미리 보여주면, 납품 후 "이것도 안 돼?" 폭탄을 발견 단계에서 미리 터뜨리게 된다. pre-mortem("1년 뒤 실패했다면 왜?")까지 더하면 빈틈을 구현 전에 캔다.

다만 솔직히 적어 둘 게 있다. 내가 통과한 한 멀티벤더 AI 프로젝트에서 빈틈은 대부분 이렇게 미리 캐내지지 않았다. 데모나 Wizard-of-Oz로 발견 단계에 터뜨린 게 아니라, 일단 결정을 내린 뒤 회의와 구현에서 사실이 드러나며 사후에 뒤집은 경우가 훨씬 많았다. 예컨대 "코드를 전부 새로 짠다"는 전면 재설계 결정은 pre-mortem이 잡아낸 게 아니라, 결정을 적고 며칠 만에 회의에서 "검증 대상이 몇 건 안 돼 전면 재설계는 과하다"는 사실이 드러나며 뒤집혔다(그 자리에서 회의 결론이 났고, 공식 폐기는 나흘 뒤였다). 그러니 이 글이 옹호하는 선제적 발굴은 이상이고, 현실의 안전망은 "빠르게 결정하고 사후에 싸게 갈아끼우는 결정 체인"이었다. 진짜 교훈은 "빈틈을 다 미리 캐라"보다 "미리 못 캐도 결정을 싸게 교체할 수 있게 해 두라"에 가깝다. 선제 발굴은 빈틈의 수를 줄이고, 교체 규율은 못 줄인 빈틈의 비용을 줄인다. 둘 다 필요하다.

spec-driven development도 빈틈은 못 푼다

2025~2026년의 유행은 spec-driven development(SDD)다. GitHub Spec Kit은 작업을 Constitution → Specify → Plan → Tasks → Implement 단계로 나눠 에이전트가 추측 대신 명시된 의도를 실행하게 한다.⁹ AWS Kiro는 아예 "코드는 사양의 빌드 산출물"이라 본다. 사양을 앞당기는 건 좋다. 하지만 emergent requirement는 풀지 못한다.

Thoughtworks의 Birgitta Bockeler가 스펙트럼으로 정리했다.¹⁰ spec-first(사양을 먼저 쓰고 폐기), spec-anchored(유지·진화), spec-as-source(사람은 사양만 편집). Spec Kit/Kiro는 대체로 spec-first다. 그리고 spec-as-source는 모델 주도 개발(MDD)의 실패(경직성)에 LLM의 비결정성까지 더할 위험이 있다고 경고한다. 구현 현실에서 살아남는 건 spec-anchored인데, 그건 빈틈을 둘 곳이 있어야만 작동한다.

그래서 진짜 축은 "SDD냐 바이브 코딩이냐"가 아니다. **"네 사양에 emergent requirement를 흘려보낼 배수구가 있는가"**다. 그 배수구가 바로 결정 기록 레이어다.

"다 되게 만들자"는 함정

이제 개발자의 딜레마를 정면으로 풀자. "미래 요구를 흡수하려면 다 되게 설계해야 하지 않나?" 직관은 그렇게 말한다. 그런데 over-general 시스템은 느려질 뿐 아니라 법칙적으로 덜 정확하고 덜 쓰인다.

• Luciano Floridi의 certainty-vs-scope 추측(2025): 증명 가능한 정확성을 가지려면 시스템은 좁게 한정돼야 하고, 넓고 고차원인 시스템은 불가피하게 오류를 떠안는다. 둘 다 가질 수 없다.¹¹
• NN/g(Kate Moran, 2025): 현장 테스트에서 좁은 범위의 AI 기능이 열린 기능보다 더 잘 작동했다. "유연할수록 사용성은 떨어진다."¹²

즉 범위를 좁히는 건 비겁한 타협이 아니라 신뢰성과 양립하는 선택이다. 그렇다고 "좁히고 기도"도 답이 아니다(나중에 "이것도 안 돼?"가 터지니까). 답은 같은 Boehm 논문 안에 있다. 좁고 믿을 수 있는 코어를 두되 변화를 싸게 만드는 것이다.

1. 변화가 올 자리를 미리 격리한다. David Parnas의 information hiding: "이것도 돼?" 폭탄이 떨어질 가능성이 높은 방향을 예측해 모듈 경계 뒤에 숨긴다.¹³ 그러면 좁은 시스템이 싸게 확장된다. 미리 다 만들지 않고도. 한 프로젝트의 도구(tool) 설계 결정이 이 원리를 그대로 따랐다. "도구가 무한정 늘면 어쩌나"라는 우려에, 팀은 동적 레지스트리와 검색 레이어를 다 깔아 "다 되게" 만들지 않았다. 대신 "지금은 도구를 수십 개 수준으로 정적 등록하고, 검색 레이어는 나중에 붙이는 방향으로 결정했다(아직 구현 전)"로 코어를 좁게 못 박았다. 그러면서 확장이 필요해질 자리는 미리 격리해, 나중에 검색을 붙여도 재설계가 아니라 저비용 훅 하나로 끝나게 했다. 결정적으로 "도구 수가 일정 규모를 넘고 오선택이 측정되기 시작하면 다시 본다"는 재방문 조건을 결정 문서의 '다시 볼 시점'에 적어 뒀다. 좁은 코어, 격리된 확장점, 재방문 트리거가 한 결정 안에 들어 있는 셈이다.
2. 낮은 우선순위 요청은 거절도 흡수도 말고 미룬다. Boehm의 evolution requirements: "나중에" 요청을 명시적 deferred 레지스터(3편 인테이크의 그 컬럼)로 보낸다.
3. 각 경계 요청은 한 줄 규칙으로 판정한다. Boehm의 위험 규칙: "빼는 게 위험하면 넣고, 넣는 게 위험하면 빼라."¹

여러 후보를 동시에 들고 가다 불확실성이 줄면 수렴하는 set-based 방식도 같은 정신이다. 한곳에 일찍 못 박지 않고 옵션을 남긴다.¹⁴

빈틈을 결정으로, 결정을 다음 인터뷰로

마지막 고리. 위에서 내린 모든 경계 결정과 미룬 요청은 그 자리에서 ADR이 된다. 배경 → 문제 → 후보 → 이유 → 선택. 최소 포맷으로는 Olaf Zimmermann의 Y-statement가 좋다. "X 맥락에서, Y에 직면해, Z를 택하고 〈대안〉을 버렸으며, 〈이득〉을 위해 〈대가〉를 감수한다." 버린 대안과 직면한 문제가 문장 안에 강제되니, 나중에 "우리가 이미 무슨 옵션을 따져 봤지?"로 검색된다.¹⁵

같은 프로젝트의 결정 로그가 이걸 그대로 보여준다. 앞서 말한 전면 재설계 결정이 "기존 자산 리팩토링"으로 뒤집혔을 때, 그 한 번의 뒤집힘은 도미노로 데이터 모델 결정 두 건의 전제까지 무너뜨렸고, 또 다른 결정이 그 둘을 한꺼번에 대체했다. 핵심은 옛 기록을 지우지 않았다는 점이다. 폐기된 결정 문서 상단에 "이 결정은 더 이상 유효하지 않음, 새 결정으로 대체"라는 배너만 박고, 본문은 역사적 기록으로 남겼다. 그래서 뒤집힌 결정조차 "그땐 왜 그렇게 봤나"가 검색 가능한 상태로 보존된다. Y-statement가 문장에 강제하는 '버린 대안 + 직면한 문제'가 실전에서 작동하는 모양이 이것이다.

여기서 이 시리즈의 feed-forward가 완성된다. Zimmermann의 SOAD는 **"내려진 결정(decisions made)"**과 **"내려야 할 결정(decisions required)"**을 구분한다.¹⁶ 지금까지의 ADR은 전자, 즉 절반만 일하고 있었다. 빠진 절반은 과거 프로젝트에서 수확한 가이드 모델 - 다음 프로젝트 인터뷰가 출발점으로 삼을 "이 종류 일에서 늘 내려야 하는 결정 목록"이다. 미해결로 남은 결정은 곧 decision debt이고, 그게 다음 인테이크의 가장 값진 질문이 된다.

flowchart LR
  I[인터뷰 / 인테이크] --> B[구현]
  B -->|"빈틈 발견<br/>(프로토타입·spike·pre-mortem)"| G[경계 결정 + 미룬 요청]
  G --> A["ADR (Y-statement)<br/>배경→문제→후보→이유→선택"]
  A --> W[Wiki 정제 + 가이드 모델]
  A --> R[deferred 레지스터]
  W --> I2[다음 프로젝트 인터뷰]
  R --> I2

기록을 질의 가능한 그래프로 만들면 더 강해진다. Kruchten의 결정 온톨로지는 결정들 사이를 constrains/enables/forbids 같은 관계로 잇는다.¹⁷ 그러면 새 요구사항이 들어올 때 "이 결정이 저 결정을 제약한다"를 추적할 수 있다. 과거 ADR을 다음 결정의 입력으로 쓰는 2025년 구현도 나왔다. 최근 K개를 컨텍스트로 주는 Last-K 방식과, 관련도 상위 K개를 검색해 few-shot으로 주는 DRAFT 방식이 두 갈래다.¹⁸

이건 새로운 게 아니라 좋은 팀이 늘 하던 것의 자동화다. Google·Stripe·Uber의 RFC/디자인 문서 문화는 맥락·고려한 대안·버린 아이디어·트레이드오프를 구현 전에 적는다.¹⁹ Pivotal/Tanzu Labs는 긴 프로젝트에서 약 3개월마다 재-인셉션을 한다. 요구사항은 한 번 잡고 끝이 아니라 계속 재발견된다는 걸 운영에 박아 넣은 것이다.²⁰ Palantir가 "가장 가치 있는 제품 개선이 현장에서 나왔다"고 한 것도 같은 되먹임이다.

정리

• 사양이 100%를 못 덮는 건 결함이 아니라 성질이다. 요구사항은 구현을 거치며 출현한다(Brooks, Boehm의 IKIWISI, Cone of Uncertainty). AI가 코딩을 싸게 만들수록 "무엇을 지을지"의 비중은 더 커진다.
• 빈틈은 싸게, 일부러 드러내라. 프로토타입은 발굴 도구다(throwaway, Wizard-of-Oz, "demo > memo"). 인테이크에서 능력의 경계를 시연해 "이것도 안 돼?" 폭탄을 미리 터뜨린다.
• spec-driven development도 emergent requirement는 못 푼다. 진짜 축은 "네 사양에 빈틈을 흘려보낼 배수구가 있는가"다.
• "다 되게 만들자"는 함정이다. over-general은 법칙적으로 덜 정확(Floridi)하고 덜 쓰인다(NN/g). 답은 좁은 코어 + 변화가 싼 구조: Parnas로 변화 자리를 격리하고, 낮은 우선순위는 deferred로 미루고, 경계 요청은 "빼는 게 위험하면 넣어라"로 판정한다.
• 모든 경계 결정과 미룬 요청은 ADR(Y-statement)이 되고, "내려야 할 결정" 가이드 모델과 deferred 레지스터가 다음 인터뷰의 입력으로 되먹인다(SOAD).

다음 글에서는 시야를 넓힌다. 한 프로젝트에서 쌓인 이 결정과 지식을 개인 → 팀 → 조직으로 어떻게 합치는가. "단일 진실 공급원"이 왜 잘못된 목표이고, 무엇이 맞는지.

참고 자료

사양은 왜 불완전한가

• No Silver Bullet (Fred Brooks, 1986)
• Requirements that Handle IKIWISI, COTS, and Rapid Change (Boehm, IEEE Computer 2000)
• Cone of Uncertainty

빈틈을 드러내는 도구

• Walking skeleton / tracer bullets
• Wizard-of-Oz prototyping
• demo > memo: prototyping with Lovable (Sophia Sun)
• Performing a Project Premortem (Gary Klein, HBR 2007)

spec-driven development

• GitHub Spec Kit
• The SDD spectrum: spec-first / spec-anchored / spec-as-source (Birgitta Bockeler, martinfowler.com)

과잉일반화 딜레마

• A Conjecture on a Fundamental Trade-Off between Certainty and Scope (Floridi, arXiv 2506.10130)
• Scope in Generative-AI Features (Kate Moran, NN/g)
• Designing Software for Ease of Extension and Contraction (Parnas, IEEE TSE 1979)

결정 feed-forward

• Architectural Decisions as Reusable Design Assets / SOAD (Zimmermann, InfoQ)
• Y-statements (Olaf Zimmermann)
• An Ontology of Architectural Design Decisions (Kruchten, 2004)
• DRAFT-ing Architectural Design Decisions using LLMs (arXiv 2504.08207)
• RFCs and design docs (Pragmatic Engineer)