이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

요즘 X를 열면 '그래프 엔지니어링(graph engineering)'이라는 말이 자꾸 보입니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 에이전트 엔지니어링, 바이브 코딩, 루프 엔지니어링에 이어 또 등장한 신조어죠. 그렉 아이젠버그(Greg Isenberg)도 처음엔 "진짜 있는 개념인가, 아니면 또 사람들 뒤처진 기분만 들게 하는 유행어인가" 싶었다고 해요. 그런데 직접 뜯어보니 이번 건 남겨둘 만한 쪽이었습니다.

레딧과 틱톡 어드바이저를 지나 지금은 커뮤니티 기반 사업을 하는 레이트체크아웃(Late Checkout)을 이끌면서, 구독자 68만 명의 유튜브 채널과 '더 스타트업 아이디어스 팟캐스트(The Startup Ideas Podcast)'를 진행하는 사람이에요. 대학에서 들은 첫 수업 중 하나가 그래프 이론이었다는 그가, 이번엔 강의실 냄새를 싹 뺀 말로 이 개념을 처음부터 끝까지 풀어냈습니다.

그래프 엔지니어링이란 무엇인가

가장 간단하게 정리하면 이렇습니다.

• 프롬프트 엔지니어링은 AI에게 더 나은 질문을 던지는 법입니다.
• 컨텍스트 엔지니어링은 AI에게 더 나은 정보를 주는 법입니다.
• 그래프 엔지니어링은 AI 주변의 일을 설계하는 법입니다. 그래야 모든 일이 거대하고 지저분한 채팅 하나에 몰리지 않게 되거든요.

앞의 두 개는 AI와 나 사이에서 오가는 것에 관한 얘기예요. 어떻게 물어볼 것인가, 무엇을 알려줄 것인가. 세 번째는 AI가 등장하기 전과 후에 무슨 일이 벌어지는가에 관한 얘기입니다. 누가 무엇을 맡고, 어떤 순서로 넘어가고, 어디서 검사를 받고, 어느 지점에서 사람이 개입하는가. 프롬프트를 아무리 다듬어도 이 층에는 손이 닿지 않아요.

예를 들어볼게요. 새 아이디어를 조사한다고 해봅시다. 보통은 채팅창을 열고 "이 아이디어 만들어야 할까?"라고 묻습니다. 모델은 자신감 있는 답을 주죠. 꽤 똑똑하게 들려요. 시장 규모도 알려주고, 경쟁사도 몇 개 짚어주고, 시장 진입 계획까지 붙여줄 수도 있습니다. 그리고 리서치를 했다는 기분이 듭니다.

그런데 잠깐 멈춰서 따져보면 좀 불편한 일이 벌어졌다는 걸 알게 됩니다. 모델 하나가 한 번에, 무엇이 중요한지 정하고, 시장을 조사하고, 근거를 해석하고, 추천안을 작성하고, 심지어 자기 답이 얼마나 확신할 만한지까지 스스로 매겼거든요. 텍스트 덩어리 하나에 맡기기엔 너무 많은 신뢰죠. 경우에 따라서는 그 질문 하나를 근거로 인생의 몇 년을 쓰게 되는데, 알고 보면 엉뚱한 걸 붙잡고 있는 걸 수도 있습니다.

같은 질문을 그래프로 풀면 많이 다릅니다. 우선 플래너(planner, 일을 쪼개서 배분하는 첫 단계)가 질문을 여러 각도로 나눕니다. 리서처 한 명은 고객을 보고, 다른 한 명은 경쟁사를, 또 다른 한 명은 유통을, 또 한 명은 가격을, 또 한 명은 리스크를 봅니다. 그다음 회의론자(skeptic)가 나와서 근거가 약한 것들을 걸러내려고 달려들어요. 살아남은 근거를 병합 담당이 한 장짜리 추천안으로 만들고요. 그리고 실행에 옮기기 전에 당신이 그 결정을 승인합니다.

