AI 프롬프트의 모순을 방지하는 방법

이미 보았거나, 곧 보게 될 것입니다

당신은 AI를 활용해 무언가를 구축하고 있습니다. 모든 것이 잘 진행되고 있습니다. 기능들은 빠르게 나타나고, 코드는 깔끔하며, 애플리케이션은 잘 작동합니다. 당신이 필요한 것을 설명하면, AI가 이를 구현하고, 당신은 다음 단계로 넘어갑니다.

50개의 프롬프트(Prompt)를 작성했을 때, 혹은 100개, 200개쯤 되었을 때 — 무언가 고장 납니다. 극적으로 고장 나는 것은 아닙니다. 일관되어야 할 동작이 일관되지 않습니다. 초기에 설정된 규칙이 하류(downstream) 어딘가에서 위반되고 있습니다. 고객이 시스템의 다른 부분과 모순되는 답변을 생성하는 엣지 케이스(edge case)를 발견합니다.

당신은 원인을 파헤칩니다. 각 위치의 코드는 합리적으로 보입니다. 두 구현 모두 작성될 당시에는 말이 되었습니다. 하지만 둘 다 맞을 수는 없습니다. 어딘가에서, 어떻게든, 애플리케이션이 무언가가 작동하는 방식에 대해 서로 양립할 수 없는 두 가지 믿음을 갖게 된 것입니다.

즉각적인 본능은 프롬프트를 수정하는 것입니다. 다음에는 더 명시적으로 작성하자. 더 구조적으로 만들자. 컨텍스트(Context)에 더 주의를 기울이자. AI에게 더 나은 지침을 주면 이런 일은 다시 일어나지 않을 것입니다.

그 본능은 틀렸습니다. 그리고 그 본능에 따라 행동하는 것 — 더 주의 깊은 프롬프팅(Prompting), 더 엄격한 템플릿(Template), 더 긴 컨텍스트 윈도우(Context Window) — 은 다음 모순을 지연시킬 뿐, 방지하지는 못할 것입니다. 왜냐하면 모순은 프롬프팅에서 발생한 것이 아니기 때문입니다. 그것은 프롬프팅이 닿을 수 없는 어딘가에서 발생했습니다.

이 글은 그것이 실제로 어디에서 오는지에 관한 것입니다. 그리고 AI보다 오래되었고, AI에 앞서 등장한 프레임워크(Framework)보다도 오래되었으며, 동일한 문제를 계속 재발견하고 동일한 해답을 잊어버리는 산업계에 의해 지속적으로 묻혀온 해결책에 관한 것입니다.

프롬프트가 문제가 아닙니다

모순이 실제로 어떤 모습인지 보여드리겠습니다.

B2B 영업 플랫폼의 사례를 들어보겠습니다. 구축 초기 단계인 프롬프트 75번에서는 '주문 (Order)'이 무엇인지 정의합니다. 주문은 단일 고객에게 속하며, 단일 배송지로 배송되고, 단일 청구 담당자에게 인보이스 (Invoice)가 발행된다는 내용입니다. 깔끔하고 단순하며, AI는 이를 정확하게 구현합니다. 이후 주문과 관련된 모든 프롬프트 — 할인 계산, 배송 추정, 인보이스 생성, 이행 추적 (Fulfilment tracking), 고객 알림 — 는 모두 그 가정을 바탕으로 작성되었습니다. 이 프롬프트들 중 틀린 것은 하나도 없습니다. 모두 당시 이해되었던 지형 (Terrain)과 일치합니다.

8개월 후, 다른 개발자가 새로운 요구 사항을 맡게 됩니다. 기업 고객들이 단일 주문을 여러 부서로 나누어야 하며, 각 부서마다 고유한 배송지와 비용 센터 (Cost centre)를 가져야 한다는 요구였습니다. 프롬프트 235번은 다중 주소 주문 지원을 요청합니다.

