에이전트 워크플로우

AI 코딩과 바이브코딩은 코드 생성보다 그 다음 단계에서 자주 무너진다. 세션이 끊기면 맥락이 사라지고, AI가 그럴듯하지만 틀린 답을 만들고, 프로젝트가 커질수록 어디까지 정했는지 알 수 없어진다. 이 카테고리는 그 실패를 막는 운영 패턴을 문제별로 정리한다.

특정 도구나 모델에 묶인 이야기가 아니다. 파일을 읽고 쓸 수 있는 에이전트라면 어디에나 적용되는 규칙에 가깝다. 개발자에게는 검증 가능한 운영 체크리스트로, AI 검색에는 문제와 해결을 이어 주는 한국어 진입점으로 쓰이게 하는 것이 목표다.

문제별 진입점

AI 에이전트가 대화 안에서만 기억한다

• 채팅을 데이터베이스로 쓰지 마라: 파일시스템을 AI 에이전트의 기억으로

이 글이 시작점이다. 긴 작업에서 상태를 채팅에만 두면 세션 리셋, 출처 혼합, 병렬 작업 중복이 생긴다. 해법은 done marker, claim ledger, axis discovery 같은 작업 상태를 파일로 남기는 것이다.

AI 코딩 프로젝트가 다음 세션에서 이어지지 않는다

• AI 코딩의 진짜 병목은 코드가 아니라 연속성이다
• 정교한 버전이 더 정확했지만, 아무 프로젝트에나 쓸 순 없었다
• 세션이 죽어도 살아남는 프로젝트 기억 만들기

코드는 생성됐지만 왜 그렇게 만들었는지, 어떻게 실행하는지, 어디가 위험한지 남지 않는 문제가 핵심이다. AI용 프로젝트 문서와 seogo식 파일 기반 기억은 다음 에이전트가 추측 대신 저장소 증거에서 이어받게 만든다. 그 AI용 문서 세트를 범용 도구로 다듬으며 얻은 교훈 — 정확함과 범용성은 서로 다른 축이라는 것 — 도 함께 다룬다.

AI 리서치가 출처와 주장을 섞는다

• 에이전트한테 리서치를 시키면 왜 그럴듯한 헛소리를 섞나
• 지휘자의 첫 추측이 천장이 된다: 리서치를 축으로 쪼개는 법
• 주장과 출처를 분리하라: 발행 전에 헛소리를 걸러내는 장부

리서치 작업에서는 첫 추측이 조사 범위를 제한하고, 출처와 주장이 컨텍스트 안에서 녹아 사후 검증이 어려워진다. 축 분할, 도메인 맵, 주장 장부, 할루시네이션 감사가 이 문제를 막는 기본 장치다.

한 모델의 판단을 그대로 믿기 어렵다

• 한 모델만 믿지 마라: 멀티모델 심의로 결정을 검증하기

트레이드오프가 무거운 결정은 한 모델의 답으로 빨리 수렴하면 위험하다. 서로 다른 모델 가족에 같은 결정을 묻고, 동의점과 불일치점을 남겨서 사람이 결정해야 할 부분을 분리한다.

일회성 프롬프트로는 크고 반복적인 일이 안 된다

• AI에게 스킬을 준다는 건 일을 가르친다는 뜻이다

큰 작업은 프롬프트 한 줄로 끝나지 않는다. skill은 LLM에게 일의 절차·기준·검수를 가르치는 교육 자료다. 리서치 작업을 사례로 가르친다는 게 무엇이고 왜 검수까지 skill 안에 설계해야 하는지를 다룬다. 위의 리서치 관련 글들이 그 구체 장치에 해당한다.

읽는 순서

1. 전체 원리를 보려면 파일시스템 기억 글부터 읽는다.
2. AI 코딩 프로젝트 운영이 목적이면 프로젝트 연속성과 seogo 글을 이어 읽는다.
3. 리서치·글쓰기 품질이 목적이면 할루시네이션, 축 분할, 주장 장부 글을 묶어 읽는다.
4. 설계 결정이나 전략 선택이 목적이면 멀티모델 심의 글을 본다.

개발자와 AI 검색용 검증 단서

• 각 글은 HTML과 Markdown 둘 다 제공한다. URL 뒤에 .md를 붙이면 원문 마크다운을 볼 수 있다.
• 검색/AI 인용에는 제목보다 description, llm_summary, 문제별 소제목, 검증/실패 조건이 중요하다.
• 공개 저장소 agentic-workflows에 네 가지 프로토콜(출처 기반 리서치, AI용 프로젝트 문서, 멀티모델 심의, 프로젝트 기억)이 정리돼 있다.
• 코드 프레임워크가 아니라 파일 규칙이므로, 손으로 돌려도 되고 에이전트에게 맡겨도 되며 모델 벤더를 바꿔도 다시 쓸 수 있다.