[🤖] Graph Engineering을 Codex에 시험 적용해봤다

✨ GPT-5.6 Sol의 요약 　

16시간짜리 Codex 작업이 엉망으로 끝난 뒤, Graph Engineering이 정말 해결책인지 계속 반박하며 검토하고 최소 Gate Skill로 만들어 실제 권한 계약에 시험 적용한 기록.

어제 UI/UX 대개편을 위한 페이지별 명세를 긴 시간 토론해서 작성해두고, 그 명세에 기반해 개발하라고 Codex Goal을 설정했다. Goal은 16시간 동안 돌았다.

오늘 기대되는 마음으로 화면을 열어봤는데 결과물은 그냥 개 쓰레기였다.

이틀 전에도 AI 원 샷 마법이라는 환상에서 벗어나자고 썼다. 이번에는 한 줄짜리 지시로 끝내지 않았다. 역할별 업무와 페이지별 명세도 만들었고, 달력과 table view, 검색과 filter, 실패 복구까지 꽤 구체적으로 정했다. 실패한 prototype을 겪으며 UI 감사 기준도 따로 만들었다.

그런데 여러 worker가 밤새 코드를 만들고 test와 감사를 통과했다고 보고한 결과가, 내가 보기에 무슨 말을 하는 화면인지조차 이해하기 어려운 옛날 관리 화면이었다. 내가 그렇게 이야기했던 달력과 table view는 대체 어디에 갔는지 알 수 없었다.

토큰은 엄청나게 썼고, 코드는 엄청나게 바뀌었고, PASS 보고도 엄청나게 쌓였다. 그런데 정작 내가 원한 결과는 없었다.

겸손해졌다. 또.

그래서 이번에는 Graph Engineering을 Codex에 시험 적용해보기로 했다. 최신 유행어를 공부하고 끝내거나 거대한 framework부터 설치하는 것이 아니라, 내가 당장 겪은 실패를 실제로 줄일 수 있는 가장 작은 형태로 만들어보기로 했다.

Graph Engineering을 시험해볼 이유가 생겼다

왜 이런 일이 생겼는지 AI에게 분석시켰다. 공용 규칙도 문제였고, UI 감사가 글자 크기나 button 높이처럼 측정하기 쉬운 항목에 치우친 것도 문제였다. 하지만 제일 큰 문제는 따로 있었다.

Codex가 중간 결과를 내놓을 때마다 내가 확인한 것이 아니었다. 구현한 세션이 스스로 완료했다고 보고했고, 다른 세션들은 그 결과를 이어받아 다음 page와 backend를 계속 만들었다. 처음 잘못 잡힌 정보 구조가 검증도 받기 전에 여러 화면으로 퍼졌다. 마지막에 내가 직접 화면을 열었을 때는 이미 16시간치 작업이 그 잘못된 방향 위에 쌓여 있었다.

그러니까 필요한 것은 AI를 더 오래 돌리는 법이 아니었다.

중간 결과가 틀렸으면 다음 작업으로 넘어가지 못하게 하는 구조가 필요했다.

이 문제를 놓고 AI와 계속 토론하다가 Graph Engineering이라는 말을 알게 됐다. 한 Agent의 긴 loop에 전부 맡기는 대신 여러 Agent와 검증기, 사람의 판단을 node와 edge로 연결하고, 어떤 결과가 나왔을 때 다음 단계로 갈 수 있는지를 명시적으로 설계하는 접근이었다. 완전히 새로운 기술이라기보다는 기존 workflow와 state machine에 최근 붙기 시작한 이름에 가까웠다.¹

중요한 것은 최신 buzzword를 하나 더 외우는 것이 아니었다. 지금은 Codex session 하나가 꽤 긴 작업 전체를 맡을 수 있으니, 그 session이 만든 결과를 node로 놓고 다음 session으로 넘어가는 조건을 설계할 수 있다는 점이었다.

내가 시험하려는 Graph Engineering을 이번 작업에 대입하면 이랬다.

