AI 도구를 도입하면 생산성이 오른다는 말은 이제 상식처럼 들린다. 하지만 막상 실무에 붙여보면 금방 깨닫는다. 도구를 켜는 것과 그 도구가 예측 가능하게 작동하게 만드는 것은 전혀 다른 과제라는 사실을. 최근 세 가지 사례가 그 간극을 정확하게 드러낸다.
자동화를 믿었더니 컨텍스트가 오염됐다
VSCode용 Claude Code 확장을 위한 세션 관리 도구 Throughline을 만든 개발자가 dev.to에 흥미로운 실패 회고를 공유했다. 핵심은 간단하다. Claude Code의 SessionStart 훅에서 source 필드를 읽으면 새 세션인지 /clear 이후 재시작인지 구분할 수 있어야 했는데, VSCode 확장 환경에서는 /clear를 쳐도 source가 항상 startup으로 덮어씌워진다는 것이다. GitHub 이슈 #49937로 추적 중인 알려진 버그다.
문제는 이 버그를 우회하려는 시도에서 본격적으로 꼬이기 시작했다. 마지막 활동 시각의 시간 차이로 추론하는 휴리스틱을 붙였더니, 병렬로 열린 두 창이 동시에 '최근 활성 세션' 후보가 됐다. VSCode를 재시작해도 트랜스크립트가 남아 있어 '최근'처럼 보였다. 프로세스 트리를 추적하려 했지만 CLI와 확장 간 프로세스 구조가 달랐다. 결론은 명확했다. 탐지할 수 있는 조건 자체가 존재하지 않는다.
그래서 개발자가 선택한 방법은 자동 감지를 포기하고 명시적 선언으로 전환하는 것이었다. /tl이라는 슬래시 커맨드를 만들어, 사용자가 세션을 이어가고 싶을 때만 직접 타이핑하도록 했다. 배턴을 넘기는 구조다. 다음 세션 시작 시 1시간 이내에 배턴이 놓여 있으면 이전 컨텍스트를 상속하고, 그렇지 않으면 새 세션으로 시작한다.
더 인상적인 건 그다음 개선이다. 컨텍스트를 '읽는' 경험과 '이어가는' 경험은 사용자가 체감하는 품질이 다르다는 것을 발견했다. 그래서 /tl을 입력하는 순간 현재 Claude가 직접 "다음 액션, 현재 가설, 미해결 이슈, 진행 중 TODO"를 마크다운 메모로 작성하게 하고, 마지막 턴의 extended thinking 블록까지 함께 저장해 다음 세션 최상단에 주입했다. 결과적으로 다음 Claude는 "아, 앞서 X 테스트를 작성하기로 했으니 바로 시작하겠습니다"라고 말하며 이어간다. 이건 로그를 읽는 게 아니라 진짜로 이어가는 것이다.
프롬프트를 믿으려면 입력을 먼저 통제해야 한다
LLM 기반 웹 스크래핑 구현기도 같은 교훈을 다른 각도에서 조명한다. 가격 비교 도구를 만들던 개발자는 CSS 셀렉터와 정규식이 사이트 배포마다 무너지는 경험을 반복한 끝에 GPT-4에게 HTML을 직접 파싱시키는 방향으로 전환했다.
초기 시도는 실패했다. 원본 HTML을 그대로 넘기면 토큰 비용이 폭발하고, 모델이 "추천 상품" 섹션의 가격을 메인 상품 가격으로 혼동하는 환각이 발생했다. html2text로 단순화하면 구조가 손실돼 메인 콘텐츠와 푸터 광고를 구분하지 못했다. 결국 돌파구가 된 건 입력 전처리와 few-shot 프롬프트의 조합이었다.
BeautifulSoup으로 스크립트·스타일·네비게이션·푸터를 제거하고 의미 있는 태그만 남긴 단순화된 DOM 트리를 구성하면 토큰을 약 70% 줄이면서 구조는 보존할 수 있다. 여기에 3~5개의 도메인 특화 예시를 시스템 프롬프트에 하드코딩하고, temperature를 0으로 고정해 결정론적 추출을 유도했다. 이 조합이 핵심이었다. LLM에게 "무엇을 추출하라"가 아니라 "이 맥락에서 가격이 의미하는 것이 무엇인지"를 가르친 것이다.
물론 트레이드오프는 있다. GPT-4 기준 건당 $0.01~0.03, 응답 지연 1~3초, 레이아웃이 복잡하면 여전히 환각이 발생한다. 하지만 셀렉터를 수동으로 유지보수하는 비용과 비교하면 현실적인 선택지다. 핵심은 LLM의 능력을 믿기 위해 그 전제 조건인 입력 품질을 먼저 설계했다는 점이다.
플랫폼 수준에서도 신뢰는 설계의 문제다
Microsoft Build 2026에서 발표된 내용도 같은 맥락의 거시적 버전이다. Microsoft는 이번 행사에서 AI 에이전트 플랫폼의 핵심 업데이트를 공개하면서, 기능 확장 못지않게 신뢰와 거버넌스 인프라에 상당한 비중을 할애했다.
ASSERT(정책 기반 안전성 평가 프레임워크)와 Agent Control Specification(에이전트 동작의 통제 지점 표준화)은 오픈소스로 공개됐다. 코드명 MDASH는 100개 이상의 에이전트를 동원해 데이터 흐름, 비즈니스 로직, 익스플로잇 체인을 추론하고 맥락 기반 수정 방안을 제시한다. Microsoft IQ라는 컨텍스트 레이어는 GitHub Copilot, Microsoft Foundry, Copilot Studio 전반에 걸쳐 조직 내부 지식과 외부 지식을 에이전트에 연결하는 구조다.
특히 Agent 365 for local agents는 Microsoft Entra·Defender·Purview를 단일 제어 평면으로 통합해, 에이전트가 어디에 호스팅되든 어떤 프레임워크 위에 돌아가든 동일한 관찰·통제·보호를 적용한다. 에이전트를 배포하는 것과 그 에이전트를 믿을 수 있게 운영하는 것이 다른 문제임을 플랫폼 설계 수준에서 인정한 셈이다.
자동화 vs 명시적 선언, 그 트레이드오프의 본질
세 사례를 관통하는 공통 축이 있다. 자동화는 탐지 가능한 조건이 있을 때만 신뢰할 수 있다. Throughline 개발자가 솔직하게 인정했듯, 명시적 선언이 이상적인 해법이어서가 아니라 자동 탐지 조건이 깨졌기 때문에 선택한 타협이다. 그럼에도 불구하고 오작동을 0으로 줄이는 결과는 분명히 더 나은 사용자 경험을 만들었다.
LLM 스크래핑도 마찬가지다. 모델의 이해 능력을 믿기 전에 입력 구조를 신뢰할 수 있게 만드는 것이 먼저였다. Microsoft의 플랫폼 거버넌스 레이어도 에이전트의 능력을 키우기 전에 그 행동을 관찰하고 통제할 수 있는 구조를 먼저 놓는 방향이다.
프론트엔드 개발자 입장에서 이건 꽤 직관적인 교훈이다. 컴포넌트가 예측 불가능하게 렌더링되면 로직이 아무리 정교해도 신뢰할 수 없다. AI 도구도 다르지 않다. 컨텍스트가 불분명하면 모델이 아무리 강력해도 결과를 믿기 어렵다. 좋은 컴포넌트 설계가 상태를 예측 가능하게 만드는 것처럼, 좋은 AI 워크플로우 설계는 컨텍스트를 예측 가능하게 만드는 일이다.
AI 도구의 신뢰성은 사후 검증이 아니라 사전 설계에서 온다
빠른 프로토타이핑과 AI 도구 도입이 개발 루프를 가속화하는 건 분명하다. 하지만 속도가 붙을수록 오작동의 파급도 커진다. 세션 컨텍스트가 조용히 오염되거나, 스크래퍼가 엉뚱한 가격을 뽑거나, 에이전트가 의도치 않은 데이터에 접근하는 일은 모두 신뢰 설계 없이 자동화만 켰을 때 나타나는 증상이다.
앞으로 AI 에이전트가 더 많은 작업을 위임받을수록, 개발자가 진짜로 투자해야 하는 곳은 더 강력한 모델이 아니다. 컨텍스트를 명확하게 경계 짓는 구조, 입력을 통제하는 전처리 레이어, 에이전트 행동을 관찰하고 개입할 수 있는 거버넌스 설계다. 도구를 켜는 건 쉽다. 그 도구가 언제 어디서 어떻게 작동할지를 예측 가능하게 만드는 것, 그게 진짜 AI 워크플로우 설계다.