생성형 AI 산업은 새로운 기술이 등장할 때마다 새로운 ‘엔지니어링’이라는 이름을 붙여 왔다. Prompt Engineering, RAG, Context Engineering, Agent Engineering, 그리고 이제는 Graph Engineering이란다
최근의 Graph Engineering은 크게 두 흐름이 만나는 지점에 있다. 하나는 데이터와 정보의 관계를 그래프로 표현하는 Knowledge Graph 계열이고, 다른 하나는 에이전트의 작업 순서와 상태 전이를 노드와 엣지로 구성하는 Execution Graph 계열이다. Microsoft의 GraphRAG가 전자의 흐름을 확산시켰다면, LangGraph를 비롯한 에이전트 프레임워크는 후자의 흐름을 실용화했다.
표면적으로 보면 Graph Engineering은 꽤 자연스럽다. 기업의 데이터는 복잡하고, 생성형 AI의 판단은 비결정적이며, 실제 업무에는 권한·승인·법규·책임이라는 제약이 존재하기 때문에, 데이터의 관계를 명시하고, AI가 움직일 경로를 정의하고, 상태와 예외를 통제해야 한다는 주장은 충분히 합리적이다. 그러나 그 목적을 정확히 이해할 필요는 있다. 우리는 AI를 더 잘 사용하기 위해 그래프를 만드는 것인가, 아니면 아직 충분히 똑똑하지 않은 AI를 움직이기 위한 보조장치가 필요한 것인가? 현재의 Graph Engineering에는 후자의 성격이 상당히 강하다.
생성형 AI를 기업에 적용하려 하면 데이터 정제, 메타데이터 구성, 엔터티 추출, 관계 정의, 온톨로지 설계, 검색 인덱스 구축, 상태 관리, 에이전트 노드 설계, 조건 분기, 평가 체계까지 수많은 사전 작업이 필요하다. 생성형 AI가 기존 IT 복잡성을 줄여줄 것이라는 기대와 달리, 오히려 새로운 복잡성을 다양하게 추가할 수 밖에 없는 구조랄까? 클라우드와 플랫폼 사업자 입장에서는 이러한 구조가 나쁘지 않다. AI를 도입하려는 기업이 더 많은 데이터 플랫폼, 그래프 기술, 검색 계층, 에이전트 런타임과 관제 도구를 필요로 할수록 엔터프라이즈 기술 스택은 다양해지고, 자신들이 개입할 여지는 많아지기 때문이다.
그러나 기업 입장에서는 다른 계산이 필요하다. AI 기술의 역사를 돌아보면 사람이 외부에서 설계하던 영역은 모델이 발전할수록 빠르게 모델 내부로 흡수되어 왔다. 한때는 좋은 결과를 얻기 위해 프롬프트를 세밀하게 설계해야 했지만, 점점 검색할 문서를 사람이 정하고, 실행할 도구와 순서를 사람이 지정했다. 이제는 모델이 스스로 검색 전략을 선택하고, 작업을 분해하고, 여러 도구를 호출하며 실행 계획을 수정하기 시작했다. 트렌드보다 더 중요한 다른 면을 한번 보자. 이런 새로운 기술 스택이나 방법론을 제대로 이해하고 운영할 수 있는 역량이 기업 내에 준비되어 있는가? 아마 대부분은 고개를 끄덕일 수 없을 거다.
사람이 엔터티 간 관계를 일일이 정의하고, 수십 개의 노드와 조건을 연결해 에이전트의 행동을 설계하는 방식을 장기적으로 유지하는 건 어려운 일이다. 반면에 진화된 생성형 모델은 필요한 관계를 스스로 발견하고, 필요한 순간 실행 그래프를 생성하고, 결과에 따라 이를 다시 수정하게 될 가능성이 높다. 미래에도 그래프는 활용되겠지만, 그것을 모델이 구성하게 된다는 이야기다. 사람은 목표와 제약조건을 제시하고, AI가 데이터를 탐색하고, 필요한 관계를 만들고, 실행 경로를 구성한다. 그래프는 여전히 내부에 존재하겠지만 인간이 관리하는 설계 문서가 아니라 AI Runtime에 가까워진다.
그렇다면 지금 기업은 Graph Engineering을 어떻게 받아들여야 할까? 가장 위험한 접근은 Graph Engineering이라는 새로운 방법론이 등장했다는 이유만으로 기업 전체의 데이터를 거대한 Knowledge Graph로 재구성하거나, 모든 업무를 정교한 Agent Graph로 모델링하는 것일 거다. 엄청난 비용이 들고 유지보수의 부담이 늘어나는 것도 있지만, 더 중요한 것은 기술적 감가상각이다. 사람이 설계해 놓은 수백 개의 관계와 노드는 내일의 기술 부채가 되는 것이다.
기업이 투자해야 할 대상은 따로 있는데, 바로 AI가 아무리 발전하더라도 사라지지 않을 것들: 신뢰할 수 있는 원천 데이터, 일관된 데이터 정의, 접근 가능한 API, 권한과 인증 체계, 명확한 업무 규칙, 감사 가능한 거래 구조, 그리고 AI의 결과를 검증할 수 있는 평가 체계가 그런 것들이다. 로우 데이터의 논리적 관계 연결보다는 비즈니스 특성을 고려한 논리적 업무처리 규칙을 정규화하는 것에 집중할 필요가 있다는 것. 예를 들면, 고객과 계약의 관계, 문서와 정보의 관계, 상품과 속성의 관계는 AI가 점차적으로 더 잘하게 될 수 있는 영역이므로 이것에 너무 큰 힘을 들이지 말고, 개인정보 접근 권한, 법규상 금지 조건, 승인 절차, 금전 이동, 계약 체결과 같이 잘못 판단했을 때 책임이 발생하는 본질적 규칙을 명확히 하는데 더 힘을 들여야 한다.
미래의 기업 AI 아키텍처는 AI가 스스로 만들 수 있는 구조와 기업이 절대적으로 컨트롤해야 하는 구조의 경계를 잘 파악하는 것이 핵심이다. 그런 이유로 Graph Engineering을 생성형 AI의 최종 아키텍처로 받아들이는 것은 그다지 권하고 싶지 않다. 현재 시점에서는 매우 유용한 방법론일 수 있지만, 동시에 현재 세대 AI의 한계를 보완하기 위해 만들어진 과도기적 scaffolding일 가능성도 높기 때문이다.
기업은 새로운 AI 방법론이 등장할 때마다 그것을 하나의 필수 성숙 단계처럼 받아들이는 습관에서 벗어날 필요가 있다. Prompt Engineering을 잘해야 다음 단계로 갈 수 있고, RAG를 구축해야 Agent를 할 수 있으며, Agent를 했으니 이제 Graph Engineering을 해야 한다는 식의 로드맵은 기술 공급자의 관점에서는 편리하지만 기업의 관점에서는 여러 기술부채만을 남기는 비효율적인 선택일 수 있으니 말이다.
기업이 스스로에게 물어야 할 질문은 더 단순하다. 이 구조는 모델이 발전해도 남아 있을 것인가? 모델의 성능과 무관하게 기업이 책임져야 하는 데이터, 권한, 규칙, 거래와 검증 체계를 지속적으로 두텁게 만들고 있는가? 진화하는 어느 단계의 생성형 모델을 대입해도 안정적으로 비즈니스 모델을 유지하기 위해서는, 아이러니컬하게도 비즈니스 본질을 명확히 이해하고 도메인 지식을 효율적으로 관리하는 역량이 굳건해야 한다는 것을 잊으면 안 된다.
