오르카 하네스 노하우 뒤에 이어진 오케스트레이션 회의론

dev1 ~ 5로 쪼갠 오르카 하네스

오후 2시 16분, 한 참여자가 오르카로 오케스트레이션할 것을 권하며 클로드(페이블)로 만든 자체 하네스 구조를 공개했다. CTO 역할을 80% 맡기고 코딩 난이도를 1 ~ 3차로 나눈 뒤, dev1부터 dev5까지 명령어로 세션을 구분해 마크다운 파일로 소통시키는 방식이었다.

🔸 "다들 오르카로 오케스트레이션하세요" 🔸 "각각 명령어로 인식하기 쉽게 dev1-5까지 나눠서 명령어 입력하면"

Sol과 클로드(페이블)에게 동시에 같은 작업을 시킨 뒤 더 나은 결과를 고르고, 섹션을 M1·M2 등으로 나눠 진행하다 한 섹션이 끝날 때마다 가재코드로 검수받는 방식까지 구체적으로 풀어놓자 궁금해하던 참여자들의 질문이 이어졌다.

🔸 "Sol이랑 페이블 동시코딩해서 비교하고 더 나은쪽으로 선택한다음에 한 섹션씩 M1 M2 이렇게 나누고 "

한 시간 뒤, "오케스트레이터가 무슨 소용" 회의론

그런데 한 시간여 뒤 같은 방에서 정반대의 목소리가 나왔다. 한 참여자는 오케스트레이터의 존재 의미 자체를 회의하며, 여러 AI를 위원회처럼 합의시키는 방식(LLM council)은 결국 망가진다고 단언했다.

🔸 "저는 오케스트레이터가 이제 뭔 소용인가 싶긴합니다" 🔸 "개똑똑한 ai 가 다른 ai 를 개패놔야함"

사장을 뽑아야 한다면 무조건 클로드(페이블)이며, 개똑똑한 독재자 하나가 멍청한 하위 모델들을 갈구고 굴리는 편이 스타트업 이론과도 맞닿아 있다고 비유했다. 이어 사람의 의도를 유도해 끌어내는 '인간 끌어내기' 방식에 대해서는, 사람 스스로도 자기가 뭘 원하는지 모르는 문제가 영원히 남기 때문에 본인 취향은 아니지만 그 흐름 자체는 유지될 것 같다는 전망도 덧붙였다.

🔸 "인간 끌어내기 계열은 어차피 사람이 자기가 뭘 말하고싶어하는지 모르는 문제는 영원해서, 이게 어떻게든 (제 취향은 아니지만) 그 플로우 자체는 유지될거같은데"

벤치마크에 대해서도 회의적인 입장을 밝혔다.

🔸 "그건 마치 학원 열심히 다녀서 서울대 붙은 친구한테 수능문제 만들라고 하는 꼴이기때문에"

결국 정답은 직접 토큰을 태워보며 모델과 친해지는 것뿐이라고 결론지었다. 하네스가 제공하던 가치가 모델 성능 자체로 흡수되는 메타 변화를 겪고 있다는 통찰도 함께 나왔다.

실전과 회의론이 같은 날 공존한 이유

같은 오후, 같은 방에서 정교하게 다듬은 멀티세션 하네스 노하우와 오케스트레이션 무용론이 나란히 오갔다는 점은 시사하는 바가 크다. 하네스를 직접 설계해 쓰는 참여자와, 모델 자체 성능이 좋아질수록 그런 설계의 효용이 줄어든다고 보는 참여자가 같은 커뮤니티 안에 공존한다는 뜻으로 읽힌다. 도구를 정교하게 짜는 실전파와, 도구보다 모델과의 친숙도를 우선하는 회의파 사이의 긴장이 이 방의 저녁 시간대를 채운 것으로 보인다.