한번은 AI에게 브랜드 웹사이트를 만들어 달라고 요청한 적이 있습니다. 처음 보기에는 그럴싸해 보였지만, 실제로 중요한 부분들은 모두 망가져 있었습니다. 헤더에는 정확히 두 개의 링크만 표시되었습니다. 어디에도 "About" 페이지는 없었습니다. 백엔드에는 관리자 패널이 존재했지만, 프론트엔드에는 그곳에 도달할 수 있는 버튼이나 경로가 전혀 없었습니다. 서버 측은 작동했지만, 사용자 측은 그렇지 않았습니다.

이런 상황을 겪는 대부분의 사람들은 AI가 게을러졌거나 토큰 제한에 걸렸다고 가정합니다. 하지만 그런 것이 아닙니다. 문제는 구조적인 것입니다. AI 코딩 도구는 내부적 일관성을 감시하도록 설계되었습니다. AI는 "내가 선언한 모든 것이 서로 일치하는가?"라고 묻습니다. 하지만 "이런 종류의 결과물이 포함되어야 할 모든 내용을 갖추고 있는가?"라고 묻지는 않습니다. 만약 당신이 브랜드 사이트에 두 개의 페이지를 언급한다면, 모델은 그 두 페이지가 서로 연결되어 있는지를 성실하게 확인합니다. 링크가 제대로 연결되면 작업이 완료되었다고 간주합니다. 브랜드 사이트에는 About 페이지, 신뢰 지표(trust signals), 또는 문의 경로가 필요하다는 내재적인 개념이 AI에게는 없습니다. AI의 머릿속에는 표준이 없습니다.

저는 이 해결책을 **완결성 기준(Completeness Baseline)**이라고 부릅니다.

완결성 기준이란 특정 결과물이 반드시 포함해야 할 항목들을 정리한 표준 체크리스트를 의미합니다. 결과물을 생성한 후, 도구의 내부적인 "완료" 감각을 믿는 대신, 이 외부 표준에 비추어 실제 출력을 검증하는 것입니다.

세 가지 계층을 통한 검증

모든 누락된 요소가 똑같이 명백한 것은 아닙니다. 유용한 기준은 세 가지 별개의 계층을 점검합니다.

존재 여부(Existence). 해당 부분이 실제로 존재하는가? 매우 기본적인 이야기처럼 들리겠지만, AI는 대시보드 페이지를 생성하지 않은 채 대시보드 페이지를 참조하는 내비게이션 래퍼(wrapper)를 기분 좋게 만들어낼 수도 있습니다. 참조는 존재하지만, 대상은 존재하지 않는 것입니다.

도달 가능성(Reachability). 실제 사용자가 실제로 그곳에 도달할 수 있는가? 숨겨진 관리자 패널이 전형적인 증상입니다. 코드베이스에는 경로와 컴포넌트가 모두 존재할 수 있지만, 메뉴 항목, 버튼 또는 리다이렉트가 인터페이스에 이를 노출하지 않을 수 있습니다. 사용자가 일반적인 사용 과정에서 우연히라도 마주칠 수 없다면, 그것은 실제로 존재하는 것이 아닙니다.

실체성(Substantiation). 표면 뒤에 실제 데이터나 구조가 있는가? 페이지는 로드되지만 자리 표시자(placeholder) 텍스트만 있고 이미지 업로드 슬롯이 없다면, 그것은 코스튬을 입은 해골과 같습니다. 이미지 슬롯이나 편집 가능한 텍스트 필드가 없는 About 페이지는 HTML이 깔끔하게 렌더링되더라도 완성된 것이 아닙니다.

이 세 가지 계층은 서로 다른 종류의 공백을 잡아냅니다. 존재 여부는 사라진 신발을 찾아냅니다. 도달 가능성은 옷장에 갇힌 신발을 찾아냅니다. 실체성은 밑창이 없는 신발을 찾아냅니다.

유형별 기준

하나의 기준이 모든 프로젝트를 커버할 수는 없습니다. 무엇을 만들고 있는지 분류하고, 해당 카테고리의 타협할 수 없는 필수 요소를 정의해야 합니다.

브랜드 사이트에는 특정 섹션과 도달 가능한 페이지가 필요합니다. About, Contact, 개인정보 보호 링크, 그리고 모든 주요 뷰를 실제로 노출하는 내비게이션 등을 생각하십시오.

API에는 문서화, 철저한 에러 코드, 그리고 속도 제한(rate limits)이 필요합니다. 성공 시에는 200 OK를 반환하고 그 외 모든 경우에 일반적인 500 오류를 반환하는 작동하는 엔드포인트는 완성된 API가 아닙니다. 그것은 위험 요소입니다.

자동화에는 로그와 장애 알림이 필요합니다. 워크플로우가 새벽 2시에 중단되었는데 사람이 실행 기록을 확인하기 전까지 아무도 모른다면, 그 자동화는 불완전한 것입니다. 관측 가능성(Observability)은 보너스 기능이 아닙니다. 그것은 결과물의 일부입니다.

카테고리를 정하고 나면 기준은 저절로 만들어집니다. 어려운 점은 코드가 생성된 후에 이를 강제하는 것입니다.