최종 결과물은 여전히 글로 된 보고서일 수 있어요. 그런데 그 뒤에 있는 일의 설계가 훨씬 낫습니다. 그게 그래프 엔지니어링의 본질이에요. 지저분한 AI 작업 하나를 가져다가, 실제로 관리할 수 있는 워크플로우로 바꾸는 겁니다.

'잡(job), 화살표, 상태' 세 단어면 됩니다

사람들이 그래프라고 말할 때 뜻하는 건 기본적으로 화살표로 연결된 잡(job, 하나의 작업 단위)들입니다. 잡 하나가 워크플로우의 한 단계고, 화살표는 그다음에 무슨 일이 일어나는지를 보여줍니다. 그리고 워크플로우를 따라 흘러 다니는 공유 메모가 상태(state)인데, 이건 "이 시스템이 지금까지 무엇을 알고 있는가"를 좀 있어 보이게 말한 것뿐이에요.

잡, 화살표, 상태. 무엇을 하는가, 그다음 어디로 가는가, 지금까지 무엇이 쌓였는가. 기술적으로 들리는 건 한 5초 정도고, 그다음엔 이게 현실에서 일이 굴러가는 방식 그 자체라는 걸 깨닫게 됩니다.

콘텐츠 제작을 생각해보세요. 유튜브 에피소드를 하나 만든다고 하면, 그 일은 '대본 쓰기'가 아닙니다. 괜찮은 에피소드는 리서치에서 시작해서, 논지를 잡고, 사례를 찾고, 후킹 문구를 만들고, 대본을 쓰고, 제목 아이디어를 뽑고, 썸네일 방향을 잡고, 엑스칼리드로(Excalidraw, 온라인 화이트보드 도구)로 도식을 그립니다. 그리고 마지막으로 한 번 훑으면서 이걸 물어요. "이게 사람이 말하는 것처럼 들리나, 아니면 SaaS 온보딩 플로우 안에 갇힌 사람처럼 들리나?"

이 단계들 중 일부는 반드시 순서대로 가야 합니다. 논지가 대본보다 먼저 나와야 하고, 대본이 도식보다 먼저 나와야 하죠. 그런데 다른 조각들은 동시에 해도 됩니다. 리서처 한 명이 사례를 찾는 동안 다른 한 명은 반론을 찾을 수 있어요. 그리고 그 결과물들이 다시 대본으로 합쳐집니다. 그래프가 값을 하기 시작하는 지점이 여기예요.

그런데 왜 채팅으로 하면 다 직선이 될까요. 채팅이라는 형식 자체가 모든 걸 순차적으로 느껴지게 만들거든요. 리서치를 시켜놓고, 그다음에 요약을 시키고, 그다음에 초안을 시키고, 그다음에 수정을 시키고, 그다음에 제목을 시킵니다. 아주 단순한 일에는 그걸로 충분해요. 그런데 일에 여러 조각이 있을 때, 이 직선 채팅은 느려지고 흐릿해지고 결과를 믿기 어려워집니다.

그래프의 좋은 점은 일을 작은 팀처럼 설계할 수 있게 해준다는 겁니다. 한 파트가 계획을 세우고, 몇 개가 동시에 일하고, 다른 하나가 그 결과를 검사하고, 또 하나가 병합하고, 마지막에 사람이 승인해요. 이게 머릿속에서 딸깍하고 맞물리는 순간 신비로운 느낌이 확 줄어듭니다. AI를 어떻게 다뤄야 하나가 아니라, 이 일을 어떤 팀 구조로 굴릴까의 문제가 되거든요.

두 가지 '그래프': 지식 그래프와 에이전트 그래프

AI 얘기에서 그래프라고 하면 서로 다른 두 가지를 뜻하고, 혼란이 많이 생기는 지점이 여기입니다.

1. 지식 그래프 (knowledge graph)

지식 그래프는 AI가 사물들 사이의 관계를 놓고 추론하도록 도와줍니다.

