그것은 내가 이미 두려워하는 법을 배운 바로 그 버그를 찾아냈다...

며칠 전, 나는 AI 모델에게 내 프로젝트의 모든 파일 — 18개월 치의 설계 문서(design docs), 결정 로그(decision logs), 청크(chunk) 단위까지 세분화된 코퍼스(corpus) 회계 데이터 — 을 건네주며 단 하나의 지시를 내렸다: 적대적인 레드팀 (red-team) 역할을 수행하라. 내 아이디어는 망할 것이라고 가정하고, 그것이 정확히 어떻게 망하게 될지 말해라. 자비는 없다. 아첨도 없다.

AI는 그 명령을 따랐다. 그리고 그 판결은 내가 예상했던 것보다 더 최악이었다. 그것이 잔인해서가 아니라, 그것이 옳았기 때문이며, 내 회사의 핵심에서 찾아낸 버그가 _내가 이미 내 코드에서 한 번 발견하고, 수정했다고 스스로 축하했던 바로 그 버그_였기 때문이다.

이것은 빌딩 인 퍼블릭 (building in public)의 솔직한 버전이다. 출시 당일의 하이라이트 영상이 아니다. 결산이다. 내가 무엇을 만들었는지, 첫 번째 버그, 두 번째 버그, 그리고 내가 지금 그것에 대해 무엇을 하고 있는지에 대한 전체 이야기다.

내가 무엇을 만들었는지, 그리고 그것이 왜 나를 거의 무너뜨릴 뻔했는지

나는 라고스(Lagos)에서 엄격한 제로 예산 스택(zero-budget stack)으로 DeepForge를 1인 개발하고 있다. 첫 번째 제품인 SynthForge는 프롬프트 엔지니어링 (prompt-engineering) 합성 엔진이다. 무엇이든 물어보면 출처가 명시된 상세한 답변을 얻을 수 있다. 그 밑단에는 궁극적으로 일련의 도메인 엔진들을 구동하기 위해 설계된 재사용 가능한 검색 코어 (retrieval core)가 자리 잡고 있다. 그것이 비전이다.

시작할 때, 나는 대부분의 사람들이 하는 방식을 따랐다. 나는 '더 많은 것'을 위해 최적화했다. 더 많은 소스, 더 넓은 범위 — 분명 더 큰 코퍼스 (corpus)가 더 나은 기반이 될 것이라고 생각했다. 그래서 나는 모든 것을 흡수했다: GitHub, 천 개의 arXiv 논문, 품질 필터를 거친 Reddit, 공식 문서, LessWrong, Hacker News, Stack Overflow, YouTube 스크립트. 10개의 소스. 거의 20,000개의 청크 (chunks). 그것은 실행되었고, 작동했다. 눈에 보이는 모든 지표상으로, 나는 결과물을 만들어냈다.

나는 이런 방식으로 구축하는 데 어떤 비용이 드는지 솔직하게 말하고 싶다. 왜냐하면 화려한 버전은 그 비용을 삭제해 버리며, 그 삭제는 거짓말이기 때문이다.

전기부터 시작하자. 모든 것이 그 위에 구축되어 있기 때문이다. 여기서 발생하는 모든 좌절의 근간은 아무도 예측할 수 없는 일정에 따라 들어왔다 사라지는 전력이다. 당신은 긴 임베딩 (embedding) 실행을 준비한다. GPU가 없어 몇 시간 동안 CPU 작업을 해야 하는 상황에서, 실행을 완료할지 여부는 당신이 아니라 전력망이 결정한다. 몇 시간을 기다린 실행을 중단시켜 버리는 그 정적을 두려워하는 법을 배우게 된다. 그다음은 네트워크다. 한 번이면 끝날 업로드가 네 번 실패하여 다섯 번이나 반복된다. 필요한 다운로드가 80%에서 끊겨서 처음부터 다시 시작한다. 당신은 모든 스크립트를 재개 가능한 (resume-safe) 방식으로 작성한다. 이는 교과서에서 배운 모범 사례 (best practice) 때문이 아니라, 연결은 반드시 끊길 것이고 작업은 그 상황에서도 살아남아야 하기 때문이다.