• node: 사용자가 독립적으로 검토할 수 있는 중간 결과
• edge: 감사 판정에 따라 수정하거나 다음 작업으로 이동하는 조건
• state: 어떤 결과를 어떤 기준으로 감사했고 지금 무엇을 할 수 있는지 남긴 기록
• cycle: 감사에서 결함이 나오면 같은 결과만 고쳐 다시 확인하는 반복

즉 Agent를 여러 개 부르는 것 자체가 Graph Engineering은 아니었다. 검증되지 않은 node에서는 후속 edge가 열리지 않도록 topology와 상태 전이를 먼저 정하는 것이 내가 시험할 핵심이었다.

내가 그린 첫 graph는 작업 세션과 감사 세션뿐이었다

Graph Engineering을 이번 문제에 적용해보자는 이야기를 꺼내자 AI는 금세 구조를 크게 만들기 시작했다. Coordinator, Worker, Auditor를 나누고, 사용자 방향 승인과 계약 version, durable ledger, 전체 cold audit 같은 것들이 줄줄이 붙었다.

각각만 보면 틀린 이야기는 아니었다. 그런데 나는 불안했다.

“쓸데없이 복잡해지는 거 아님?”

16시간 동안 토큰을 다 써놓고 성과가 없었던 문제를 막겠다고, 이번에는 Agent를 여러 개 띄우고 상태와 보고서만 잔뜩 만들면 무엇이 달라지는가. Graph Engineering을 적용하는 일 자체가 또 하나의 거대한 작업이 되면 똑같이 토큰만 빨아먹을 수 있었다.

내가 생각한 것은 훨씬 단순했다.

작업 세션이 검토 가능한 결과 하나를 완성한다.
→ 감사 세션에 전달하고 작업 세션은 기다린다.
→ 감사 세션이 PASS 또는 수정 사항을 돌려준다.
→ 작업 세션은 그때 다시 움직인다.

나는 이 방식을 반복해서 쓸 수 있도록 Skill로 만들면 어떻겠느냐고 물었다. 그런데 AI가 자꾸 세션 구조와 기계적 강제의 한계를 이야기하며 복잡하게 굴었다. 그래서 다른 세션의 답변까지 가져와 다시 물었다.

“Skill로 만드는 게 비효율적이라고? 진심? 네 멋대로 말하는 것 아니고?”

그리고 무조건 내 말에 동의하지 말고 비판하라고 계속 요구했다. 내 아이디어가 맞다는 결론을 듣고 싶었던 것이 아니라, 정말 이 방식이 16시간짜리 실패를 막을 수 있는지, 아니면 그럴듯한 새 장난감을 하나 더 만드는 것인지 알고 싶었다.

반박을 거듭하면서 실험 범위를 줄였다

여러 차례 비판적 검토를 거치면서 내 단순한 안에도 빈틈이 있다는 사실은 인정했다.

작업 세션이 감사 기준까지 정하면 자기 결과에 유리한 기준을 만들 수 있었다. 감사 세션에 작업자의 reasoning과 자기평가를 몽땅 넘기면, 감사자가 독립적으로 보는 것이 아니라 작업자의 설명을 다시 읽는 데 그칠 수 있었다. 감사 중에도 다음 작업을 미리 시작하면 PASS gate는 아무 의미가 없었다. Runtime이 바뀌었는데 예전 화면을 보고 통과시키거나, 대화가 압축된 뒤 이전 PASS를 잘못 기억할 수도 있었다.

반대로 AI가 제안한 것을 다 받을 필요도 없었다. 세 개의 장수명 session, 별도 graph runtime, DB, dashboard, 모든 page의 감사, 계약이 바뀔 때마다 전체 재검사는 버렸다. 그런 것을 다 만들면 제품보다 관리 체계가 더 커진다.

결국 다음 원칙만 남겼다.

• 메인 세션이 조정과 작업을 함께 맡는다.
• 감사가 필요한 결과에서만 별도의 감사 세션을 연다.
• 감사 세션에는 이전 대화 전체를 주지 않는다.
• 감사할 결과를 고정하고, 감사가 끝날 때까지 그 결과와 직접 후속 작업을 건드리지 않는다.
• 구현이 틀린 것과 작업 방향 자체가 틀린 것을 구분한다.
• 한 번 고치고 다시 감사해도 중요한 문제가 남으면 계속 patch하지 않고 계획부터 다시 연다.
• 계약이 바뀌면 영향받은 작업만 다시 검사한다.
• 감사 PASS는 내 제품 방향 승인이나 배포 승인을 대신하지 않는다.

