[Week 03] 최선규 - 개발 에이전트로 서비스 유지보수 효율 개선하기

[luke0408]

1. 작업 내용

이번 주의 핵심은 개발 에이전트 자체가 아니라, 고객 피드백을 관찰 가능한 테스트
루프로 바꾼 과정이다.

1. 실제 발송본과 초안의 차이에서 반복 실패 패턴을 찾았다.
2. 실패 사례를 회귀 픽스처로 고정하고 작은 변경마다 자동 검증했다.
3. 고정된 코드와 데이터 시점으로 과거 사례를 격리 재현했다.
4. 운영 적용 뒤 해결시간, 7일 내 해결률, 초안 채택, 변경 제안 결과를 다시 측정했다.
5. 좋아진 결과와 악화된 가드레일을 분리해 다음 실험을 정했다.

flowchart LR
    P["문제 관측<br/>초안과 실제 처리 비교"] --> T["테스트 자산화<br/>픽스처·기대 결과·회귀 게이트"]
    T --> C["작은 개선<br/>분류·컨텍스트·초안·검증"]
    C --> R["격리 재현<br/>고정 코드·시점·DB"]
    R --> A["운영 적용<br/>사람 승인 경계 유지"]
    A --> M["실측<br/>결과·속도·품질·채택"]
    M --> P

Loading

문제와 해결: 무엇이 문제였고 어떻게 고쳤는가

문제는 코드 작성보다 맥락 전달에 있었다

기존 유지보수는 한 건의 문의를 처리할 때마다 사람이 다음 작업을 반복해야 했다.

• 문의와 과거 대화를 읽고 실제 요구를 다시 해석한다.
• 어느 서비스와 코드 경로가 원인인지 찾는다.
• 운영 데이터, 도메인 문서, 최근 변경 이력을 따로 조회한다.
• 수정 후 테스트 결과와 고객 설명을 다시 정리한다.
• 답변, 변경 제안, 리뷰, 배포 도구 사이에서 맥락을 계속 옮긴다.

초기 실데이터 66개 초안을 분석하니 단순한 체감이 아니라 구체적인 품질 병목이 보였다.

pie showData
    title 초기 초안 66개의 운영 상태
    "발송 24" : 24
    "폐기 10" : 10
    "검토 대기 32" : 32

Loading

발송된 24개 중 수정 없이 그대로 사용된 초안은 1개뿐이었다.

pie showData
    title 발송된 초안 24개의 편집 여부
    "무편집 발송 1" : 1
    "사람이 수정 후 발송 23" : 23

Loading

초기 관측	수치	의미
전체 초안 중 무편집 발송	1 / 66, 1.5%	생성 성공과 발송 가능 품질은 달랐다
발송본 중 무편집 비율	1 / 24, 4.2%	채택돼도 대부분 다시 써야 했다
채택분 평균 문면 유사도	0.48	초안의 약 절반이 교체됐다
초안보다 짧아진 발송본	20 / 24, 83%	초안이 구조적으로 장황했다
평균 길이 변화	-99자	핵심 정보보다 계획·설명 문장이 많았다

초안과 실제 발송본을 대조하니 수정은 세 부류로 모였다.

문제	실측에서 보인 패턴	개선 방향
문면·톤	계획형 시제, 자동 번호 목록, 장황한 설명	고객 문면과 내부 수정 계획을 분리하고 짧은 완료형 후속 답변 생성
판단·행동	조사 가능한 내용을 되묻거나 동작 변경을 바로 약속	조사 우선, 선택이 필요한 변경은 확인 질문으로 전환
정확성·범위	초기 가설을 단정하거나 외부 문제까지 코드 수정으로 분류	근거·불확실성·수정 방향을 함께 점수화하고 낮은 신뢰도는 실행 차단

고객 문의를 하나의 유지보수 파이프라인으로 연결했다

운영 서비스는 문의를 저장한 뒤 개발 에이전트에 비동기로 작업을 전달한다. 개발
에이전트는 과거 대화, 서비스 구조, 도메인 문서, 관련 변경 이력과 운영 데이터를 모으고,
먼저 안내·확인·조사·코드 수정·사람 이관 중 하나로 분류한다.