그리고 때로는 마일스톤 (milestone)에 도달하는 유일한 방법이 물리적으로 자리를 뜨는 것뿐일 때도 있다. 안정적인 전력과 무료 인터넷이라는 두 가지를 같은 장소에서 동시에 얻을 수 있는 곳을 찾아, 노트북을 챙겨 도시를 가로질러 이동했던 밤들이 있다. 그곳에서 밤을 새워 일한다. 그래야만 두 가지가 모두 유지되기 때문이며, 그 대안인 집에서 모바일 데이터를 소모하고 발전기 연료를 태우는 것은 예산이 제로인 상황에서 계속 감당할 수 없는 비용이기 때문이다. 나는 그렇게 해왔다. 그리고 내일도 다시 그럴 것이다.

이곳은 비상 발전기와 아무도 신경 쓸 필요가 없는 광섬유 라인을 갖춘 스탠퍼드(Stanford)나 MIT, 혹은 샌프란시스코의 어느 연구실이 아니다. 이곳은 가공되지 않은 날것 그대로의 라고스(Lagos)다. 이 중 어느 것도 불평이 아니다. 이것은 프로젝트의 날씨이며, 이 글의 모든 문장은 그 날씨 속에서 구축되었다.

첫 번째 버그: 완료된 것처럼 보였던 것이 사실은 아니었다

여기서 프로젝트가 처음으로 전환점을 맞이했다.

나는 결국 내 파이프라인 (pipeline)이 코퍼스 (corpus)에 실제로 무엇을 쓰고 있는지 확인하러 갔다. 내가 쓰도록 설계한 것이 아니라, 디스크에 기록된 실제 바이트 (bytes)를 확인한 것이다. 그리고 오염 (contamination)을 발견했다. 결코 자격이 없어야 할 202개의 레코드 (records)가 어쨌든 유입되어 있었다.

그 원인을 추적해 보니, 참으로 겸허해지는 근본 원인이 밝혀졌다. 나는 입학 계약 (admission contract) — 즉, 모든 청크 (chunk)가 진입하기 전에 반드시 충족해야 하는 규칙 — 을 _명시(specified)_해 두었지만, 정작 그 계약을 _실제 쓰기 경로 (live write path)에 연결 (wired)_하지 않았던 것이다. 규칙은 스키마 (schema)에 존재했다. 스키마는 실재했다. 하지만 실제로 기록을 수행하는 코드는 그 규칙들을 완전히 우회하고 있었다. 나는 법을 써놓고 정작 문에 연결하지는 않았던 것이다.

한번 그 형태를 보고 나면, 어디에서나 그것이 보이기 시작한다. 잘못된 필드에 레코드 (records)를 입력하여 조용히 고아 (orphaning)로 만드는 라이터 (writer), 오류를 발생시키지 않으면서 실패를 유발하는 유령 디렉토리 (ghost directory) — 그저 나중에 혼란스러운 숫자로 나타나는 조용히 잘못된 결과들. 이 중 그 어떤 것도 일반적인 의미에서의 버그 (bugs)는 아니었다. 코드는 실행되었고, 아무것도 충돌 (crash)하지 않았다. 모든 것은 _규율 (discipline)_의 실패였다. 즉, 내가 진실이라고 믿었던 것과 실제로 연결되고 검증된 것 사이의 간극이었다.

그래서 나는 잘못된 것처럼 느껴졌지만 결과적으로 옳았던 일을 했다. 나는 빼버렸다. 모든 청크가 검증 가능한 라이선스 (licence)를 지니고, 증명 가능하게 자격을 갖추지 않으면 아무것도 진입할 수 없는 '실패 시 차단 (fail-closed)' 기준점으로부터 다시 구축했다. 그 깨끗한 코퍼스 (corpus)는 1,231개의 청크였다. 거의 2만 개에 달하던 것에서 1,200개로 — 94%를 삭제한 것이다. 그리고 답변은 더 좋아졌다. 왜냐하면 알 수 없는 비율의 독 (poison)이 섞여 있는 2만 개를 대상으로 하는 검색 (retrieval)보다, 1,200개의 신뢰할 수 있는 청크를 대상으로 하는 검색이 더 뛰어나기 때문이다.

