에이전트에게 “다르게 생각하라”를 가르칠 수 있는가

에이전트가 막히는 순간을 지켜본 적이 있다면 익숙한 장면이 있을 겁니다. 같은 접근을 조금씩 바꿔가며 반복하다가, 같은 벽에 같은 각도로 계속 부딪히는 모습. 사람이라면 이쯤에서 담배를 피우러 나가거나, 동료에게 “이거 좀 봐줄래?”라고 말하거나, 아예 문제 정의부터 뒤집습니다. 에이전트는 그걸 못 합니다 — 루프에 그런 상태가 없기 때문입니다.

Ouroboros의 ooo lateral(내부적으로 ouroboros_lateral_think)은 정확히 그 빈칸을 겨냥한 기능입니다. 이 글은 설치된 소스 코드를 직접 열어 이 기능의 구조를 확인하고, 실제 운영 경험에 비춰 그 유용성을 고찰한 기록입니다.

구조: 다섯 명의 사고 페르소나

ooo lateral은 막힌 문제를 서로 다른 사고 방식을 가진 페르소나에게 던집니다. 소스의 페르소나 정의 파일(agents/*.md)에서 직접 인용하면:

Hacker — "’불가능’을 받아들이지 않는다 — 남들이 놓친 경로를 찾는다. 규칙은 멈춰 설 벽이 아니라 우회할 장애물이다.” 정공법이 실패했을 때의 비정통적 우회로.
Contrarian — “모두가 참이라 가정하는 것을 검증하고, 자명해 보이는 것을 뒤집는다.” 접근 자체의 근본 결함을 찾는 역발상.
Simplifier — “복잡성은 밥값을 못 하면 잘린다.” 요구사항과 추상화를 의심하며 최소 해법으로 환원.
Architect — 문제의 구조 자체를 재편성.
Researcher — 관점이 아니라 정보가 부족할 때, 부족한 정보부터 찾는다.

persona='all'로 지정하면 다섯을 병렬로 팬아웃하는데, 여기 중요한 설계가 하나 숨어 있습니다 — 각 페르소나는 독립된 LLM 컨텍스트에서 돕니다(공식 표현으로 “no cross-contamination”). 이게 왜 중요한지는 뒤에서 다시 이야기하겠습니다.

진짜 발명: UNSTUCK이라는 ‘상태’

기능 자체보다 더 흥미로운 건 이 기능이 어디에 꽂혀 있는가입니다. Ouroboros의 실행 루프는 Directive라는 상태 기계로 돌아갑니다. 소스의 열거형을 그대로 옮기면:

CONTINUE  — 현재 계획대로 진행
EVALUATE  — 산출물을 평가 파이프라인으로
EVOLVE    — 다음 세대 제안으로 진화
RETRY     — 같은 계획으로 재실행
UNSTUCK   — 침체(stagnation) 감지 시, 측면 사고 페르소나 호출
COMPACT   — 컨텍스트 압축 후 계속
WAIT      — 외부 입력 대기
CANCEL    — 실패 종료 / CONVERGE — 수렴 성공 종료

주목할 것은 RETRY와 UNSTUCK이 별개의 상태라는 점입니다. 독스트링은 명시적으로 적습니다: “단순 재시도가 아니라 접근의 변화가 필요할 때(a change in approach is required rather than a simple retry)”.

대부분의 에이전트 루프는 실패를 한 종류로만 취급합니다 — 재시도하거나 포기하거나. 하지만 실패에는 두 종류가 있습니다. 우연한 실패(타임아웃, 플레이크 — 재시도가 답)와 구조적 막힘(접근 자체가 틀림 — 재시도는 같은 벽에 다시 부딪히는 일). Ouroboros는 이 구분을 상태 기계에 새겨 넣었습니다. “언제 다르게 생각해야 하는가”라는 메타인지를 루프의 일급 시민으로 만든 것 — 제가 보기에 이게 ooo lateral의 진짜 발명입니다.

왜 독립 컨텍스트가 핵심인가

막힌 에이전트에게 “다르게 생각해봐”라고 같은 세션에서 말하면 어떻게 될까요. 별로 달라지지 않습니다. 지금까지의 시도, 실패, 가정이 전부 컨텍스트에 쌓여 있고, 모델은 그 관성 위에서 “다른 척하는 같은 답”을 냅니다. 사람의 고착(anchoring)과 정확히 같은 메커니즘입니다.

ooo lateral이 페르소나마다 깨끗한 독립 컨텍스트를 주는 건 그래서입니다. 막힌 컨텍스트는 오염원입니다. 신선한 컨텍스트 + 강하게 편향된 페르소나 프롬프트 = 진짜 관점 다양성. 같은 모델이라도 “무엇을 보고 시작하는가”와 “어떤 철학으로 보는가”를 바꾸면 실질적으로 다른 사고가 나옵니다. 에드워드 드 보노가 말한 수평적 사고(lateral thinking)의 원리 — 같은 구덩이를 더 깊게 파지 말고 다른 곳을 파라 — 를 컨텍스트 격리로 구현한 셈입니다.

유용성 고찰: 실제로 언제 값어치를 하는가

이론은 아름답습니다. 실전 감각으로 저울질해 보겠습니다.

값어치가 확실한 순간들. 최근 홈랩에서 디스크 폭주를 추적하며 겪은 일이 좋은 예입니다. “UFW 로깅 레벨이 원인”이라는 첫 가설에 갇혀 logging low → off를 반복했지만 로그는 계속 쌓였습니다. 그때 필요했던 건 더 정교한 재시도가 아니라 Contrarian의 질문이었습니다 — “UFW 설정이 이 로깅을 통제한다는 가정 자체가 맞나?” 실제 범인은 UFW 밖에서 삽입된 유령 iptables 규칙이었죠. GPU 도입 검토에서도 마찬가지입니다. “어떻게 GPU로 옮기지?”에 매몰될 뻔한 순간, Simplifier의 답 — “옮기지 마라, 이미 해결됐다” — 이 정답이었습니다. 구조적 막힘은 생각보다 자주 오고, 그때 재시도는 항상 배신합니다.

비용을 따져야 하는 순간들. 반대로 냉정하게 볼 지점도 있습니다. 첫째, 5-페르소나 팬아웃은 공짜가 아닙니다 — 독립 컨텍스트 다섯 개는 토큰 다섯 배입니다. 가벼운 막힘에 전 페르소나를 소집하는 건 낭비이고, 실제로 단일 페르소나 지정이 기본 동작인 이유이기도 합니다. 둘째, 참신함 편향의 위험. Hacker가 제안하는 “비정통적 우회로”는 때로 제약 조건(보안, 컨벤션, 운영 안전)을 우회하자는 말과 구분이 어렵습니다. 다행히 Ouroboros는 lateral의 산출물이 곧바로 채택되는 구조가 아니라 평가 게이트(EVALUATE)를 다시 통과해야 하는 구조라, 발산은 자유롭게 하되 수렴은 검증이 맡습니다. 발산-수렴의 분리 — 이게 없었다면 위험한 기능이었을 겁니다.

가장 흔한 오용은 방향이 반대일 때입니다. 막힘의 원인이 관점이 아니라 정보 부족인 경우 — 로그를 안 읽었거나, 문서를 안 찾았거나 — 에는 화려한 역발상보다 Researcher 한 명(혹은 그냥 검색)이 답입니다. 다섯 페르소나 중 Researcher가 끼어 있는 건 이 오용을 자인하는 설계로 읽힙니다. “다르게 생각하기 전에, 더 알아봐야 하는 것 아닌가?”라는 자문이 내장돼 있는 거죠.

하네스 관점의 위치: 규율의 반대말이 아니다

하네스 시리즈의 언어로 정리하면 재미있는 역설이 보입니다. Superpowers가 “절차를 지켜라”는 규율이고 gstack이 “만들 가치부터 심문하라”는 게이트라면, ooo lateral은 언뜻 규율의 반대 — 일탈의 장려 — 처럼 보입니다.

하지만 실제로는 일탈조차 하네스가 관리합니다. 언제 일탈할지(UNSTUCK 감지), 어떻게 일탈할지(다섯 페르소나), 일탈의 결과를 어떻게 받을지(평가 게이트 재통과)가 전부 구조화되어 있습니다. 창의성을 운에 맡기지 않고 호출 가능한 서브루틴으로 만든 것. 자유분방한 브레인스토밍이 아니라, 규율 잡힌 발산입니다.

맺으며

ooo lateral의 유용성을 한 문장으로 압축하면 이렇습니다 — “막혔다”를 감지 가능한 상태로, “다르게 생각하기”를 호출 가능한 동작으로 만들었다. 사람의 문제 해결에서 가장 암묵적이던 부분(언제 접근을 바꿀지 아는 감각)을 명시적 기계 상태로 옮긴 시도이고, 그래서 재시도밖에 모르는 순진한 에이전트 루프보다 한 층 깊습니다.

물론 페르소나 다섯이 실제 동료 다섯을 대체하지는 않습니다. 하지만 새벽 4시의 홈랩에는 동료가 없습니다. 그 시간에 “이 가정 자체가 틀린 것 아니야?”라고 물어줄 Contrarian이 상태 기계 안에 산다는 것 — 그게 이 기능의 정직한 값어치라고 생각합니다.