바이브 코딩을 넘어서: AI 기반 개발의 진짜 병목은 Why다

솔로 CTO 한 명이 Claude Code와 3개월간 도메인 OS 플랫폼을 만들었다. 마이크로서비스 30개, AI 에이전트 13개, 모바일 앱 3개, 임베디드 펌웨어 30만 줄. 총 110만 줄의 프로덕션 코드. 이 과정에서 LLM 기반 개발의 근본적 트레이드오프를 발견했고, 이를 프레임워크로 정리했다. ## 코딩 머신 함정 AI를 “빨리 코드 짜는 기계”로만 쓰면 what과 how는 나오지만 why가 빠진다. 패턴이 “여기에 핸들러가 있어야 한다”고 말하니까 핸들러를 쓰는 것이지, 새벽 3시 부하 상황에서 그 핸들러가 실패하면 무슨 일이 벌어지는지 이해해서 쓰는 게 아니다. 이것은 AI의 실패가 아니다. why를 주지 않은 인간의 실패다. ## CHP 트레이드오프 삼각형 LLM 기반 개발에는 세 변수가 있다. Creative — 새로운 솔루션을 만드는 능력. Hallucination — 그럴듯하지만 작동 안 하는 코드를 만드는 경향. Principles — 출력을 제한하는 규칙과 가이드라인. 이 셋은 동시에 최대화할 수 없다. Creative를 올리면 Hallucination이 동반 상승한다. 둘은 같은 생성 메커니즘에서 나온다. Principles를 올리면 Creative가 죽고 AI는 코딩 머신이 된다. 47개 규칙을 넣은 커널 서비스는 창의적 솔루션을 하나도 못 냈다. 핵심 발견: why 기반의 Principles가 이 트레이드오프를 우회한다. “이렇게 구현해라”가 아닌 “이것이 왜 중요한지”를 주면, AI에게 자기 평가 기준이 생긴다. 드레스 코드와 취향의 차이다. 드레스 코드는 나쁜 선택과 창의적 선택을 모두 제거한다. 취향은 나쁜 선택만 제거하면서 창의적 선택은 허용한다. 철학 문서는 AI에게 “취향”을 준다. ## 도메인별 다이얼 이 트레이드오프는 도메인마다 최적점이 다르다. 모바일 UI는 Creative 높게, 커널 서비스는 Principles 높게, 프로토콜 구현은 Creative 제로. 솔로 CTO의 진짜 병목은 코드 작성이 아니라 이 다이얼을 모든 도메인에서 동시에 보정하는 것이다. ## 실전에서의 효과 코드 한 줄 없이 검증 기준과 판단 근거만 담은 철학 문서를 AI 맥락에 넣었다. 모델 변경 없이, 규칙 추가 없이, 맥락만 바꿨을 때 운영 검증 커버리지가 3배 증가했다. 더 나은 모델을 기다릴 필요 없다. 더 나은 맥락이 필요하다. ## AI가 강해질수록 Why의 가치가 올라간다 AI는 코드 생성을 민주화한다. 엔지니어링 판단을 민주화하지는 않는다. 더 유능한 AI가 더 그럴듯한 옵션을 생성할수록, 그것을 평가할 도메인 전문성이 더 중요해진다. 코딩 머신 함정은 AI의 한계가 아니다. 거울이다.