확률적 도구 시대

 

 

 

Claude Code가 개발 워크플로우에 깊숙이 들어오면서 직접 타이핑하는 코드의 양이 줄었습니다. 요구사항을 전달하면 구조를 잡고, 코드를 짜고, PR 본문까지 작성해 주는 덕분에 효율이 높아진 것은 사실입니다.

 

하지만 시스템의 무결성을 책임지는 엔지니어로서, 이 도구를 실무에 적용할수록 근본적인 질문과 마주하게 되었습니다. 입력값에 따라 매번 다른 아웃풋을 뱉는 이 '확률적 도구'를 가지고, 어떻게 우리가 만드는 소프트웨어의 '결정론적 신뢰성'을 보장할 수 있을까요?

 

수많은 시행착오 끝에 내린 결론은 하나입니다. LLM 자체를 통제하려 들지 말고, LLM이 뱉어낸 결과를 검증하는 '외부 안전망'을 촘촘하게 짜서 최종 시스템의 정합성을 멱등하게 보장해야 한다는 점입니다. Claude Code를 사용하며 거쳤던 저의 생각을 공유합니다.

1. 생산성 향상과 창작 욕구

AI 도구의 제어 방식을 개선하고 효율 극대화를 위해 세 가지 단계를 거쳤습니다.

돌이켜보니 이는 생산성 향상이 아닌, 단순한 창작의 욕구를 채우기 위한 비효율적 행동이었습니다.

1-1. 멀티 에이전트 아키텍처의 한계와 단일화

초기에는 도메인별 서브 에이전트(백엔드, QA, 기획 등)를 구축하고, 이들을 조율하는 중앙 관리 에이전트를 두는 복잡한 멀티 에이전트 구조를 설계했습니다. 더 고도화된 자동화를 이루고 싶었기 때문입니다.

그러나 이 구조는 문맥이 파편화된다는 문제가 있었습니다. 서브 에이전트들은 조건이 조금만 부족해도 작업을 중단하거나 대기 상태로 멈춰버렸습니다. 결국 이들을 가동하기 위해 세부 규칙을 계속 추가해야 했고, 사람이 직접 오케스트레이션에 소모하는 리소스가 더 늘어났습니다. 결국 현재는 이러한 멀티 에이전트 구조보다 스킬과 같은 도구를 정교하게 제어하는 방향으로 선회했습니다.

 

1-2. '기억 누적 자동화'의 함정과 프롬프트 다이어트

(memory 이전) 단일 툴로 전환한 뒤, 세션이 끝날 때마다 대화 요약본을 전역 규칙 파일(.claude/my-memory)에 누적하여 저장해 주는 '메모리 관리 자동화 시스템'을 직접 구축해 사용했습니다. 새로운 도구와 자동화 파이프라인을 창조하는 재미에 깊이 빠져들었기 때문입니다.

 

하지만 이 자동화 훅은 예상치 못한 부작용을 낳았습니다. 매 세션마다 범용적인 규칙이 아니라 일회성 작업에만 필요한 데이터가 전역 규칙 파일에 누적되었습니다. 불필요한 맥락이 쌓이면서 오히려 답변 정확도가 떨어졌습니다.

 

돌이켜보니 이는 생산성 향상이 아닌, 단순한 창작의 욕구를 채우기 위한 비효율적 행동이었습니다. AI에게 기억을 자동으로 맡기는 환상을 버리고, 전역 파일에는 핵심적인 아키텍처 표준만 남긴 뒤 반복되는 범용 태스크는 제가 직접 선별하여 컨텍스트 파일로 관리하는 '프롬프트 다이어트'로 돌아왔습니다.

 

1-3. 진짜 개발 생산성을 높이는 핵심 열쇠

컨텍스트를 정비하고 나니 코딩 속도가 압도적으로 빨라졌습니다. 하지만 도구의 제약이 사라지자 본질적인 문제가 눈에 들어왔습니다. AI가 코드를 순식간에 짜주더라도, 작업 단위를 정교하게 쪼개지 않으면 결과물을 검토하고 테스트하는 과정에서 리소스가 낭비되었습니다.

 

