우리는 20년 된 헬프데스크 (helpdesk) 시스템 위에 내부 AI 어시스턴트를 운영하고 있습니다. 4월부터 운영을 시작했으며, 개발자부터 운영자, 프로젝트 매니저까지 5개 역할에 걸쳐 15명의 활성 사용자가 있습니다. 모델은 사람들이 생각하는 것만큼 중요하지 않습니다. 실제로 매주 어시스턴트를 개선하는 것은 지루한 프로세스, 즉 로그에 대한 구조화된 주간 검토입니다. 이 포스트에서는 그 프로세스와 우리가 추적하는 지표, 그리고 검토를 통해 발견했지만 그렇지 않았다면 절대 찾지 못했을 두 가지 실제 실패 사례를 설명합니다.

무엇이 로그로 남는가

두 가지 수준이 있습니다. 요청당 한 줄로 구성된 요약 로그 (summary log)입니다:

[2026-07-20 16:46:52] user=xxx timing=99926ms status=ok
  model=... turns=13 tools=12 cost=$0.25
  profile=xxx ftok=1820ms query="have we ever solved..."

그리고 세션당 전체 JSONL 트랜스크립트 (transcript)가 있습니다: 모든 사용자 턴 (user turn), 모든 답변, 그리고 어떤 컨텍스트 (context)가 주입되었으며 어디에서 왔는지까지 포함됩니다. 출처 (provenance) 부분은 검토 결과 어시스턴트가 왜 그렇게 말했는지 알 수 없다는 점이 드러난 후에 나중에 추가되었습니다. 만약 어시스턴트를 구축하고 있다면, 첫날부터 답변의 출처를 로그로 남기세요.

주간 검토는 에이전트에 의해 수행됩니다

일주일 치의 트랜스크립트를 수동으로 읽는 것은 지속 가능하지 않으므로, 검토 자체를 에이전트 (agent) 작업으로 처리합니다. 저는 "검토를 수행해"라고 말하면, 에이전트가 아직 커버되지 않은 기간이 언제인지 파악하고, 서버에서 로그를 가져와 모든 세션을 처리합니다. 샘플링이 아닙니다. 전부 다 처리합니다.

검토에는 세 가지 결과물이 있습니다:

1. 세션 품질 검토 (Session quality review). 에이전트는 답변에 등급을 매기며, 중요한 부분은 실제 데이터베이스와 대조하여 사실 관계를 재검증한다는 점입니다. 만약 어시스턴트가 사용자에게 "이 수정 사항은 5월에 고객 X에 설치되었습니다"라고 말했다면, 검토 과정에서 그것이 사실인지 확인합니다.
2. 개선 제안 (Improvement proposals). 구체적이고 우선순위가 지정되어 있으며, 각 제안에는 문제, 증거 (세션 ID, 인용구), 제안된 해결책, 그리고 예상 공수가 포함됩니다. 각 제안은 제안됨 (proposed), 승인됨 (approved), 구현됨 (implemented), 거부됨 (rejected), 또는 관찰 대상 (watch) 상태와 함께 백로그 (backlog)에 등록됩니다.
3. 사용자 프로필 (User profiles). 개인화를 위한 사용자별 사용 패턴 (자세한 내용은 아래 참조).

그다음 검토 단계에서는 이전 라운드를 검증합니다. 즉, 구현된 수정 사항이 목표로 했던 실패를 실제로 중단시켰는지를 확인합니다. 여러 번의 경우 답변은 "부분적으로"였으며, 해당 항목은 다시 백로그 (backlog)로 돌아갔습니다. 이러한 검증 단계가 없다면, 개선 백로그는 그저 기분만 좋게 만드는 리스트로 전락하고 맙니다.

스코어카드 (The scorecard)

매 검토 시마다 장기적으로 운영되는 스코어카드에 한 줄이 추가됩니다. 동일한 지표 (metrics)와 동일한 방법론 (methodology)을 사용하므로 추세를 확인할 수 있습니다: 요청 (requests), 사용자 (users), 세션 (sessions), 에러율 (error rate), 중앙값 (median) 및 p95 응답 시간 (response time), 수정 사항 (corrections), 사실적 오류 (factual errors), 미검출 (false negatives), 보안 이벤트 (security events), 사용자 피드백 (user feedback), 평균 세션 등급 (average session grade).

최근 한 주의 데이터는 다음과 같았습니다: 요청 137건, 사용자 12명, 세션 44개, 에러 0건, 중앙값 응답 시간 99초, p95 262초, 평균 세션 등급 5점 만점에 4.5점 (검토 커버리지 100%).