예를 들면 이런 겁니다. 이 고객은 이 회사에 다닌다, 이 회사는 이 제품을 쓴다, 이 제품은 이 도구와 연결돼 있다, 이 문의는 이 기능과 관련이 있다, 이 기능은 이 팀이 담당한다. 이렇게 연결해두면 AI가 지저분한 데이터 안에서 관계를 타고 추론할 수 있게 됩니다.

이게 중요한 이유가 있습니다. 일반적인 RAG(AI가 답하기 전에 관련 문서를 찾아와서 참고하는 방식)는 질문과 비슷해 보이는 텍스트 덩어리를 가져오는 데는 강한데, 답을 내려면 서로 다른 사람과 회사와 주제와 주장과 사건을 연결해야 하는 경우엔 잘 못 하거든요. 마이크로소프트의 그래프래그(GraphRAG, 원문에서 지식 그래프를 뽑아내 계층 구조로 정리한 다음 검색에 쓰는 방식) 같은 도구가 있는 것도 그래서입니다. 가장 가까운 문단을 찾아오는 걸로는 부족하고, 지식 덩어리 안의 관계 자체를 이해해야 하는 순간이 있으니까요.

2. 에이전트 그래프 (agent graph)

에이전트 그래프는 일이 어떤 순서로 움직이는가에 관한 겁니다. 앞에서 아이디어 검증을 예로 그려본 그림, 그러니까 질문 하나가 여러 갈래로 갈라졌다가 검사를 거쳐 다시 하나로 합쳐지는 그 구조가 에이전트 그래프예요.

오늘 얘기는 대부분 에이전트 그래프에 관한 겁니다. 창업가로, 크리에이터로, 운영자로, 작은 팀으로 당장 쓰기 시작할 수 있는 쪽이 이쪽이거든요.

헷갈리지 않으려면 이렇게 외우면 됩니다. 지식 그래프는 AI가 정보들이 어떻게 연결되는지 이해하도록 돕고, 에이전트 그래프는 AI가 일이 어떻게 움직여야 하는지 이해하도록 돕는다. 그리고 결국 가장 좋은 시스템은 둘 다 쓰는 겁니다. AI가 당신 비즈니스 안의 관계를 이해하면서, 동시에 올바른 단계들을 밟아나갈 줄도 아는 거죠.

언제 그래프를 써야 하나

새 프로젝트 이름 열 개를 브레인스토밍해달라고 하는 거라면 그래프는 필요 없습니다. 짧은 이메일 하나 요약해달라는 것도 마찬가지고요. 그런데 AI로 심층 리서치를 하거나, 시장 진입 계획을 만들거나, 고객 문의를 분류하거나, 코드를 리뷰하거나, 영업 미팅을 준비하거나, 고객 피드백을 종합하거나, 반복되는 콘텐츠 워크플로우를 돌린다면, 그때부터 그래프식 사고가 크게 중요해집니다.

규칙은 세 개로 줄일 수 있습니다. 일에 여러 단계가 있고, 그중 몇몇은 동시에 진행할 수 있고, 최종 결과물이 실제로 쓰이기 전에 검사가 필요할 때. 이때 그래프를 쓰는 거예요.

그렇게 짜면 모양이 다이아몬드가 됩니다. 질문 하나에서 시작해서, 여러 갈래로 갈라져 동시에 진행되고, 그 결과를 검사한 다음, 다시 하나의 답으로 합쳐져요. 시작점도 하나, 끝점도 하나인데 중간이 부풀어 있는 형태죠.

실전 예시 : 쇼피파이 판매자용 AI 장부 정리 제품

실제 아이디어 하나로 처음부터 끝까지 가볼게요. 질문은 이겁니다. "쇼피파이(Shopify) 판매자를 위한 AI 장부 정리(부기, bookkeeping) 제품을 출시해야 할까?"

지저분한 채팅 버전은 큰 질문 하나와 큰 답변 하나입니다. 그래프 버전은 플래너에서 시작해요.

플래너는 이렇게 말합니다. "이 질문에 제대로 답하려면 고객의 고통, 경쟁 구도, 시장 진입의 쐐기, 가격 압박, 그리고 리스크를 이해해야 한다." 그리고 일이 갈라집니다.