AI는 이를 정확하게 구현합니다. 국지적으로는 합리적입니다. 하지만 AI는 방금 '주문'이 무엇인지 재정의해 버렸습니다. 하나의 주소에 속하는 대상에서 여러 주소에 속할 수 있는 대상으로 말입니다. 밑바닥의 지형이 변한 것입니다. 배송지, 인보이스 수신자, 또는 고객 식별 정보와 관련된 75번과 235번 사이의 모든 프롬프트는 더 이상 존재하지 않는 토대 위에 구축되었습니다.

프롬프트 235번을 작성하는 개발자는 이 사실을 모릅니다. 그들은 프롬프트 75번 당시에 그 자리에 없었습니다. 8개월은 팀 구성이 바뀌기에 충분한 시간이며, 원래의 가정이 더 이상 프로젝트에 참여하지 않을 수도 있는 누군가의 기억 속에만 존재하기에 충분한 시간입니다. 그들이 참고할 수 있는 산출물 (Artifact)도 없었습니다. 그 가정은 문서로 기록된 적이 없었기 때문입니다. 그것은 모두가 헤엄치고 있던 물과 같았습니다 — 더 이상 그렇지 않게 되기 전까지는 말입니다.

그렇다면 어디를 살펴봐야 할까요? AI는 두 구현 모두 정확하게 작성했습니다. 프롬프트들도 모두 합리적이었습니다. 지시 시점에는 아무런 실수가 없었습니다. 모순은 프롬프트 사이의 공간, 즉 '주문'이 실제로 무엇인지에 대한 전체적인 모델 — 가정되었으나 정의된 적은 없는 모델 — 속에 존재합니다.

그리고 이 연쇄 반응은 단지 이 두 개의 프롬프트에만 국한되지 않습니다. 그 사이에 존재하는 모든 프롬프트가 해당됩니다. 보고 (Reporting), 할인 (Discounting), 이행 (Fulfilment), 알림 (Notifications) — 이 모든 것들은 단일 주소(single address)라는 가정하에 작성되었습니다. 이 중 명백히 고장 난 것은 아무것도 없습니다. 하지만 이 모든 것들은 기업 고객이 처음으로 부서 간 통합 주문 (multi-department order)을 넣을 때 비로소 드러날 방식으로 모두 잘못되어 있습니다.

더 나은 프롬프트 작성 (Prompting)으로는 이를 해결할 수 없습니다. 존재 여부조차 모르는 모순을 바로잡는 프롬프트를 작성할 수는 없습니다. 명시적으로 정의된 적 없는 모델에 대해 AI에게 일관성을 유지하라고 요구할 수도 없습니다. 문제는 지시 사항의 품질이 아닙니다. 문제는 지시 사항이 일관성을 유지할 수 있는 대상(something)이 부재한다는 점입니다.

재구축 (Rebuilding)이 효과가 없는 이유

재구축하려는 본능은 이해할 수 있습니다. 애플리케이션은 엉망이고, 로직은 흩어져 있으며, 아무도 무엇이 어디에 있는지 모릅니다. 처음부터 다시 시작해서 이번에는 제대로 해보자는 생각이죠.

하지만 이번에 제대로 하려면 이번에는 도메인 (Domain)을 올바르게 이해해야 합니다. 그리고 이전에는 도메인을 올바르게 이해하지 못했습니다. 이는 팀이 무능해서가 아니라, 도메인을 올바르게 이해하려면 그것을 구현하고, 조정하고, 모순에 부딪히고, 도메인 소유자들과 함께 이를 해결하며, 다시 구현하는 과정이 필요하기 때문입니다. 그 과정에는 시간이 걸립니다. 더 세심한 계획만으로는 이를 대체할 수 없습니다.