진정한 의미의 생산성을 높이기 위해서는 작은 변경 단위라는 근본적인 엔지니어링 원칙을 철저히 지켜야 합니다. AI 도입 후 겪었던 오해의 흐름과, 이를 바로잡은 진실의 흐름을 시퀀스 다이어그램으로 대조해 보면 다음과 같습니다.

 

[오해의 흐름 : 대규모 코드 양산과 검증 지옥]

 

[진실의 흐름 : 근본 원칙 준수를 통한 안전한 생산성 확보]

 

 

결국 AI를 잘 쓰기 위한 방법은 역설적이게도 기본기였습니다.
작업 단위를 쪼개는 등의 기본기를 잘해야만 AI를 사람이 제어하며 진짜 생산성으로 전환할 수 있습니다.

 

 

 

2. '다음 토큰 예측'이 만든 환상: AI의 함정

 

 

 

AI 도구를 무결한 정답만 내놓는 해결사로 바라보는 오해는 경계해야 합니다. LLM은 절대적인 팩트를 아는 존재가 아니라, 통계와 확률에 기반한 시스템입니다.

 

LLM은 구조적으로 '다음 토큰 예측(Next-Token Prediction)' 메커니즘으로 동작합니다. 질문의 비즈니스적 배경이나 현실적 제약 조건을 이해하는 것이 아니라, 방대한 데이터 안에서 문맥상 가장 그럴듯한 단어 조합을 계산해서 보여주는 것입니다. 확률에 기댄 결과물이라는 점에서 이는 매번 결과가 달라지는 '랜덤뽑기 문서'와 본질적으로 다르지 않습니다.

 

그렇기 때문에 비개발 직군이 AI로 만들어낸 기획서(PRD)나 스펙 문서의 완벽해 보이는 문장 뒤에는 치명적인 함정이 숨어있습니다. 실제 현업 소통 과정에서 터지는 대표적인 두 가지 리스크의 실체는 다음과 같습니다.

 

예시 1. 도메인 비즈니스 제약 조건 누락 (기획 정책의 오류)

팀원
AI가 기획서 완벽하게 짜줬어요! 반품 시 사용된 마케팅 쿠폰을 일할 계산해서 차감 후 환불하는 정책으로 즉시 진행하시죠!


엔지니어
아쉽게도 시스템 구조상 불가능합니다. 현재 우리가 연동 중인 PG사 구형 API는 쿠폰이 적용된 결제 건에 대해 '부분 환불' 기능 자체를 지원하지 않아요. 이 정책을 고수하려면 결제대행사를 바꾸거나, 사내 정산/인프라 시스템 판을 처음부터 완전히 새로 짜야 하는 상황입니다.

 

예시 2. 시스템 실체와 닿지 않은 가짜 기술 스펙 제안 (기술 추론의 오류)

팀원
이번 쿠폰 환불 기능 고도화 건이요, AI가 API 명세랑 DB 쿼리까지 다 짜줬어요!
POST /api/v1/coupons/refund로 쏘고 coupon_state 컬럼만 업데이트하면 끝이라는데요?


엔지니어
확인해 보니 클로드가 잘못 작성한거 같네요.
첫째로 우리 전사 API 표준 패스는 v1/b2c/... 형태여야 하고, 결제에 필수인 tx_id(거래식별키)가 통째로 누락되었습니다.
둘째로 우리 DB 테이블에는 coupon_state라는 컬럼 자체가 없습니다. 해당 비즈니스 상태는 별도의 정산 매핑 테이블에서 상태 머신으로 관리 중입니다.

 

언뜻 보면 고품질 문서 같지만, 실제 시스템 아키텍처를 열어보고 검토했을 때는 완전히 엉뚱하고 구현 불가능한 상상에 불과합니다. 이러한 기획서로 스프린트를 시작하면, 결국 구현 단계에서 설계를 전부 뒤엎어야 하는 심각한 병목과 리스크를 마주하게 됩니다.

 

 

 