리서처 1 — 고객: 쇼피파이 판매자를 연구하면서 장부 정리 업무의 고통을 파악합니다. 이 사람들은 퀵북스(QuickBooks, 중소사업자용 회계 소프트웨어)를 쓰고 있나? 스프레드시트를 쓰나? 장부 정리 담당자를 고용하나? 세금 낼 때마다 짜증이 나나? 자동화를 원하는 건가, 아니면 그냥 한 달에 한 번 누가 와서 엉망이 된 걸 정리해주길 바라는 건가?

리서처 2 — 경쟁사: 쇼피파이용 장부 정리 도구가 이미 있나? 회계 법인들이 이걸 수작업으로 해주고 있나? 앱스토어 제품들이 이 문제를 조금이라도 풀고 있나? 업워크(Upwork)나 파이버(Fiverr) 같은 해외 프리랜서 마켓플레이스에서 사람들이 하고 있는 일 중에 소프트웨어가 일부 대체할 수 있는 게 있나?

리서처 3 — 유통: 쇼피파이 판매자들이 실제로 어디에 모여 있나? 무슨 뉴스레터를 읽나? 이미 이 사람들의 신뢰를 확보한 에이전시는 어디인가? 쇼피파이 앱 카테고리 중 뭘 검색하나? 구매 의도가 드러나는 검색어는 뭔가?

이 세 가지 일은 서로 의존하지 않기 때문에 동시에 진행할 수 있습니다.

그다음은 회의론자입니다. 회의론자는 이렇게 물어요. 실제로 근거가 뒷받침되는 주장은 뭔가? 어떤 근거가 이미 낡았나? 어떤 경쟁사가 빠졌나? 어디서 '고통'과 '돈 낼 의사'를 헷갈리고 있나? AI가 아무것도 증명하지 않은 채 자신감만 실어서 말한 곳은 어디인가?

이 단계는 사람들이 생각하는 것보다 훨씬 중요합니다. AI 리서치가 실패하는 이유 상당수는, 답을 쓴 모델이 그 답을 채점까지 하기 때문이거든요. 그건 누군가에게 자기 인사평가를 직접 쓰라고 시켜놓고, 그 사람이 스스로를 '비전 있는 인재'라고 적어놨을 때 충격받는 것과 같습니다. 좋은 그래프에서는 검사가 독립된 하나의 일이에요.

그다음은 병합입니다. 병합 단계는 살아남은 근거를 가지고 추천안을 만듭니다. 이걸 추진할 것인가? 잠시 멈출 것인가? 접을 것인가? 쐐기는 뭔가? 첫 고객은 누구인가? 이번 주에 뭘 테스트해봐야 하나? 그리고 어떤 근거가 나오면 우리 생각이 바뀔 것인가?

마지막은 사람 승인입니다. 여기서 당신이 다음에 뭘 할지 결정합니다. 쇼피파이 판매자들의 랜딩페이지를 뜯어보는 콘텐츠를 찍기로 할 수도 있고요. 쇼피파이 에이전시 대표 열 명을 인터뷰하기로 할 수도 있습니다. 장부 정리 비용이 얼마나 나올지 계산해주는 작은 계산기를 만들어보기로 할 수도 있고요. 아니면 이 시장은 이미 너무 붐빈다고 판단하고 그냥 넘어갈 수도 있습니다.

그게 핵심이에요. 그래프 엔지니어링이 당신 대신 결정을 내려주지는 않습니다. 결정을 내릴 때 쓸 근거를 더 잘 만들어내는 방법을 줄 뿐이에요.

시작은 생각보다 훨씬 단순하게

여기서 사람들이 너무 빨리 화려해집니다. X에서 첫날부터 랭그래프(LangGraph, AI 에이전트들의 작업 흐름을 코드로 설계하는 프레임워크)나 오토젠(AutoGen, 마이크로소프트가 만든 다중 에이전트 프레임워크), 아니면 직접 만든 에이전트 프레임워크를 쓰는 걸 보게 되죠.