유지되는 설계 규칙

저는 이 아이디어를 중심으로 저만의 워크플로우를 재구축했고, 프로젝트가 서서히 무너지는 것을 방지하는 세 가지 실질적인 규칙을 정립했습니다.

기능 제약적 설계(Capability-gated design). 특정 도구나 생성된 모듈을 사용하기로 결정하기 전에, 그것이 실제로 무엇을 할 수 있는지 파악하십시오. 만약 컴포넌트 라이브러리에 네이티브 모바일 드로어(drawer) 지원이 없다면, AI가 해당 기능이 존재한다고 가정하고 전체 내비게이션 체계를 생성하게 두지 마십시오. 기능이 누락되었을 때 시스템이 깨지는 대신, 우아하게 성능을 낮추며(degrade gracefully) 작동해야 합니다. 경계를 먼저 파악하십시오. 그리고 그 안에서 설계하십시오.

공용 엔진, 프라이빗 값(Public engine, private values). 무거운 작업에는 공용 엔진을 사용하되, 런타임에 당신의 프라이빗 데이터, 설정, 관습(conventions)을 주입하십시오. 이렇게 하면 개인 또는 회사의 방식이 생성된 스캐폴드(scaffold)와 분리되어 안전하게 유지됩니다. AI는 프레임을 만들고, 당신은 유리를 끼워 넣는 것입니다. 이를 통해 모델이 당신의 실제 표준을 위반하거나 민감한 패턴을 공개 학습 컨텍스트로 유출하는 가정을 하드코딩하는 것을 방지할 수 있습니다.

제안하되, 자동으로 진행하지 마십시오. AI가 다음 단계를 제안하게 하되, 최종 선택은 반드시 사람이 하도록 강제하십시오. 실행 흐름은 자동화하되, 판단은 결코 자동화하지 마십시오. 모델이 데이터베이스 마이그레이션, 인증 체계, 결제 훅을 한 번에 자동으로 생성할 때, 당신은 감독을 희생하여 편의성을 얻게 됩니다. 도구가 계획을 제시하게 만드십시오. 버튼을 누르는 것은 개발자가 하게 하십시오.

작업에 적합한 모델 선택하기

여러 모델을 대상으로 테스트해 본 결과, 가치의 차이가 명확하게 갈리는 것을 확인했습니다. 저렴한 모델은 기계적인 대량 작업을 놀라울 정도로 잘 처리합니다. 보일러플레이트, 반복적인 컴포넌트, 구조적 스텁(stub)을 사용자가 타이핑하는 것보다 훨씬 빠르게 뽑아냅니다. 반면, 비싼 모델은 절제력을 보여줄 때에만 그 값을 합니다. 가짜 해결책을 지어내는 대신 실제 결여된 부분을 지적할 때 프리미엄 옵션의 진가가 드러납니다. 누락된 API 엔드포인트에 대해 환각(hallucination)을 일으켜 임시방편을 만들어내는 모델은 위험합니다. 반면, "이 워크플로우에는 정의되지 않은 웹훅 타겟이 필요합니다"라고 멈춰서 말하는 모델은 비용을 지불할 가치가 있습니다. 양이 아닌 통찰력에 비용을 지불하십시오.

마법을 쫓지 말고 시스템을 구축하십시오

더 큰 모델을 투입하거나 더 많은 프롬프트 기술을 사용하는 방식으로 AI의 공백을 메우려 하지 마십시오. 베이스라인(baseline)으로 해결하십시오. 그 공백은 역량의 문제가 아니라 기대치의 문제입니다.

누락되는 블록을 방지하려면 다음 세 가지를 수행하십시오.

코드가 작성되기 전에 시스템에 완성도 베이스라인을 제공하십시오. 이를 작업 옆에 두는 물리적인 체크리스트로 만드십시오.

컨벤션을 재사용 가능한 구성 요소로 만드십시오. 템플릿, 린트(lint) 규칙 또는 사전 구축된 스캐폴드(scaffold)를 통해 베이스라인을 강제하면, AI는 사용자의 표준을 추측하려 애쓰는 대신 올바른 상태에서 시작하게 됩니다.

판단의 주도권은 사람이 갖되 흐름은 자동화하십시오. 반복적인 작업은 기계에 맡기십시오. 결정은 맥락을 이해하는 사람의 몫으로 남겨두십시오.

제 작업 방식을 바꾼 마지막 습관 하나를 소개합니다. 만약 동일한 설계 결정을 일곱 번 내렸다면, 그것을 일회성 선택으로 취급하는 것을 멈추십시오. 그것은 반복이 아니라 법칙입니다. 이름을 붙이십시오. 규칙으로 만드십시오. 문서화하십시오. 패턴을 명문화하면, 여덟 번째에 AI가 그 패턴에서 벗어날 가능성을 제거할 수 있습니다.

이 프레임워크의 출처와 원문 탐구 내용은 여기에서 확인할 수 있습니다.

동일한 문제를 해결하고 있는 다른 사람들과 의견을 나누고 싶다면, GyaanSetu learning community에 참여할 수 있습니다.