내가 얻은 교훈이자, 하나의 온전한 규율로 구축한 교훈은 이것이다: 단언(asserted)하지 말고, 연결(wired)하라. "내가 명시했다"는 것이 "시스템이 강제한다"는 뜻은 아니다. "채팅에서 검증했다"는 것이 "파이프라인 (pipeline)이 그것을 볼 수 있다"는 뜻은 아니다. 그 사이의 간극이 바로 내가 저지른 모든 잘못이 머물던 곳이었다. 나는 내 코드 속의 그 간극을 불신하는 데 진정으로 능숙해졌다.

그리고 나서, 나는 다른 곳에서는 그 간극을 찾는 것을 잊어버렸다.

전환점: 나 자신에게 칼끝을 겨누다

내가 믿는 것과 검증된 것 사이의 간극을 불신하는 법을 배웠기에, 나는 그 동일한 불신을 코드 자체가 아닌 프로젝트의 전제 (premise) 자체로 겨누기로 결심했다. 그래서 나는 AI에게 CIA 스타일의 레드팀 (red-team) 브리핑을 주었다. 내가 서 있는 모든 가정을 나열하고, 그것들이 얼마나 치명적인지에 따라 등급을 매기며, 각 하중을 견디는 핵심 가정(load-bearing assumption)에 대해 그것이 틀렸음을 증명할 수 있는 증거가 무엇인지 말해달라고 했다. 왜냐하면 그 증거를 지목할 수 없다면, 나는 분석이 아닌 믿음에 의존해 운영하고 있는 것이기 때문이다. 그다음, 18개월이 지나 이 프로젝트가 처참하게 실패했다고 가정하고 사후 분석 보고서 (post-mortem)를 작성하라. 그다음에는 나를 증오하는 자본을 확보한 경쟁사가 되어라. 그다음에는 비용을 지불했지만 속았다고 느끼는 고객이 되어라.

모든 권한을 부여했다. 모든 파일에 대하여. 나는 AI에게 그 정도의 문맥 (context)을 가지고 할 수 있는 가장 친절한 행동은 나에게 아첨하기를 거부하는 것이라고 말했다.

AI는 거부했다.

가차 없는 판결

AI가 찾아낸 것들을, 내가 온전히 책임져야 하기에 그 차가운 목소리에서 나의 목소리로 번역하여 여기에 기록한다.

코퍼스 (corpus)가 약속을 지키기에는 너무 빈약하며 — 나의 데이터가 이를 증명한다. SynthForge는 "무엇이든 물어보세요, 출처가 있는 답변을 드립니다"라고 약속한다. 하지만 코퍼스를 법적으로 배포 가능한 상태로 만드는 라이선스 게이트 (licence gate)가 코퍼스의 94%를 무너뜨렸고, 그 1,231개의 깨끗한 청크 (chunks) 중 깨끗한 arXiv 중추 (spine) 전체는 단 두 편의 논문뿐이다. 나머지는 책과 문서들이다. 배포 가능한 연구 중추가 논문 두 편뿐인 합성 엔진 (synthesis engine)은 코퍼스가 부족한 것이 아니라, 코퍼스가 거의 없는 수준이다. 약속과 코퍼스의 규모는 일치하지 않으며, 진실을 말하고 있는 것은 코퍼스다.

검증된 수요가 전혀 없으며 — 수요를 찾아낼 도구조차 존재하지 않는다. 18개월 동안 40회 이상의 빌드 세션을 거치는 동안, 나는 단 한 명의 인간이라도 비용을 지불할 의사가 있는지 테스트할 방법을 단 한 번도 만들지 않았다. 대기 명단 (waitlist)은 아무 곳에도 연결되지 않은 프런트엔드 스텁 (front-end stub)일 뿐이다. 여기서의 판결은 AI 정보의 공백이 아니다. 수요 측정 도구의 부재 자체가 바로 발견된 사실이다. 나는 입문서가 의미했던 정확한 의미로, 믿음에 의존해 운영하고 있었다.

도메인이 구축 과정 아래에서 부패하고 있다. 독립적인 기술로서의 프롬프트 엔지니어링 (Prompt engineering)은 모델 자체와, 내가 직접 사용하고 글을 쓰는 자동 최적화 도구 (auto-optimizers) 속으로 흡수되고 있다. 나의 스키마 (schema)에는 "지식 반감기 (Knowledge Half-Life)" 필드가 있는데, 이는 이 콘텐츠가 매우 빠르게 노후화된다는 것을 내가 알고 있기 때문이다. 2022년의 사고의 사슬 (chain-of-thought) 논문은 해자 (moat)가 아니다. 그것은 박물관의 전시물일 뿐이다.

