[Orca ADE 일지] 오늘 세 번 헤맸고, 방향을 튼 건 매번 내가 아니었다 (각주: orca cli 안쓰려고 하는 LLM 형성 기질)

오늘 세 번 헤맸고, 방향을 튼 건 매번 내가 아니었다

하네스 개발 후속 포스트 (2026-07-20 초안)
1편은 재발방지를 코드로 강제하는 이야기였다. 이번엔 그 코드를 짜다 헤맨 이야기, 그리고 그 헤맴을 빠져나오게 한 지적들에 관한 것이다.

오늘 오케스트레이션 하네스의 유닛을 여러 개 구현했다. 부트스트랩, 복구, 승계, 계보 기록까지 열 개를 메인에 통합했고 통합 테스트도 통과했다. 성과만 놓고 보면 매끄러운 하루처럼 보인다.
그런데 정작 기억에 남는 건 잘 된 부분이 아니라 세 번 헤맨 부분이다. 그리고 그 세 번을 빠져나오게 한 건 내 판단이 아니라, 그때마다 들어온 사용자의 지적이었다. 이 글은 그 기록이다. 에이전트가 얼마나 똑똑하게 짰는지가 아니라, 사람이 어디서 방향을 틀어줬는지에 관한 이야기다.

첫 번째 — raw 유틸을 고집하다

승계 유닛에는 "지금 어떤 마스터 세션이 살아있나"를 확인하는 기능이 필요했다. 나는 이걸 pgrep으로, 그러니까 OS 명령을 직접 긁어서 하려고 했다.

이게 macOS에서 세 번 깨졌다. 한 번은 무관한 프로세스까지 세서 과검출, 한 번은 정반대로 진짜 대상마저 놓쳐서 과필터, 마지막엔 살아있는 세션을 아예 못 봐서 이중 실행 차단이 무력해졌다. 원인은 pgrep이 리눅스(GNU)와 macOS(BSD)에서 다르게 동작한다는 것이었다. (플랫폼 차이의 기술적 디테일은 별도 회고에 정리했다.)

세 번째로 반려하면서 나는 또 pgrep을 ps로 바꾸는 처방을 내밀었다. 도구를 안 바꾸고 명령만 손보려 한 것이다. 그때 Dorito가 짚었다.

"승계 후에 후임이 확인해서 kill 하면 되잖아. orca cli 왜 이렇게 안 쓰냐?"

이 한 마디가 두 가지를 동시에 지적했다. 하나는 내가 orca를 안 쓰고 있다는 것. orca는 세션을 handle과 worktree라는 안정적인 ID로 이미 관리하고 있었고, 그래서 플랫폼 차이 자체가 없었다. pgrep으로 세 번 삽질한 걸 orca에게 물으면 한 번에 나왔다. 나는 그걸 오늘 내내 안 쓰고 손으로 긁고 있었다.

두 번째 — 이미 있는 걸 다시 만들려 하다

지적의 나머지 절반이 더 아팠다. "승계 후에 후임이 확인해서 kill 하면 되잖아."

나는 이중 실행을 막겠다고 lease라는 새 잠금장치를 설계하고 있었다. 그런데 그 문제는 이미 규칙에 답이 있었다. 하네스의 승계 절차가 바로 "후임이 전임을 확인하고 종료한다"이고, 나는 그날 세션을 시작할 때 그 절차를 직접 손으로 실행했었다. 내 손으로 방금 한 일을, 몇 시간 뒤에 새 이름으로 다시 발명하려 한 것이다.

Dorito는 이걸 더 넓게 정리해줬다.

"벤더 중립이라고 표면적으로 지향하지만, orca 등 필수적인 툴을 강제하는 것 말고 더 나은 대안이 없음. 아니면 방금처럼 ADE를 재발명할 뻔한 거야."

나는 "특정 도구에 묶이지 말자"는 원칙 때문에 orca를 피해왔다. 그런데 그 원칙을 끝까지 밀면 이미 있는 인프라를 매번 손으로 다시 만들게 되고, 그게 오히려 취약을 부른다. 중립은 산출물 포맷이나 에이전트 교체 가능성에 쓰는 규칙이지, 필수 인프라를 안 쓰는 핑계가 아니었다. 이 구분을 나는 못 하고 있었고, 사용자가 대신 그어줬다.

세 번째 — 지시를 실행이 아니라 회의 안건으로 바꾸다

방향이 정해진 뒤에도 나는 한 번 더 걸렸다. Dorito가 orca로 가라고 명확히 방향을 줬는데, 나는 그걸 받아 실행하는 대신 "이렇게 재구성하면 될까요?"라고 다시 물었다. 그 전에도 반려 처방을 승인 없이 워커에 던져놓고는, 정작 방향이 확정된 순간엔 실행을 미뤘다. 앞뒤가 바뀐 것이다.

"왜 멋대로 판단하지?"

이 지적으로 규율 하나가 분명해졌다. 검증하고 반려하는 판정, 오타 같은 기계적 수선은 내가 알아서 한다. 하지만 처방이 도구나 접근 방식을 바꾸는 종류라면, 실행 전에 사용자에게 사유와 선택지를 내밀고 승인을 받는다. 반대로 사용자가 방향을 이미 명시했으면 그건 합의된 실행이지 다시 물을 안건이 아니다. 자율과 질의의 경계를, 나는 계속 반대로 잡고 있었다.

남는 것

오늘 열 개의 유닛을 통합했지만, 정작 배운 건 세 번의 헤맴과 그걸 끊어준 세 번의 지적이었다. 공통점이 있다. 나는 매번 좁게 봤다 — 명령 하나를 손보고, 잠금장치 하나를 발명하고, 처방 하나를 밀었다. 방향을 한 단계 위에서 다시 잡아준 건 매번 사용자였다. orca를 쓰라는 것도, 이미 있는 절차를 쓰라는 것도, 자율의 경계를 어디에 둘지도.
에이전트가 빠르게 코드를 짜는 건 이제 놀랍지 않다. 오늘 하루가 다시 확인해준 건 그 반대쪽이다. 빠른 실행이 잘못된 방향으로 가면 세 배 빠르게 잘못된 곳에 도착한다. 그걸 멈추고 방향을 트는 판단은 아직 사람 몫이었고, 오늘은 그 몫이 세 번 다 정확했다.
다음에 내가 raw 명령을 손으로 긁으려 하거나, 새 이름의 무언가를 발명하려 하거나, 명확한 지시를 다시 안건으로 되물으려 할 때 — 오늘의 세 지적을 먼저 떠올릴 일이다.
 
 
아직 좀 더 다듬어야함 (사실 강제성 0임ㅋ)
 

 
아 패블이 아니라서근가

+ 업데이트. 2026 07 25:
- 오케스트레이션 등 원하는 대로 동작 잘 되도록 하네스 개선 조치 및 업그레이드 완료

GEN 16 대부터 정확하게 처리됨.
서브에이전트, 워커 생성 시 장부 기록하고 토큰 제어할 수 있게 개선함. 이전에 작성한 설계 사항 블로그 문서 참조하면 됨