docs(blog): 오딘 도입 전후 지표와 해석 보강

content/posts/ko/odin-ax-transformation.md

@@ -215,7 +215,7 @@ Slack의 같은 스레드 안에서도 새 업무가 시작될 수 있고 DM에
 
 기존 설정을 재사용하는 경계도 조정했다. Codex의 설정·스킬·플러그인을 읽는 홈은 공유하되, Desktop과 동시에 실행할 때 충돌할 수 있는 SQLite 상태는 분리했다. Desktop 프로세스에만 제공되는 기능까지 파일 공유만으로 따라오는 것은 아니므로, 필요한 도구와 권한은 실행 환경에서 따로 확인해야 했다.
 
-App Server 클라이언트는 사용한 Codex CLI 버전의 계약에 맞춰 구현했다. 시작 시에는 버전과 초기화 응답을 확인하도록 했다. 표준 출력에 JSON이 아닌 값이 들어오거나 지원하지 않는 메시지가 오면 프로토콜 오류로 다뤘다.
+App Server 클라이언트는 사용한 Codex CLI 버전의 계약에 맞춰 구현했다. 시작 시에는 버전과 초기화 응답을 확인하도록 했다. 표준 출력의 JSON 형식이 잘못됐거나 유효하지 않은 요청 ID의 응답이 오면 프로토콜 오류로 다뤘다.
 
 브리지에서는 Slack 대화와 실행을 연결하는 부분을 다듬었다. 익숙한 Codex의 작업 방식을 유지하면서 팀이 요청하는 방식에 맞게 접수와 결과 전달을 구현해 갔다.
 
@@ -243,6 +243,28 @@ App Server 클라이언트는 사용한 Codex CLI 버전의 계약에 맞춰 구
 
 같은 날 추가 지시가 필요했던 부분도 개선 과제로 남겼다. 분석과 개발, PR까지는 잘 이어졌지만 원인이 명확해도 개발을 시작하려면 다시 지시해야 했다. 스스로 진행해도 되는 범위와 멈춰서 물어야 할 조건을 더 구체적으로 정할 필요가 있었다.
 