그러한 과정 없는 재구축은 동일한 오해들을 더 깨끗한 코드베이스 (Codebase)로 재구성할 뿐입니다. 새로운 시스템은 더 높은 우연적 복잡성 (Accidental complexity) — 즉, 이전 시스템의 교훈이 방어적 패턴 (Defensive patterns)으로 인코딩된 상태 — 을 안고 시작하며, 근본적인 모순은 이제 더 깊은 곳에 파묻힌 채 여전히 남아 있게 됩니다.

이것은 AI의 실패가 아닙니다. 이것은 지도 없이 구축했을 때 나타나는 예측 가능한 결과입니다. AI는 지시받은 대로 정확히 수행하고 있습니다. 문제는 지시받은 내용에 중심(center)이 없다는 것입니다. 즉, 모든 지침이 일관성을 유지해야 하는 도메인에 대한 단일하고 일관된 명시적 모델 (explicit model)이 없습니다. 그러한 중심이 없다면 모순은 단순히 발생 가능한 수준을 넘어 필연적인 것이 됩니다. 그리고 그 어떤 재구축이나 재프롬프팅 (re-prompting)도 사후적으로 그러한 중심을 만들어낼 수는 없습니다.

중심이 먼저 존재해야 합니다.

Fred Brooks가 알고 있었던 것

중심이 먼저 존재해야 합니다. Fred Brooks는 60년 전에 그 이유를 규명했으나, 업계는 그 시간의 대부분을 그를 무시하며 보냈습니다.

Brooks는 소프트웨어의 두 가지 복잡성 (complexity)을 구분했습니다. **본질적 복잡성 (Essential complexity)**은 문제 자체에 내재된 복잡성입니다. 즉, 비즈니스 규칙, 도메인 제약 조건, 주문 (Order)의 생명 주기, 고객의 자격 규칙 등이 이에 해당합니다. 이는 제거될 수 없습니다. 당신이 어떤 도구를 사용하든, 어떤 아키텍처 (architecture)를 선택하든 상관없이 존재합니다. 비즈니스는 그 자체로 복잡하며, 그 복잡성은 어딘가에 반드시 표현되어야 합니다.

**우연적 복잡성 (Accidental complexity)**은 그 외의 모든 것입니다. 프레임워크 (frameworks), 간접 참조 (indirections), 이유 없이 적용된 패턴들, 그리고 동작이 실제로 어디에 속해야 하는지 아무도 결정하지 않아 존재하는 서비스들이 이에 해당합니다. 우연적 복잡성은 문제에 내재된 것이 아닙니다. 그것은 접근 방식에 의해 도입된 것입니다. 그리고 본질적 복잡성과 달리, 이는 줄이거나 완전히 피할 수 있습니다.

이러한 구분은 무엇이 영구적이고 무엇이 교체 가능한지를 정의하기 때문에 중요합니다. 올바르게 모델링된 애플리케이션의 본질적 복잡성은 그것이 실행되는 모든 프레임워크, 그것에 대해 내려진 모든 인프라 (infrastructure) 결정, 그리고 그것을 다루는 모든 팀보다 더 오래 지속되어야 합니다. 그것이 영구적인 부분입니다. 그 주변의 모든 것은 교체 가능한 부분입니다.

업계가 프레임워크, 아웃소싱, AI와 관련하여 계속해서 겪고 있는 문제는 — 부수적 복잡성 (accidental complexity)은 보이지 않게 축적되는 반면, 본질적 복잡성 (essential complexity)은 지도화되지 않은 채로 남아 있다는 점입니다. 비계 (scaffolding)는 점점 커지고, 도메인 (domain)은 축소됩니다. 결국 시스템은 엄청나게 복잡해지지만 그 누구도 진정으로 이해하지 못하는 상태가 되는데, 이는 복잡성이 시스템이 해결하기 위해 구축된 문제가 아니라 지원 구조 (support structure)에 존재하기 때문입니다.

강과 지형

