대부분의 팀은 더 작은 모델을 사용하여 AI 비용을 줄이려고 시도합니다. 진짜 병목 현상은 시스템 이해도에 있습니다.

대부분의 팀은 AI 비용이 모델의 문제라고 생각합니다.

그래서 다음과 같은 시도를 합니다:

• 더 작은 모델 (Smaller models)
• 더 나은 프롬프트 (Better prompts)
• 더 공격적인 캐싱 (More aggressive caching)
• 더 낮은 컨텍스트 윈도우 (Lower context windows)
• 더 빠른 추론 제공자 (Faster inference providers)

때로는 이것이 도움이 됩니다.

하지만 대부분의 경우 그렇지 않습니다.

왜냐하면 가장 큰 비용 동인은 모델이 아니기 때문입니다.

그것은 모델이 당신의 프로젝트를 이해하지 못한다는 사실입니다.

컨텍스트 (Context)의 숨겨진 비용

AI 코딩 에이전트가 새로운 리포지토리 (Repository)에 합류할 때 어떤 일이 발생하는지 살펴보십시오.

에이전트는 읽기 시작합니다.

파일들.

디렉토리들.

설정 (Configuration).

문서 (Documentation).

소스 코드 (Source code).

테스트 (Tests).

그러고 나서 더 많은 파일을 읽습니다.

그다음 더 많은 파일을 읽습니다.

그러고 나서 추가적인 컨텍스트 (Context)를 요청합니다.

그러고 나서 또 다른 리포지토리 스캔 (Repository scan)을 수행합니다.

그다음 또 수행합니다.

비용은 단지 토큰 (Tokens)만이 아닙니다.

비용은 매 세션, 매 작업, 매 변경 시마다 시스템에 대한 이해를 처음부터 반복해서 재구성하는 것입니다.

왜 더 큰 컨텍스트 윈도우 (Context Windows)가 해결책이 되지 못하는가

업계의 대응은 예측 가능했습니다.

모델에게 더 많은 컨텍스트 (Context)를 제공하는 것입니다.

200k 토큰.

500k 토큰.

1M 토큰.

하지만 컨텍스트 (Context)는 이해가 아닙니다.

새로운 엔지니어에게 회사의 모든 문서에 대한 접근 권한을 준다고 상상해 보십시오.

그들이 즉시 이해할 수 있을까요:

• 어떤 팀이 서비스를 소유하고 있는가?
• 어떤 API 계약 (API contracts)이 중요한가?
• 어떤 의존성 (Dependencies)을 변경해도 안전한가?
• 어떤 릴리스 게이트 (Release gates)를 통과해야 하는가?
• 어떤 시스템이 특정 엔드포인트 (Endpoint)를 소비하는가?

당연히 아닙니다.

정보는 이용 가능하지만, 이해는 되어 있지 않습니다.

AI 에이전트에게도 똑같은 일이 일어납니다.

리포지토리 (Repository) 문제

대부분의 AI 도구는 리포지토리 (Repositories)를 이해합니다.

하지만 프로덕션 시스템 (Production systems)은 리포지토리보다 더 큽니다.

프로덕션 시스템에는 다음이 포함됩니다:

• 소유권 경계 (Ownership boundaries)
• 아키텍처 결정 (Architecture decisions)
• 서비스 계약 (Service contracts)
• 운영 가정 (Operational assumptions)
• 검증 요구 사항 (Verification requirements)
• 변경 영향 (Change impact)
• 릴리스 준비 상태 (Release readiness)

그러한 지식의 상당 부분은 소스 코드 외부에 존재합니다.

에이전트는 모든 파일을 읽을 수 있지만, 여전히 가장 중요한 정보를 놓칠 수 있습니다.

비용이 많이 드는 루프 (The Expensive Loop)

이는 비용이 많이 드는 패턴을 만들어냅니다.

에이전트가 작업을 받음.
↓
에이전트가 저장소 (Repository)를 스캔함.
↓
에이전트가 일시적인 멘탈 모델 (Mental model)을 구축함.
↓
에이전트가 작업을 수행함.
↓
컨텍스트 (Context)가 사라짐.
↓
에이전트가 내일 똑같은 과정을 반복함.

The agent isn't learning your system. It's rebuilding it.

동일한 저장소 (Repository).

동일한 파일들.

동일한 탐색 과정.

동일한 토큰 (Token) 비용.

계속해서 반복됩니다.

만약 이해(Understanding)가 이미 존재한다면?

에이전트에게 매번 시스템을 다시 발견하도록 요청하는 대신:

시스템에 이미 모델이 있다면 어떨까요?

다음 사항들을 설명하는 공유된 이해 (Shared understanding)가 있다면 말입니다:

• 프로젝트 (Projects)
• 서비스 (Services)
• 의존성 (Dependencies)
• 명령어 (Commands)
• 정책 (Policies)
• 계약 (Contracts)
• 검증 증거 (Verification evidence)
• 변경 영향 (Change impact)

이제 에이전트는 재구성 (Reconstruction) 대신 이해 (Understanding)에서 시작합니다.

컨텍스트 (Context)는 더 작아집니다.

답변은 더 빨라집니다.

의사결정은 더 안전해집니다.

컨텍스트 엔지니어링에서 시스템 이해로

AI 산업은 컨텍스트 엔지니어링 (Context engineering)에 엄청난 노력을 기울이고 있습니다.

그리고 그것은 중요합니다.

하지만 저는 다음 과제가 시스템 이해 (System understanding)라고 생각합니다.

동일한 프로젝트를 반복해서 다시 발견하는 것을 멈출 때 비용이 더 저렴해집니다.