생성형 AI와 Vibe Coding이 보편화되면서 소프트웨어 개발 방식은 빠르게 변하고 있다. 이제 코드를 작성하는 것 자체는 더 이상 어려운 일이 아니다. 프롬프트 몇 줄만으로 CRUD 화면, API, 데이터베이스 스키마, 테스트 코드까지 생성할 수 있다. 하지만 개발 속도가 빨라질수록 오히려 더 중요해지는 것이 있다. 바로 설계 판단(Design Decision) 이다. AI는 대안을 제시할 수 있고, 장단점을 설명할 수 있으며, 심지어 상당히 괜찮은 코드까지 생성한다. 그러나 지금 어떤 판단을 해야 하는지, 무엇을 우선해야 하는지, 어떤 위험을 감수해야 하는지는 결정하지 않는다.
실제로 AI 도입 이후 현장에서 관찰되는 많은 문제들은 새로운 문제가 아니다. 과거에도 존재했던 설계 실패 패턴들이 AI의 생산성과 결합하면서 훨씬 더 빠른 속도로 증폭되고 있을 뿐이다. 이 글에서는 Decision Quality(DQ)라는 의사결정 프레임워크를 기반으로 21가지 설계 실패 패턴을 체계적으로 정리해본다.
좋은 결과와 좋은 의사결정은 다르다
Decision Quality(DQ)는 SDG에서 체계화한 의사결정의 품질을 다음 여섯 요소로 설명한다.
- Frame (무엇이 문제인가 - 결정의 목적(Purpose), 범위(Scope), 관점(Perspective)을 명확히 하는 것. “우리가 풀고자 하는 진짜 문제는 무엇인가?“)
- Alternatives (어떤 선택지가 있는가 - 의미 있게 다른, 실행 가능한 여러 옵션을 충분히 생성하는 것. “우리가 선택할 수 있는 선택지는 무엇인가?“)
- Information (정보는 충분한가 - 관련성 있고, 신뢰할 수 있으며, 시의적절한 정보(사실 + 판단 + 불확실성)를 수집하는 것. “우리가 무엇을 알고, 무엇을 모르는가?“)
- Values (무엇을 기준으로 평가하는가 - 이해 관계자들이 진짜 중요하게 여기는 가치(Values)를 명확히 하고, 그 사이의 트레이드오프를 이해하는 것. “우리가 무엇을 중요하게 여기는가?“)
- Sound Reasoning (논리는 타당한가 - Alternatives + Information + Values를 논리적으로 결합해 최선의 선택을 도출하는 과정. “이 대안을 선택하는 이유는 무엇인가?”를 명확히 설명할 수 있어야 한다.)
- Commitment to Action (실행 가능한가 - 결정 후 실행을 위한 자원 배분, 이해관계자 정렬(Alignment), 실행 의지(Commitment)를 확보하는 것)
DQ의 가장 중요한 주장은 다음 한 문장으로 요약된다. 의사결정의 품질은 가장 약한 요소에 의해 결정된다. 좋은 의사결정을 했더라도 결과가 나쁠 수 있다. 반대로 운 좋게 좋은 결과가 나왔다고 해서 좋은 의사결정을 한 것은 아니다. 설계 역시 마찬가지다. 많은 설계 실패는 사실 두 가지 문제로 귀결된다.
- 문제를 잘못 정의했다 (Frame 오류)
- 평가 기준을 잘못 잡았다 (Values 오류)
그래서 Values는 ‘평가축’으로 8개를 정리해 평가를 하고 Frame의 문제는 ‘지배축의 문제’로 해결해보고자 한다. 나머지 4개 요소도 부차적으로 얽힐 수 있다. ‘성급한 결론’은 Information의 신뢰성 문제, ‘명목상 이름뿐인 완료’는 Commitment to Action의 누락, ‘바퀴의 재발명’과 ‘너무 이른 추상화’는 Alternatives의 빈곤, ‘임시방편의 영구화’나 ‘계층 침범 구현’은 Sound Reasoning의 논리 비약으로 읽을 수 있다. 가장 약한 요소가 전체의 품질을 결정한다는 DQ의 주장은 그대로 설계 판단에도 적용할 수 있다.
설계 판단의 8가지 평가축
설계를 평가할 때 사용하는 기준은 분야마다 이름이 다르다.
- Decision Analysis에서는 Criteria
- ATAM에서는 Quality Attributes
- ISO/IEC 25010에서는 Quality Characteristics
여기서는 이들을 통합하여 평가축(Evaluation Axis) 이라고 부르겠다. 설계 판단에 필요한 핵심 평가축은 다음 여덟 가지로 정리할 수 있다.
- 목적 적합성: 현재 해결하려는 문제를 얼마나 잘 해결하는가.
- 제약 적합성: 요구사항과 제약사항을 만족하는가.
- 실현 가능성: 기술적으로 가능하고, 조직이 실제로 운영할 수 있는가.
- 품질 영향: 유지보수성, 운영성, 확장성, 테스트 용이성 등에 미치는 영향이다.
- 시간 효과: 단기적인 효과와 장기적인 효과를 함께 고려한다.
- 위험과 불확실성: 예상 가능한 위험과 불확실성을 얼마나 통제할 수 있는가.
- 정합성: 기존 아키텍처와 얼마나 일관되는가.
- 합의 가능성: 팀과 조직이 실제로 받아들이고 실행할 수 있는가.
대부분의 실패는 지배축을 잘못 선택해서 발생한다
모든 평가축이 항상 동일하게 중요하지는 않다. 상황에 따라 가장 중요한 축이 존재한다. 이를 지배축(Dominant Criterion) 이라고 부른다. 예를 들어 장애 대응 상황이라면 단기 시간 효과가 지배축이 된다. 반대로 플랫폼 재설계라면 장기 품질, 유지보수성, 확장성 이 지배축이 된다.
문제는 대부분의 실패가 다음 구조를 가진다는 점이다.
실제 지배축 ≠ 선택한 지배축. 예를 들면,
- 장애 대응인데 이상적인 아키텍 처를 고민한다.
- PoC인데 운영 품질을 요구한다.
- 보안 문제인데 UX만 고려한다.
- 장기 플랫폼인데 개발 속도만 본다.
이러한 지배축의 착오가 다양한 실패 패턴으로 나타난다. 그리고 여기에서 사용하는 용어를 다시 한번 요약해서 이해를 돕고자 한다.
- 평가축: 설계 판단에 사용하는 평가 기준(Criteria).
- 지배축: 지금의 판단에서 가장 중시하는 평가축(Dominant Criterion).
- 2차 조건: 지배축만큼 중요하지 않지만, 채워야 할 수준을 결정해 두는 축. 예를 들어 지배축을 ‘시간 효과(단기)‘로 해도 ‘제약 적합성’을 2차 조건으로 최저 수준은 확보한다는 형태로 사용할 수 있다. 또한, 실현가능성(기술)/실현가능성(조직)을 2차 조건으로 걸어서 리스크를 완화할 수도 있다.
그래서 설계 판단을 할때 평가축, 지배축, 2차 조건 등을 고려하는 습관을 가진다면 아래와 같은 설계 실패 패턴들을 줄일 수 있을 것이다.
설계 실패 패턴들
재사용과 중복 오판
1. 바퀴의 재발명
이미 검증된 표준 해법이 있는데도 직접 구현하는 경우다. 대표적 사례는,
- 자체 인증 시스템을 만드는 것
- 자체 권한 시스템을 만드는 것
- 자체 스케줄러를 만드는 것
- 자체 에러 프로토콜을 만드는 것
Spring Security가 있는데 인증을 만들고, Quartz가 있는데 스케줄러를 만들고, HTTP 상태 코드가 있는데 자체 에러 체계를 만든다. 대개 “우리 서비스는 조금 특별하다”는 생각에서 시작된다. 그러나 대부분은 특별하지 않다. AI가 생성한 코드에서도 자주 나타나는 패턴이다. 코드는 동작하지만 프레임워크가 제공하는 정석적인 방법을 벗어나 있는 경우가 많다. 평가축의 편향으로는 목적 적합성은 과대평가하고 정합성, 실현 가능성(기술), 품질 영향(유지보수성)을 고려하지 않으면 일어나는 현상이다.
2. 주변을 보지 않는 재구현
이미 존재하는 기능을 모르고 다시 구현한다. 대표 사 례로,
- 날짜 유틸리티가 있지만 보지 않고 함수를 중복 생성하는 것
- 유효성 검사 규칙이 공통화 되어 있지만 동일 규칙을 로컬함수나 개별 컨트롤러에 중복 구현하는 것
- 권한 체크가 Decorator나 Interceptor에 구현되어 있으나 Controller에 개별적으로 구현하는 것
- 동일한 도메인 상수가 있지만 Constants.java 파일에 재정의하는 것
이 패턴은 Addy Osmani가 말한 Comprehension Debt의 전형적인 사례다. 평가축의 편향으로는 정합성, 품질영향(유지보수성), 합의 가능성 등을 고려하지 않아서 일어나는 현상이다. AI를 사용한다면 “신규 함수를 만들기 전에 기존 코드를 검색한다”는 규칙을 명시해 두면 중복 빈도를 낮출 수 있다.
3. 황금 망치
익숙하거나 최근에 도입한 특정 기술을 문제의 적합성을 따지지 않고 모든 곳에 적용하는 경우다. 예를 들어,
- Redis를 도입한 팀이 캐시가 필요하지 않은 곳에도 Redis를 추가하는 것
- Kafka를 도입한 이후 모든 서비스 간 통신을 이벤트 기반으로 바꾸려는 것
- 특정 디자인 패턴(Observer, Strategy 등)을 배운 직후 모든 코드에 적용하려는 것
- RDB로 충분한 데이터에도 최신 유행 NoSQL을 선택하는 것
“바퀴의 재발명”이 이미 있는 표준 해법을 무시하고 새로 만드는 문제라면, 황금 망치는 반대로 익숙한 도구를 적합성 검토 없이 적용하는 문제다. AI도 학습 데이터에 자주 등장한 기술 조합을 문맥 없이 그대로 제안하는 경향이 있어 이 패턴을 강화한다. 평가축의 편향으로는 목적 적합성과 제약 적합성을 고려하지 않고 실현 가능성(기술)에만 편향되어 판단할 때 일어나는 현상이다.
범위와 복잡도 오판
4. 닭 잡는데 소 잡는 칼 쓰기
과도하게 복잡한 기술을 선택하는 경우다. 예를 들어,
- 30명 규모 시스템에 마이크로서비스 도입하는 것
- 간단한 입력 검증(필수, 자리수, 정규식)이나 승인프로세스에 Drools 같은 룰 엔진을 도입하는 것
- 하루 500건 정도의 CSV 처리를 Kafka + Consumer Group으로 구성하는 것
- 월 1회 실행하는 보고서 생성 배치를 Spark 클러스터와 Kubernetes CronJob으로 운영하는 것
등이 있다. AI는 일반적으로 알려진 베스트 프랙티스를 맥락 없이 적용하는 경향이 있다. 그래서 실제 문제보다 훨씬 큰 해법을 제안하는 경우가 많다. 평가축의 편향으로는 목적 적합성은 과대평가하고, 실현 가능성(기술), 시간 효과(단기), 품질 영향(운용성-운영팀 역량), 합의 가능성 등을 고려하지 않으면 일어나는 현상이다.
5. 너무 이른 추상화
변화가 관찰되지 않았는데 추상화를 도입한다. 예를 들어,
- 구현이 아직 하나밖에 없는데 Strategy 패턴을 도입하는 것.
- 검색 조건이 name과 status 두 개뿐인데 독자 DSL을 설계하는 것.
- 설정 항목이 거의 변하지 않을 것 같은데 미리 DB 기반 설정 관리 화면을 만드는 것.
대응하는 대표적인 원칙은 Rule of Three다. 같은 변화가 최소 세 번은 발생한 후 추상화하라. 평가축의 편향으로는 품질 영향(변경 용이성)만 과대평가하고 목적 적합성이나 실현 가능성(기술), 시간 효과(단기)를 무시하면 일어나는 현상이다.
6. 잡히지도 않은 미래를 위한 확장점
“너무 이른 추상화”와 비슷한 면이 있지만, “너무 이른 추상화”는 변화가 관찰되지 않은 상태에서 추상화이고, 여기에서는 미래의 연결고리가 없는 상황에서 미리 만들어 버리는 것이다. “언젠가 필요할 것 같다”는 이유로 확장 구조를 만드는 경우다. 예를 들어,
- 언젠가 DB가 여러 개 될지도 몰라서 멀티 데이터소스 환경을 구성하는 것
- 언젠가 SMS를 보낼지도 몰라서 SMS 발송 기능을 구현하는 것
- 언젠가 다국어 지원할지도 몰라서 다국어 버전을 구성하는 것
- 다른 PG사를 사용할 지 몰라서 결제 추상 클래스를 만드는 것
문제는 그 미래는 일정이 없고, 책임자도 없고, 비즈니스 가치도 명확하지 않다는 점이다. 미래는 계획이 아니라 가정일 뿐이다. 평가축의 편향으로는 시간 효과(장기)만 과대평가하고 시간 효과(단기), 실현 가능성(기술), 위험·불확실성은 고려하지 않아서 일어나는 현상이다.
조직 역량 오판
7. 조직 수준을 무시한 설계
기술적으로는 맞지만 조직이 운영할 수 없는 경우다. 예를 들어,
- 24시간 온콜 체계가 없는 팀인데 멀티 리전 고가용성 아키텍처를 도입하는 것
- Kubernetes나 Kafka 운영 경험이 거의 없는 팀이 본격 도입하는 것
- DBA가 없는 팀에 복잡한 샤딩 + 멀티마스터 DB 구성을 처음부터 설계하는 것
- SRE 전담 인력이 없는 팀에 SLO, Error Budget, Chaos Engineering을 도입하는 것
그런데도 복잡한 분산 시스템을 도입한다. 기술적 가능성과 조직적 가능성은 다르다. 실무에서는 후자가 더 중요할 때도 많다. 평가축의 편향으로는 실현 가능성(기술)만 과대평가하고 조직의 실현 가능성, 품질영향(운용성-운영팀의 역량), 위험·불확실성을 고려하지 않으면 일어나는 현상이다.
8. 과도한 보수주의
반대로 조직 역량을 지나치게 낮게 평가하는 경우도 있다. 예를 들어,
- TypeScript 도입을 “타입 관리할 사람이 없다”며 거부하고 계속 JavaScript로 개발하는 것.
- 과거에 빌드 자동화가 실패한 경험이 있다고 해서 CI/CD를 포기하고 수동 빌드·배포를 유지하는 것
- 과거 Lambda/Stream API로 버그가 난 적이 있다고 해서, 모든 반복문을 확장 for문으로 강제하는 것.
- Optional 사용을 금지하고, null 체크를 호출하는 쪽에 모두 떠넘기는 것.
이유는 대부분 동일하다. 우리 조직은 그런 걸 못한다. 문제는 이런 판단이 미래의 역량 성장 기회까지 제거한다는 점이다. 평가축의 편향으로는 조직의 실현 가능성을 낮게 보고, 위험과 불확실성을 통제할 수 없다고 생각하며 품질영향(확장성)은 안 좋고, 장기적인 시간 효과를 고려하지 않고 품질영향(유지보수성, 운영안정성)만 강조할 경우 일어나는 현상이다. 직원 들이 역량을 키울 기회를 빼앗는다.
시간 감각 오판
9. 임시방편의 영구화
긴급 대응은 필요하다. 문제는 임시 대응이 영구 구조가 되는 것이다. 예를 들어,
- 권한 처리를 프론트엔드에만 적용하고 백엔드에는 미루는 것
- 기존의 책임 분리를 무시하고 Controller에 비즈니스 로직 추가하는 것
- NullPointerException 피하기 위해 무분별한 null 체크 남발
- 실제 코드의 버그를 고치는 대신 테스트를 변경해서 통과시키는데에만 집중하는 것
단기 효과만 보고 장기 효과를 무시한 결과다. 평가축의 편향으로는 시간 효과(단기)만 과대평가하고 품질 영향, 시간 효과(장기)를 무시하면 일어나는 현상이다.
10. 성급한 결론
다음과 같은 착각이다.
- 가입 API를 호출했는데, 사용자가 생성, 환영메일 발송 등 처리가 완결되었는지 확인하지 않고 HTTP 200 반환을 성공으로 판단하는 것
- 테스트를 검증 가능한 범위(중요한 시나리오)를 고민하지 않고 단순 성공처리만 하는 테스트 케이스
- 배치에서 실제 처리건수 등을 확인하지 않고 정상 종료 로그만 보고 성공으로 판정하는 것
세 사례의 공통점은 처리 완료를 업무 완료로 동일시한다는 것이다. HTTP 200은 요청이 수신됐다는 신호이지, 가입이 완결됐다는 의미가 아니다. AI 에이전트도 종료 코드 0과 작업 성공을 같은 것으로 보는 경향이 있다. 평가축의 편향으로는 목적 적합성을 무시하고 위험과 불확실성을 고려하지 않으면 일어나는 현상이다.
11. 준비되지 않은 출발
요구사항이나 전략 없이 구현을 시작한다. 대표 사례는,
- 요구사항이 모호한 상태에서 화면, API, DB를 만들어 버리는 것
- 에러 발생 시 업무 처리가 정해지지 않았는데 예외 처리 코드를 먼저 작성하는 것.
- 권한 정책이 미정인데 UI에서만 숨기는 것.
- 데이터 이관 방침이 결정되기 전에 이관 스크립트를 먼저 작성하는 것.
- 성능 요구사항(건수, 응답시간)이 정해지지 않았는데 Redis 캐시를 처음부터 도입하는 것.
준비도 되지 않았는데 문제 해결을 한다. 동작하는 프로토타입이 문제 해결처럼 보이지만 실제로는 판단을 미룬 것뿐이다. 평가축의 편향으로는 목적 적합성과 제약 적합성, 품질 영향도 생각하지 않고 시간 효과(단기)만 보 고 판단하면 일어나는 현상이다.
12. 제약조건의 후처리
업무 시스템에서는 기능보다 제약이 중요하다. 그런데 종종 제약을 무시한 채 개발을 시작한다.
- CRUD 기능을 먼저 만든 뒤, 나중에 권한 체크를 추가하는 것
- 데이터 갱신 기능을 만든 뒤에 감사 로그를 뒤늦게 추가하는 것
- 삭제 기능을 만든 후에 “이력 관리가 필요하다”는 요구를 받고 대응하는 것
- 동기 연동을 만든 후 재시도·멱등성(idempotency) 처리를 나중에 붙이는 것
결국 처음 설계가 뒤집힌다. 평가축의 편향으로는 제약 적합성, 위험·불확실성, 품질 영향 등을 고려하지 않으면 일어나는 현상이다.
정합성과 일관성 오판
13. 계층 침범 구현
책임이 있어야 할 곳이 아닌 곳에 구현하는 경우다. 예를 들어,
- Controller에 도메인 규칙을 작성하는 것
- 백엔드의 도메인 권한 규칙 없이 화면 코드에서 권한을 판정하는 것
- SQL에 화면 표시 규칙 삽입하는 경우
AI는 “어디에 있어야 하는가”보다 “어디에 쓰면 동작하는가”를 우선하는 경향이 있다. 평가축의 편향으로는 정합성, 품질영향(유지보수성), 위험·불확실성을 고려하지 않으면 일어나는 현상이다.
14. 기존 관례를 무시한 올바른 말
일반적으로는 맞지만 현재 프로젝트에는 맞지 않는 경우다. 예를 들어,
- 기존 코드는 Checked Exception과 Business Exception을 구분하는데 신규 코드만 RuntimeException 사용하는 경우
- 기존 로깅 정책 무시하고 AI 코드만 전부 INFO 레벨로 하는 경우
- 기존 트랜잭션 정책 무시하고 서비스 계층에서만 트랜잭션을 열기로 했는데 Controller에 @Transactional 하는 경우
- 날짜 유틸리티 규약 무시하는 경우(테스트 가능성, 타임존 문제 등의 이슈가 생길 수 있음)
- JUnit4 프로젝트에 JUnit5 테스트 추가하는 경우
기술적으로는 옳더라도 조직 차원에서는 틀릴 수 있다. 또한 AI는 GitHub, StackOverflow, 공식 문서, 블로그 등을 통해 학습한다. 그래서 AI는 현재 프로젝트 규칙, 현재 조직 문화, 현재 코드 스타일을 잘 알지 못한다. 즉, 관례를 지정해야 한다. 평가축의 편향으로는 정합성, 목적 적합성, 실현 가능성(기술) 을 고려하지 않으면 일어나는 현상이다.
15. 암묵적 의존성
의존 관계가 코드 시그니처에 드러나지 않아 변경과 테스트가 어려운 경우다. 예를 들어,
- 전역 변수나 싱글턴을 통해 외부 서비스 클라이언트에 접근하는 것
- 함수 내부에서 환경 변수를 직접 읽어 동작을 결정하는 것
- 서비스 로케이터 패턴으로 의존성을 내부에 숨기는 것
- ThreadLocal이나 요청 컨텍스트에서 사용자 정보를 암묵적으로 꺼내 비즈니스 로직에 사용하는 것
의존성이 함수 시그니처에 없으면 코드를 읽어도 어떤 외부 상태에 의존하는지 알 수 없다. 테스트하려면 전역 상태를 미리 설정해야 하고, 호출 순서나 실행 환경에 따라 결과가 달라진다. AI가 생성한 코드에서도 자주 나타나는 패턴인데, AI는 “어떻게 연결되는가”보다 “어떻게 동작하는가”를 우선하기 때문이다. 평가축의 편향으로는 정합성, 품질영향(테스트 용이성, 유지보수성), 위험·불확실성을 고려하지 않으면 일어나는 현상이다.
아키텍처 구조 오판
16. Big Ball of Mud (진흙 덩어리 아키텍처)
구조 없이 기능이 무질서하게 쌓인 시스템이다. 처음에는 빠른 배포를 위해 “일단 동작하게”를 반복하다가 어느 순간 모든 코드가 모든 코드를 참조하게 된다. 예를 들어,
- 레이어 구분 없이 Controller가 Repository를 직접 호출하고, Service가 Controller에 의존하는 것
- 특정 기능을 수정하면 예상치 못한 곳이 연달아 깨지는 것
- 서비스 클래스가 수천 줄에 달하고 비즈니스 로직, 데이터 접근, 외부 연동이 한 파일에 뒤섞인 것
- 새 기능을 추가할 때마다 “어디에 넣어야 할지 모르겠다”는 논의가 반복되는 것
AI 시대에 이 패턴이 특히 위험한 이유는 생성 속도가 빠르기 때문이다. AI는 “어디에 넣어야 하는가”보다 “어디에 넣으면 동작하는가”를 먼저 선택한다. 빠른 코드 생성이 쌓이면 구조 붕괴 속도도 그만큼 빨라진다. 평가축의 편향으로는 시간 효과(단기)만 반복적으로 지배축으로 삼고 정합성, 품질 영향(유지보수성·확장성), 위험·불확실성을 지속적으로 무시하면 일어나는 현상이다.
17. God Class / The Blob (신 클래스)
하나의 클래스가 너무 많은 책임을 가져 모든 것을 처리하는 경우다. 이 패턴은 앞서 다룬 ‘계층 침범 구현’(13번)과 겹치는 면이 있지만, 그쪽이 책임의 위치 문제라면 여기서는 책임의 집중 문제다. 예를 들어,
- UserService가 사용자 CRUD뿐만 아니라 이메일 발송, 권한 판정, 결제 처리, 통계 집계까지 담당하는 것
- 단일 Manager 클래스가 전체 비즈니스 플로우를 순차적으로 제어하는 것
- 모든 유틸리티 함수가 Utils.java 한 파일에 모인 것
- 클래스가 2,000줄을 넘어도 “어차피 여기 다 있으니까”라는 이유로 계속 쌓이는 것
God Class는 빠른 기능 추가의 결과물이기도 하다. 새 기능을 추가할 때 가장 저항이 적은 경로가 기존 클래스에 메서드를 추가하는 것이기 때문이다. 그렇게 점진적으로 비대해진다. 테스트 가능성도 함께 무너진다. 하나의 메서드가 의존하는 외부 상태가 너무 많아 단독으로 테스트할 수 없게 된다. 평가축의 편향으로는 목적 적합성과 실현 가능성(기술)에만 치중하고 정합성, 품질 영향(유지보수성·테스트 용이성)을 무시하면 일어나는 현상이다.
18. 분석 마비 (Analysis Paralysis) / 과도한 Big Design Up Front
너무 많은 시간을 사전 설계에 투자하다가 실제 구현이 늦어지거나, 그 사이에 요구사항이 바뀌어 설계가 무용지물이 되는 경우다. 예를 들어,
- 3개월을 아키텍처 설계에만 투자했는데 시장 상황이 바뀌어 요구사항 자체가 달라진 것
- 모든 엣지 케이스를 사전에 완벽하게 정의하려다 스프린트가 계속 밀리는 것
- PoC 단계에서 운영 환경을 가정한 완전한 설계를 요구하는 것
- “완벽한 설계가 나와야 코딩을 시작할 수 있다”는 사고방식으로 팀이 아무것도 착수하지 못하는 것
과도한 BDUF의 문제는 설계 자체가 나쁜 것이 아니라, 알 수 없는 것을 알려고 시간을 쏟는다는 점이다. 초기에는 요구사항이 불완전하고 시스템에 대한 이해도도 낮다. 코드를 작성하면서 비로소 명확해지는 제약과 트레이드오프가 있다. 설계에 쓴 시간이 길어질수록, 그 설계를 버리기 어려워지는 매몰비용 편향도 작동한다. 평가축의 편향으로는 위험·불확실성을 과도하게 과대평가하고 시간 효과(단기), 실현 가능성(조직)을 무시하면 일어나는 현상이다.
19. Architecture by Implication (암묵적 아키텍처)
아키텍처를 명시적으로 정의하지 않고 코드와 관행으로만 암시적으로 운영하는 경우다. 예를 들어,
- 레이어 분리 원칙이 팀 내에서 문서화나 합의 없이 각자 다르게 해석되고 있는 것
- 팀원이 바뀔 때마다 컨벤션이 달라져 기존 코드와 신규 코드의 구조가 충돌하는 것
- “코드가 곧 문서”라는 생각으로 아키텍처적 결정이 어디에도 명시되지 않은 것
- 신규 팀원이 아키텍처를 파악하려면 전체 코드를 읽어야만 하는 것
아키텍처는 모두가 동일하게 이해하고 있어야 작동한다. 암묵적으로 공유되는 지식은 팀 규모가 커지거나 구성원이 바뀌면 즉시 흔들린다. ADR(Architecture Decision Record)처럼 결정과 그 이유를 기록하는 습관이 없으면, 왜 그렇게 설계했는지는 시간이 지나면 아무도 모르게 된다. 평가축의 편향으로는 Frame 오류와 함께 정합성, 합의 가능성 고려가 부족하고 시간 효과(단기)가 강력한 지배축으로 작용하면 일어나는 현상이다.
요구사항과 완료 정의 오판
20. 과거에 대한 과도한 배려
실제 사용자를 확인하지 않은 채 무한한 하위 호환성을 유지하려는 경우다. 대표 사례는,
- 기존 API를 깨뜨리지 않으려고 신규 API와 기존 API를 병렬로 계속 유지하는 것
- 오류 거부감 때문에 is_deleted, is_archived, is_suspended 같은 DB 칼럼이 계속 쌓이는 것
- 마이그레이션을 통해 기존 데이터를 변환하지 않고 구버전을 동시 지원하는 코드를 작성
- 상태 관리가 필요할 경우 열거형으로 변환하지 않고 기존 로직의 변경 거부감으로 새로운 값의 다른 필드를 계속 추가하는 것.
호환성은 중요하지만, 범위와 종료 시점이 없는 호환성은 기술 부채가 된다. 평가축의 편향으로는 제약 적합성만 과대평가하고 목적 적합성, 실현 가능성(기술), 품질영향(유지보수성), 시간 효과(단기)를 고려하지 않으면 일어나는 현상이다.
21. 명목상 이름뿐인 완료
완료 조건이 있지만 검증 가능한 형태가 아닌 경우다. 예를 들면,
- 구체적인 요구사항이 없이 “적절히 표시될 것”으로 표현하는 것
- 성능도 구체적 지표 정의 없이 “충분히 빠를 것”으로 표현하는 것
- UX 요구사항을 두리뭉실하게 “사용하기 편할 것”으로 정의하는 것
- 표시할 정보를 구체화하지 않고 “적절히 로그를 남길 것”으로 표현하는 것
이러한 표현은 완료 여부를 누 구도 판단할 수 없다. AI가 “그럴듯한 수용 기준”을 매우 잘 만들어 내기 때문에, 문서가 존재한다는 사실만으로 요구사항이 명확하다고 착각하기 쉽다. 평가축의 편향으로는 합의 가능성, 목적 적합성, 품질 영향을 고려하지 않으면 일어나는 현상이다.
AI 시대에 설계가 더욱 중요해진 이유
흥미로운 사실은 이 21가지 실패 패턴이 AI 이전에도 존재했다는 점이다. 새로운 문제는 아니다. 하지만 AI는 문제를 훨씬 빠르게 증폭시킨다. Big Ball of Mud처럼 구조가 서서히 무너지는 패턴은 과거엔 수년이 걸렸지만, AI로 코드를 빠르게 쌓으면 수개월 만에 같은 결과에 도달한다.
AI는 빠르게 구현하고, 다양한 대안을 제시하며, 그럴듯한 코드를 만든다. 그러나 지금 내가 어떤 실패 패턴에 빠져 있는지는 알려주지 않는다. 이 프레임워크를 실무에서 적용해보면, 대부분의 실패는 ‘지금 어떤 상황인가’를 잘못 파악한 데서 출발한다는 것을 알 수 있다. 지배축이 틀렸거나, 중요한 평가축 하나가 처음부터 고려 대상에 없었거나. 특히 Vibe Coding 시대에는 과거처럼 선배의 코드를 읽으며 암묵지를 습득하기 어려워지고 있다. 따라서 앞으로 중요한 역량은 특정 기술을 아는 능력이 아니라, 지금의 지배축은 무엇인지, 어떤 평가축을 과대평가하고 있는지, 어떤 평가축을 무시하고 있는지, 지금 어떤 실패 패턴에 진입하고 있는지를 스스로 점검하는 능력이다.