제 본업은 20년 된 보험 시스템을 유지보수하는 것입니다. 1,000개가 넘는 PL/SQL 패키지, 230만 줄의 코드, 그 위에 구축된 Oracle Forms, 그리고 20개 이상의 고객사에 설치되어 동일한 코드베이스가 실행되고 있습니다. 9개월 전, 저는 Claude Code의 AI 에이전트를 통해 지원 티켓(support tickets)을 처리하기 시작했습니다. 108개의 티켓을 처리한 지금, 제가 하는 일 중 수동으로 하는 것은 거의 없습니다. 이 포스트에서는 워크플로우(workflow), 시스템을 안전하게 유지하는 부분, 그리고 티켓이 쌓일수록 점점 더 개선되는 루프(loop)에 대해 설명합니다.

레거시 시스템에서 이것이 작동하는 이유

사람들은 AI 도구가 그린필드(greenfield) 프로젝트에서 가장 도움이 될 것이라고 가정합니다. 제 경험은 그 반대입니다. 레거시 시스템에서의 고통은 코드를 작성하는 것이 아니라, 컨텍스트(context)를 찾는 것입니다:

• 누구도 전체 코드베이스를 알지 못합니다. 230만 줄 규모라면 누구도 알 수 없습니다.
• 동일한 코드가 수백 개의 설치 파라미터(installation parameters)에 의해 제어되어 고객마다 다르게 동작합니다. 제 질문의 절반은 "왜 고객 X에서는 이것이 다르게 작동하는가?"입니다.
• 저희 헬프데스크(helpdesk)에는 20년 이상의 기록이 담긴 약 100만 개의 티켓이 있습니다. "이 문제를 이전에 해결한 적이 있는가?"라는 질문에 대한 답은 거의 항상 '예'입니다. 문제는 그 답이 2017년의 티켓에 들어있거나, 3년 동안 아무도 열어보지 않은 매뉴얼의 한 단락에 들어있다는 점입니다.
• 지식이 헬프데스크, 파일 공유 서버의 사용자 매뉴얼, 위키(wiki), GitLab, 그리고 SVN 등 5개의 시스템에 흩어져 있습니다.

이러한 컨텍스트를 수동으로 수집하는 데는 시니어 개발자에게도 반나절이 걸립니다. 적절한 도구를 갖춘 에이전트(agent)는 이를 몇 분 만에 해냅니다. 이것이 핵심적인 거래(trade)입니다.

워크플로우: 티켓당 하나의 명령

새로운 티켓이 도착하면, 저는 단 하나의 분석(analyze) 명령을 실행합니다. 그러면 에이전트는 다음과 같이 동작합니다:

1. 헬프데스크의 SOAP API를 통해 첨부 파일을 포함한 티켓을 읽습니다. PDF, Word 및 Excel 파일은 먼저 텍텍스트로 변환됩니다.
2. 유사한 과거 티켓을 검색합니다. 키워드 검색과 벡터 검색 (vector search)을 병행하는데, 이는 헬프데스크 내장 검색 기능이 키워드만 지원하여 표현 방식이 다른 내용은 놓치기 때문입니다.
3. 재사용 가능한 것이 있는지 제가 미리 만들어 둔 SQL 스크립트 라이브러리를 확인합니다.
4. 데이터베이스의 관련 코드를 살펴보고, 필요한 경우 GitLab 또는 SVN의 변경 이력을 확인합니다.

Workflow diagram: a new ticket goes to an analyze agent that reads four sources (helpdesk API with attachments, similar past tickets via keyword and vector search, a library of 759 SQL templates, source code with change history), produces ANALIZA.md with findings and a proposed next step, which branches into a code fix, a customer reply, or more diagnostics; everything gets attached back to the ticket, and an orange feedback arrow loops from the ticket archive back into the search sources

출력물은 단일 마크다운 (markdown) 파일인 ANALIZA.md입니다. 모든 조사 결과가 한곳에 모여 있으며, 제안된 다음 단계가 포함됩니다. 다음 단계는 항상 코드 수정, 고객에게 보낼 답장, 또는 고객 데이터베이스에 대한 추가 진단 중 하나입니다.

충분한 데이터가 모이면, 에이전트는 전체 패키지를 준비합니다: 제안된 해결책, 고객에게 보낼 메시지, 티켓에 참여하는 동료들을 위한 내부 메모, 진단 및 수정 스크립트, 그리고 왜 이런 방식으로 처리했는지에 대한 짧은 설명글입니다. 이 모든 것이 티켓에 첨부됩니다.

실제 작업이 이루어진 곳은 바로 스킬 (Skills)입니다

에이전트의 성능은 당신이 제공할 수 있는 컨텍스트 (context)의 수준에 달려 있습니다. 9개월 동안 저는 24개의 스킬을 구축했습니다. 기능별로 분류하면 다음과 같습니다:

메타 스킬 (meta skill)은 들리는 것보다 더 중요합니다. 제가 에이전트에게 같은 내용을 두 번 설명하고 있다는 것을 깨달을 때마다, 그 설명은 하나의 스킬이 됩니다. 도구 세트는 일상적인 업무의 부수적인 결과로 성장합니다.

안전을 유지하는 두 가지 규칙

안전을 유지하는 두 가지 규칙

생성된 모든 스크립트는 라이브 스키마를 통해 검증됩니다. SQL에서 가장 흔한 LLM 실패 사례는 거의 존재하는 테이블이나 컬럼을 지어내는 것입니다. 해결책은 간단합니다. 제가 손을 떠나기 전에 개발 데이터베이스에 대해 EXPLAIN PLAN FOR <statement>를 실행하는 것입니다. 이는 아무것도 실행하지 않고도 실제 데이터 딕셔너리와 스크립트를 비교 분석하므로, UPDATE와 DELETE에도 안전합니다. 지어낸 객체는 ORA-00942 또는 ORA-00904 오류로 즉시 실패합니다.

위험한 변경 사항은 두 번째 엔지니어의 검토를 거칩니다. 되돌리기 어려운 변경 사항에 대해서는 같은 작업을 두 번째 독립적인 에이전트에게 맡기고 그 결과를 비교합니다. 저는 두 가지 방법을 사용합니다. 첫째, 진정으로 독립적인 시각을 위해 다른 벤더의 모델을 사용하고(다른 모델, 다른 사각지대), 둘째, 도메인 관련 검토가 필요한 경우 모든 도메인 지식을 로드한 동일 모델의 새로운 세션을 이용합니다. 두 방법 모두 발견하는 것은 거의 확실히 실제입니다. 한쪽에서만 발견하는 것은 제가 직접 확인합니다. 소규모 팀에게 있어 이것은 제가 얻을 수 있는 가장 가까운 동료 검토(peer review)와 같습니다.

모든 것을 가능하게 하는 루프

이 부분이 제가 이 글을 읽고 훔쳐가고 싶은 부분입니다.

에이전트가 생성하는 모든 결과물은 티켓에 다시 첨부됩니다. 스크립트, 분석 내용, 수정의 근거가 모두 포함됩니다. 내년에 유사한 티켓이 도착하면, 벡터 검색(vector search) 기능이 그 이전 티켓을 찾아내고, 에이전트는 우리가 무엇을 했는지뿐만 아니라 왜 그렇게 했는지를 읽습니다. 그런 다음 별도의 마감 단계에서 재사용 가능한 모든 것을 스크립트 라이브러리로 추출합니다. 이 라이브러리는 이제 32개의 주제 폴더에 걸쳐 759개의 SQL 템플릿으로 구성되어 있으며, 수년에 걸쳐 구축되었고 마침내 저 혼자가 아닌 에이전트에 의해 검색 가능해졌습니다.

그 결과: 해결된 모든 티켓은 다음 티켓을 더 싸게 만듭니다. 추가적인 노력이나 '지식 관리 이니셔티브'가 필요 없습니다. 이는 단순히 티켓을 닫는 과정의 부산물로 발생합니다.

여전히 작동하지 않는 것들

솔직한 고백입니다. 세 가지 부분이 아직 미흡합니다:

• 테스트는 여전히 수동입니다 (Testing is still manual). 에이전트는 수정 사항을 작성하는 속도를 높여줄 뿐, 해당 수정이 다른 20개의 설치 환경에서 아무것도 망가뜨리지 않는다는 것을 증명해주지는 않습니다. 그것이 여전히 남아있는 가장 큰 리스크입니다.
• 지표가 빈약합니다 (Metrics are thin). 원시 데이터(108개의 티켓, 약 4,000개의 프롬프트, 그 중 94%가 티켓 관련)는 있지만, 해결 시간(resolution time)에 대한 체계적인 전후 측정 데이터가 없습니다. 더 빨라졌다는 것은 알지만, 아직 얼마나 빨라졌는지는 증명할 수 없습니다.
• 버스 지수(Bus factor)가 1입니다. 전체 스택이 제 컴퓨터에서 구축되고 구성되었습니다. 아직 존재하지 않는 설정 가이드 없이는 동료가 이 작업을 이어받을 수 없습니다.

마무리하며

핵심적인 통찰: 거대한 레거시 시스템에서 AI 에이전트가 가져다주는 승리는 코드 생성(code generation)이 아닙니다. 단 한 줄의 코드를 쓰기 전에 다섯 개의 시스템을 뒤지며 반나절을 보내야 했던 컨텍스트 수집(context gathering) 과정이 단 몇 분으로 단축된다는 점입니다. 그리고 그 결과를 다시 티켓 아카이브로 라우팅한다면, 시스템은 복리로 성장합니다. 해결된 모든 티켓이 다음 티켓을 위한 학습 자료가 되기 때문입니다.