Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 31. 04:51

의도 계층 (The Intent Layer)

요약

사용자 신호와 코드 실행 도구 사이의 간극을 메우는 '의도 계층(Intent Layer)'의 필요성을 제안합니다. 단순한 프롬프트를 넘어, 흩어진 맥락을 구조화된 명세로 변환하여 올바른 코드를 생성하는 아키텍처를 설명합니다.

핵심 포인트

  • 프롬프트는 요청이지만, 의도는 명세(Specification)임
  • 사용자 신호와 실행 도구 사이의 맥락 누락 문제를 지적
  • 의도 계층은 비정형 신호를 구조화된 사양으로 계산함
  • 소프트웨어 스택이 3계층 아키텍처로 수렴하고 있음을 제시

소프트웨어 스택에는 간극이 존재합니다.

한쪽 끝에는 신호(signal)를 포착하는 도구들이 있습니다. Dovetail, Intercom, 사용자 조사 플랫폼 등—사용자가 _무엇을 필요로 하는지_를 알려주는 모든 것들입니다. 다른 쪽 끝에는 실행하는 도구들이 있습니다. Cursor, v0, Claude Code 등—지시 사항을 작동하는 소프트웨어로 변환하는 모든 것들입니다.

그 중간 지점이 압축되고 있습니다. 그리고 그 중간 지점이 바로 가장 중요한 작업이 일어나는 곳입니다: 무엇을 왜 만들 것인가를 결정하는 일 말입니다.

대부분의 팀은 이 과정을 건너뜁니다. 고객 피드백에서 바로 Cursor의 프롬프트(prompt)로 넘어갑니다. 그 결과: 잘못된 문제를 해결하는 코드, 혹은 맥락(context) 없이 문제를 해결하는 코드가 만들어집니다.

우리는 이 누락된 중간 단계를 **의도 계층 (the Intent Layer)**이라고 부릅니다.

┌─────────────────────────────────────┐
│         사용자 신호 (User Signal)                 │  ← 피드백, 마찰(friction), 조사
├─────────────────────────────────────┤
...

프롬프트는 의도가 아니다

프롬프트(prompt)는 요청입니다. 의도(intent)는 명세(specification)입니다.

프롬프트 (Prompt)의도 명세 (Intent Spec)
"결제 흐름을 추가해줘"전제 조건, 기대 결과, 예외 케이스, 사용자 마찰과의 추적 가능성
...

개발자가 Cursor를 열었을 때, 처음부터 맥락을 발명해내야 해서는 안 됩니다. 무엇을 왜 만들어야 하는지를 이미 계산해낸 시스템으로부터 정보를 가져와야 합니다.

프롬프트는 코드를 생성합니다. 의도 명세는 _올바른 코드_를 생성합니다.

간극이 존재하는 이유

오늘날 의도는 조직 전체에 흩어져 있습니다:

  • 조사는 Dovetail에 있습니다.
  • 명세(Specs)는 Notion이나 Google Docs에 있습니다.
  • 작업(Tasks)은 Jira나 Linear에 있습니다.
  • 맥락(Context)은 누군가의 머릿속에 있습니다.

사용자의 마찰을 구조화되고 기계가 읽을 수 있는 의도로 합성하는 단일 시스템이 없습니다. 이러한 도구들 사이의 각 인수인계(handoff) 과정에서 편차(drift)가 발생합니다. 각 해석 과정에서 오류가 발생합니다.

해결책은 스택에 또 다른 도구를 추가하는 것이 아닙니다. 그 도구들 위에 위치하여—신호를 합성하고, 의도를 구조화하며, 모든 하위 에이전트(agent)에게 맥락을 전달하는 계층(layer)을 만드는 것입니다.

의도의 세 가지 계층

우리는 소프트웨어 개발이 3계층 아키텍처(3-layer architecture)로 수렴하고 있다고 봅니다:

1. 의도 (Intention) — 가공되지 않은 신호 (The Raw Signal)

비정형 정보 (Unstructured information): 사용자 인터뷰, 고객 지원 티켓, 분석 데이터, NPS 설문조사. 서로 연결되지 않은 사일로 (Silos) 곳곳에 흩어져 있습니다. 이곳은 마찰 (Friction)이 표면화되는 지점이며, 제품이 사용자에게 실패하고 있다는 가공되지 않은 증거가 드러나는 곳입니다.

2. 구조 (Structure) — 계산된 의도 (Computed Intent)

이것이 바로 의도 계층 (Intent Layer) 그 자체입니다. 이는 추상적인 마찰을 공식화된 사양 (Specification)으로 변환합니다. 사용자에게 처음부터 사양을 작성하라고 요구하는 것이 아니라, 마찰 신호를 클러스터링 (Clustering)하고 증거에 기반한 구조화된 사양을 생성함으로써 이를 _계산 (Computing)_해냅니다.

**IntentSpec**은 문서가 아닙니다. 그것은 데이터 객체 (Data object)입니다:

objective:
  statement: "결제 단계에서의 장바구니 이탈 감소"
  success_criteria:
...

