프롬프트를 잘 쓰는 시대는 이미 지났다
요즘 개발자들 사이에서 "AI를 잘 쓴다"는 말은 여전히 프롬프트 실력을 가리키는 경우가 많다. 더 정교한 지시문, 더 세밀한 역할 부여, 더 긴 예시. 그런데 솔직히 말하면, 그건 이미 2023년 레벨의 접근이다. 실제로 Claude Code나 Cursor를 프로덕션 워크플로우에 박아 넣고 쓰다 보면 금방 벽에 부딪힌다. 세션이 끊기면 모든 맥락이 사라지고, MCP 서버를 몇 개 연결하다 보면 컨텍스트 윈도우의 30%가 툴 정의만으로 소진되며, 어제 고쳐준 버그를 오늘 또 설명해야 한다. 이 문제들의 공통 원인은 하나다. 컨텍스트 아키텍처의 부재.
dev.to에서 주목할 만한 실무 경험들이 동시에 올라왔다. Presidio의 Michael Tuszynski가 6개월간 Claude Code 기반 프리세일즈 자동화 시스템을 구축하며 정리한 "Context Engineering" 접근법, MCP 프로토콜 위에 영구 메모리 레이어를 직접 개발한 Smara 프로젝트, 그리고 Claude Code 내부의 Tool Search 메커니즘 분석. 이 세 편의 글은 각각 다른 문제를 다루지만, 결국 하나의 질문으로 수렴한다. AI 코딩 도구를 실제로 어떻게 설계해야 제대로 작동하는가.
축 1. 스킬 파일 — 프롬프트는 소모품, 지식은 자산
Tuszynski가 지적하는 가장 흔한 실수는 도메인 지식을 프롬프트에 욱여넣는 것이다. "당신은 엔터프라이즈 세일즈 전문가입니다. 딜을 분석할 때 다음 47가지 요소를 고려하세요..." 이런 구조는 대화가 끝나는 순간 증발한다. 지식이 세션에 종속되기 때문이다.
대안은 스킬 파일이다. Claude Code의 플러그인 아키텍처가 지원하는 개념으로, 마크다운으로 작성한 재사용 가능한 의사결정 프레임워크를 말한다. .claude/skills/ 디렉토리 안에 자격 검토 기준, 가격 전략, SOW 검토 체크리스트 같은 파일들을 두고, 에이전트가 필요할 때 읽어서 적용하는 방식이다. 핵심은 이 파일이 버전 관리된다는 것. 팀이 프레임워크를 업데이트하면 이후 모든 세션이 자동으로 최신 버전을 참조한다. 프롬프트는 소모품이고, 스킬 파일은 자산이다.
여기에 더해 Tuszynski는 "실수를 인프라로 전환하라"고 강조한다. 에이전트가 틀렸을 때 프롬프트를 다시 쓰는 것이 아니라, 해당 실수를 시스템 설정 파일의 번호 매긴 규칙으로 영구 등록하는 것이다. 6개월 운영 후 39개의 규칙이 쌓였고, 시스템은 재학습 없이도 계속 똑똑해졌다. 실패가 곧 학습 데이터가 되는 구조를 설계한 셈이다.
축 2. 메모리 지속성 — 망각 비용을 측정하면 설계가 보인다
Smara 프로젝트가 출발한 지점은 냉정한 측정이었다. 세션 복원에 매번 20~25분 소요. MCP 서버 로딩으로 첫 프롬프트 입력 전에 이미 67,000 토큰 소진. 5명 팀 기준, 하루 약 7시간의 개발자 시간이 AI에게 "어제 한 일"을 재설명하는 데 증발한다. 한 달이면 3.5주치 공수다.
Smara는 MCP 프로토콜을 선택해 이 문제를 해결했다. 특정 도구에 종속되지 않고, Claude Code·Cursor·Windsurf 등 MCP 호환 클라이언트라면 어디서든 동일한 메모리 풀을 공유한다. smara_store, smara_search 두 개의 툴로 시작했지만, 결국 7개의 인지적 원시 연산으로 확장됐다. smara_forget(잘못된 기억 삭제), smara_relate(기억 간 연결), smara_recall(대화 시작 시 컨텍스트 자동 로드)처럼, AI가 메모리를 이해하는 것이 아니라 관리할 수 있도록 인터페이스를 설계한 것이다.
가장 흥미로운 부분은 에빙하우스 망각 곡선을 적용한 감쇠 스코어링이다. 단순 최신순이나 벡터 유사도 정렬이 아니라, 중요도와 경과 시간을 함께 고려해 기억의 "신선도"를 계산한다. 중요도 1.0의 기억은 반감기가 약 10일, 중요도 0.1이면 하루 만에 자연스럽게 흐릿해진다. 게다가 AI가 기억에 접근할 때마다 강도가 올라간다. "프로덕션 DB는 PostgreSQL 15 포트 5432"는 몇 주가 지나도 강하게 유지되고, "utils.ts 변수명 하나 바꿈"은 며칠 후 자연 소멸한다. 현재 Mem0, Zep 같은 경쟁 도구들 중 이 방식을 쓰는 곳은 없다고 한다.
축 3. 토큰 디퍼럴 — 도구 정의도 지연 로딩이 된다
MCP 서버 세 개를 연결하고 툴을 50개씩 올리면, 매 API 요청마다 툴 정의만으로 약 90,000 토큰이 소진된다. 200K 컨텍스트 모델에서 대화 시작 전에 45%가 날아가는 셈이다. Claude Code의 Tool Search 메커니즘은 이 문제를 지연 로딩 패턴으로 푼다.
작동 방식은 직관적이다. 토큰 임계값을 초과하면 대부분의 MCP 툴 정의를 API 요청에서 제외하고, 대신 ToolSearch라는 단일 툴만 전달한다. 모델이 특정 기능이 필요할 때 ToolSearch({ query: "github create issue" })를 호출하면, 시스템이 해당 툴의 전체 스키마를 다음 턴에 주입한다. 20턴 대화 기준으로 약 150만 토큰을 절약할 수 있다. 추가 비용은 검색 한 번당 약 200 토큰과 한 턴의 지연뿐이다.
세부 설계에서 놓치지 말아야 할 원칙이 있다. 시스템은 "불확실할 때 전부 로드"하는 방향으로 실패한다(fail closed, fail toward loading). 모델을 파악할 수 없거나 프록시 게이트웨이 환경이면 디퍼럴을 비활성화한다. 중요한 툴에는 alwaysLoad 플래그를 달아 항상 즉시 로드되도록 한다. 컨텍스트 압축 이후에도 발견된 툴은 스냅샷으로 보존된다. 편의가 아닌 안정성을 기본값으로 설계한 것이다.
시사점: 컨텍스트는 코드다
세 가지 접근을 관통하는 공통 원리는 하나다. 컨텍스트를 코드처럼 다뤄라. 구조화하고, 버전 관리하고, 검토하고, 의도적으로 로드하라. 마크다운 스킬 파일은 팀의 의사결정 기준을 코드화한 것이고, 메모리 감쇠 스코어는 정보 가치를 수식으로 모델링한 것이며, 툴 디퍼럴은 컴포넌트 지연 로딩과 동일한 논리를 AI 툴체인에 적용한 것이다. 우리가 오랫동안 프론트엔드에서 해온 일들—코드 스플리팅, 상태 관리, 캐시 전략—이 이제 AI 컨텍스트 설계에도 그대로 적용된다.
또 하나 주목할 점은 모델 라우팅이다. Tuszynski는 파일 정리 같은 단순 작업에 Haiku, 리서치·요약에 Sonnet, 전략 수립에 Opus를 배정한다. 가장 비싼 모델을 모든 작업에 쓰는 것은 가장 비효율적인 선택이다. 태스크 복잡도에 따른 모델 라우팅은 비용 절감이 목적이 아니라, 각 모델의 추론 능력을 적재적소에 배치하는 설계 결정이다.
전망: 설계 역량이 곧 AI 활용 역량
앞으로 AI 코딩 도구의 성능은 계속 올라가겠지만, 그 성능을 실제로 끌어내는 병목은 모델이 아니라 컨텍스트 아키텍처에 남을 것이다. 더 큰 컨텍스트 윈도우가 나와도 무엇을 그 안에 넣을지 설계하지 않으면 노이즈만 커진다. MCP 생태계가 확장될수록 어떤 툴을 언제 로드할지 정책이 없으면 토큰 비용만 폭증한다.
결국 가장 중요한 역량은 "AI에게 무엇을 시킬 것인가"가 아니라 "AI가 잘 작동할 수 있는 환경을 어떻게 설계할 것인가"다. 좋은 팀원은 명확한 역할, 접근 가능한 문서, 반복 실수를 줄이는 프로세스가 있을 때 최고의 성과를 낸다. AI 에이전트도 다르지 않다. 컨텍스트 설계는 코딩 실력 위에 얹는 부가 스킬이 아니라, AI 네이티브 워크플로우의 핵심 엔지니어링이다.