docs(blog): 하네스 설명을 개발 경험과 선택 이유로 보강 (#216)

* docs(blog): 팀의 업무 병목을 줄이기 위한 AX 전환 글 발행

* docs(resume): AX 전환 경력에 관련 블로그 글 연결

* docs(blog): 하네스 설명을 개발 경험과 선택 이유로 보강

Author: devy1540

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

@@ -120,17 +120,19 @@ flowchart TB
 
 오딘의 실행 기반을 고를 때 기준은 이미 업무에서 사용하던 Codex였다.
 
-나는 Codex에 코드 분석과 수정을 요청하고 결과를 보며 추가 지시를 내리는 방식에 익숙했다. 업무용 지침과 스킬, 플러그인, 외부 도구 연결도 사용하고 있었다. Slack에 에이전트를 만든 뒤에도 그 작업 경험과 쌓아 둔 설정을 활용하고 싶었다.
+Codex에 “이 오류를 고쳐 줘”라고 요청하면 관련 코드를 읽고 파일을 수정한 뒤 테스트를 실행한다. 테스트가 실패하면 그 결과를 보고 다시 수정하고, 내가 조건을 추가하면 앞선 작업을 이어간다. 평소 Codex를 쓰면서 익숙해진 것은 이런 작업 방식이었다.
 
-Hermes나 다른 하네스로 옮기면 요청 처리와 도구 실행, 후속 작업 방식을 다시 익혀야 한다고 봤다. 결과를 신뢰할 수 있을 때까지 검증하는 과정도 필요했다. 이미 업무에서 쓰던 Codex를 유지하면 이 부담을 줄이고 Slack에서 어떻게 사용할지에 집중할 수 있다고 생각했다.
+이 과정에서 모델이 다음에 할 일을 판단하면, 모델이 요청한 도구를 실행하고 그 결과를 다시 전달하는 프로그램이 필요하다. 대화와 작업 기록을 이어 주고, 접근할 수 있는 파일과 명령의 범위를 제한하며, 필요한 승인을 받는 것도 이 프로그램의 역할이다. 여기서 말하는 **하네스**는 이렇게 모델이 실제 개발 작업을 이어갈 수 있도록 받쳐 주는 실행 환경이다.
 
-8월 말 에이전트와 대화할 때도 Codex Desktop에서 느끼는 효능감과 사용성을 이쪽에서도 느낄 수 있는지 물었다. 9월 2일 설계를 다시 검토할 때는 기존 Codex 환경과 분리된 홈 디렉터리를 두자는 제안에, 그러면 이미 사용하는 플러그인·인증·스킬을 어떻게 활용하느냐고 되물었다.
+Codex는 이 하네스 안에 작업을 반복하는 실행 루프부터 문맥 관리, 도구 실행, 샌드박스와 승인 처리까지 갖추고 있다. 모델 주변의 실행 기능을 폭넓게 포함한다는 의미에서 ‘fat harness’로 이해할 수 있다. [Codex의 실행 구조](https://developers.openai.com/blog/codex-as-a-platform)
+
+Hermes 역시 모델 호출과 도구 실행, 대화 기록을 관리하는 자체 하네스를 갖고 있다. 같은 모델을 연결하더라도 어떤 지침과 맥락을 전달하고 도구 실행 결과를 어떻게 처리하는지는 하네스에 따라 달라진다. Hermes를 오딘의 실행 기반으로 선택하면 그 동작 방식에 맞춰 설정을 옮기고, 내가 기대하는 방식으로 작업하는지 다시 검증해야 한다고 봤다. [Hermes의 실행 구조](https://hermes-agent.nousresearch.com/docs/developer-guide/architecture)
 
-그래서 **Codex의 작업 경험을 최대한 유지하면서 Slack을 연결하기로 했다.** 새로운 환경에 적응하고 동작을 다시 검증하는 부담을 줄이고 싶었다.
+나는 이미 Codex에서 업무용 지침과 스킬, 플러그인, 외부 도구 연결을 사용하고 있었다. 코드 분석과 수정을 요청한 뒤 실행 결과를 확인하고 추가 지시를 내리는 방식에도 익숙했다. 오딘에서도 이 경험과 쌓아 둔 설정을 최대한 이어가고 싶었다.
 
-여기서 하네스는 모델이 실제 작업을 수행하도록 돕는 실행 체계를 뜻한다. 대화 맥락을 관리하고 도구를 실행하며 진행 상황을 내보낸다. 설정된 권한과 승인 정책 안에서 작업을 이어가는 역할도 한다. OpenAI도 Codex 하네스를 이런 실행 체계로 설명하고 있다. [Codex 하네스 공식 설명](https://developers.openai.com/blog/codex-as-a-platform)
+8월 말 에이전트와 대화할 때도 Codex Desktop에서 느끼는 효능감과 사용성을 이쪽에서도 느낄 수 있는지 물었다. 9월 2일 설계를 다시 검토할 때는 기존 Codex 환경과 분리된 홈 디렉터리를 두자는 제안에, 그러면 이미 사용하는 플러그인·인증·스킬을 어떻게 활용하느냐고 되물었다.
 
-이 실행 체계를 그대로 활용하려 했다. 요청을 이해하고 파일을 조사한 뒤 도구를 실행하고 결과를 보며 다음 지시를 이어가는 작업 방식을 Slack으로 가져오고 싶었다.
+그래서 **오딘의 분석·개발은 Codex 하네스가 맡고, Slack과의 연결은 브리지에서 처리하는 방식**을 택했다. OpenAI가 제공하는 App Server를 활용하면 Codex의 실행 과정을 Slack에서 시작하고 그 결과를 같은 대화로 돌려줄 수 있었다. 새로운 하네스에 적응하고 작업 방식을 다시 검증하는 부담을 줄이면서, 팀원이 Slack에서 직접 요청할 수 있도록 만들고자 했다.
 
 ### App Server와는 양방향 JSON-RPC로 통신했다