품질만이 유일한 변수입니다
프로젝트 매니저의 역할은 네 가지 변수를 조율하는 것입니다: 범위, 시간, 비용, 그리고 품질. 고전적인 제약 삼각형 이론에 따르면 네 가지를 모두 최적화할 수는 없고, 두 가지만 선택할 수 있습니다. 빠르고 저렴하게 원한다면? 품질이 떨어집니다. 좋고 빠르게 원한다면? 비용이 올라갑니다. 이 삼각형은 자원이 제한된 환경에서 유용한 사고 모델입니다.
저는 자원이 제한된 환경에서 일하지 않습니다. 추론 속도로 코드를 생성하는 AI 에이전트, 전체 코드베이스를 담을 수 있는 컨텍스트 윈도우, 그리고 급여가 아닌 달러 단위의 세션 비용으로 일합니다. 제약 삼각형은 무너집니다.
에이전트가 몇 분 만에 기능을 구현할 수 있을 때, 질문은 “제대로 할 여유가 있는가?”가 아닙니다. 질문은 “왜 잘못된 방식으로 하겠는가?”입니다.
제거의 원칙
시간을 의사결정에서 제거하세요. “이게 얼마나 걸릴까?”가 아니라 “완성되었을 때 어떤 모습이어야 하는가?”를 물으세요. 첫 번째 질문은 납품 속도를 최적화합니다. 두 번째 질문은 결과물을 최적화합니다.
비용을 의사결정에서 제거하세요. 정확하고, 깔끔하고, 잘 테스트된 코드를 생산하는 세션의 비용은 편의적이고, 지저분하고, 테스트되지 않은 코드를 생산하는 세션의 비용과 같습니다. API은 품질과 무관하게 토큰당 동일한 요금을 부과합니다. 올바르게 하는 것의 한계 비용은 제로입니다.
노력을 의사결정에서 제거하세요. 에이전트는 지치지 않습니다. 백 번째 함수도 첫 번째 함수와 같은 능력으로 작성됩니다. 세션 후반에 편법을 정당화할 인간의 피로 곡선이 없습니다. 결과물의 품질은 지시의 품질과 주변 컨텍스트의 품질에 의해 제한되지, 경과 시간에 의해 제한되지 않습니다.
시간, 비용, 노력을 제거하면 무엇이 남을까요? 품질입니다. 품질만이 유일한 변수입니다.
실제로 의미하는 것
품질이 유일한 변수가 되면, 여러 일반적인 엔지니어링 결정이 자명해집니다:
테스트를 작성하세요. 특정 함수에 대한 테스트를 작성할지 말지에 대한 논쟁이 사라집니다. 에이전트가 몇 초 만에 테스트를 작성합니다. 한계 비용은 제로입니다. 한계 이익은 영구적인 검증입니다. 테스트를 작성하지 않는 것은 아무런 절감 없이 낮은 품질을 받아들이겠다는 선택입니다.
인접한 코드를 수정하세요. 버그를 수정할 때 주변 코드에도 관련 문제가 있는 경우가 많습니다: 일관성 없는 네이밍, 누락된 에러 처리, 오래된 패턴. 시간이 제약인 환경에서는 버그만 수정하고 인접 코드는 “나중에” 남겨둡니다. 품질이 유일한 변수일 때는 접촉한 모든 것을 수정합니다. 나중은 오지 않습니다. 지금은 무료입니다.
올바른 추상화를 사용하세요. 임시방편은 즉각적인 문제를 해결합니다. 올바른 추상화는 문제의 범주를 해결합니다. 시간이 제약인 환경에서는 임시방편이 오늘 출시되고 추상화는 영원히 출시되지 않습니다. 에이전트가 같은 세션에서 둘 다 구현할 수 있을 때, 임시방편에는 아무런 이점이 없습니다. 추상화를 선택하세요.
쓰기 전에 읽으세요. 시간이 제약인 환경에서 엔지니어들은 코드를 완전히 읽지 않고 수정하기도 하며, 부분적인 이해에 의존합니다. 에이전트가 전체 파일을 읽고, 패턴을 이해하고, 완전한 컨텍스트로 수정할 수 있을 때, 부분적인 이해로 작업할 이유가 없습니다. 전체 파일을 읽으세요. 패턴을 이해하세요. 그다음에 작성하세요.
미루지 마세요. TODO, FIXME, HACK은 미뤄진 품질의 표식입니다. 시간이 제약인 환경에서 미루기는 합리적입니다: 시간이 있을 때 나중에 고치면 됩니다. 품질이 유일한 변수일 때 미루기는 비합리적입니다. 에이전트가 여기 있습니다. 컨텍스트가 로드되어 있습니다. 수정 비용은 지금이나 나중이나 같습니다. 지금 하세요.
지로의 원칙
오노 지로는 70년 넘게 스시를 만들어 왔습니다. 그의 식당은 미쉐린 3스타에 열 개의 좌석뿐입니다. 메뉴도, 방법도 바꾸지 않았습니다. 70년간 매일 그 방법을 다듬어 왔을 뿐입니다.
누군가 지로에게 스시가 충분히 좋은지 물었을 때, 그 대답은 식당이 얼마나 바쁜지, 대기 고객이 몇 명인지, 생선이 얼마나 비쌌는지에 근거하지 않습니다. 스시가 자신의 기준에 부합하는지에 근거합니다. 기준은 절대적입니다. 상황은 무관합니다.
이것이 엔지니어링에 적용된 원칙입니다: 기준은 코드이지 스프린트가 아닙니다. 함수는 정확하고, 깔끔하고, 잘 테스트되었거나, 아니거나입니다. 마감일이 평가를 바꾸지 않습니다. 예산이 평가를 바꾸지 않습니다. 유일한 질문은 결과물이 기준에 부합하는지 여부입니다.
AI 에이전트는 소프트웨어 엔지니어링에서 이 원칙을 처음으로 실현 가능하게 만들었습니다. 에이전트 이전에 지로의 원칙은 이상에 불과했습니다. 완벽함의 인적 비용이 너무 높았습니다. 모든 편법에는 합리적인 정당화가 있었습니다: 목요일에 출시해야 하고, 예산이 바닥났고, 엔지니어가 지쳐 있습니다. 에이전트가 있으면 올바르게 하는 비용이 잘못하는 비용과 같습니다. 편법은 정당화를 잃습니다.
자부심 점검
사소하지 않은 모든 변경 후, 다섯 가지 질문을 합니다:
- 시니어 엔지니어가 이것을 존중할 것인가?
- 코드가 스스로를 설명하는가?
- 엣지 케이스가 처리되어 있는가?
- 적절한 수준의 단순성인가?
- 코드베이스를 발견했을 때보다 나은 상태로 남겼는가?
이 질문들은 정확성에 관한 것이 아닙니다. 정확성은 증거 게이트가 처리합니다. 자부심 점검은 장인 정신을 다룹니다. 아무도 유지보수하고 싶지 않은 정확한 코드는 질문 1에서 실패합니다. 이해하려면 주석이 필요한 교묘한 코드는 질문 2에서 실패합니다. 정상 경로는 처리하지만 에러 경로를 무시하는 코드는 질문 3에서 실패합니다.
질문 4가 가장 어렵습니다. “적절한 수준의 단순성”은 “가능한 가장 단순한 것”이 아닙니다. 한 줄짜리 임시방편이 적절한 추상화보다 단순하지만, 문제가 반복될 경우 임시방편은 잘못된 수준의 단순성입니다. 올바른 단순성은 가상의 미래 문제를 해결하지 않으면서 실제 문제를 해결하는 최소한의 복잡성입니다.
질문 5는 궤적에 관한 것입니다. 모든 세션은 코드베이스를 발견했을 때보다 나은 상태로 남겨야 합니다. 수정된 특정 파일뿐만 아니라 주변 컨텍스트까지: 업데이트된 테스트, 정리된 임포트, 수정된 주석, 제거된 데드 코드. 기준은 “작업을 완료했는가?”가 아닙니다. 기준은 “내가 여기 있었기 때문에 프로젝트가 더 나아졌는가?”입니다.
반론
명백한 반론이 있습니다: 속도가 중요합니다. 출시가 중요합니다. 절대 출시되지 않는 완벽한 코드베이스는 실제 문제를 해결하는 지저분한 코드베이스보다 못합니다.
이 반론은 품질과 속도가 반비례하는 세상에서는 맞습니다. AI 에이전트가 저품질 결과물과 같은 속도로 고품질 결과물을 생산하는 세상에서는 그 상관관계가 깨집니다. 품질과 속도는 독립 변수가 됩니다. 둘 다 가질 수 있습니다.
남은 트레이드오프는 시간이 아니라 주의력입니다. 전체 파일을 읽는 데는 주의력이 필요합니다. 증거 게이트를 실행하는 데는 주의력이 필요합니다. 자부심 점검을 적용하는 데는 주의력이 필요합니다. 에이전트의 시간은 무료입니다. 당신의 주의력은 유한합니다.
품질이 유일한 변수이지만, 주의력이 품질에 대한 제약 조건입니다. 해결책은 기준을 낮추는 것이 아닙니다. 해결책은 기준을 유지하는 데 드는 주의력 비용을 줄이는 인프라를 구축하는 것입니다: 일반적인 실패를 자동으로 잡아내는 훅, 품질 워크플로를 인코딩하는 스킬, 그리고 세션 간 컨텍스트를 전달하여 결정을 다시 도출하지 않아도 되는 메모리 시스템.
이것이 품질을 위한 복합 컨텍스트입니다. 각 인프라 조각이 다음 세션의 주의력 비용을 줄여줍니다. 충분한 세션이 쌓이면 기준이 스스로 유지됩니다.
FAQ
모든 소프트웨어 프로젝트에 적용되나요?
이 원칙은 AI 에이전트가 구현을 담당하는 프로젝트에 가장 직접적으로 적용됩니다. 전적으로 사람이 구현하는 프로젝트에서는 시간과 비용이 여전히 실질적인 제약 조건입니다. 에이전트 능력이 향상되고 인간의 구현 시간이 줄어들수록 이 원칙의 적용 가능성은 높아집니다.
프로토타이핑은 어떤가요?
프로토타입은 정의상 일회용입니다. 프로토타입의 품질 기준은 “조사하려는 질문에 답하는가?”입니다. 답이 예라면 코드 품질과 무관하게 프로토타입은 목적을 달성한 것입니다. 이 원칙은 지속될 코드에 적용되며, 폐기될 코드에는 적용되지 않습니다.
이건 그냥 완벽주의 아닌가요?
완벽주의는 아무것도 충족할 수 없는 무한한 기준입니다. 품질은 증거 게이트가 정의하는 유한한 기준입니다: 정확하고, 깔끔하고, 테스트되었고, 회귀가 없으며, 실제 문제를 해결하는 것. 기준을 충족하는 것은 달성 가능합니다. 초과하는 것은 불필요합니다. 기준은 높지만 무한하지 않습니다.
기술 부채는 어떻게 처리하나요?
만들지 않음으로써 처리합니다. 기술 부채는 미뤄진 품질입니다. 품질이 유일한 변수일 때 미루기는 정당화를 잃습니다. 에이전트가 지금 사용 가능합니다. 수정 비용은 지금이나 나중이나 같습니다. 에이전트가 생산한 기술 부채에는 이자율이 없습니다. 애초에 발생시킬 이유가 없기 때문입니다.
출처
여기서 설명한 철학은 일본의 쇼쿠닌 장인 정신 전통과 AI 엔지니어링 시리즈에 걸쳐 기록된 프로덕션 경험에 기반합니다. 구체적으로 참조한 구현:
- 증거 게이트: 완료 검증을 위한 6가지 기준
- 자부심 점검: 장인 정신 평가를 위한 5가지 질문
- 훅 시스템: 품질 인프라로서의 84개 훅 (Every Hook Is a Scar)
- 복합 컨텍스트: 품질의 주의력 비용을 줄이는 인프라 (Compound Context)