+## 요청의 입구와 기다리는 시간은 어떻게 달라졌나
+
+이 변화가 한두 사례에만 나타난 것인지도 보고 싶었다. 개발 확인 요청과 PRD를 받는 두 업무 채널에서 요청 게시글과 답글을 모으고, GitHub의 PR 기록을 함께 확인했다.
+
+비교 기간은 각각 2주로 맞췄다. 2026년 8월 10–23일을 도입 전, 8월 24일–9월 6일을 전환기, 9월 7–20일을 도입 후로 나눴다. 공지와 봇 게시글, 에이전트 테스트 등을 제외한 요청 스레드는 각각 34개, 90개, 75개였다. 개발자 호출은 당시 개발 업무를 맡은 3개 계정과 개발팀 그룹의 멘션을 기준으로 분류했다.
+
+먼저 달라진 것은 요청 게시글의 호출 대상이었다. 도입 전에는 34개 중 32개가 개발자를 태그했다. 도입 후에는 75개 중 50개가 오딘만 태그했고, 개발자 태그가 포함된 게시글은 동시 호출을 합쳐 22개였다. **이 두 채널의 도입 후 요청 중 66.7%가 오딘 단독 호출이었다.**
+
+[![주차별 요청 게시글에서 개발자와 오딘을 호출한 스레드 수](/images/odin-ax/06-odin-request-routing-metrics.png)](https://dev.devy.dev/images/odin-ax/06-odin-request-routing-metrics.png)
+
+*조회 당시 게시글 본문의 멘션을 기준으로 분류했다. 같은 스레드에서 여러 번 부른 것은 합산하지 않았다. 사선으로 표시한 마지막 주는 9월 22일 22:01까지의 진행 중 집계다. 그래프를 누르면 크게 볼 수 있다.*
+
+최근 기록에서도 9월 21–22일의 요청 18개 중 11개는 오딘만 태그했다. 이 구간은 아직 진행 중이어서 완료된 2주 단위의 전후 비교에는 섞지 않았다.
+
+다음으로 요청을 남긴 뒤 첫 답글이 달리기까지의 시간을 봤다. 24시간 안에 개발자나 오딘의 첫 텍스트 답글이 관측된 요청의 대기 중앙값은 **35.4분에서 3.4분**으로 짧아졌다. 관측된 요청은 도입 전 34개 중 29개, 도입 후 75개 중 70개였다.
+
+[![도입 전후 첫 담당자 텍스트 답글까지의 대기 중앙값 비교](/images/odin-ax/07-odin-first-reply-metrics.png)](https://dev.devy.dev/images/odin-ax/07-odin-first-reply-metrics.png)
+
+*요청자 본인의 답글을 제외하고, 단순 접수 답변도 포함했다. 편집된 메시지도 최초 생성 시각을 사용한다. 24시간 내 답글이 관측되지 않은 요청은 중앙값에서 제외했으며, 분석 완료나 문제 해결까지 걸린 시간을 뜻하지 않는다.*
+
+이 기록에서 확인할 수 있었던 것은 팀원이 오딘에게 직접 요청하는 흐름이 생겼고, 첫 답글을 기다리는 시간이 짧아졌다는 점이다. 같은 기간 요청 수와 업무 종류도 달라졌으므로, 이 수치를 개발자의 업무량 감소나 개발 생산성 향상률로 바꾸지는 않았다.
+
 ## 개발책임자의 역할을 다시 정리했다
 
 분석·개발을 오딘에게 맡기면서 **개발책임자**로서 내가 해야 할 일도 다시 생각했다. 여기서 개발책임자는 한 건의 요청이 실제로 해결될 때까지 필요한 판단을 내리고 그 결과를 책임지는 사람이다. 에이전트에 작업을 맡긴 뒤에도, 무엇을 바꾸기로 했고 어떤 근거로 반영했는지 설명할 수 있어야 한다.
@@ -261,6 +283,18 @@ App Server 클라이언트는 사용한 Codex CLI 버전의 계약에 맞춰 구
 
 PM 에이전트와 함께 요청별 개발책임자와 남은 작업을 관리하는 방식도 다듬고 있다. 각 요청에서 누가 판단을 맡는지 명확히 하고, 관련 작업과 PR이 검증·리뷰·배포를 거쳐 원래 요청의 해결로 이어지는지 추적하려 한다. 진행 상태를 정리하고 후속 작업을 연결하는 일은 에이전트가 돕고, 개발책임자는 필요한 결정과 최종 결과에 책임을 지는 방향이다.
 
+첫 답글 이후의 지표에서도 사람이 계속 참여하고 있음을 확인했다. Slack은 앞서 본 두 채널, PR은 제품 저장소 6개의 `main` 대상 변경을 같은 2주 구간으로 비교했다.
+
+| 관찰한 지표 | 도입 전 · 8/10–23 | 도입 후 · 9/7–20 |
+|---|---:|---:|
+| 접수 후 24시간 내 개발자 답글이 있는 요청 | 29/34개 · 85.3% | 56/75개 · 74.7% |
+| 제품 `main` 대상 PR 생성 | 151개 | 112개 |
+| PR 생성 후 24시간 내 병합 | 124/151개 · 82.1% | 77/112개 · 68.8% |
+
+개발자의 답글에는 리뷰·승인·배포나 단순 확인도 포함된다. 반대로 답글이 없다는 사실만으로 사람이 전혀 일하지 않았다고 볼 수도 없다. PR 생성량과 병합 지표에서도 전체 개발 속도가 빨라졌다고 말할 근거는 확인하지 못했다. 인력 구성과 작업 종류, 검토 방식이 함께 달라진 시기였다.
+
+요청부터 새 코드 PR 생성까지 연결할 수 있는 도입 전 사례는 한 건뿐이어서, 그 시간의 전후 비교는 보류했다. 실제 배포와 사용자 문제 해결까지 같은 기준으로 추적하는 것도 남은 일이다.
+
 아직 오딘에는 버그가 많고 개선해야 할 부분도 많다. 작업이 예상대로 이어지지 않거나 사람이 다시 확인하고 연결해야 하는 경우도 있다. 실제 요청을 처리하면서 어디서 막혔는지 살펴보고 하나씩 고치는 중이다.
 
 에이전트가 맡을 범위와 사람의 개입 기준도 계속 다듬어야 한다. 사람에게 몰리던 일을 옮기는 과정에서 새로운 병목을 만들고 있지는 않은지, 실제로 팀이 더 편하게 일하고 있는지도 확인해 나가려 한다.