3. LLM 도입이 초래하는 오해와 현실적 부작용

 

 

 

LLM의 확률적 특성을 고려하지 않고 모든 과정을 AI에 의존하려 할 때 조직은 심각한 비용과 리스크를 마주하게 됩니다.

 

3-1. "클로드가 맞다는데요?" 신드롬이 유발하는 검증자의 독박 리스크

실무에서 마찰이 발생하는 가장 피로한 지점은 "클로드가 분석해 보더니 이거 맞다는데요?"라는 피드백을 마주할 때입니다.

 

AI에게 질문을 던진 당사자는 1초 만에 결과가 나오니 본인의 업무 효율이 높아졌다고 착각합니다. 하지만 최종 결과물을 검토하고 시스템을 방어해야 하는 입장에서는 엄청난 리소스가 소모됩니다. 검증자는 AI가 뱉어낸 문장과 코드 사이에 숨겨진 환각 현상과 논리적 빈틈을 찾기 위해 온 신경을 곤두세우고 교차 검증을 해야 합니다.

 

질문자는 버튼 하나로 일을 끝냈지만, 검증자는 몇 배의 에너지를 쏟아야 하는 문제가 발생합니다. 눈앞의 편리함 뒤에 숨겨진 검증의 무게를 조직원들이 함께 이해해야 건강한 AI 협업 문화가 시작됩니다.

 

3-2. Amplitude 이벤트 명세 오독으로 발생하는 퍼널 해석의 오류

최근에는 Amplitude 같은 데이터 분석 플랫폼의 로우 이벤트를 LLM에 추출·주입하여 비즈니스 리포트를 도출하는 방식이 보이는거 같습니다.

 

어느 날 AI 분석 리포트를 들고 와 "이번에 새로 배포한 '신규 프로모션 페이지'의 유저 구매 전환 퍼널을 AI로 뽑아봤는데, 최종 결제 완료까지의 전환율이 무려 25%에 달합니다! 레이아웃 개편이 대성공을 거두었으니 이 방향으로 밀고 나가죠"라는 결론을 공유됐습니다.

 

하지만  Amplitude의 실제 이벤트 세팅과 로우 데이터 명세를 정밀하게 교차 대조해 본 결과, AI의 리포트는 심각한 통계적 왜곡을 일으키고 있었습니다.

 

Amplitude 내에는 하위 호환성 관리를 위해 과거 버전과 신규 버전의 이벤트명이 view_promotion_v1과 view_promotion_v2로 엄연히 분리되어 등록되어 있었으나, LLM이 컨텍스트를 해석하는 과정에서 "이름이 비슷하니 둘 다 프로모션 페이지 분석이겠거니" 하고 두 개의 독립된 이벤트를 임의로 합산(v1 + v2)하여 단일 퍼널로 퉁쳐버린 것이었습니다. 실제 신규 버전(v2)만 제대로 발라냈을 때의 진짜 데이터 갭은 다음과 같았습니다.

 

📊 프로모션 퍼널 단계별 데이터 오차 및 버전 갭 분석

퍼널 단계	AI 리포트 수치 (v1 + v2 오독 합산)	Amplitude 실제 명세 (오직 신규 v2)	수치 차이	AI의 통계 합산 오류 원인
1단계: 프로모션 진입	10,000명	4,000명	+6,000명	view_promotion_v1과 v2 이벤트를 동일 태그로 오인 합산
2단계: 결제서 진입	5,000명	1,500명	+3,500명	과거 버전(v1) 페이지에서 결제 단계를 밟은 트래픽 혼입
3단계: 최종 결제 완료	2,500명	500명	+2,000명	과거 버전(v1) 기반의 결제 성공 성과가 신규 성과로 둔갑

 