첫 그래프는 뒤에서 수동으로 돌려도 됩니다. 왜 이렇게 하는 사람이 더 없는지 모르겠어요. 중요한 건 구조거든요. 각 잡에 자기 레인을 하나씩 주는 겁니다. 한 레인은 고객 리서치, 다른 레인은 경쟁사 리서치, 또 다른 레인은 유통 리서치. 그다음 검사 레인이 그 근거들을 공격하고, 병합 레인이 살아남은 근거를 추천안으로 바꿉니다.

이미 이게 그래프 엔지니어링이에요. 레벨 1이죠. 완전 자동화된 시스템보다 느립니다. 대신 훨씬 이해하기 쉬워요. 그리고 수동 버전이 눈에 띄게 더 나은 결과물을 못 만들어낸다면, 자동화해봤자 그저 평범한 결과물을 더 빨리 뽑아낼 뿐입니다.

첫 연습은 자동화하기 전에 그래프를 그려보는 겁니다. 빈 엑스칼리드로나 티엘드로(tldraw, 브라우저에서 바로 쓰는 화이트보드 도구) 보드를 열고, 맨 위에 최종 결과물을 적어요. 그다음 잡들을 그립니다. 플래너, 고객 리서처, 경쟁사 리서처, 유통 리서처, 회의론자, 병합, 사람 승인. 그다음 화살표를 그려요. 플래너가 세 리서처에게 이어지고, 리서처들이 회의론자로 이어지고, 회의론자가 병합으로, 병합이 사람 결정으로 이어집니다. 이 정도면 충분합니다. 이게 수동으로 세 번 잘 굴러가고 나면, 그때 도구를 생각하는 거예요.

레벨별 구현

• 초급: 레인을 나눠서 수동으로 돌립니다. 도구 없이 구조만으로 시작해요.
• 중급: 클로드 코드나 코덱스, 또는 저장소를 두고 각 단계가 파일을 쓰게 합니다. 플래너는 plan.md, 리서처들은 customer.md, competitors.md, distribution.md, 회의론자는 review.md, 병합 단계는 recommendation.md를 써요. 좋은 점은 종이 흔적이 남는다는 겁니다. 무슨 일이 있었는지 볼 수 있고, 버전을 비교할 수 있고, 다음 주나 몇 주 뒤에 그 구조를 그대로 다시 쓸 수 있습니다.
• 고급: 랭그래프, 오토젠 그래프플로우(AutoGen GraphFlow, 오토젠에서 작업 흐름을 그래프 형태로 정의하는 기능), n8n(코딩 없이 여러 서비스를 연결해 자동화하는 오픈소스 도구), make.com(n8n과 비슷한 클라우드 자동화 서비스), 아니면 직접 짠 작은 스크립트로 그래프를 실제로 지휘합니다. 랭그래프는 상태 저장과 사람 개입 승인이 필요할 때, 오토젠 그래프플로우는 순차·병렬·조건 분기·루프가 있는 워크플로우를 원할 때, n8n이나 make.com은 그래프가 슬랙, 이메일, 에어테이블, CRM처럼 매일 쓰는 업무 시스템에 닿을 때 유용합니다.

다시 말하지만 도구가 핵심이 아니에요. 도구는 워크플로우 다음에 와야 합니다. 이해하지 못한 워크플로우를 자동화하면 엉망이 돼요. 워크플로우를 먼저 이해하면, 자동화는 그다음에 너무 당연해집니다.

비즈니스에 어떻게 적용할까

고객 지원

간단한 지원 그래프는 문의를 분류하는 것에서 시작해요. 결제 문제인가? 제품이 헷갈리는 건가? 버그인가? 이탈 위험인가?

그다음 계정 맥락을 확인합니다. 신규 고객인가? 고액 고객인가? 전에도 문의한 적 있나? 지금 화가 나 있나? 같은 문장이라도 어제 가입한 사람이 쓴 건지, 2년 쓰다가 세 번째로 같은 문제를 겪는 사람이 쓴 건지에 따라 답이 달라져야 하니까요.