그리고 자본 배분이 역전되어 있다. 버스 지수 (Bus factor) 1, 파트타임, 석사 과정 중간 단계, 인프라 스트레스 상황 — 그리고 모든 희소한 시간은 회복 가능한 리스크 (엔지니어링의 정확성, 나중에 언제든 수정 가능)로 흘러가고, 존재론적인 리스크 (누구도 이것을 원하는가)는 굶주리고 있다. 내 머릿속에 박힌 문구는 이것이다: 나의 검증 규율은 진정으로 탁월하며, 동시에 지금까지 기록된 것 중 가장 정교한 형태의 생산적 미루기일지도 모른다. 아무도 사기로 동의하지 않은 자동차의 구동계를 연마하는 것 말이다.

그러더니 AI는 바이럴이 될 법한 1점짜리 리뷰를 작성했다. 나는 그것을 스크린샷으로 찍어두었다. 왜냐하면 모든 단어가 현재 상태의 제품에 대한 정당한 타격이었기 때문이다:

★☆☆☆☆ "아무것도 배우지 않기에 가장 엄격하게 인용된 방법." 비용을 지불하고 다섯 가지 질문을 했지만, 세 번이나 "코퍼스 (corpus)가 불충분하다"는 답변을 들었다. 검색하기를 거부하는 검색 엔진에 돈을 지불한 셈이다. Claude에게 똑같은 다섯 가지 질문을 무료로 던졌더니 — 더 나은 답변을 주었고, 소스 계층에 대한 해석적 춤 (interpretive dance) 따위는 없었다. 한 남자의 라이선스 준수 (licence compliance)를 위한 9달러짜리 기념비다. 출처 인용은 결점 없이 완벽하다. 다만 인용할 내용이 없을 뿐이다. 대장간질 (Forging)을 하려면 분명 철이 필요할 텐데 말이다.

그리고 가장 아팠던 인용 트윗은, 그것이 사실이었기에 더욱 그랬다: 신발 상자에 달린 금고 문.

AI가 나에게 돌려준 한 문장의 근본 원인은 다음과 같았다: 나는 내 발밑에서 도메인이 부패하는 동안, 수요 측면을 단 한 번도 계측 (instrumenting)하지 않은 채, 18개월 동안 공급 측면의 엔진을 결점 없는 표준으로 구축했다.

버그는 동일한 버그였다

이 부분 때문에 나는 노트북을 내려놓고 한동안 어둠 속에 앉아 있어야 했다.

나는 이미 이 실패를 알고 있다. 나는 그것에 이름을 붙였다. 그것은 내가 내 코퍼스 (corpus)의 94%를 삭제하면서까지 고치려 했던 바로 그 버그다.

그 오염은 내가 명시했지만 결코 연결(wired)하지 않은 계약이었다. 수요의 격차는 내가 가정했지만 결코 계측(instrumented)하지 않은 시장이었다. 이 둘은 동일한 실패다. 내가 틀렸음을 알려줄 수 있는 단 하나의 테스트를 구축하는 대신, 내가 그렇게 설계했기 때문에 그것이 사실이라고 믿어버린 것 말이다. 거부 프로토콜(refusal protocol), 2단계 키 검증(two-key verification), 페일 클로즈드 라이선스 게이트(fail-closed licence gate) — 나는 _엔지니어링 (engineering)_의 모든 구석에 엄격함을 연결해 두었지만, 이 모든 사업에서 가장 중요한 단 하나의 가정 — 누군가가 이것을 원할 것이라는 점 — 은 완전히 연결하지 않은 채로 남겨두었다. 단언했다. 믿음이었다.

나만의 시그니처 규율(signature discipline). 그것이 비즈니스가 될 수 있을지를 결정하는 단 한 곳을 제외한 모든 곳에 적용되었다.

코드 수준에서는 결점 없이 완벽할 수 있지만, 회사 수준에서는 순진할 수 있으며, 후자는 전자가 결코 겪지 않을 방식으로 치명적이다. 나는 문이 잠겼는지 확인하느라 너무 바빠서, 아무도 들어오려고 시도하는지조차 확인하지 못했다.

