새 개념이 나오면 사람들은 곧장 도구부터 집는다. 그래프 엔지니어링이라는 말을 듣자마자 첫날부터 랭그래프나 오토젠으로 프로덕션급 시스템을 짜기 시작한다. 그런데 프로덕션용 랭그래프 베스트 프랙티스는 6개 영역 18개 항목이고, 첫 그래프에 그게 다 필요할 리 없다.
제안된 순서는 반대다. 화이트보드를 열고 최종 결과물을 한 문장으로 적고, 잡을 그리고, 앞 단계 없이는 정말로 할 수 없는 일에만 화살표를 긋는다. 그리고 손으로 세 번 돌려본다. 이게 이미 그래프 엔지니어링 레벨 1이다.
근거
수동 버전이 눈에 띄게 더 나은 결과물을 못 만들어낸다면, 자동화해봤자 그저 평범한 결과물을 더 빨리 뽑아낼 뿐입니다.
도구는 워크플로우 다음에 와야 합니다. 이해하지 못한 워크플로우를 자동화하면 엉망이 돼요.
이 원칙의 짝이 되는 경고가 규모에 대한 것이다. 에이전트가 많다고 결과가 좋아지지 않는다. AI 작업자 다섯이 똑같이 틀린 생각을 자신 있게 반복하기도 하고, 시스템이 생각하는 시간보다 서로 조율하는 데 시간을 더 쓰기도 한다. X에서 거대한 그래프로 바이럴을 타는 건 목표가 아니다. 목표는 일의 품질을 높이는 가장 작은 그래프다.
수동 실행은 느린 대신 하나를 준다 — 이 구조가 실제로 품질을 올리는지에 대한 증거. 자동화는 그 증거를 확보한 뒤에 붙이는 증폭기다. 증거 없이 증폭기를 먼저 달면, 검증되지 않은 워크플로우가 더 큰 소음을 더 빨리 만들어낸다.
연결된 생각
- 20260812-graph-engineering — 레벨 1(수동) → 레벨 2(파일) → 레벨 3(오케스트레이션) 구현 경로의 근거.
- 20260611-the-orchestration-paradox-in-multi-agent-systems — 조율이 정교해질수록 실행 신뢰성이 떨어지는 역설과 같은 경고.
- 20260806-skills-mark-the-shift-from-user-to-workflow-designer — 도구 사용자에서 워크플로 설계자로 넘어가는 순간의 판단 기준.
- 20260605-process-beats-prompting — 레버리지는 도구가 아니라 프로세스 이해에 있다.