'graph engineering'이 이번 달 X에서 트렌드로 뜬 것을 본 대부분의 사람들은 두 가지 중 하나를 했다.
그것을 또 하나의 유행어로 치부했거나, 실제로 어떻게 구축하는지 전혀 모른 채 고개만 끄덕였거나.
소수의 사람들만이 세 번째 선택을 할 것이다: 제대로 배우는 것. 군중이 따라잡기 전에, 이 용어가 아직 충분히 새로운 지금, 진짜로 능숙해지는 것이 몇 년을 앞서가게 하는 때에.
그 그룹을 가르는 것은 재능이 아니다.
그것은 경로다.
그래프 아키텍트는 프레임워크를 암기한 사람이 아니다. 지저분한 현실 문제를 보고 에이전트, 도구, 검증, 인간의 결정으로 구성된 네트워크를 설계해서 그 문제를 안정적으로 해결하는 사람이다. 그것은 진정으로 가치 있는 기술이고, 현재 AI 엔지니어링의 최전선이며, 용어가 생긴 지 2주밖에 안 됐기 때문에 아직 거의 아무도 가지지 못한 기술이다.
그 기술에 도달하는 정확한 경로가 여기 있다. 다섯 개의 단계로 묶인 20개의 스텝이다. 그래프 이론 학위는 필요 없다. 순서대로 따르고 건너뛰지 마라. 모든 스텝이 그 이전 스텝 위에 세워져 있기 때문이다.
1단계: 먼저 루프를 마스터하라 (스텝 1–4)
루프의 네트워크를 구축하려면 먼저 루프 하나를 구축할 수 있어야 한다. 이 단계는 타협할 수 없으며, 이것을 건너뛰는 것이 대부분의 사람들의 그래프가 무너지는 이유다.
스텝 1: 루프가 실제로 무엇인지 이해하라. 루프는 에이전트 작업의 원자다: 에이전트가 행동을 취하고, 결과가 돌아오고, 무언가가 그 결과가 좋은지 확인하고, 작업이 끝날 때까지 주기가 반복된다. 그래프라고 불리는 무엇이든 만지기 전에 이 형태를 뇌리에 새겨야 한다. 그래프는 이런 루프 여러 개를 연결한 것에 불과하기 때문이다. 실행하기: 당신이 이해하는 작업 하나에 대해 루프의 네 가지 요소를 알기 쉬운 말로 적어보라. 행동, 결과, 검증, 반복 조건.
스텝 2: 작동하는 루프 하나를 구축하라. 단순한 실제 작업을 하나 고르고 완료될 때까지 반복하는 단일 에이전트를 구축하라. 도구를 하나만 주어라. 시도하고, 검증하고, 다시 시도하게 하라. 그것이 어떻게 행동하는지, 어디서 막히는지, 어디서 무한 루프에 빠지는지 느껴보라. 이렇게 직접 부딪히는 좌절이야말로 당신이 얻을 최고의 스승이다. 실행하기: 하나의 실제 멀티스텝 작업을 처음부터 끝까지 완료하는 단일 에이전트 루프를 구축하라.
스텝 3: 왜 검증기가 전부인지 배워라. 어떤 루프에서 가장 중요한 부분은 검증, 즉 작업이 좋은지 판단하는 검증기다. 검증기가 약한 루프는 자신만만한 쓰레기를 빠르게 생산한다. 그래프 바로 직전 단계인 루프 엔지니어링은 대체로 좋은 검증기를 작성하는 기술이다. 지금 이것을 마스터하면 나중에 그래프가 쉬워진다. 실행하기: 스텝 2의 루프를 가져와 검증기를 진짜로 엄격하게 만들어라. 출력 품질이 올라가는 것을 지켜보라.
스텝 4: 단일 루프가 규모에서 실패하는 네 가지 방식을 배워라. 루프는 강력하지만 작업이 복잡해지면 예측 가능한 방식으로 무너진다: 깔끔하게 분기할 수 없고, 병렬로 실행할 수 없고, 스텝 간 체크포인트를 강제할 수 없으며, 실패를 그저 재시도로 처리한다. 이 네 가지 실패 모드를 이해하면 그래프가 무엇을 위한 것인지 정확히 알게 된다. 실행하기: 네 가지 실패 모드 각각에 대해, 단일 루프가 어려움을 겪을 작업을 하나씩 적어보라.
2단계: 그래프 멘탈 모델을 배워라 (스텝 5–9)
이제 어휘와 형태를 배운다. 이 단계는 그래프를 구축하기 전에 작업을 그래프로 보는 것에 관한 것이다.
스텝 5: 세 가지 기본 요소를 배워라: 노드, 엣지, 상태. 노드는 작업의 단위다. 엣지는 다음에 무엇이 실행될지 결정하는 경로다. 상태는 시스템을 통해 흐르는 공유 정보다. 아무리 복잡한 그래프라도 이 세 가지일 뿐이다. 완전히 익혀라. 실행하기: 당신이 아는 작업 하나를 골라 종이에 노드와 엣지로 스케치하고, 그 사이에 어떤 상태가 흐르는지 메모를 달아보라.
스텝 6: 모든 노드가 LLM일 필요는 없다는 것을 이해하라. 이것이 아키텍트와 초보자를 가르는 통찰이다. 최고의 그래프는 LLM 기반 노드와 일반 결정적 함수, 도구 호출, 검증기를 혼합한다. 단순한 확인은 모델이 아니라 함수여야 한다. LLM을 남용하는 것은 그래프가 느리고, 비싸고, 불안정해지는 가장 흔한 지름길이다. 실행하기: 스텝 5의 종이 스케치에서 어떤 노드가 정말 LLM이 필요하고 어떤 노드가 일반 함수일 수 있는지 표시하라. 대부분은 함수여야 한다.
스텝 7: 조건부 엣지를 배워라. 그래프를 강력하게 만드는 엣지는 조건부 엣지다: "출력에 오류가 있으면 여기로 라우팅하고, 그렇지 않으면 저기로 계속 가라." 이것이 그래프가 단순 루프가 할 수 없는 결정을 표현하는 방식이다. 실행하기: 스케치에 조건부 엣지를 최소 두 개 추가하라. 시스템이 실제로 내려야 할 결정을 하나 주어라.
스텝 8: 상태를 의도적으로 설계하라. 좋은 그래프 설계의 절반은 좋은 상태 설계다. 공유 상태가 너무 적으면 노드가 제 역할을 못 하고, 너무 많으면 아무도 시스템을 추론할 수 없다. 각 노드가 정확히 어떤 정보를 필요로 하고 무엇을 전달해야 하는지 결정하는 연습을 하라. 실행하기: 스케치한 그래프가 운반하는 전체 상태를 필드별로 작성하고 각각을 정당화하라.
스텝 9: 프레임워크 하나를 골라 그 방식으로 배워라. 많이 필요 없다. 그래프 오케스트레이션 프레임워크 하나를 골라라. LangGraph가 가장 흔한 시작점이며, 그것이 노드, 엣지, 상태를 어떻게 표현하는지 배워라. 개념은 어디에나 전수된다. 연습할 장소 하나만 있으면 된다. 실행하기: 종이 스케치를 하나의 프레임워크에서 실제로 실행되는 그래프로 구축하라. 처음부터 끝까지 실행되게 만들어라.
3단계: 핵심 패턴을 마스터하라 (스텝 10–14)
아키텍트는 구조를 재발명하지 않는다. 어떤 알려진 패턴이 맞는지 인식하고 적용한다. 이 다섯 가지 패턴이 대부분의 실제 작업을 커버한다.
스텝 10: 라우터. 입력을 보고 올바른 전문가 또는 경로로 라우팅하는 노드. 이것은 가장 단순한 분기 패턴이자 다른 모든 것의 관문이다. 실행하기: 다양한 종류의 입력을 서로 다른 처리 노드로 라우팅하는 그래프를 구축하라.
스텝 11: 오케스트레이터-워커. 관리자 노드가 작업을 하위 작업으로 나누고 각각을 워커 노드에 할당한 후 결과를 조합한다. 이것은 대부분의 멀티 에이전트 시스템의 백본이다. 실행하기: 하나의 노드가 두 개 이상의 워커 노드에 위임하고 그 출력을 결합하는 그래프를 구축하라.
스텝 12: 병렬 팬아웃과 팬인. 여러 독립적인 노드가 동시에 실행된 후 그 결과가 단일 노드로 수렴한다. 이것이 그래프가 루프가 낼 수 없는 진짜 속도를 내는 방식이다. 실행하기: 세 가지 작업을 병렬로 실행하고 결과를 병합하는 그래프를 구축하라.
스텝 13: 평가자-최적화기. 한 노드가 작업을 생산하고, 다른 노드가 기준에 따라 그것을 비판하며, 통과할 때까지 작업이 수정을 위해 루프로 돌아간다. 이것은 진지한 그래프의 품질 엔진이다. 실행하기: 생성기 노드와 비평가 노드를 구축하고, 약한 출력이 구체적인 피드백과 함께 돌아가도록 연결하라.
스텝 14: 인간 개입(human-in-the-loop) 게이트. 시스템이 멈추고 계속하기 전에 사람의 승인을 기다리는 노드. 보내기, 게시, 지출, 삭제처럼 되돌릴 수 없는 모든 것은 이 중 하나를 거쳐야 한다. 이것은 프로덕션에서 선택 사항이 아니라 그래프를 안전하게 만드는 요소다. 실행하기: 그래프 하나에서 중대한 작업 앞에 승인 대기 노드를 추가하라.
4단계: 안정성을 위해 구축하라 (스텝 15–18)
누구나 그래프를 한 번 실행하게 만들 수 있다. 아키텍트는 만 번째도 실행되게 만든다. 이 단계가 기업이 실제로 돈을 지불하는 이유다.
스텝 15: 검증 게이트를 추가하라. 평가자 패턴을 넘어, 중요한 지점에 명시적 게이트 노드를 추가해서 진행 전에 작업이 기준을 충족하는지 검증하는 역할만 하게 하라. 이름이 있고 타협할 수 없는 체크포인트는 루프에 대한 그래프의 가장 큰 장점이다. 실행하기: 출력이 정의된 기준을 통과하지 못하면 그래프를 완전히 중지시키는 검증 게이트를 추가하라.
스텝 16: 복구 경로를 설계하라. 루프가 실패에 답하는 방식은 "재시도"다. 아키텍트의 답은 의도적인 경로다: 더 단순한 방법으로 폴백하거나, 인간에게 에스컬레이션하거나, 명확한 메시지와 함께 안전하게 실패한다. 각 종류의 실패가 무엇을 할지 미리 결정하라. 실행하기: 실패할 수 있는 모든 노드에 대해, 그냥 영원히 재시도하는 대신 실패가 어디로 라우팅될지 정의하라.
스텝 17: 체크포인트와 상태 영속화를 추가하라. 실제 그래프는 일시 중지하고 재개할 수 있다. 시스템이 중간에 멈추면, 인간을 기다리든 크래시에서 복구하든, 처음부터 다시 시작하는 대신 중단한 지점에서 이어가야 한다. 체크포인트에서 상태를 영속화하는 것이 이것을 가능하게 한다. 실행하기: 그래프 하나가 실행 중간에 멈추고 중단한 지점에서 재개할 수 있게 만들어라.
스텝 18: 관찰 가능하게 만들어라. 보이지 않는 것은 고칠 수 없다. 각 노드가 무엇을 했는지, 어떤 상태가 흘렀는지, 어디서 문제가 생겼는지 볼 수 있도록 로깅과 추적을 추가하라. 아키텍트는 그래프를 디버깅할 수 있는데, 디버깅 가능하게 설계했기 때문이다. 실행하기: 어떤 실행에서 무슨 일이 일어났는지 정확히 재생할 수 있도록 그래프에 추적을 추가하라.
5단계: 아키텍트처럼 생각하라 (스텝 19–20)
마지막 두 스텝은 구축에 관한 것이 아니다. 그것은 판단에 관한 것이며, 그것이 실제로 누군가를 기술자가 아니라 아키텍트로 만든다.
스텝 19: 그래프를 구축하지 말아야 할 때를 마스터하라. 이 전체 분야에서 가장 시니어한 기술은 대부분의 작업에 그래프가 전혀 필요 없다는 것을 아는 것이다. 단일 검증기가 있는 단일 작업은 루프이며, 루프로 남아 있어야 한다. 작업이 요구하기 전에 그래프를 꺼내드는 것은 당신에게 없던 분산 시스템 문제를 떠안기는 것이다. 아키텍트는 작동하는 가장 단순한 것으로 시작하고 문제가 복잡성을 하나씩 정당화하게 한다. 실행하기: 세 가지 작업을 가져와 어떤 것이 그래프가 필요하고 어떤 것이 그냥 루프나 일반 스크립트인지 정확히 판단하라. "이건 그래프가 필요 없어"라고 말할 수 있는 것이 바로 숙달의 표시다.
스텝 20: 프로덕션, 평가, 팀을 위해 설계하라. 마지막 도약: 다른 사람들이 실행하고, 신뢰하고, 유지할 수 있는 그래프를 설계하라. 그것은 변경이 도움이 되었는지 해가 되었는지 측정할 수 있는 평가 스위트를 구축하고, 동료가 이해할 수 있도록 그래프를 문서화하고, 무너지지 않으면서 확장할 수 있게 설계하는 것을 의미한다. 이것이 영리한 데모와 회사가 비즈니스를 운영하는 시스템을 가르는 기준이다. 실행하기: 그래프 하나에 대한 평가 세트를 구축하고 변경할 때마다 실행하라. 다른 사람이 유지보수할 수 있도록 그래프를 문서화하라.
이 경로를 실제로 걸어가는 방법
20개의 스텝은 사실 다섯 가지 아이디어라는 것을 깨닫기 전까지는 많아 보인다: 루프를 마스터하고, 그래프 모델을 배우고, 패턴을 배우고, 안정성을 위해 구축하고, 언제 멈출지 아는 판단력을 기르는 것.
주말에 스무 개를 모두 소화하려고 무리하지 마라. 서두르는 사람들은 흔들리는 멘탈 모델과 쉽게 깨지는 그래프를 얻게 된다. 1단계에 충분한 시간을 투자하라. 모든 것이 그 위에 놓이기 때문이다. 그런 다음 한 번에 한 단계씩 나아가며, 각 스텝에서 읽기만 하지 말고 실제로 무언가를 구축하라. "실행하기" 액션은 선택 사항이 아니다. 그것이 전부다. 당신은 그래프를 추상적으로 이해해서가 아니라 실제로 구축함으로써 그래프 아키텍트가 된다.
현실적인 속도: 이미 코딩과 LLM API 사용에 익숙하다면 단계당 1~2주, 이제 막 시작했다면 더 걸린다. 진짜 손으로 하는 연습을 6~8주 하면 한 달 전에는 거의 아무도 할 수 없었던 일을 할 수 있게 된다: 실제 문제를 보고 그에 맞는 그래프를 설계하는 것, 그리고 정답이 "이건 필요 없어"일 때를 아는 지혜까지 포함해서.
사람들을 멈추게 하는 네 가지 (그리고 극복하는 방법)
이 로드맵을 시작한 대부분의 사람들은 끝내지 못하고, 예측 가능한 지점에서 멈춘다. 여기가 그 지점과, 각각을 넘어서는 방법이다.
그들은 루프가 너무 기초적으로 느껴져서 1단계를 건너뛴다. 그들은 'graph engineering'이 트렌드인 것을 봤으니, 단일 루프로 시작하는 것은 한 걸음 물러서는 것처럼 느껴진다. 그러다 그래프가 무너지는데 왜 그런지 설명할 수 없다. 내부의 개별 루프가 단단해 본 적이 없기 때문이다. 진짜로 엄격한 검증기가 있는 단일 루프를 구축할 수 있을 때까지 넘어가지 않음으로써 극복하라. 모든 것이 이것 위에 놓이며, 이것을 지키는 사람들은 더 느리게가 아니라 전체적으로 더 빠르게 나아간다.
그들은 구축 대신 프레임워크를 모은다. 튜토리얼을 계속 시청하고, 세 가지 다른 도구를 시도하고, 작동하는 그래프 하나를 배포하지 못한다. 그래프에 대해 배우는 것은 발전처럼 느껴지지만 아무것도 만들어내지 못한다. 프레임워크 하나를 골라 그 안에서 실제 그래프를 최소 세 개 구축할 때까지 다른 것을 만지지 않음으로써 극복하라. 하나에 대한 깊이가 많은 것에 대한 얕은 노출을 이긴다.
그들은 패턴을 배우는 순간 과도하게 설계한다. 3단계 직후, 오케스트레이터와 병렬 워커로 새롭게 무장한 그들은 루프만 필요했던 문제를 위해 정교한 그래프를 구축한다. 그것은 세련되게 느껴지지만 취약하고 유지보수 불가능한 시스템을 낳는다. 스텝 19, 즉 언제 그래프를 구축하지 말아야 하는지를 아는 것을 사후 생각이 아닌 진짜 졸업으로 취급함으로써 극복하라. 절제가 시니어의 기술이다.
그들은 "실행된다"에서 멈추고 "안정적이다"에 도달하지 못한다. 그래프를 한 번 작동시키면 끝났다고 느끼고 4단계를 통째로 건너뛴다. 그러다 현실이 예상치 못한 무언가를 던지는 첫 순간에 그것이 깨지고, 그래프는 불안정하다고 결론 내린다. 검증 게이트, 복구 경로, 디버깅 능력을 갖출 때까지 그래프를 미완성으로 취급함으로써 극복하라. "데모에서는 실행됐다"는 아마추어가 멈추는 지점이고, 아키텍트가 시작하는 지점이다.
각 단계에서 잘하는 것이 어떤 모습인가
스스로를 정직하게 평가할 수 있도록, 각 단계에서 진짜 역량의 기준이 여기 있다.
1단계 이후, 당신은 실제 작업을 안정적으로 완료하는 단일 에이전트 루프를 구축할 수 있고, 약한 검증기가 왜 그것을 망치는지 정확히 설명할 수 있다. 2단계 이후, 어떤 문제든 코드를 작성하기 전에 종이에 노드, 엣지, 상태로 스케치할 수 있고, 어떤 노드가 LLM을 필요로 하고 그렇지 않은지 본능적으로 표시한다. 3단계 이후, 문제를 보고 어떤 핵심 패턴이 맞는지 이름을 말하고, 튜토리얼 없이 구현할 수 있다. 4단계 이후, 그래프가 잘못된 입력, 실패한 도구, 중단과 맞닥뜨려도 살아남고, 어떤 실행이든 재생해서 무슨 일이 있었는지 볼 수 있다. 그리고 5단계 이후, 당신을 차별화하는 것: 요청을 보고 "이건 그래프가 전혀 필요 없어"라고 정확히 말할 수 있다. 어떤 패턴보다 이것이 그래프 아키텍트가 실제로 무엇인지를 보여준다.
다섯 가지를 모두 할 수 있다면, 한 달 전에는 거의 아무도 가지지 못했고 유행어가 사라진 후에도 계속 가치를 발할 기술을 가진 것이다.
시작하기 전에 모두가 묻는 질문들
이 경로를 시작할 때마다 빠짐없이 나오는 몇 가지 질문이 있다. 솔직한 답변은 다음과 같다.
그래프 이론이나 심화 수학을 알아야 하나요? 아니요. 이것은 컴퓨터 과학 수업에서 배우는 그래프 이론이 아니며, 순회에 관한 정리를 증명할 필요도 없다. 여기서 "그래프"는 단지 정보가 흐르는 엣지로 연결된 노드들, 즉 해결책을 그리는 한 가지 방식을 의미한다. 상자와 화살표를 스케치하고 그 사이에 흐르는 것을 추론할 수 있다면, 필요한 수학은 모두 가진 것이다.
먼저 뛰어난 프로그래머가 되어야 하나요? 코드 작성과 LLM API 사용에 익숙해야 한다. 프로그래밍이 완전히 처음이라면, 먼저 거기에 시간을 써라. 하지만 전문가일 필요는 없다. 그래프 엔지니어링의 어려움 대부분은 고급 코딩이 아니라 구조에 대한 명확한 사고다. API를 호출하고 응답을 처리하는 단일 에이전트를 구축할 수 있다면 1단계를 시작할 준비가 된 것이다.
어떤 프레임워크를 배워야 하나요? 흔히 쓰이는 그래프 오케스트레이션 프레임워크 하나를 골라 깊게 파라. 구체적인 선택보다 하나에 충분히 전념해서 그 안에서 실제 그래프 여러 개를 구축하는 것이 훨씬 중요하다. 노드, 엣지, 상태, 게이트 같은 개념은 어디에나 전수되므로, 당신은 실제로 도구가 아니라 그 분야 자체를 배우는 것이다. 프레임워크를 옮겨 다니는 것은 나아지지 않으면서 바쁘게 느껴지는 방법일 뿐이다.
이건 6개월이면 사라질 유행어일 뿐 아닌가요? 단어는 사라질 수 있어도 기술은 사라지지 않는다. 당신이 실제로 배우는 것, 즉 믿을 수 없는 모델을 중심으로 안정적인 시스템을 설계하는 것은 다른 이름으로 수년간 가치가 있었고, 다음 이름이 무엇이든 계속 가치 있을 것이다. 당신은 용어에 베팅하는 것이 아니다. 지금 우연히 트렌디한 라벨을 갖게 된, 오래 지속되는 능력을 구축하는 것이다.
언제쯤 나를 그래프 아키텍트라고 불러도 되는지 어떻게 알 수 있나요? 실제 문제를 보고 그에 맞는 구조를 설계할 수 있을 때다. "이건 그래프가 필요 없어"라고 자신 있게 말하는 것까지 포함해서. 자격증이나 프레임워크 배지가 아니라, 그 판단이 전부다. 패턴을 구축할 수 있고 언제 하지 말아야 하는지 안다면, 당신은 거기에 도달한 것이다.
그래프 아키텍트가 되는 것에 대한 솔직한 진실
그 타이틀은 인상적으로 들리고 유행어는 뜨겁지만, 실제로 중요한 것은 이것이다.
그래프 아키텍트가 되는 것은 그래프에 관한 것이 아니다. 복잡함 속에서 명확하게 사고하는 것에 관한 것이다. 그래프는 단지 안정적으로 작동할 만큼 정밀하게 해결책을 그리는 한 가지 방식이다. 이것을 마스터하는 사람들은 가장 많은 패턴을 암기한 사람들이 아니다. 혼돈을 보고 그것을 길들이는 가장 단순한 구조를 볼 수 있는 사람들이다. 때로는 그래프를 의미하고, 종종 훨씬 더 단순한 것을 의미한다.
그 기술은 유행어가 사라져도 만료되지 않는다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 루프 엔지니어링, 그리고 이제 그래프 엔지니어링, 이름은 계속 바뀌지만, 믿을 수 없는 모델을 중심으로 안정적인 시스템을 설계하는 기반 능력은 더욱 가치 있어질 뿐이다. 이것을 깊이 배우면 트렌드를 쫓는 것이 아니다. 사다리의 모든 미래 단계가 요구할 기술을 구축하는 것이다.
지금 이 기회의 창 안에서 움직여야 할 이유가 있다. 기술은 수요가 높고 공급이 거의 없을 때 가장 가치가 있다. 그리고 그 격차는 어떤 용어가 주류가 된 직후, 대부분의 사람들이 실제 작업을 하기 전에 가장 크다. 지금 막대한 수의 사람들이 그래프 엔지니어링에 대해 이야기하고 있지만, 그들 중 거의 아무도 실제로 안정적인 그래프를 설계할 수 없다. 그 격차가 기회이며, 이런 격차는 군중이 따라잡으면서 좁혀진다. 창이 닫힌 후가 아니라 창이 열려 있는 동안 움직이는 사람들이 몇 년의 선두를 몇 주로 압축한다.
이 용어는 생긴 지 2주다. 군중은 여전히 그것이 무엇을 의미하는지 논쟁 중이다.
8주 후, 당신은 여전히 한 단어에 대해 의견을 쏟아내는 사람 중 하나일 수 있다.
또는 실제로 그것을 구축할 수 있는 소수 중 하나일 수 있다.
1단계는 단일 루프를 이해하는 것이다. 오늘 거기서 시작하라.
이 글이 유용했다면, 저를 팔로우해 주세요 @eng_khairallah1 이런 AI 콘텐츠를 더 원하신다면요. 매주 분석, 코스, 도구를 게시합니다.
도움이 되었기를 바랍니다, Khairallah ❤️