무엇보다 모든 작업에 이 구조를 씌우지 않기로 했다. 오타 하나, 결정적인 test로 끝나는 bug, 아직 답을 찾는 중인 자유 탐색에 감사 세션을 붙이는 것은 낭비다. 잘못된 결과가 여러 후속 작업을 오염시킬 수 있는 지점에만 Gate를 둔다.

페이지 하나도 무조건 하나의 작업 단위로 삼지 않았다. 목록에서 검색하고 상세로 들어가 처리한 뒤 원래 조건으로 돌아오는 과정이 하나의 업무라면, 그 여정 전체가 검토 단위여야 한다. 반대로 같은 pattern을 단순 반복하는 화면마다 별도 감사를 붙일 이유는 없다.

이렇게 따지고 나니 내가 원했던 단순한 graph는 유지하면서도, 왜 멈춰야 하고 무엇을 감사해야 하는지는 분명해졌다.

최소 graph를 Codex Skill로 옮겼다

최종적으로 내가 Codex에 요구한 것은 custom-graph-engineering-gate라는 공용 Skill이었다. OpenAI도 반복해서 사용할 workflow를 Skill로 저장하고, 메인 Agent가 별도의 subagent를 불러 결과를 회수하는 방식을 제공하고 있었다.²³ 별도 서비스를 만들지 않아도 내가 말한 작업 세션과 감사 세션의 왕복을 Codex 안에서 구성할 수 있었다.

Skill을 만들 때도 일을 키우지 말라고 했다. 실행 script도, 별도 DB도, graph dashboard도 만들지 않았다. Skill 본문과 Codex에 표시할 최소 metadata만 만들었다.

Skill이 하는 일은 크게 세 가지다.

첫째, 지금 작업이 정말 Gate를 열 만큼 중요한지 먼저 판단한다. 틀린 중간 결과가 여러 후속 작업을 망칠 때만 사용한다.

둘째, 감사할 결과를 한 문장으로 고정한다. 사용자가 얻을 결과, 성공과 실패를 나눌 기준, 지금 감사하는 정확한 후보, 정상 검증 경로, PASS 뒤에 열릴 직접 후속 작업만 기록한다. 파일을 몇 개 고쳤는지나 test를 몇 개 돌렸는지는 사용자 결과를 대신하지 못한다.

셋째, 작업과 감사 사이의 전이를 제한한다.

PASS              → 직접 후속 작업만 진행
CHANGES_REQUESTED → 같은 결과를 한 번 수정하고 재감사
REPLAN_REQUIRED   → 구현이 아니라 계약이나 작업 분해부터 재검토
NOT_VERIFIABLE    → 증거 없이 통과시키지 않음

감사 세션에는 이전 대화 맥락을 넘기지 않도록 했다. 내가 무엇 때문에 화가 났는지, 작업 세션이 얼마나 열심히 했는지, 구현자가 어디를 잘했다고 생각하는지는 감사 근거가 아니다. 원래 요구와 현재 결과를 직접 보게 한다.

감사 중 source나 Runtime이 바뀌면 기존 판정은 버린다. 작업이 중단되거나 대화가 압축된 뒤에도 어떤 결과가 어떤 판정을 받았는지 실제 증거로 복구할 수 없으면, 통과했다고 추측하지 않는다.

이 정도면 내가 처음 말했던 구조와 크게 다르지 않다. 다만 “감사 세션 하나 두자”라는 아이디어를 다음 session에서도 같은 topology로 실행할 수 있도록, 빠뜨리기 쉬운 전이 조건만 Skill에 박아둔 것이다.

만든 graph를 실제 계약에 시험 적용했다