코드 수정이 필요한 경우에도 바로 운영에 반영하지 않는다. 문의별 격리 작업 공간에서
수정하고 저장소의 검증 명령을 실행한 뒤 변경 제안(PR)과 근거를 함께 만든다. 고객 답변은
검토 대기 초안으로만 저장하고, 발송·병합·배포는 사람이 결정한다.

flowchart TD
    U["고객 피드백"] --> S["운영 서비스에 원문 저장"]
    S -->|"비동기 작업 전달"| C["공통 컨텍스트 수집"]
    C --> J{"의도·명확도·신뢰도 판단"}
    J -->|"사용 안내"| G["안내 초안"]
    J -->|"정보 부족"| Q["확인 질문 초안"]
    J -->|"데이터 경위"| I["운영 데이터 읽기 전용 조사"]
    J -->|"수정 필요"| H{"실행 게이트 통과?"}
    J -->|"책임 범위 밖"| E["사람 이관"]

    I -->|"코드 원인 확인"| H
    I -->|"설명·데이터 조치"| E
    H -->|"아니요"| Q
    H -->|"예"| W["격리 작업 공간에서 코드 수정"]
    W --> V["시스템이 저장소 검증 명령 실행"]
    V --> P["변경 제안과 근거 생성"]

    G --> D["검토 대기 초안 저장"]
    Q --> D
    E --> D
    P --> D
    D --> O{"사람 검토"}
    O -->|"승인"| R["고객 발송 또는 병합"]
    O -->|"수정·폐기"| L["편집·폐기 신호 저장"]
    R --> M["결과 지표 축적"]
    L --> M

Loading

핵심 변경은 자동화 범위를 넓힌 것이 아니라 되돌릴 수 있는 작업만 자동화하고 책임
경계를 코드로 고정한 것이다.

• 컨텍스트 일부 조회가 실패해도 문의 저장과 초안 생성은 중단하지 않는다.
• 운영 데이터는 읽기 전용으로 조사한다.
• 불확실성이 남으면 코드 수정 대신 확인 질문을 만든다.
• 기본 브랜치 직접 수정, 강제 반영, 자동 병합, 자동 배포를 차단한다.
• 에이전트의 테스트 보고를 그대로 믿지 않고 시스템이 검증 명령을 다시 실행한다.

2. Deep Dive 해본 것

테스트 루프 설계: 하나의 점수가 아니라 네 개의 검증층으로 나눴다

LLM 기반 시스템은 테스트가 통과해도 답변이 쓸 수 없을 수 있고, 초안 채택률이 높아도
잘못된 코드가 배포될 수 있다. 그래서 정확도, 코드 안전성, 재현성, 운영 결과를 서로 다른
게이트로 뒀다.

검증층	입력과 판정	실제 적용
결정적 회귀 테스트	파싱, 상태 전이, 신뢰도 보정, 가드레일, 검증 실패 처리	1차 개선 반영 시 typecheck와 125개 테스트 통과, 실패 0개
의도 분류 벤치	실문의에서 만든 픽스처와 기대 분류 비교	확인 유형 정확도 80%, 코드 변경 회수율 90%, 질문 정확도 80%를 게이트로 설계
격리 재현	고정 기준 커밋, 입력 시점, 마이그레이션 기반 DB로 과거 상황 재현	외부 쓰기를 막은 4개 사례 스모크 세트와 병렬 실행·정리·리포트 경로 구현
운영 관측	해결시간, 성숙 코호트 해결률, 첫 답변, 초안 사용, 변경 제안 상태	적용 전후 코호트와 운영 상태를 읽기 전용으로 집계

격리 평가 환경은 다음 원칙으로 만들었다.

1. 최신 코드가 아니라 문의 당시의 기준 커밋과 입력 cutoff를 고정한다.
2. 데이터베이스는 당시 마이그레이션으로 별도 컨테이너에 재현한다.
3. 웹, 원격 저장소, 외부 API 쓰기와 운영 알림을 차단한다.
4. 실행마다 patch, 변경 파일, 검증 결과와 도구 trace를 보존한다.
5. 병렬 실행 뒤 작업 공간과 테스트 데이터를 명시적으로 정리한다.
6. 결과는 JSON, Markdown, HTML로 남겨 다음 변경과 같은 조건에서 비교한다.