Claude는 이벤트명의 문맥적 유사성에만 의존하여 데이터를 요약하기 때문에, 데이터 명세서에 명시된 하위 버전 규칙 등을 스스로 고려하지 못합니다. 툴 내부의 실제 데이터 규격과 스펙을 교차 검증하지 않고 AI의 요약 결론을 그대로 인용하는 것은, 조직 전체가 눈이 가려진 채 잘못된 비즈니스 의사결정으로 이끄는 위험한 도박이 됩니다.

 

 

 

4. 결론: 통제할 수 없는 도구 앞에서 멱등성을 확보하는 법

결국 정답이 없는 이 안갯속 같은 과도기에서, 제가 찾고 있는 현실적인 돌파구는 기술적 보완과 대화라는 두 가지 방향의 끈질긴 시도뿐입니다.

 

4-1. 기술적 보완: 전사 차원의 커스텀 스킬(Skill) 배포와 보안 리스크의 경계

개인 단위를 넘어 조직과 전사 차원에서 공통 커스텀 스킬(Skills)을 배포하여 잘못된 스펙 양산을 시스템적으로 막고자 끊임없이 실험하고 있습니다. 하지만 이 역시 명확한 한계가 존재합니다. 고도화된 전사 스킬조차 100%의 정확도를 보장할 수 없다는 태생적 불안감이 남으며, 무엇보다 기업 보안 가이드라인에 의해 사내 프로덕션 데이터와 민감한 핵심 도메인 지식을 외부 LLM에 무분별하게 넘겨줄 수 없기 때문입니다. 결국 기술적으로 자동 주입할 수 있는 맥락의 경계는 철저히 제한됩니다.

 

4-2. 대화: 끈질긴 소통과 하나씩 검토하는 프로세스

 

 

 

결국 시스템이 완벽할 수 없다면, 남는 것은 사람의 영역입니다. AI가 지어낸 허구와 현실의 격차를 좁히기 위해, 팀원들과 마주 앉아 빈틈을 하나씩 검토하고 대화하며 풀어가는 과정을 외면할 수 없습니다.

 

"착각에서 벗어나 본질로 돌아가기"

돌이켜보면 우리는 'LLM을 완벽하게 잘 쓰는 방법'을 찾기 위해 이 지난한 실험을 하고 있는 것이 아닙니다. 우리의 진짜 목적은 '업무를 잘하고, 비즈니스 문제를 올바르게 해결하는 것'이었습니다. 도구의 화려함에 눈이 멀어 수단과 목적을 착각하고 있었는지도 모릅니다.

 

엔지니어가 말하는 '멱등성'은 동일한 요청을 여러 번 보내도 결과가 항상 같아야 함을 의미합니다. 수학적으로 표현하면 다음과 같습니다.

f(f(x)) = f(x)

 

하지만 LLM이라는 함수 f(x)는 확률적으로 동작하기 때문에 입력값이 같아도 아웃풋이 매번 요동칩니다.

 

즉, AI 단독으로는 구조적으로 멱등성을 가질 수 없습니다. 우리가 해야 할 일은 이 확률형 도구 자체를 통제하려는 무의미한 피로감에서 벗어나는 것입니다. 대신, AI라는 확률형 함수 f(x)가 뱉어낸 불안정한 결괏값을, 사람의 기본기와 정적 검증 시스템이라는 결정론적 함수 g(f(x))의 입력으로 넣어 최종 정합성을 확보하는 구조를 짜야 합니다.

 

g(f(x)) = Deterministic Output

 

제가 쓰는 방식이 누군가의 눈에는 답답해 보일지라도, AI가 검증 없이 가져오는 상상의 속도를 제어하고 현실의 단단한 비즈니스 가치로 깎아내는 강력한 '방어벽' 역할을 묵묵히 해내는 것. 확률형 시스템의 파도 속에서 변하지 않는 소프트웨어의 정합성을 최종적으로 보장하는 것, 그것이 지금 엔지니어인 제가 해야 할 가장 가치 있는 노력이자 진짜 업무를 잘하는 방법이지 않을까요?