요구사항 (Requirements)은 움직임을 설명합니다. 사용자가 무언가를 하면, 무언가가 발생하고, 다른 무언가에 통지가 전달됩니다. 사용자 스토리 (User stories)는 움직임입니다. 프로세스 다이어그램 (Process diagrams)도 움직임입니다. 심지어 이벤트 기반 아키텍처 (event-driven architecture)조차도 — 그 개념적 핵심은 — 기술적인 모자를 쓰고 있는 움직임입니다. 소프트웨어 명세 (software specification)의 전체 전통은 흐름 (flows)을 설명하는 것을 중심으로 구축되어 있습니다.

흐름은 강입니다. 그리고 강은 지형 (terrain)을 따릅니다.

강은 풍경 그 자체가 아닙니다. 강은 물이 풍경을 발견하고 저항이 가장 적은 경로를 택할 때 발생하는 현상입니다. 풍경을 바꾸면 강은 이동합니다. 강은 원인이 아니라 결과입니다. 강만을 모델링한다면 당신은 실재하는 무언가를 포착한 것이지만, 그것은 기저의 풍경이 바뀔 때마다 변하게 될 무언가입니다.

지형은 사물이 존재하는 방식 (are)입니다. 분수계 (watershed). 계곡 (valley). 두 배수 시스템을 나누는 능선 (ridge). 이것들은 계절이 바뀌거나 근처에 새로운 도로가 건설된다고 해서 변하지 않습니다. 이것들은 강보다 앞서 존재하며, 강보다 더 오래 지속될 것입니다.

소프트웨어에서 지형은 도메인 (domain)입니다. 주문 (Order)이 실제로 무엇인지. 고객이 자격을 갖춘다는 것이 무엇을 의미하는지. 계약이 어떤 의무를 생성하고 어떤 이벤트가 그 의무를 해소하는지. 이러한 것들은 새로운 결제 제공업체가 등장하거나 이행 (fulfilment) 프로세스가 재편된다고 해서 변하지 않습니다. 지형은 강보다 수년, 때로는 수십 년 동안 더 오래 지속됩니다.

프롬프트 75는 강(river)이었습니다. 프롬프트 235도 강이었습니다. 둘 다 강로서는 말이 되었습니다. 하지만 두 프롬프트는 서로 모순되었습니다. 그 아래에 지형(terrain)이 없었기 때문입니다. 즉, 두 강이 모두 흘러가야 하는 '명령(Order)'의 실제 모습에 대한 공유된 모델이 없었습니다. 지형이 없으면 각 강은 자신만의 사적인 지형학을 갖게 됩니다. 결국 두 강은 만나게 되고, 물은 결코 가서는 안 될 곳으로 흘러가 버립니다.

결여된 중심은 바로 지형입니다. 해결책은 강을 만들기 전에 지도부터 만드는 것입니다.

도메인 전문가의 강

자연스러운 대응책은 다음과 같습니다: 도메인 전문가(domain experts)와 대화하십시오. 요구사항(requirements)을 철저히 파악하십시오. 구축하기 전에 비즈니스를 이해하십시오. 그들이 지형을 정의하게 하십시오.

이것은 의도 면에서는 옳지만, 실행 면에서는 지속적으로 틀리고 있습니다. 그리고 그 이유는 매우 중요합니다.

도메인 전문가는 자신이 자라온 도시를 아는 사람처럼 자신의 도메인을 알고 있습니다. 그들은 지도를 그릴 수는 없어도 그 안을 완벽하게 항해할 수 있습니다. 그들은 자신들이 무엇을 하는지 압니다. 어떻게 하는지도 압니다. 그들에게는 수십 년간 축적된 실무 경험과 판단력이 있습니다. 하지만 그들은 그것을 움직임, 즉 강(rivers)으로서 알고 있습니다. 왜냐하면 움직임이야말로 업무가 나타나는 방식이기 때문입니다. 아무도 자신의 직업을 지형으로 경험하지 않습니다. 그들은 직업을 자신이 수행하는 행위로 경험합니다.