Skill을 만들었다고 내가 곧바로 잘 만들었다고 믿으면 이번 사고와 다를 게 없었다. 그래서 새 Skill 자체도 이전 대화 맥락을 받지 않은 별도 reviewer에게 넘겼다.

단순한 문구 수정에는 이 Skill을 적용하지 않는 것이 맞는지 먼저 확인했다. 안 써도 되는 일에 안 쓰는 것이 토큰 낭비를 막는 첫 검증이었다.

그다음 여러 기능이 함께 의존할 권한 전환 계약을 첫 실제 node로 삼았다. 작업 결과를 동결하고 감사 세션에 넘기자 첫 verdict는 PASS가 아니라 CHANGES_REQUESTED였다. 권한을 어느 시점 기준으로 판단하는지, 위임 권한이 어디서 왔고 어떻게 철회되는지, 사용자와 권한과 대상 회사가 정말 같은 범위에 묶였는지가 불충분했다.

그 상태로 여러 기능에 적용했다면 나중에 권한 체계 전체를 다시 뜯어고칠 문제였다. 작업 세션이 같은 범위에서 한 번 수정했고, 같은 감사 세션이 다시 확인한 뒤에야 PASS가 나왔다. 그동안 후속 구현과 배포는 열지 않았다.

작은 시험이지만 내가 원했던 Graph Engineering의 효과는 확인했다. 작업자가 “충분하다”고 넘긴 node에서 후속 edge가 닫혔고, 그 결과가 다른 작업으로 퍼지기 전에 고쳤다. 수정된 같은 candidate를 같은 감사 세션이 다시 보고 PASS한 뒤에야 다음 단계를 열 수 있었다.

첫 실험은 통과했지만 UI 실패를 해결했다고 말할 수는 없다

첫 시험에서는 의도한 graph가 작동했다. 하지만 이 Skill이 실제로 16시간짜리 UI 실패를 막았다고 말할 수는 없다. 권한 계약처럼 비교적 명확한 source를 검토한 것과, 사람이 보고 느끼는 UI 방향을 중간에 끊어내는 것은 다른 문제다. 아직 실제 대규모 UI 작업에서 총시간과 토큰을 줄였는지 검증하지 않았다. 감사 세션도 같은 모델과 같은 Working Tree를 보기 때문에 작업 세션과 같은 잘못된 전제에 함께 속을 수 있다. Skill은 지침이지 강제 실행 엔진도 아니다.

그래서 다음 장기 작업에서 봐야 할 것은 PASS 개수가 아니다.

• 첫 잘못된 방향을 전체 확장 전에 잡았는가.
• 감사에 쓴 토큰보다 막아낸 재작업이 더 컸는가.
• 첫 결과를 내가 직접 보는 시점이 늦어지지는 않았는가.
• 작업 세션과 감사 세션이 같은 잘못된 계약에 함께 속지는 않았는가.

효과가 없으면 규칙을 더 붙일 것이 아니라 Gate를 더 적게 써야 한다. 같은 실패가 반복되면 감사 단계를 하나 더 추가할 것이 아니라, 애초에 무엇을 하나의 결과로 묶었는지와 무엇을 감사자에게 보여줬는지부터 다시 봐야 한다.

Graph Engineering을 알게 됐다고 갑자기 AI를 잘 쓰게 된 것은 아니다. 다만 이번에는 유행하는 말을 듣고 거대한 framework부터 설치하지 않았다. 내가 겪은 실패에 필요한 graph만 남기고, AI의 과한 제안도 계속 반박하면서, 다음 session에서도 다시 시험할 수 있는 작은 Skill로 만들었다.

16시간 뒤에야 전체가 잘못됐다는 사실을 발견하지 않기 위해서.

참고 자료

1. LangChain, “3 Years of Graph Engineering with LangGraph”. Graph Engineering이라는 최근 용어와 Agent workflow를 명시적 graph로 설계하는 관점을 설명한다. ↩

2. OpenAI, “Build skills”. 반복해서 사용할 workflow를 Codex Skill로 저장하는 공식 경로를 설명한다. ↩

3. OpenAI, “Subagents”. 메인 Agent가 별도 subagent를 만들고 결과를 회수하는 구조를 설명한다. ↩