대부분의 팀은 코드에 대한 버전 관리 (Version Control)를 생각합니다.

개발자의 버전:

• 애플리케이션 로직 (application logic)
• 인프라 구성 (infrastructure configuration)
• 배포 스크립트 (deployment scripts)
• 데이터베이스 마이그레이션 (database migrations)

이 프로세스는 너무나 당연해서 아무도 의문을 제기하지 않습니다.

그러다 AI 워크플로우가 등장합니다.

그리고 갑자기 많은 팀이 시스템의 가장 중요한 부분 중 일부에 대한 버전 관리를 중단합니다.

프롬프트 (Prompts)가 변경됩니다.

검색 로직 (Retrieval logic)이 변경됩니다.

에이전트 (Agent)의 동작이 변경됩니다.

검증 규칙 (Validation rules)이 변경됩니다.

워크플로우 라우팅 (Workflow routing)이 변경됩니다.

종종 의미 있는 버전 이력 없이 말이죠.

그렇게 한동안은 잘 작동합니다.

운영 환경 (Production)이 다르게 동작하기 시작하고 아무도 그 이유를 모를 때까지 말입니다.

첫 번째 문제는 보통 실패가 아닙니다

첫 번째 징후는 서비스 중단인 경우가 드뭅니다.

시스템은 여전히 작동합니다.

사용자는 여전히 답변을 받습니다.

워크플로우는 여전히 완료됩니다.

그저 무언가 다르게 느껴질 뿐입니다.

아마도:

• 답변 품질 저하
• 검색 결과가 약해짐
• 자동화 동작의 변화
• 예상치 못한 비용 증가
• 지연 시간 (Latency) 변화
• 워크플로우의 일관성 결여

어려운 부분은 무엇이 변했는지 파악하는 것입니다.

버전 관리 (Version control) 없이는 조사가 매우 고통스러워집니다.

AI 시스템은 전통적인 소프트웨어보다 더 자주 변경됩니다

백엔드 서비스는 의미 있는 동작 변화 없이 몇 주를 보낼 수도 있습니다.

AI 워크플로우는 종종 매일 변경됩니다.

팀은 다음을 업데이트합니다:

• 프롬프트 (prompts)
• 검색 전략 (retrieval strategies)
• 청킹 규칙 (chunking rules)
• 메모리 동작 (memory behavior)
• 랭킹 로직 (ranking logic)
• 도구 권한 (tool permissions)

각 변경 사항은 운영 결과에 영향을 미칠 수 있습니다.

문제는 이러한 변경 사항이 코드 변경처럼 보이는 경우가 드물다는 점입니다.

이들은 종종 설정 파일, 워크플로우 빌더, 프롬프트 저장소 또는 관리자 대시보드 내부에서 발생합니다.

그 영향은 소프트웨어 배포만큼이나 중요할 수 있습니다.

우리의 생각을 바꾼 사건

한 배포 이후 눈에 띄게 다른 출력이 생성되기 시작했습니다.

고장 난 것은 없었습니다.

오류도 나타나지 않았습니다.

인프라는 건강한 상태를 유지했습니다.

하지만 사용자들은 응답이 덜 유용하게 느껴진다고 보고했습니다.

명백한 용의자들은 다음과 같았습니다:

• 모델 변경 (model changes)
• 검색 실패 (retrieval failures)
• 데이터 품질 문제 (data quality issues)

몇 시간 동안의 조사 끝에, 우리는 실제 원인을 발견했습니다.

며칠 전 도입된 프롬프트 수정이 워크플로우의 동작을 변화시켰습니다.

그 변경 사항은 작아 보였습니다.

하지만 그 영향은 그렇지 않았습니다.

좌절스러웠던 점은 버그 자체가 아니었습니다.

좌절스러웠던 점은 동작이 언제 변했는지 식별하는 것이었습니다.

그것은 마땅히 그래야 하는 것보다 훨씬 더 어려워졌습니다.

프롬프트는 코드입니다

결국 우리는 프롬프트를 콘텐츠처럼 취급하는 것을 멈췄습니다.

우리는 프롬프트를 소프트웨어처럼 취급하기 시작했습니다.

운영 측면에서 보면, 그것이 바로 프롬프트의 실체이기 때문입니다.

프롬프트는 다음과 같은 일을 할 수 있습니다:

• 비즈니스 결정에 영향을 미침
• 워크플로우를 트리거함
• 검색 (retrieval)에 영향을 미침
• 자동화 동작을 변경함
• 고객에게 영향을 미침

코드가 버전 관리 (version control)를 필요로 한다면, 프롬프트 역시 버전 관리를 필요로 합니다.

동일한 논리가 워크플로우 설정 (workflow configuration)에도 적용됩니다.

동일한 논리가 검색 동작 (retrieval behavior)에도 적용됩니다.

동일한 논리가 에이전트 라우팅 (agent routing)에도 적용됩니다.

검색 로직의 변경에도 이력이 필요합니다

예상치 못한 AI 동작을 만드는 가장 쉬운 방법 중 하나는 검색 (retrieval)을 수정하는 것입니다.

예시는 다음과 같습니다:

• 랭킹 규칙 (ranking rules) 변경
• 청크 크기 (chunk sizes) 수정
• 필터 (filters) 조정
• 임베딩 모델 (embedding models) 업데이트
• 컨텍스트 조립 (context assembly) 변경

이러한 변경 사항 중 어느 것도 모델에 직접적인 영향을 미치지는 않습니다.

그럼에도 불구하고 출력값에는 극적인 영향을 미칠 수 있습니다.

버전 이력 (version history)이 없다면, 동작을 비교하는 것이 어려워집니다.

다음과 같은 질문들에 답하는 것이 불가능해집니다:

• 어떤 검색 전략 (retrieval strategy)이 이 결과를 생성했는가?
• 관련성 품질 (relevance quality)이 언제 변했는가?
• 어떤 랭킹 로직 (ranking logic)이 활성화되어 있었는가?
• 어떤 임베딩 버전 (embedding version)이 사용되었는가?

프로덕션 시스템에는 이러한 답변들이 필요합니다.

디버깅에는 역사적 맥락이 필요합니다

AI 디버깅의 놀라울 정도로 많은 부분이 단 하나의 질문에 답하는 것과 관련이 있습니다:

"이것이 제대로 작동했을 때는 무엇이 달랐는가?"

버전 관리 (version control)가 없다면, 그 질문에 대한 답을 찾는 데 많은 비용이 듭니다.

엔지니어들은 다음과 같은 것들을 뒤지기 시작합니다:

• 채팅 로그 (chat logs)
• 배포 기록 (deployment records)
• 내부 문서 (internal documentation)
• 설정 이력 (configuration histories)
• 워크플로우 정의 (workflow definitions)

단순한 비교는 조사가 됩니다.

버전 관리 (Versioning)는 그러한 복잡성을 줄여줍니다.

이는 시스템을 위한 운영 메모리 (operational memory)를 생성합니다.

롤백 (Rollbacks)이 가능해집니다

버전 관리의 가장 큰 이점 중 하나는 신뢰성입니다.

동작이 예상치 못하게 변경될 때, 롤백 (rollback)이 수월해집니다.

버전 관리가 없을 때:

• 변경 사항을 식별하기 어려움
• 이전 상태로 복구하기 어려움
• 장애 해결에 더 많은 시간이 소요됨

버전 관리가 있을 때:

• 차이점이 가시화됨
• 변경 사항의 추적이 가능해짐
• 복구가 빨라짐

이는 AI 시스템이 비즈니스 워크플로우 내에서 지속적으로 작동할 때 매우 중요합니다.

더 큰 교훈

AI 시스템이 성숙해짐에 따라, 시스템 동작의 더 많은 부분이 코드 (code)보다는 설정 (configuration) 영역으로 이동합니다.

프롬프트 (Prompts).

검색 로직 (Retrieval logic).

에이전트 워크플로우 (Agent workflows).

메모리 정책 (Memory policies).

검증 규칙 (Validation rules).

이러한 구성 요소들은 매일 프로덕션 (production) 결과에 영향을 미칩니다.

이들을 임시 설정으로 취급하는 것은 실험 단계에서는 효과적일 수 있습니다.

하지만 프로덕션 환경에서는 리스크 (liability)가 됩니다.

결국 모든 AI 팀은 동일한 질문에 직면하기 때문입니다:

"왜 시스템이 지난주와 다르게 오늘 다르게 동작하는가?"

버전 관리는 그 질문에 답할 수 있게 해주는 도구입니다.

그리고 AI가 인프라 (infrastructure)가 되는 순간, 답변 가능성 (answerability)은 지능 (intelligence)만큼이나 중요해집니다.