flowchart LR
    O["운영 실패 사례 수집"] --> F["개인정보 제거 후<br/>픽스처와 기대 결과 고정"]
    F --> B["동일 입력으로 기준선 측정"]
    B --> H["실패 원인 가설<br/>분류·컨텍스트·문면·검증"]
    H --> C["작은 변경 1개 적용"]
    C --> U{"단위·회귀 테스트"}
    U -->|"실패"| H
    U -->|"통과"| E{"격리 DB 재현"}
    E -->|"실패"| H
    E -->|"통과"| P["사람 검토 후 적용"]
    P --> M{"운영 결과와<br/>가드레일 재측정"}
    M -->|"개선 또는 새 실패"| O

Loading

실제 적용: 실패 패턴을 작은 변경으로 닫았다

첫 분석에서 가장 자주 반복된 편집은 시제 변경, 번호 목록 삭제, 축약이었다. 이를 한 번에
대규모 프롬프트로 덮지 않고 다음처럼 나눠 반영했다.

• 고객 답변에서 내부 수정 계획 번호 목록을 제거하고, 계획은 검토 메타데이터에만 남겼다.
• 직접 조사할 수 있는 내용은 되묻지 않도록 하고, 동작 선택이 필요한 경우만 확인한다.
• 확인된 사실과 추정을 분리하고, 외부 책임 영역의 네거티브 사례를 추가했다.
• 코드 조사에서 초기 가설이 바뀌면 최종 초안도 실제 수정 근거로 다시 조립하도록 했다.
• 변경 제안 상태를 추적해 병합 전 약속과 병합 후 완료 안내를 분리했다.

변경 뒤 기록된 로컬 검증은 다음과 같다.

xychart-beta
    title "로컬 자동 검증 결과"
    x-axis ["1차 개선 테스트", "격리 평가 테스트", "전체 테스트"]
    y-axis "통과 건수" 0 --> 420
    bar [125, 16, 392]

Loading

검증 실행	통과	건너뜀	실패	해석
1차 품질 개선 회귀 테스트	125	-	0	작은 프롬프트·문면 변경이 기존 계약을 깨지 않음을 확인
격리 평가 전용 테스트	16	2	0	실행 API, 재현, 정리, 리포트 경로 확인
전체 테스트	392	2	0	평가 기능을 포함한 전체 코드 회귀 확인

4개 격리 사례는 공식 품질 점수셋이 아니라 실행 경로를 검증하는 스모크 세트다. 로컬
재현과 정리는 확인됐지만 원격 파일럿은 실행하지 않았다. 따라서 테스트 통과를 운영 품질
개선이나 원격 실행 성공의 증거로 과장하지 않는다.

운영 적용 후 무엇이 달라졌는가

최종 해결시간과 7일 내 해결률

2026-08-11 KST 기준 운영 관측에서 완료된 문의의 중앙 해결시간은 67.7시간에서
20.2시간으로 47.5시간 낮게 관측됐다. P75도 68.8시간에서 45.4시간으로 23.4시간
낮았다.

xychart-beta
    title "적용 전후 해결 리드타임"
    x-axis ["중앙값 전", "중앙값 후", "P75 전", "P75 후"]
    y-axis "시간(h)" 0 --> 80
    bar [67.7, 20.2, 68.8, 45.4]

Loading

접수 후 7일이 지난 성숙 코호트만 분모에 넣으면 7일 내 해결률은 38.8%에서 94.1%로
55.3%p 높게 관측됐다.

xychart-beta
    title "성숙 코호트의 7일 내 해결률"
    x-axis ["적용 전", "적용 후"]
    y-axis "해결률(%)" 0 --> 100
    bar [38.8, 94.1]

Loading