그다음 문서나 내부 정책을 검색하고, 답변 초안을 쓰고, 검사 담당이 정확성과 톤과 리스크 관점에서 그 답변을 검토합니다. 그리고 환불, 계정 변경, 화난 고객, 법적 리스크, 나중에 회사가 후회할 만한 약속이 걸린 건은 사람이 승인해요.

이게 "AI야, 이 티켓에 답해줘"보다 나은 이유는, 지원 티켓 자체가 진짜 워크플로우가 아니기 때문입니다. 진짜 워크플로우는 이해하고, 조사하고, 초안 쓰고, 검사하고, 승인하는 거예요.

콘텐츠 제작

콘텐츠 그래프의 단계는 앞에서 본 그대로입니다. 리서치, 논지, 사례, 후킹, 대본. 여기에 붙일 건 검사 담당이에요.

검사 담당은 묻습니다. 사례가 구체적인가? 호흡은 괜찮은가? 요즘 먹히는 포맷을 기준으로 봤을 때 이 후킹이 사람들의 주의를 끌 만한가?

그다음 그래프는 제목 아이디어, 썸네일 콘셉트, 자막, B롤 같은 갈래로 뻗어나갈 수 있습니다. 이게 당신이 실제로 콘텐츠 리드를 뽑아서 맡겼을 때 그 사람이 일하는 방식에 훨씬 가까워요.

코딩

코딩 그래프는 계획에서 시작합니다.

그다음 에이전트 하나가 코드를 수정하고, 다른 하나가 변경분을 리뷰하고, 또 하나가 테스트를 돌리고, 또 하나가 브라우저에서 UI를 확인하고, 또 하나가 예외 상황을 찾아요.

그리고 사람이 최종 풀 리퀘스트를 승인합니다.

지금 AI 코딩 도구들이 향하고 있는 방향이 기본적으로 이겁니다. 코드를 쓰는 모델은 워크플로우의 한 부분일 뿐이고, 계획하고 테스트하고 리뷰하고 점검하고 무엇을 배포해도 안전한지 판단하는 그 모든 곳에 레버리지가 있어요.

왜 중요한가

그래프 엔지니어링이 의미 있는 큰 이유 하나가, 결과물의 품질이 "누군가 완벽한 프롬프트를 기억해내느냐"에 덜 의존하게 만든다는 겁니다.

검토가 훨씬 일관되게 바뀝니다. 검사가 사람의 기분이나 그날의 여유가 아니라 워크플로우의 한 단계로 박혀 있으니까요.

위임이 훨씬 깔끔해집니다. 넘길 일이 "이거 좀 해줘"가 아니라 잡 단위로 잘려 있으니까요.

승인 지점이 명확해집니다. 어디서 사람이 봐야 하는지가 그림에 그려져 있으니까요. 그리고 시간이 지나면서 도구와 메모리와 검사와 권한을 붙일 자리가 생깁니다. 그래프에 노드가 있으니 거기에 하나씩 달면 되거든요.

그러면서 AI로 하는 일이 그냥 채팅에서 하나의 운영체제로 바뀝니다. 거기까지 가면 확실히 다른 세계에 와 있는 기분이 들어요.

한 가지 경고: 에이전트가 많다고 좋은 게 아니다

에이전트가 많다고 결과물이 저절로 좋아지지 않습니다. 오히려 에이전트가 많아서 소음만 늘어나는 경우가 있어요. AI 작업자 다섯이 똑같이 틀린 생각을 자신 있게 반복하는 상황이 되기도 하고요. 시스템이 생각하는 시간보다 서로 조율하는 데 더 많은 시간을 쓰기도 합니다.

그러니 목표는 가능한 한 큰 그래프를 만드는 게 아니에요. X에서 거대한 그래프로 바이럴 타는 사람들을 봤는데, 그건 목표가 아닙니다. 목표는 일의 품질을 높이는 가장 작은 그래프를 만드는 겁니다.

좋은 그래프는:

• 가짜 대기를 없앱니다. 서로 의존하지 않는데 그냥 순서대로 늘어놓느라 뒤에서 기다리고 있는 단계들을 지웁니다.
• 일하는 쪽과 검사하는 쪽을 분리합니다. 앞에서 말한 자기 인사평가 문제를 피하는 방법이 이겁니다.
• 실수의 대가가 비싼 지점에 사람 승인을 둡니다. 모든 곳이 아니라 비싼 곳에요.
• 답이 충분히 좋아졌으면 멈춥니다. 계속 굴릴 이유가 없으니까요.
• 쓸모 있는 상태를 남깁니다. 회의 메모, 근거, 초안, 출처, 그리고 결정까지요.

마지막 항목이 과소평가돼 있습니다. 그래프 엔지니어링의 진짜 복리 효과는 작업 하나가 좋아지는 데 있지 않고, 당신의 일이 기억을 만들어내기 시작한다는 데 있거든요. 고객 리서치 그래프를 돌릴 때마다 더 나은 고객 메모가 쌓입니다. 콘텐츠 그래프를 돌릴 때마다 더 나은 사례와 독자 인사이트가 쌓이고요. 지원 그래프를 돌릴 때마다 더 나은 제품 피드백이 쌓입니다.

컨텍스트가 해자가 되는 지점이 여기예요. 그래프가 결과물을 만들어내는 동시에, 다음 그래프를 더 똑똑하게 만들 기억까지 만들어냅니다. 그렇게 당신의 자산이 되는 거죠.

첫 그래프를 만드는 법

1. 이미 AI로 매주 돌리고 있는 워크플로우를 하나 고르세요. 아이디어를 조사하는 일일 수도 있고, 팟캐스트 에피소드를 준비하는 일, 랜딩페이지를 검토하는 일, 고객 피드백을 분석하는 일일 수도 있어요.
2. 최종 결과물을 한 문장으로 쓰세요. 예를 들면 "이 스타트업 아이디어를 테스트해볼 가치가 있는지에 대한 한 장짜리 추천안이 필요하다."
3. 훌륭한 사람이라면 할 일들을 나열하세요. 질문을 명확히 하고, 고객을 조사하고, 경쟁사를 조사하고, 유통을 살펴보고, 리스크를 살펴보고, 근거를 검사하고, 추천안을 만들겠죠.
4. 앞 단계가 없으면 정말로 할 수 없는 일에만 화살표를 그으세요. 고객 리서치와 경쟁사 리서치 사이에는 화살표가 필요 없고, 회의론자 앞에는 반드시 있어야 합니다.
5. 비용이 큰 결정 앞에 사람 승인을 하나 두세요. 결과물이 내부용 메모라면 관문은 가벼워도 돼요. 고객에게 나가는 이메일, 공개 게시물, 코드 배포, 환불, 운영 데이터를 건드리는 일이라면 훨씬 엄격한 관문이 있어야 합니다.
6. 수동으로 한 번 돌려보세요. 거창한 자동화 프로젝트를 만들 필요 없습니다. 잡과 화살표만 만들면 됩니다.

한 번 해보고 나면 AI로 하는 일이 다르게 보이기 시작합니다. "이 작업에 완벽한 프롬프트가 뭘까"를 고민하는 대신, "이 일에 가장 맞는 워크플로우가 뭘까"를 고민하게 되거든요. 그리고 그 답을 만들어낼 경로를 설계하게 됩니다.

그래서 그래프 엔지니어링이 주목할 만한 개념인 겁니다. 프롬프팅 다음에 오는 논리적인 단계에 가깝거든요. AI에서 가장 많은 걸 얻어내는 사람은, 일을 알맞은 조각으로 쪼개고, 각 조각에 알맞은 맥락을 주고, 결과물을 검사하고, 사람을 있어야 할 자리에 두는 법을 아는 사람일 겁니다.

그리고 제대로 돌아가는 그래프가 하나 생기고 나면, 당신은 더 이상 AI에게 프롬프트를 던지는 사람이 아니라 AI의 일을 관리하는 사람이 됩니다.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의  뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]