이것은 산문이 아닙니다. 이것은 계약 (Contract)입니다. 에이전트 (Agent)는 이를 바탕으로 실행할 수 있고, 사람은 이를 검토할 수 있습니다. 양측 모두 이것이 이행되었는지 검증할 수 있습니다.

3. 투영 (Projection) — 실행 (Execution)

사양이 실행 가능한 산출물 (Artifacts), 즉 코드, UI, API 문서, 테스트로 변환되는 단계입니다. Cursor, Claude Code, v0가 존재하는 영역입니다. 이들이 프롬프트 (Prompt) 대신 IntentSpec을 전달받으면, 추측하는 대신 명시적인 기준에 따라 실행합니다.

이것이 지금 중요한 이유

AI는 실행 비용을 저렴하게 만들었습니다. 과거에 와이어프레임 (Wireframe)을 두고 논쟁하던 시간 동안 이제는 작동하는 솔루션의 프로토타입 (Prototype)을 만들 수 있습니다. 이는 강력하지만, 위험한 환상을 만들어냅니다.

빌드가 즉각적으로 이루어질 때, 팀은 무엇을 만들고 있는지 정의하는 힘든 과정을 건너뛰게 됩니다. 빠른 실행은 부실한 의도를 가려버립니다. 번지르르하게 AI로 생성된 기능이 하루 만에 출시되지만, 정작 사용자가 그것을 정말 필요로 하는지 아무도 묻지 않았기 때문에 이탈률만 높이는 결과로 이어집니다.

이것이 바로 우리가 The Vibe Coding Hangover라고 불러온 현상입니다. 1인 개발자는 머릿속에 컨텍스트 (Context)를 유지할 수 있습니다. 하지만 여기에 PM, 디자이너, 그리고 세 명의 AI 에이전트를 추가하면 컨텍스트는 파편화됩니다. 프롬프트는 성공에 대한 공유된 정의가 없는 단순한 요청이 되어버립니다.

병목 현상 (Bottleneck)이 이동했습니다. 이제는 코드를 작성하는 것이 문제가 아닙니다. 어떤 코드를 작성할지 정의하는 것이 문제입니다.

PM의 역할이 변하고 있습니다

PM의 역할은 과거에 '번역'이었습니다. 고객과 대화하고, 문제를 종합하며, 사양(spec)을 작성하여 엔지니어에게 전달하는 것이었습니다. 그 가치는 압축(compression)에 있었습니다. 즉, 노이즈가 섞인 정성적인 입력을 받아 구조화된 출력물로 만들어내는 과정에 있었습니다.

하지만 그 압축 단계야말로 언어 모델(language models)이 매우 잘 수행하는 작업입니다. 에이전트(agents)가 잘 형성된 문제를 받아 작동하는 코드를 생성할 수 있게 되면, 사양이 곧 제품이 됩니다. PM의 역할은 인수인계 문서를 작성하는 것에서, 에이전트가 직접 실행할 수 있을 만큼 의도(intent)를 명확하게 형성하는 것으로 전환됩니다.

이는 격하가 아닙니다. 명확함(Clarity)은 장황함(verbosity)보다 어렵습니다. 정밀함(Precision)은 산문(prose)보다 어렵습니다.

의도 계층 (Intent Layer)의 역할

  1. 마찰(friction) 포착: 직관에만 의존하는 것이 아니라, 고객 지원 티켓, 리서치 녹취록, 분석 데이터 등 실제 사용자 신호로부터 마찰을 포착합니다.
  2. 의도 구조화: 명시적인 성공 기준(success criteria), 제약 조건(constraints), 예외 케이스(edge cases)를 포함하여, 버전 관리되는 기계 판독 가능(machine-readable) 사양으로 의도를 구조화합니다.
  3. 에이전트에게 공급: 에이전트가 실행하는 데 필요한 정보를 정확하게 공급하여 환각(hallucination)이나 이탈(drift)이 발생하지 않도록 합니다.
  4. 결과 검증: 배포 후 정의된 사양에 따라 결과를 검증합니다. 실제로 마찰이 감소했습니까?
  5. 기억 보존: 팀이 단순히 '무엇을' 만들었는지뿐만 아니라, '왜' 만들었는지를 알 수 있도록 기억을 보존합니다.

누가 의도를 소유하는가?

John Moriarty는 제품(products)에서 시스템(systems)으로의 전환에 대해 글을 쓴 바 있습니다. 새로운 디자인 역할에 대한 그의 프레임워크는 '시스템적 오케스트레이션(Systemic Orchestration)'입니다. 디자이너는 완성된 집이 아니라 벽돌, 설계도, 건축 규정을 제공합니다.

이는 제품 작업 전반에 적용됩니다. 디자이너, PM, 엔지니어는 모두 동일한 규율로 수렴하고 있습니다. 바로 에이전트가 충실하게 실행할 수 있을 만큼 충분한 구조를 갖추어 의도를 정의하는 것입니다.

누군가는 반드시 그 계층을 소유해야 합니다. 그것이 바로 우리가 Pathmode에서 만들고 있는 것입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0