이를 유지 관리하며 얻은 두 가지 실질적인 교훈이 있습니다. 첫째, 계산 방법론 (counting methodology)을 기록해 두십시오. 왜냐하면 "세션이 몇 개인가"라는 질문에는 예외 케이스 (edge cases)가 발생하기 때문입니다 (현재 저희는 세션을 최소 하나 이상의 실제 사용자 턴 (user turn)이 포함된 트랜스크립트 파일로 계산하며, 피드백 전용 파일은 제외합니다). 둘째, 방법론의 변경 사항을 스코어카드 자체에 표시하십시오. 그렇지 않으면 지표의 급격한 변화가 실제로는 더 정밀한 측정임에도 불구하고 성능 퇴보 (regression)로 읽힐 수 있습니다.

검토를 통해 발견한 두 가지 실패 사례

유출된 제한 배너 (The leaking limit banner). 어느 오후, 우리의 기본 인증 토큰 (auth token)이 계속해서 속도 제한 (rate limit)에 걸리자 폴백 (fallback) 기능이 작동했습니다. 장애 극복 (failover)은 성공적이었지만, 검토 결과 최소 4명의 사용자에게 보여진 12개의 답변에 영어로 된 "You've hit your limit" 배너와 실패한 첫 번째 시도의 파편들이 최종 답변 상단에 붙어 있는 것이 발견되었습니다. 사용자들은 이를 보았지만 아무 말도 하지 않았습니다. 아직 완전히 신뢰하지 못하는 도구에서 발생하는 이상 현상은 아무도 보고하지 않으며, 이것이 바로 여러분이 로그를 읽어야 하는 정확한 이유입니다.

채택된 잘못된 전제 (The adopted false premise). 한 사용자가 프로젝트에 대해 질문했는데, 그 질문에는 특정 코드가 어떤 고객 그룹을 지칭하는지에 대한 잘못된 가정이 포함되어 있었습니다. 어시스턴트는 그 전제를 액면 그대로 받아들였고, 모든 것을 잘못된 회사에 자신 있게 귀속시켰습니다. 트랜스크립트 등급 (transcript grade)은 괜찮았습니다 (사용자는 만족했으니까요!). 하지만 사실관계는 틀렸습니다. 해결책은 프롬프트 규칙 (prompt rule)을 만드는 것이었습니다: 사용자가 단언하더라도, 답변을 구성하기 전에 데이터베이스를 통해 코드 뒤에 있는 엔티티 (entity)를 검증하도록 하는 것입니다. 이러한 종류의 실패는 사용자 피드백으로는 잡아낼 수 없습니다. 왜냐하면 사용자가 오류의 근원이기 때문입니다.

두 가지 유형의 사용자 프로필

각 사용자는 어시스턴트가 시스템 프롬프트 (system prompt)에 로드하는 프로필을 가지고 있습니다: 역할 (role), 볼 수 있는 프로젝트, 전형적인 질문, 선호하는 답변 깊이 등입니다. 패키지에 대해 묻는 개발자에게는 코드 참조가 제공됩니다. 동일한 것을 묻는 프로젝트 매니저에게는 비즈니스 요약이 제공됩니다. 에러 코드에 대해 묻는 운영자에게는 과거 티켓의 해결책과 함께 어떤 개발자에게 할당할지에 대한 제안이 제공됩니다.

반복적인 개선이 필요했던 부분은 다음과 같습니다: 우리는 두 개의 별도 프로필 세트를 유지합니다. 분석적 프로필 (Analytical profiles)은 로그 검토를 통해 구축된 각 사용자에 대한 우리의 내부적 이해입니다. 에이전트 프로필 (Agent profiles)은 어시스턴트가 실제로 로드하는 정제된 버전입니다. 분석적 프로필이 원재료라면, 에이전트 프로필은 제품입니다. 이 둘을 섞는 것은 우리가 처음에 저질렀던 실수였습니다. 사용자에 대한 내부 관찰 결과는 프롬프트에 포함되어서는 안 됩니다.

이 작업을 수행하는 모든 분께 제가 강조하고 싶은 한 가지 규칙은, 개인화(personalization)는 기본 설정(default)이어야 하며, 감옥(cage)이 되어서는 안 된다는 점입니다. 기술적인 질문을 하는 비기술적(non-technical) 사용자는 기술적인 답변을 받아야 합니다. 그리고 로그 검토의 목적은 직원을 평가하는 것이 아니라 어시스턴트를 개선하는 데 있다는 점을, 누군가 자신의 대화가 읽히고 있다는 사실을 발견하기 전에 명시적으로 말하고 기록해 두어야 합니다.

마무리

운영 환경(production)에 있는 AI 어시스턴트는 제품이며, 제품 루프(product loop)가 필요합니다: 계측(instrumentation), 주기적인 검토(periodic review), 우선순위가 지정된 백로그(prioritized backlog), 그리고 수정 사항이 제대로 작동했는지에 대한 검증(verification)이 그것입니다. 에이전트(agent)를 통해 검토를 수행하면 100% 커버리지를 경제적으로 달성할 수 있습니다. 그리고 가장 가치 있는 발견은 사용자가 절대 보고하지 않을 내용들입니다. 즉, 모든 사용자가 만족하고 있는 동안 정작 답변은 틀렸던 사례들입니다.