생성형 AI가 처음 대중화됐을 때 가장 중요한 기술은 Prompt Engineering이었습니다.
당시 AI에게 기대한 것은 주로 한 번의 질문에 좋은 답을 내놓는 일이었습니다. 무엇을 원하는지 구체적으로 설명하고 필요한 배경과 조건을 제공하면 결과가 좋아졌습니다.
하지만 AI에게 맡기는 일이 길고 복잡해지면서 설계해야 할 범위도 넓어졌습니다.
한 번의 답변으로 끝나지 않는 일에는 실행 결과를 확인하고 수정하는 Loop가 필요했습니다. 여러 AI Agent가 역할을 나눠 일하기 시작하면서 작업의 순서와 의존 관계를 설계하는 Graph가 중요해졌습니다.
이는 Prompt가 Loop로, 다시 Graph로 대체되는 과정이 아닙니다.
AI에게 맡기는 일이 복잡해지면서 설계 대상이 하나의 업무 → 목표 달성 과정 → 여러 업무의 연결 구조로 확장된 과정에 가깝습니다.
| 구분 | 무엇을 설계하는가 | 조직에서 익숙한 형태 |
|---|---|---|
| Prompt Engineering | 하나의 업무 | 업무 지시와 작업 계약 |
| Loop Engineering | 목표에 도달하는 과정 | 목표·측정·Feedback·개선 |
| Graph Engineering | 여러 업무의 연결 구조 | 프로세스·Input/Output·Gate·책임 |
한 문장으로 줄이면 이렇습니다.
Prompt는 한 작업의 계약이고,
Loop는 목표에 수렴하는 구조이며,
Graph는 여러 작업이 연결되는 프로세스입니다.
새로워 보이는 이 AI Engineering의 개념들은 사실 조직이 복잡한 일을 효율적으로 수행하기 위해 오래전부터 고민해 온 일하는 방식과 매우 닮아 있습니다.
Prompt Engineering: 하나의 업무를 명확하게 정의합니다
좋은 Prompt는 문장을 길게 쓰는 기술이 아닙니다.
AI가 스스로 판단하며 일할 수 있도록 하나의 업무를 모호하지 않게 정의하는 일입니다.
예를 들어 다음 요청은 해석의 여지가 큽니다.
경쟁사를 조사해 주세요.
반면 다음 요청에는 작업에 필요한 조건이 들어 있습니다.
국내 직접 경쟁사 5곳을 가격, 고객층, 주요 기능, 차별점 기준으로 비교해 주세요. 공식 자료와 추정은 구분하고, 마지막에는 우리가 진입할 수 있는 영역을 제안해 주세요.
두 요청의 차이는 표현력이 아닙니다.
두 번째 요청에는 목표와 범위, 사용할 정보의 기준, 결과물의 형식과 완료 조건이 들어 있습니다.
조직에서 구성원에게 일을 맡길 때도 마찬가지입니다. 목표와 범위가 불분명하면 담당자는 그 빈틈을 추측해 채웁니다. 결과가 기대와 다르면 다시 설명하고 다시 작업해야 합니다.
그래서 Prompt Engineering은 AI만을 위한 특별한 기술이라기보다 좋은 업무 지시와 작업 계약을 만드는 기술에 가깝습니다. 구체적인 작성 방법은 AI가 발전해도 통하는 프롬프트 작성법에서 살펴볼 수 있습니다.
Loop Engineering: 목표와 달성 기준을 정의합니다
복잡한 일은 한 번에 완성되지 않습니다.
실행하고 결과를 확인한 뒤 부족한 부분을 수정하고 다시 검증해야 합니다.
하지만 같은 작업을 여러 번 시키는 것만으로 Loop가 만들어지는 것은 아닙니다.
Loop에서 가장 중요한 것은 무엇을 달성할 것인지와 어떤 상태를 달성으로 볼 것인지를 먼저 정의하는 일입니다.
제대로 된 Loop에는 최소한 다음이 필요합니다.
- 달성해야 할 목표
- 목표 달성 여부를 판단할 기준
- 결과에 따라 다음 행동을 정하는 Feedback
- 반복을 끝내거나 사람에게 넘길 종료 조건
구조는 단순합니다.
목표
↓
실행
↓
결과 측정
↓
목표와의 차이 확인
↓
수정 · 종료 · 격상
예를 들어 “보고서를 더 좋게 만들어라”는 제대로 된 Loop가 아닙니다. 무엇이 좋아진 상태인지 판단할 수 없기 때문입니다.
반면 다음처럼 정의하면 목표에 수렴할 수 있습니다.
근거 없는 주장이 없고, 필수 항목이 모두 포함되며, 주요 반론이 해소될 때까지 수정합니다. 같은 문제가 세 번 반복되면 자동 수정을 중단하고 사람에게 판단을 요청합니다.
조직도 같습니다.
목표를 선언하는 것만으로는 부족합니다. 실행 결과를 측정하고 목표와의 차이를 확인해야 합니다. 문제가 반복된다면 사람에게 더 열심히 하라고 요구하는 대신 업무 기준이나 일하는 방식을 수정해야 합니다.
조직에서도 실행 → 측정 → 병목 진단 → 개선을 반복하면서 업무 방식 자체를 조정합니다.
목표가 없는 반복은 방황이고,
종료 조건이 없는 개선은 비용 누수입니다.
Loop Engineering의 핵심은 재시도가 아니라 목표와 달성 기준을 정하고, 그 차이를 줄여 가는 구조입니다.
Graph Engineering: 일이 흐르는 구조를 설계합니다
하나의 Agent가 하나의 일을 수행한다면 Prompt와 Loop만으로도 충분할 수 있습니다.
하지만 여러 Agent가 일을 나누기 시작하면 새로운 문제가 생깁니다.
어떤 작업을 먼저 해야 하는가.
어떤 작업은 동시에 할 수 있는가.
앞 단계에서 무엇을 넘겨받아야 하는가.
어떤 조건을 충족해야 다음 단계로 갈 수 있는가.
이 구조를 설계하는 것이 Graph Engineering입니다.
Graph에서 하나의 작업은 Node, 작업 사이의 실제 의존 관계는 Edge가 됩니다.
여기서 중요한 질문은 단순합니다.
다음 작업이 앞 작업의 결과를 실제로 사용하는가?
사용하지 않는다면 두 작업은 기다릴 필요가 없습니다. 서로 독립적인 Node이므로 동시에 수행할 수 있습니다.
반대로 다음 작업이 앞 작업의 결과를 필요로 한다면, 무엇을 전달할 것인지 명확해야 합니다.
좋은 Graph에서는 Node가 하나의 제한된 업무를 맡고, 명확한 Input을 받아 검증 가능한 Output을 만듭니다. Edge 역시 단순히 “그다음에 실행한다”는 순서가 아니라, 앞 단계의 Output을 다음 단계의 Input으로 전달하는 실제 의존 관계입니다.
이것을 조직의 프로세스 언어로 바꾸면 익숙한 구조가 됩니다.
Input → Work → Output → Gate → Next Step
└─ Accountable
Input은 일을 시작하기 위해 필요한 것입니다.
Output은 다음 단계에 전달할 결과입니다.
Gate는 다음 단계가 그 결과를 신뢰하고 받아들일 수 있는 통과 기준입니다.
Accountable은 해당 단계의 결과를 끝까지 책임지는 사람입니다.
여기서 Gate는 단순한 결재 단계가 아닙니다.
예를 들어 개발이 끝났다는 이유만으로 바로 배포하는 것이 아니라, 코드 리뷰 통과, 주요 테스트 완료, 치명적 결함 0건과 같은 조건을 충족해야 다음 단계로 이동하는 것입니다.
결국 Graph Engineering은 Agent를 많이 만드는 기술이 아닙니다.
업무를 어떻게 나누고, 무엇을 동시에 수행하고, 어디에서 합치며, 어떤 조건을 통과해야 다음 단계로 갈지를 설계하는 기술입니다.
조직에서 Workflow를 설계할 때 앞 단계의 Output이 다음 단계의 Input이 되고, 단계별 Gate와 Accountable을 명확히 하는 것과 본질적으로 같습니다.
하나의 업무에서 Prompt, Loop, Graph는 함께 작동합니다
신규 서비스를 검토한다고 생각해 보겠습니다.
먼저 고객 수요, 경쟁사, 기술 타당성, 보안·법률, 수익성을 확인해야 합니다.
고객 수요 조사 ───┐
경쟁사 조사 ──────┤
기술 타당성 검토 ─┼→ 결과 통합 → 투자 판단 Gate
보안·법률 검토 ───┤
수익성 검토 ──────┘
각 조사에는 Prompt가 필요합니다.
무엇을 조사하고 어떤 근거를 사용하며 어떤 형식으로 결과를 제출할지 정의해야 합니다.
서로의 결과를 필요로 하지 않는 조사는 동시에 진행합니다. 결과를 어디에서 합치고 어떤 조건을 충족해야 투자 판단으로 넘어갈지 설계하는 것은 Graph입니다.
서비스를 출시한 뒤에는 목표 지표를 측정합니다. 기대한 결과에 도달하지 못했다면 제품이나 운영 방식을 수정하고 다시 검증합니다. 이것은 Loop입니다.
이렇게 보면 셋의 관계는 명확합니다.
Prompt가 각 작업을 정의하고,
Graph가 작업을 나누고 연결하며,
Loop가 결과를 목표에 수렴시킵니다.
AI가 조직을 닮아가는 것이 아닙니다
Prompt, Loop, Graph Engineering은 전혀 새로운 일의 원리를 발명한 것이 아닙니다.
AI가 단순한 답변 생성을 넘어 여러 단계의 복잡한 업무를 수행하기 시작하면서, 조직이 오랫동안 해결해 온 문제를 똑같이 만나기 시작한 것입니다.
업무가 모호하면 결과가 흔들립니다.
목표와 성공 기준이 없으면 반복이 끝나지 않습니다.
Input과 Output이 불명확하면 인계할 때마다 다시 해석해야 합니다.
Gate가 없으면 품질이 확인되지 않은 결과가 다음 단계로 넘어갑니다.
책임과 의사결정권이 불분명하면 결국 모든 판단이 한 사람에게 몰립니다.
사람이든 AI Agent든 여러 주체가 복잡한 일을 나눠 수행하는 순간 업무 정의, 목표, 인계 기준, 검증, 책임과 Feedback 구조가 필요합니다.
즉,
AI가 조직을 흉내 내는 것이 아닙니다.
AI에게 복잡한 일을 맡기기 시작하자, 사람이 복잡한 일을 분업하며 이미 발견했던 문제를 똑같이 만나기 시작한 것입니다.
결국 AI 도입은 ‘일하는 방식’을 다시 설계하는 일입니다
그래서 AI Agent를 도입할 때 처음부터 “Agent를 몇 개 만들 것인가”를 고민하는 것은 순서가 아닙니다.
먼저 현재의 일을 다시 그려야 합니다.
무엇을 달성해야 하는가.
무엇을 달성했다고 볼 것인가.
업무를 어떤 단위로 나눌 것인가.
각 단계는 무엇을 입력받고 무엇을 출력하는가.
어떤 조건을 통과해야 다음 단계로 갈 수 있는가.
문제가 생기면 어디로 돌아가고 누가 최종 판단하는가.
이 질문에 답할 수 없다면 문제는 AI의 성능이 아닙니다.
아직 업무 자체가 충분히 설계되지 않은 것입니다.
Prompt Engineering에서 시작해 Loop Engineering, Graph Engineering으로 가는 흐름이 흥미로운 이유도 여기에 있습니다.
AI에게 더 복잡한 일을 맡길수록 우리는 결국 다시 목표를 명확하게 하고, 일을 나누고, 연결하고, 검증하고, 책임을 정의하는 문제로 돌아옵니다.
좋은 조직을 만드는 원리와 크게 다르지 않습니다.
AI에게 복잡한 일을 맡기는 기술은
결국 사람이 복잡한 일을 함께 수행하도록 만드는 기술과 맞닿아 있습니다.
프롬프트를 잘 쓰는 것에서 시작하지만, 마지막에는 언제나 일의 구조를 어떻게 설계할 것인가라는 문제에 도달합니다.