빌드 실패: Kiro와 Claude는 내가 요청한 것을 정확히 전달했지만, 그것은 내가 원했던 것이 아니었다

공개적으로 빌드(Building in public)한다는 것은 로봇들이 잘못된 것에 대해 훌륭한 작업을 수행한 부분을 보여주는 것을 의미합니다.

Agentis Lux의 배포(deploy)는 성공했습니다. 초록색 체크 표시, 오류 없음, 사이트 라이브 상태. 비포 앤 애프터(before-and-after)를 위한 "이전" 사진을 찍기 위해 내 사이트를 스캔했는데, 스캐너는 62점이라는 점수를 돌려주었습니다.

다음 사이트에서도 62점을 돌려주었습니다. 그리고 그다음 사이트도요. 매번 점수도 같고, 발견된 내용도 같았습니다. 심지어 체크아웃 버튼이 없는 사이트에서 "체크아웃 버튼"에 대한 발견 사항까지 포함해서 말이죠.

빌드는 작동했습니다. 그것은 내가 몇 주 전에 작성하고 버렸던 스캐너 버전을 실행하고 있었습니다. 그 이후에 내가 만든 모든 것은 저장소(repo)에 앉아 있었고, 병합(merged)되었고, 테스트되었지만 배포되지는 않았습니다. 배포 파이프라인(deploy pipeline)은 5월에 딱 한 번 실행되었고, 그 이후로는 다시 실행되지 않았습니다. 그리고 나는 전혀 알아차리지 못했습니다!

따라서 라이브 사이트는 자신감 넘치고, 잘 테스트되었으며, 완전히 초록색인 스텁(stub)이었습니다.

기술적으로, 아무것도 잘못되지 않았습니다. 그 부분이 내가 계속해서... 계속해서... 계속해서 곱씹고 있는 부분입니다...

간극을 주의하세요!

나는 AI 에이전트(AI agents)와 함께 빌드합니다. 나는 지시하고, 그들은 생성합니다. 한 에이전트는 인프라(infrastructure)를 작성하고, 다른 에이전트는 이를 감사(audit)하며, 나는 호출(calls)을 하고 병합(merge)합니다. 빠르고 훌륭하며, 실패 모드(failure mode)는 내가 예상했던 것과 다릅니다.

나는 에이전트들이 실수를 할 것이라고 예상했습니다. 하지만 그들은 대부분 실수하지 않습니다. 대신 그들이 하는 일은, 내가 요청한 것이 내가 원했던 것이 아닐 때, 내가 요청한 것을 정확하게, 올바르게 빌드하는 것입니다. 버그는 코드에 있는 것이 아닙니다. 버그는 나의 지시(instruction)와 나의 의도(intention) 사이의 간극에 있으며, 에이전트는 그 간극을 가장 문자 그대로 사실인 것으로 채워버립니다. 바로 이 현상인 컨텍스트 엔지니어링(context engineering)은 AWS Summit에서 열린 Anthropic의 강연에서도 언급되었습니다.

이 경우 인간 오케스트레이터(orchestrator)... 즉, 제가 반박합니다. "배포하라고 말했지만, 파이프라인이 5월 이후로 실행되지 않았는데, 현재 코드를 재배포(redeploy)하라는 뜻이었나요?" 에이전트는 "배포 성공"이라고 말합니다. 왜냐하면 배포가 실제로 성공했기 때문입니다. 에이전트는 내가 물어본 질문에 답한 것입니다. 나는 나의 사각지대에 명확히 놓여 있던 잘못된 질문을 던졌던 것입니다.

나는 일주일 동안 한 프로젝트에서 이 일을 네 번이나 겪었습니다. 매번 같은 형태였습니다.

네 번 모두 맞으면서 동시에 틀렸던 순간들

출시된 스텁 (The stub that shipped). 모든 사이트에서 똑같이 돌아온 62점, 마치 '사랑의 블랙홀 (Groundhog Day)' 같은 점수였습니다. 인프라는 실재했고, 테스트는 통과(green)했으며, 배포도 작동했습니다. 단지 내가 뒤에 남겨두었던 코드가 배포되었을 뿐입니다. "배포되었는가?"라는 질문에는 '예'가 맞았습니다. "내가 만든 것이 배포되었는가?"가 내가 묻는 것을 잊어버린 질문이었습니다. [교훈: 가정하지 마세요.]