더 깊은 문제가 있습니다. 도메인 전문가의 현재 구현 방식은 이미 그들이 사용하는 도구에 의해 형성되어 있습니다. 프로세스를 관리하는 스프레드시트(spreadsheet), 기존 시스템이 예외 케이스(edge case)를 처리할 수 없어서 존재하는 수동 단계, 너무 오래전에 표준 관행이 되어버려 아무도 그것이 임시방편(workaround)이었다는 사실을 기억하지 못하는 우회책 — 이 모든 것이 강입니다. 도구가 강요한 제방에 의해 형성된 강들입니다.

비즈니스가 스프레드시트에서 애플리케이션(application)으로 전환될 때, 순진한 접근 방식은 스프레드시트의 프로세스를 코드(code)로 그대로 재현하는 것입니다. 강은 명확하게 보이고, 도메인 전문가는 이를 정확하게 설명할 수 있으며, 구현은 일치합니다. 작동도 잘 됩니다. 그리고 스프레드시트의 기술적 한계는 그러한 한계가 없는 소프트웨어(software) 안에 영구적으로 인코딩(encoded)되어 버립니다.

우회책(workaround)을 만들게 했던 제약 조건은 사라졌습니다. 하지만 우회책은 남아 있습니다. 이제 그것은 시스템을 지탱하는 하중을 견디는 요소(load-bearing)가 되었습니다.

도메인 전문가(domain expert)와 나누어야 할 올바른 대화는 "이것을 어떻게 하나요?"가 아닙니다. 그것은 "이것이 왜 일어나야 하나요?"입니다. 프로세스(process)가 아니라 의무(obligation)를 묻는 것입니다. 강(river)이 아니라, 강이 흘러가는 지형적 특징(terrain feature)을 묻는 것입니다.

그 질문은 불편합니다. 그것은 현재의 프로세스가 불필요하거나, 최적화되지 않았거나, 혹은 역사적인 우연일 수도 있음을 암시하기 때문입니다. 도메인 전문가들은 자신의 업무 방식에 전문적인 정체성(professional identity)을 투영합니다. "왜"라는 질문은 그들에게 그 정체성 밖으로 나와 그 밑에 있는 지면을 조사하라고 요구합니다. 많은 이들이 한 번도 그런 요구를 받아본 적이 없습니다. 어떤 이들은 질문을 받았을 때, 그 "왜"가 예상보다 더 모호하다는 사실을 발견합니다. 즉, 같은 팀의 두 사람이 서로 다른 답을 내놓거나, 규칙의 원래 이유가 수십 년 전에 잊혔거나, 정책처럼 보였던 것이 실제로는 습관에 불과하다는 사실을 깨닫게 됩니다.

"왜"라고 물을 수 있고, 지형이 보일 때까지 그 불편함을 견뎌내며 지속하는 개발자는 소프트웨어 개발에서 가장 어렵고 가치 있는 일을 하고 있는 것입니다. 이것은 기술적인 기술(technical skill)이 아닙니다. 고고학(archaeology)에 더 가깝습니다.

맥락적 중심 (The Contextual Center)

지형이 지도화되었을 때 — 즉, 도메인이 사물이 무엇을 '하는가(do)'가 아니라 무엇 '인가(are)'의 수준에서 이해되었을 때 — 맥락적 중심(contextual center)을 구축하는 것이 가능해집니다.

맥락적 중심은 도메인 모델(domain model)입니다. 데이터베이스 스키마(database schema)가 아닙니다. 서비스 레이어(service layer)도 아닙니다. DTO(Data Transfer Object)의 집합도 아닙니다. 도메인이 실제로 무엇인지 — 즉, 엔티티(entities), 그들의 불변성(invariants), 그들의 의무(obligations), 그들의 생명주기(lifecycles) — 를 도메인 전문가가 읽고 인식할 수 있는 코드로 표현한, 살아있고 정직한 인코딩(encoding)입니다.