AI 에이전트 개발 직무를 준비하는 취업 준비생의 프로젝트를 함께 점검하다 보면 ChatGPT나 LLM API를 활용한 기능은 여러 개 만들었는데, 실제 에이전트가 어떤 구조로 동작하는지를 설명하는 단계에서 답변이 짧아지는 경우가 있습니다. 사용자의 질문을 받아 모델에 전달하고 답변을 화면에 출력하는 챗봇은 완성했지만, 사용자가 일정 조회와 문서 검색, 데이터 등록처럼 실제 작업을 요청했을 때 어떤 기능을 선택하고 어떤 순서로 실행해야 하는지는 프로젝트에 포함되지 않은 식입니다. 조금 더 깊게 질문하면 차이가 분명해집니다. LLM이 잘못된 형식으로 결과를 반환하면 어떻게 처리하는지, 외부 API 호출이 실패하면 다시 시도할 것인지 중단할 것인지, 여러 도구를 사용해야 한다면 어느 작업부터 실행할 것인지, 실제 데이터를 변경하는 작업은 사람의 확인 없이 실행해도 되는지까지 설명하지 못하는 경우입니다. 결국 AI를 사용한 애플리케이션은 만들었지만 에이전트가 판단하고 도구를 사용하며 여러 단계를 수행하는 전체 실행 구조는 충분히 설계하지 않은 것입니다.
현재 주요 에이전트 개발 프레임워크에서도 이런 구조가 중요하게 다뤄지고 있습니다. OpenAI의 현재 Agents SDK 문서에서는 에이전트를 모델과 지시사항, 도구를 중심으로 구성하고, 복잡한 시스템에서는 handoff와 orchestration, guardrail, human review, tracing 등을 추가하는 구조를 제시하고 있습니다. Google의 Agent Development Kit 역시 여러 전문 에이전트와 도구를 조합하는 멀티에이전트 애플리케이션 개발을 주요 목적으로 설명합니다. 취업 준비 관점에서 보면 에이전트 개발은 프롬프트를 잘 작성하는 능력만으로 설명하기 어렵습니다. LLM에서는 모델이 무엇을 판단하고 어떤 결과를 만들어야 하는지, API에서는 AI가 실제 데이터와 기능을 어떻게 사용할 것인지, 오케스트레이션에서는 여러 단계와 도구를 어떤 조건으로 연결하고 통제할 것인지를 함께 이해해야 합니다.
이번 글에서는 AI 에이전트 개발 직무에서 필요한 기본 역량을 LLM, API, 오케스트레이션 세 가지 기준으로 나누어 정리하겠습니다.
LLM은 에이전트가 사용자의 요청을 이해하고 다음 행동을 결정하는 핵심 영역입니다
- LLM을 단순 답변 생성기가 아니라 판단 과정의 한 요소로 이해할 필요가 있습니다
생성형 AI 프로젝트를 처음 만들면 사용자의 질문에 자연스러운 답을 생성하는 데 집중하기 쉽습니다. 하지만 에이전트에서는 LLM이 단순히 최종 문장을 만드는 것뿐 아니라 현재 요청을 이해하고 어떤 도구가 필요한지 판단하며 도구의 결과를 바탕으로 다음 단계를 결정하는 역할까지 담당할 수 있습니다.
LLM 관련 프로젝트에서는 다음 내용을 연결할 수 있습니다.
- 사용자의 요청에서 실제 수행해야 할 작업을 구분합니다.
- 모델이 직접 답할 내용과 외부 도구가 필요한 내용을 나눕니다.
- 구조화된 결과가 필요한 경우 출력 형식을 명확하게 정의합니다.
- 도구 호출에 필요한 파라미터를 올바르게 생성하는지 확인합니다.
- 불확실한 정보가 있을 때 바로 실행하지 않고 추가 확인하도록 구성합니다.
- 최종 응답과 중간 판단을 어떤 방식으로 분리할지 정리합니다.
예를 들어 사용자가 다음 주 회의 일정을 잡아달라고 요청했다면 모델이 적절한 시간대를 문장으로 추천하는 것만으로는 실제 작업이 완료되지 않습니다. 사용자의 일정 정보를 가져와 가능한 시간을 확인하고, 참석자 조건을 비교한 뒤, 일정 등록 기능을 호출할 수 있어야 합니다. 이런 경험이 있어야 LLM을 단순 생성 모델이 아니라 에이전트가 다음 행동을 선택하는 판단 엔진의 일부로 이해할 수 있습니다.
- 좋은 프롬프트와 좋은 에이전트 설계는 같은 의미가 아닙니다
프롬프트를 세밀하게 작성하면 모델의 결과를 어느 정도 개선할 수 있습니다. 하지만 에이전트가 여러 도구를 사용하고 실제 작업을 수행하는 환경에서는 프롬프트만으로 모든 문제를 해결하기 어렵습니다.
- 프롬프트 중심의 설계: 모델에게 역할과 답변 형식, 금지사항을 자세하게 설명합니다.
- 구조 중심의 설계: 모델이 어떤 상황에서 어떤 도구를 사용할 수 있는지를 기능으로 제한합니다.
- 검증 중심의 설계: 모델이 만든 결과가 요구한 형식과 조건을 충족하는지 별도의 로직으로 확인합니다.
- 권한 중심의 설계: 읽기와 수정처럼 영향이 다른 작업의 실행 범위를 구분합니다.
- 실패 처리 중심의 설계: 모델이 잘못된 도구를 선택하거나 필요한 정보가 부족할 때 다음 행동을 정합니다.
OpenAI의 현재 에이전트 문서에서도 instructions만이 아니라 tools, guardrails, handoffs, structured outputs 등 여러 요소를 에이전트 정의에 포함할 수 있도록 구성하고 있습니다. 이는 에이전트 품질이 프롬프트 하나만으로 결정되는 구조가 아니라는 점을 보여줍니다. 따라서 포트폴리오에서도 프롬프트 전문을 길게 보여주는 것보다 어떤 판단을 LLM에 맡기고 어떤 부분을 애플리케이션 로직으로 통제했는지를 설명하는 편이 더 중요합니다.
- 모델의 결과를 평가하고 실패 유형을 구분하는 경험도 필요합니다
LLM은 같은 질문에서도 표현이 달라질 수 있고, 필요한 정보를 빠뜨리거나 예상하지 못한 형식으로 결과를 생성할 수 있습니다. 따라서 에이전트 프로젝트에서는 정상적으로 동작한 사례만 보여주는 것보다 어떤 상황에서 결과가 흔들리는지도 확인할 필요가 있습니다.
평가 과정에서는 다음 내용을 확인할 수 있습니다.
- 정상적인 사용자 요청에서 원하는 결과가 생성되는지 확인합니다.
- 정보가 부족한 요청에서 모델이 임의로 값을 만들지 않는지 살펴봅니다.
- 여러 도구가 가능한 상황에서 적절한 기능을 선택하는지 확인합니다.
- 잘못된 파라미터를 만들어 API 호출이 실패하는 사례를 기록합니다.
- 같은 유형의 요청에서 결과 형식이 일정하게 유지되는지 비교합니다.
- 수정 이후 동일한 테스트 사례를 다시 실행해 결과를 재검증합니다.
예를 들어 사용자가 날짜를 지정하지 않은 상태에서 예약을 요청했는데 모델이 임의의 날짜를 선택해 바로 실행한다면 자연스러운 답변을 생성했더라도 좋은 에이전트라고 보기 어렵습니다. 이 경우 실행 전에 필요한 정보를 다시 요청하도록 설계를 수정하는 편이 적절할 수 있습니다. 이런 경험이 있어야 LLM 활용 능력을 모델 호출 경험이 아니라 모델의 판단 품질을 평가하고 개선한 경험으로 설명할 수 있습니다.
- LLM 역량은 모델 이름보다 비용과 속도, 품질의 균형까지 이해할 때 깊어집니다
에이전트 개발에서는 모든 작업에 가장 강력한 모델을 사용하는 것이 항상 적절한 선택은 아닐 수 있습니다. 업무 난도와 응답속도, 사용량, 비용에 따라 다른 선택이 필요할 수 있기 때문입니다.
- 단순 분류 작업: 비교적 간단한 판단이므로 높은 추론 비용이 필요한 모델이 항상 필요한 것은 아닐 수 있습니다.
- 복잡한 계획 작업: 여러 조건을 비교하고 도구 호출 순서를 결정해야 한다면 더 높은 추론 능력이 필요할 수 있습니다.
- 구조화된 출력 작업: 모델 성능뿐 아니라 정해진 형식을 안정적으로 반환하는지가 중요합니다.
- 대규모 반복 작업: 한 번의 품질뿐 아니라 처리시간과 호출 비용까지 고려해야 합니다.
- 서비스 운영 작업: 모델 변경 이후 기존 에이전트 동작이 달라지지 않는지 평가할 필요가 있습니다.
따라서 AI 에이전트 개발자에게 모델 이해는 어떤 LLM이 가장 좋다는 결론을 내리는 것이 아닙니다. 각 작업에 필요한 수준의 모델을 선택하고 실제 테스트 결과를 바탕으로 품질과 속도, 비용을 비교할 수 있는 능력으로 연결되는 것이 중요합니다.
API는 에이전트가 현실의 데이터와 기능을 실제로 사용할 수 있게 만드는 영역입니다
- API 연결 경험은 외부 기능을 호출했다는 것보다 입력과 결과 구조를 이해하는지가 중요합니다
에이전트가 검색과 일정, 데이터베이스, 메시지 전송 같은 작업을 수행하려면 외부 시스템과 연결되어야 합니다. 이때 API는 LLM의 판단을 실제 기능으로 변환하는 중요한 연결점이 됩니다.
API 프로젝트에서는 다음 내용을 함께 확인할 수 있습니다.
- 어떤 사용자 요청에서 외부 기능이 필요한지 구분합니다.
- API가 요구하는 입력값과 데이터 형식을 이해합니다.
- 필수값과 선택값을 나누어 처리합니다.
- 반환된 응답에서 필요한 데이터만 추출합니다.
- 오류 코드와 실패 응답을 구분합니다.
- 결과를 다시 LLM이나 다음 작업에 전달할 구조를 정리합니다.
예를 들어 여행 에이전트가 장소 검색 API를 사용한다면 도시 이름을 전달해 검색 결과를 받아오는 것에서 끝나지 않습니다. 검색된 장소의 위치와 영업정보, 사용자가 요청한 조건을 비교하고 필요한 정보만 다음 단계의 일정 구성 작업으로 전달해야 할 수 있습니다. 따라서 API 경험은 단순 연결 실습보다 LLM의 판단과 실제 서비스 기능 사이의 데이터 흐름을 설계한 경험으로 설명하는 것이 중요합니다.
- API 호출과 에이전트 도구는 비슷해 보여도 사용 방식에 차이가 있습니다
일반적인 애플리케이션에서는 개발자가 어느 시점에 어떤 API를 호출할지 코드로 미리 결정하는 경우가 많습니다. 에이전트에서는 상황에 따라 모델이 필요한 도구를 선택하는 구조가 추가될 수 있습니다.
- 일반 API 호출: 프로그램의 정해진 로직에 따라 특정 API를 실행합니다.
- 에이전트 도구 호출: 사용자의 요청과 현재 상황에 따라 모델이 필요한 도구를 선택할 수 있습니다.
- 함수 도구 방식: 애플리케이션 내부 함수를 모델이 사용할 수 있는 도구 형태로 제공합니다.
- MCP 연동 방식: 표준화된 연결 인터페이스를 통해 외부 도구와 데이터를 에이전트가 사용할 수 있게 구성할 수 있습니다.
- 전문 에이전트 호출 방식: 특정 업무를 담당하는 다른 에이전트를 하나의 도구처럼 사용할 수도 있습니다.
현재 OpenAI의 도구 문서에서도 function tools와 MCP, hosted tools, agents-as-tools 등 여러 연결 방식을 제공하고 있습니다. 에이전트 런타임은 모델의 결과에 도구 호출이 포함되면 해당 기능을 실행하고 그 결과를 다시 모델에 전달하는 반복 구조로 동작할 수 있습니다. 따라서 에이전트 개발을 준비할 때는 REST API 문법만 공부하는 것이 아니라 어떤 기능을 도구로 공개하고 모델이 언제 사용하게 할 것인지까지 연결해서 이해할 필요가 있습니다.
- API가 늘어날수록 인증과 권한, 오류 처리 경험이 더 중요해집니다
여러 외부 서비스를 연결하면 에이전트가 할 수 있는 작업도 많아집니다. 하지만 동시에 잘못된 호출이나 과도한 권한이 실제 서비스에 영향을 줄 가능성도 커질 수 있습니다.
API 연결 프로젝트에서는 다음 내용을 함께 볼 수 있습니다.
- API 키와 토큰을 코드에 직접 노출하지 않도록 관리합니다.
- 사용자별로 접근 가능한 기능을 구분합니다.
- 조회 기능과 실제 변경 기능의 권한을 나눕니다.
- 네트워크 오류와 인증 실패를 구분합니다.
- 일정 시간 동안 응답이 없을 때 중단 기준을 설정합니다.
- 실행한 기능과 주요 결과를 로그로 기록합니다.
예를 들어 문서를 검색하는 기능과 실제 문서를 삭제하는 기능은 같은 권한 수준으로 보기 어렵습니다. 검색은 자동으로 실행할 수 있더라도 삭제나 결제, 예약 취소처럼 영향이 큰 기능은 별도의 확인 과정이 필요할 수 있습니다. 이런 경험이 있어야 API 활용이 단순 기능 연결에서 벗어나 실제 서비스를 안전하게 운영할 수 있는 백엔드 경험으로 발전합니다.
- 좋은 API 프로젝트는 성공 화면뿐 아니라 실패 상황까지 설명할 수 있어야 합니다
포트폴리오에서는 에이전트가 정상적으로 도구를 선택하고 작업을 완료한 화면만 보여주기 쉽습니다. 하지만 실제 환경에서는 외부 API가 항상 정상적으로 응답한다고 가정하기 어렵습니다.
- 정상 호출: 필요한 파라미터를 전달하고 예상한 데이터를 정상적으로 받습니다.
- 인증 실패: 만료되거나 잘못된 인증 정보 때문에 호출이 실패합니다.
- 입력 오류: 모델이 API에서 허용하지 않는 값을 전달해 요청이 거절됩니다.
- 서비스 장애: 외부 API 자체가 일시적으로 응답하지 않습니다.
- 부분 실패: 여러 작업 중 일부는 성공하고 일부는 실패합니다.
- 복구 처리: 재시도할 작업과 사용자 확인이 필요한 작업을 구분합니다.
이처럼 API 실패 상태를 나누어두면 에이전트가 아무 응답도 하지 않거나 같은 호출을 무한히 반복하는 상황을 줄일 수 있습니다. 포트폴리오에서도 성공 화면 하나보다 API 실패를 어떻게 감지하고 다음 행동을 어떻게 결정했는지를 보여주는 편이 에이전트 개발 역량을 더 잘 드러낼 수 있습니다.
오케스트레이션은 여러 모델과 도구, 작업 단계를 하나의 실행 흐름으로 관리하는 영역입니다
- 에이전트 업무를 하나의 긴 프롬프트보다 여러 단계로 나누는 경험이 중요합니다
AI 에이전트가 복잡한 업무를 수행하려면 하나의 프롬프트에서 모든 작업을 해결하려 하기보다 업무를 여러 단계로 나누는 방식이 필요할 수 있습니다. 각 단계의 목적이 명확해야 어떤 도구가 필요한지와 실패했을 때 어디에서 다시 시작해야 하는지를 판단하기 쉬워집니다.
오케스트레이션에서는 다음 내용을 연결할 수 있습니다.
- 사용자의 최종 목표를 먼저 정의합니다.
- 목표 달성에 필요한 중간 작업을 나눕니다.
- 각 단계가 필요로 하는 입력과 결과를 정합니다.
- 어떤 도구나 전문 에이전트를 사용할지 구분합니다.
- 이전 단계 결과를 다음 작업에 전달합니다.
- 완료 조건과 중단 조건을 명확하게 정의합니다.
예를 들어 채용공고 분석 에이전트를 만든다고 하면 공고 검색부터 최종 보고서 작성까지 한 번에 수행하도록 만들 수 있습니다. 하지만 공고 수집과 정보 추출, 기술 분류, 사용자 경험과의 비교, 결과 검증, 최종 문서 작성으로 단계를 나누면 어느 부분에서 오류가 발생했는지 확인하기 훨씬 쉬워집니다. 이런 경험이 에이전트 개발에서 말하는 워크플로 설계와 오케스트레이션의 기본으로 연결됩니다.
- 단일 에이전트와 멀티에이전트는 복잡할수록 좋은 관계가 아닙니다
멀티에이전트라는 용어가 주목받으면서 프로젝트에서도 여러 에이전트를 만들어야 더 높은 수준의 결과물이라고 생각하기 쉽습니다. 하지만 업무를 명확하게 분리할 이유가 없다면 하나의 에이전트가 여러 도구를 사용하는 구조가 더 단순하고 관리하기 쉬울 수 있습니다.
- 단일 에이전트 방식: 하나의 에이전트가 사용자의 요청을 이해하고 필요한 여러 도구를 직접 사용합니다.
- 전문 에이전트 방식: 검색과 분석, 문서 작성처럼 업무 성격이 다른 역할을 각각 분리합니다.
- Handoff 방식: 현재 에이전트가 특정 전문 업무를 다른 에이전트에게 넘기고 이후 응답 책임도 이동합니다.
- Manager 방식: 중앙 에이전트가 전체 작업을 관리하면서 여러 전문 에이전트를 도구처럼 호출합니다.
- 혼합 방식: 일부 업무는 단일 에이전트가 처리하고 명확한 전문 영역만 별도 에이전트로 분리합니다.
OpenAI의 현재 오케스트레이션 가이드 역시 전문 에이전트가 응답 책임을 넘겨받는 handoff와 중앙 관리자가 전문 에이전트를 도구처럼 사용하는 구조를 구분하며, 역할 분리가 실제로 필요한 경우에 전문 에이전트를 나누는 방식을 제시하고 있습니다. 따라서 포트폴리오에서 중요한 것은 에이전트 개수가 아니라 왜 역할을 나누었고 어떤 구조가 문제 해결에 적합했는지를 설명하는 것입니다.
- 오케스트레이션에는 상태와 실패, 사람의 승인까지 포함되어야 합니다
여러 단계의 작업이 이어지면 현재 어느 단계까지 진행됐는지 관리해야 합니다. 도구 하나가 실패했을 때 처음부터 전체 작업을 다시 실행할 것인지, 해당 단계만 재시도할 것인지도 결정해야 합니다.
오케스트레이션 프로젝트에서는 다음 내용을 확인할 수 있습니다.
- 현재 작업이 어느 단계까지 진행되었는지 상태를 기록합니다.
- 이전 단계의 결과를 다음 단계에서 재사용합니다.
- 특정 도구가 실패했을 때 재시도 횟수를 제한합니다.
- 같은 작업이 반복 호출되는 상황을 방지합니다.
- 위험하거나 되돌리기 어려운 작업은 사람의 승인을 거치게 합니다.
- 전체 실행 과정에서 어떤 판단과 도구 호출이 있었는지 추적합니다.
현재 OpenAI의 guardrail 및 human review 문서에서도 입력과 출력, 도구 행동에 대한 검증을 지원하고, 취소나 수정처럼 실제 영향을 만드는 작업에서는 사람의 승인을 거쳐 실행을 계속할 수 있는 구조를 제시합니다. 따라서 오케스트레이션은 여러 도구를 순서대로 호출하는 기능에만 머물지 않습니다. 상태와 실패, 승인, 재개를 포함해 전체 에이전트 실행을 통제하는 과정으로 이해하는 것이 좋습니다.
- 좋은 오케스트레이션은 실행 과정을 관찰하고 개선할 수 있어야 합니다
에이전트가 복잡해질수록 최종 결과만 보고 어느 부분이 잘못되었는지 찾기 어려워집니다. 따라서 모델 호출과 도구 실행, handoff, 오류가 어떤 순서로 발생했는지를 확인할 수 있는 관찰 구조가 중요합니다.
- 실행 추적 단계: 모델이 어떤 판단을 했고 어떤 도구를 호출했는지 확인합니다.
- 성능 확인 단계: 어느 모델이나 API 호출에서 시간이 많이 걸리는지 살펴봅니다.
- 오류 확인 단계: 반복적으로 실패하는 도구와 입력 조건을 구분합니다.
- 비용 확인 단계: 불필요한 모델 호출이나 반복 작업이 발생하지 않는지 확인합니다.
- 품질 확인 단계: 정상 사례와 실패 사례를 모아 동일한 기준으로 평가합니다.
- 개선 단계: 실행 기록을 근거로 프롬프트와 도구 설명, 라우팅 조건, 검증 로직을 수정합니다.
OpenAI Agents SDK는 tracing을 이용해 모델 호출과 도구 호출, handoff와 guardrail 등 실행 과정을 확인하도록 안내하고 있습니다. 현재 에이전트 개발에서는 단순 실행뿐 아니라 이러한 관찰과 평가 과정도 중요한 운영 요소로 다뤄지고 있습니다. 이런 경험이 포트폴리오에 포함되면 오케스트레이션을 단순 작업 연결이 아니라 실행 상태를 추적하고 실패 원인을 찾아 개선하는 시스템 설계 경험으로 설명할 수 있습니다.
- conclusion
AI 에이전트 개발 직무를 준비할 때 가장 먼저 피해야 할 것은 에이전트를 LLM API에 프롬프트를 보내는 챗봇과 동일하게 보는 것입니다. 챗봇 형태의 프로젝트도 중요한 기초가 될 수 있지만, 에이전트가 실제 작업을 수행하려면 모델의 판단과 외부 기능의 실행, 여러 단계의 상태 관리가 하나의 구조로 연결되어야 합니다. LLM 영역에서는 좋은 문장을 생성하는 것뿐 아니라 사용자의 의도를 이해하고 어떤 행동이 필요한지 판단하며, 도구 호출에 필요한 구조화된 결과를 안정적으로 만들어야 합니다. API 영역에서는 모델의 판단을 검색과 데이터 조회, 일정 등록, 문서 처리 같은 실제 기능으로 연결해야 하고 인증과 권한, 오류 처리까지 함께 고려할 필요가 있습니다. 오케스트레이션 영역에서는 여러 작업의 실행 순서를 설계하고 실패와 재시도, 사람의 승인, 상태 저장과 추적까지 관리해야 합니다.
최종적으로 확인할 항목은 다음과 같습니다.
- LLM이 담당할 판단과 애플리케이션 로직을 구분할 수 있는지 확인합니다.
- 구조화된 출력과 도구 호출 결과를 검증한 경험이 있는지 살펴봅니다.
- 외부 API의 입력과 출력, 인증 방식을 이해하고 있는지 확인합니다.
- 도구 호출 실패와 재시도 조건을 구분할 수 있는지 점검합니다.
- 복잡한 업무를 여러 단계의 워크플로로 나눈 경험이 있는지 살펴봅니다.
- 상태와 승인, 실행 로그를 이용해 전체 에이전트 흐름을 검증했는지 확인합니다.
AI 에이전트 개발 준비 흐름은 다음과 같이 연결할 수 있습니다.
- Python 또는 JavaScript 기초 → HTTP와 REST API 이해 → LLM API 활용 → 프롬프트와 구조화 출력 → 함수 도구 연결 → 인증과 오류 처리 → 여러 도구 연결 → 작업 단계 분해 → 에이전트 루프 이해 → 상태 관리 → 오케스트레이션 구성 → guardrail과 승인 적용 → tracing과 평가 → 실패 사례 개선 → 프로젝트 문서화 → 포트폴리오와 면접 연결
결국 AI 에이전트 개발 직무에서 중요한 것은 최신 프레임워크 이름을 많이 알고 있는지가 아닙니다. LLM에서는 모델의 판단 범위를 설계하고, API에서는 AI를 실제 데이터와 기능에 연결하며, 오케스트레이션에서는 여러 작업과 도구가 안전하고 반복 가능한 흐름으로 움직이도록 관리할 수 있는가가 핵심입니다. 이 세 영역이 하나의 프로젝트 안에서 연결되어 있다면 단순한 생성형 AI 챗봇을 만든 경험을 넘어, 실제 업무를 수행하는 에이전트 시스템을 설계하고 개발했다는 근거를 포트폴리오와 면접에서 더 구체적으로 보여줄 수 있습니다.