세 개의 문, 그중 하나만 진짜. 나의 스캐너는 세 가지 종류의 입력값을 받습니다: URL, 코드 저장소 (code repo), API 명세 (API spec). 인터페이스에는 이를 위한 세 개의 탭이 표시되었습니다. 깔끔하고 명확하며, 설계가 의도한 그대로였습니다. 오직 URL 탭만 연결되어 있었습니다. 나머지 두 개는 내가 준 명세(세 개의 탭을 기술함)에 따라 구축되었고, 나는 나중에 URL 스캐닝만 먼저 출시하기로 결정했으면서 인터페이스를 그에 맞춰 업데이트하지 않았습니다. 그래서 방문자가 "API spec"을 클릭하고 무언가를 입력하면, 정중한 벽에 부딪히게 됩니다. 탭 자체는 정확했습니다. 나의 범위(scope)는 이동했지만, 탭은 그 소식을 듣지 못했던 것입니다. [교훈: Kiro와 Claude는 내 마음을 읽을 수 없습니다!]

엔지니어만이 읽을 수 있는 결과물들. 나의 전체 타겟 오디언스는 AI로 무언가를 만드는 사람들이며, 이들은 <ul>이 무엇인지 모를 수도 있습니다. 스캐너의 결과물은 "ul 또는 ol로 감싸이지 않은 반복되는 형제 요소 (repeated sibling elements)"와 같은 식으로 말했습니다. 그것은 정확한 결과입니다. 하지만 내가 이 도구를 만든 사람에게는 쓸모없는 정보이기도 합니다. 나는 정확하고, 기술적이며, 군더더기 없는 결과물을 요청했습니다. 나는 그것을 얻었습니다. 다만 "나의 실제 사용자가 이것을 읽을 수 있는가"를 묻는 것을 잊었습니다. [교훈: 당신이 구축하고 있는 대상이 이론적인 존재가 아니라, 실제 사람인 최종 사용자임을 잊지 마세요.]

아무것도 렌더링하지 못한 카드. 소셜 카드 라우트(social card route)를 구축하고, 배포하고, 작동까지 시켰습니다. 이미지를 저장했더니 0바이트 파일이 생성되었습니다. 해당 라우트는 웹에서 세 개의 폰트(font)를 가져왔는데, 그중 하나가 완전히 실패하는 대신 빈 값으로 돌아오자 이미지 렌더러(image renderer)에 쓰레기 데이터가 입력되어 아무것도 생성되지 않은 것입니다. 폰트 실패를 처리하기로 되어 있던 catch 블록은 실행되지 않았습니다. 왜냐하면 fetch(가져오기)가 실패하지 않았기 때문입니다. 그것은 빈손으로

하지만 모델이 "그들이 구축하고 나는 지켜본다"가 아니라 "나는 지시하고, 그들이 생성한다"인 데에는 이유가 있습니다. 지시(Direction)는 한 번 건네주고 끝내는 일회성 명령이 아닙니다. 그것은 작업물을 의도(intent)에 비추어 지속적으로 검토하며 "비슷하지만, 이건 아니야"라고 말하는 연속적인 행위입니다. 에이전트(agents)들은 "당신이 요청한 정확한 것"을 수행하는 데 매우 탁월합니다. 무엇을 요청할지 알고, 답변이 기술적으로는 완벽하지만 조용히 틀렸을 때를 알아차리는 것은 여전히 나의 몫입니다.

배포(deploy)는 성공했습니다. 내가 생각했던 배포는 아니었지만 말입니다. 그리고 이제 나는 두 번 확인해야 한다는 것을 압니다.

이 네 가지 사례는 모두 에이전트 준비 상태 스캐너(agent-readiness scanner)인 Agentis Lux를 구축하는 과정에서 발생했습니다. 그렇습니다. 에이전트가 무엇을 읽을 수 없는지 다른 사람들에게 알려주는 도구가 스텁(stub)을 배포하고, 깨진 탭을 숨기고, 빈 카드를 렌더링(render)했습니다. 제가 계속해서 실수하는 것을 지켜보고 싶다면 공개된 곳에 있습니다: [https://github.com/earlgreyhot1701D/perseus-clew].

AI 보조. 인간 승인. NLP 기반.

Kiro, Claude, 그리고 실제 출력물을 수없이 확인하며 구축됨.