코호트	접수	완료	중앙 해결시간	P75	7일 내 해결
적용 전	188	76	67.7h	68.8h	73 / 188, 38.8%
적용 후	130	125	20.2h	45.4h	111 / 118, 94.1%

최종 결과가 좋아져도 첫 응답은 악화될 수 있었다

같은 기간 첫 팀 답변 중앙시간은 4.9시간에서 14.8시간으로 9.9시간 늘었다. 최종 해결
속도와 고객이 처음 체감하는 응답 속도는 같은 지표가 아니었다.

xychart-beta
    title "품질 가드레일: 첫 팀 답변 중앙시간"
    x-axis ["적용 전", "적용 후"]
    y-axis "시간(h)" 0 --> 16
    bar [4.9, 14.8]

Loading

이는 개발 에이전트가 느렸다는 직접 증거는 아니다. 초안이 만들어져도 사람의 검토와 발송
대기열에서 시간이 늘었을 가능성이 있다. 현재 데이터에는 검토 시작·활성 편집·대기 시간이
분리돼 있지 않아 원인은 아직 확정할 수 없다.

생성량보다 사람의 채택과 변경 결과를 따로 봤다

적용 후 문의 130개 중 127개에 초안이 만들어져 커버리지는 97.7%였다. 초안이 생성된
문의 중 사용 이력이 확인된 문의는 70개로, 문의 단위 채택 신호는 55.1%였다.

flowchart LR
    A["적용 후 문의<br/>130건"] --> B["초안 생성 문의<br/>127건 · 97.7%"]
    B --> C["초안 사용 문의<br/>70건 · 55.1%"]

Loading

별도 변경 제안 집계에서는 110건 중 64건이 병합됐고, 43건은 종료됐으며 3건은 열려
있었다. 상태 판정이 끝난 107건의 병합률은 59.8%다.

pie showData
    title 개발 에이전트가 만든 변경 제안 110건의 상태
    "병합 64" : 64
    "종료 43" : 43
    "열림 3" : 3

Loading

초안 퍼널과 변경 제안 집계는 분모가 다르므로 하나의 전환율로 연결하지 않는다. 또한
병합은 배포나 사용자 경험 개선을 뜻하지 않는다.

3. 알게된 것

수치에서 얻은 인사이트

관측	해석	아직 말할 수 없는 것
중앙 해결시간 67.7h → 20.2h	적용 후 코호트의 최종 처리 속도는 더 낮게 관측됨	개발 에이전트 단독으로 70.2% 단축했다는 인과 주장
7일 내 해결률 38.8% → 94.1%	성숙 코호트의 완료 결과가 함께 좋아짐	요청 난이도·담당자·운영 방식 변화의 영향 배제
첫 답변 4.9h → 14.8h	최종 처리 개선과 응답성 악화가 동시에 가능	개발 에이전트 실행시간이 원인이라는 단정
초안 커버리지 97.7%, 사용 신호 55.1%	생성 성공과 사람 채택 사이에 별도 품질·대기 문제가 있음	무편집 채택률이나 절감된 사람 시간
상태 판정 변경 제안 병합률 59.8%	코드 제안이 실제 리뷰 결과까지 이어진 비율을 확인	병합된 변경의 배포 완료와 UX 개선

가장 중요한 학습은 좋아 보이는 하나의 수치로 전체 효율을 설명하면 안 된다는 점이다.
결과, 속도, 품질·안전, 사람 비용을 독립적으로 봐야 병목이 이동한 것을 발견할 수 있다.

앞으로 무엇을 개선할 것인가

첫 응답 대기열을 다음 실험의 1순위로 둔다

다음 실험의 가설은 "초안 생성 이후의 검토 대기열을 줄이면 최종 해결 성과를 해치지 않고
첫 답변시간을 낮출 수 있다"이다.

flowchart LR
    D["초안 생성"] --> Q["검토 큐 진입"]
    Q --> O["검토 열기"]
    O --> E["편집 또는 승인"]
    E --> S["고객 발송"]

    Q -. "현재 미측정" .-> Q1["대기시간"]
    O -. "추가 수집" .-> O1["활성 검토시간"]
    E -. "추가 수집" .-> E1["무편집·수정·폐기 사유"]