지금부터 내가 하고 있는 일

여기서 나의 방식은 결코 절망이 아니었다. 전장에서 매장당하는 것보다 작전실(war room)에서 망신을 당하는 것이 낫다 — 그리고 나는 작전실을 요청했다. 그래서 이제 전환점이 찾아왔고, 나는 이 글을 게시함과 동시에 그것을 실행하고 있다.

앞으로 30일 동안, 나는 코퍼스 (corpus) 코드를 건드리지 않을 것이다. 데이터 수집(ingestion), 임베딩 (embedding), 전환 (cutover) 모두 없다. 빌드는 동결된다 — 파괴적인 것은 없으며, 닻(anchor)은 유지된다 — 그리고 모든 시간은 내가 18개월 동안 피해왔던 단 하나의 질문에 투입될 것이다: 낯선 이 한 명이 돈을 지불할 것인가?

구체적으로 말하자면: 나는 말뭉치(corpus)가 정직하게 지킬 수 있는 약속으로 다시 쓰고 있다. "프롬프트 엔지니어링 (prompt engineering)에 대해 무엇이든 물어보세요"가 아니다. 그것은 나의 빈약한 말뭉치가 뒷받침할 수 없는 범위이며, 별점 1점짜리 리뷰가 달린 이유이기도 하다. 대신, 좁지만 방어 가능한 것, 즉 출처(provenance)가 실제로 필요한 사람들을 위한 큐레이션된, 라이선스 문제가 없는, 인용 가능한 (citable) 참조 자료를 만드는 것이다. 즉, 무료 모델이 이미 나보다 더 잘 처리하고 있는 표면적인 팁이 아니라, 부식되지 않는 깊고 체계적인 기술(craft)을 말한다. 무료 모델은 가짜 인용(citations)을 만들어내지만, 출처가 명확하고 라이선스가 깨끗한 엔진은 그렇지 않다. 이것은 전 세계적인 문제이며, 실질적인 차이점이다. 그 대상이 정확히 누구인지, 그리고 그들이 무엇에 비용을 지불할지는 향후 30일 동안 알아내야 할 과제이지, 내가 의자에 앉아 또 다른 가정을 내릴 문제가 아니다. 그리고 "출처를 밝히며, 모를 때는 모른다고 말한다"는 점은 리뷰가 비난했던 창피한 요소가 아니라, 서비스의 핵심 목적이 된다.

그래서: 나는 대기 명단(waitlist)을 실제로 작동시키려 한다. 저녁 한 끼 정도의 작업으로, 가장 중요한 질문 하나를 던질 것이다: 한 달에 9달러를 지불할 의사가 있습니까, 예 혹은 아니오. 나는 SynthForge를 단독으로, 무료로, 그리고 측정 가능한(instrumented) 상태로 출시하며, 더 어렵고 미완성된 제품에 묶어두려 했던 나 자신의 규칙을 깨뜨린다. 나는 까다로운 프롬프트 엔지니어링(PE) 질문을 던지는 사람들과 스무 번의 실제 대화를 나누며, 그들이 이미 사용 중인 모델이 무료임에도 불구하고 이 서비스에 비용을 지불할 것인지 생생한 목소리로 들을 것이다. 그리고 나는 데이터가 도착하기 전에 '실패 혹은 출시(kill-or-ship)' 기준을 작성해 두었기에, 스스로 골대를 옮길 수 없다. 만약 거의 아무도 지불할 의사가 없고 말뭉치가 실제 질문의 절반조차 답할 수 없다면, 나는 프레임워크를 전환하거나 프로젝트를 보류함으로써 신뢰성을 지킬 것이다. '27-Forge' 비전은 _유료 사용자 10명 달성 시 재개_라고 적힌 서랍 속으로 들어갈 것이다.

나는 한 달 안에 이 프로젝트를 접을지도 모른다. 그것이 정직한 이해관계다. 하지만 어느 쪽이든, 18개월간의 엄격하고 법적으로 깨끗한 엔지니어링은 기념비가 되는 대신 포트폴리오와 교훈이 될 것이다. 나는 날 끝에 담금질할 철(iron)도 없이 아름다운 칼날만을 만들어내는 데 또 다른 1년을 쓰는 것보다, 지금 당장 확인하는 쪽을 택하겠다.