Loading

추가할 이벤트는 초안 생성, 검토 열기, 포커스 시작·종료, 편집 시작·종료, 승인·폐기,
발송 시각이다. 주 지표는 첫 답변 P50/P75, 가드레일은 최종 해결 P50/P75와 7일 내
해결률, 초안 폐기율이다.

같은 품질 지표로 다시 측정한다

초기에는 무편집 발송률 4.2%, 편집 유사도 0.48, 평균 -99자라는 기준선을 얻었지만,
개선 적용 후 같은 방식의 재측정값은 아직 없다. 다음 릴리스부터 아래 지표를 동일한
분모와 규칙으로 반복 측정한다.

• 무편집 채택률과 수정 후 채택률
• 초안과 최종 발송본의 문면 유사도
• 시제 수정률, 번호 목록 제거율, 확인 질문 유지율
• 폐기율과 폐기 사유: 오진, 범위 오판, 버그 부정, 장황함
• 코드 조사 결론과 고객 초안 설명의 일치 여부

변경 제안에서 사용자 효과까지 증거 사슬을 연결한다

현재는 피드백, 초안, 변경 제안 상태와 사용자 행동 신호가 각각 존재하지만, 병합된 코드가
언제 어느 환경에 배포됐는지 연결하는 키가 없다.

flowchart LR
    F["피드백"] --> P["변경 제안과 head SHA"]
    P --> M["merge SHA"]
    M -. "추가 필요" .-> D["배포 ID·SHA·환경·시각"]
    D -. "추가 필요" .-> X["경로별 오류·피드백·UX"]

Loading

배포 이력이 연결되기 전에는 병합 시각을 배포 시각으로 대체하지 않는다. 연결 뒤에는
변경 리드타임, 배포 실패·롤백, 배포 전후 경로별 오류와 피드백을 함께 볼 수 있다.

같은 화면의 반복과 같은 결함의 재발을 구분한다

현재 피드백 322건 모두에 URL이 있고, 정확 URL 52개 중 33개는 반복 발생 그룹이다.
하지만 같은 URL에서 문의가 반복됐다는 사실만으로 같은 결함이 재발했다고 볼 수 없다.

다음에는 URL의 동적 ID와 쿼리를 제거한 경로 패턴, 결함 fingerprint, 수정 커밋, 배포 ID,
재발 사유를 함께 기록한다. 배포 후 7일·14일·28일 관찰창에서 경로 노출 사용자 수를
분모로 반복 피드백률을 계산한다.

인과효과는 비교 설계가 준비된 뒤 판단한다

이번 수치는 한 서비스의 적용 전후 운영 관측이다. 다음 단계에서는 비슷하지만 개발
에이전트가 적용되지 않은 서비스나 경로를 비교군으로 두고, 주 단위 결과와 가드레일의
사전 추세를 확인한다. 비교군과 사전 추세가 충분히 유사할 때만 통제 시계열이나 시차 도입
비교로 효과와 불확실성을 보고한다.

근거와 해석 범위

이 문서는 다음 내부 근거를 프로젝트 식별 정보 없이 역할 중심으로 정리했다.

• 운영 결과 대시보드와 상세 코호트 집계
• 초안과 실제 발송본의 문면·톤 비교 분석
• 변경 제안의 자체 보고와 실제 변경 내용 대조
• 개발 에이전트의 분류·조사·수정·검증 구현
• 회귀 픽스처, 의도 분류 벤치, 격리 재현 하네스와 로컬 검증 기록
• 운영 서비스의 초안·변경 제안·품질 평가·사용자 행동 상태 스키마

현재 확인할 수 있는 결론은 개발 에이전트 적용 후 코호트에서 최종 해결시간과 7일 내
해결률의 관측값이 달라졌고, 피드백에서 초안·코드 변경·사람 검토 결과까지의 테스트 루프를
구축했다는 것이다. 사람 공수 절감, 프로덕션 배포 효과, 동일 결함 재발 감소, 개발
에이전트 단독 인과효과는 아직 확인되지 않았다.