AI 애플리케이션을 만들고 운영하는 역량 소개
Andrew Ng가 설명한 AI Engineering Skills Map의 첫 번째 축은 AI 애플리케이션을 만들고 실제 사용자에게 제공하는 역량입니다. 모델을 호출해 시연하는 단계에서 끝나지 않고, 적절한 데이터를 연결하고 결과를 평가하며 운영 중 발생하는 문제까지 다루는 일입니다. 앞서 소개한 네 가지 핵심 역량 가운데 가장 직접적으로 AI 기능을 제품에 구현하는 영역입니다.
일반적인 소프트웨어는 입력과 코드가 같으면 결과를 예측하기 쉽지만, 대형 언어 모델(LLM)이나 지도 학습 모델의 출력은 그만큼 확정적이지 않습니다. 그래서 Ng는 AI 개발을 미리 정한 순서대로 구현하는 작업보다, 일부를 만들고 결과를 살펴본 뒤 다음 실험을 결정하는 반복 과정으로 설명합니다. 불확실한 모델을 쓰면서도 신뢰할 수 있는 서비스를 만들려면 이 반복을 체계적으로 수행해야 합니다.
원문은 이 영역을 LLM의 기초, 데이터 연결, 에이전트 시스템, 평가 중심 개발, 운영, 머신러닝 기초의 여섯 가지로 나눕니다. 이 역량 지도는 다수의 채용 공고 분석, 전문가 대상 구조화 인터뷰, 설문 응답을 바탕으로 만들어졌습니다. 아래에서는 각 항목이 개발 과정에서 어떤 판단으로 이어지는지 살펴보겠습니다.
LLM의 동작을 알아야 모델을 적절하게 선택할 수 있습니다
대형 언어 모델의 기초(LLM foundations) 는 모델을 직접 학습시키는 방법만을 뜻하지 않습니다. 입력을 토큰으로 나누는 방식, 출력을 생성하는 과정, 컨텍스트 창의 한계, 샘플링 설정처럼 API를 사용하는 개발자도 알아야 할 성질을 포함합니다. 예를 들어 긴 문서를 한 번에 입력할지, 필요한 부분만 찾아 넣을지는 컨텍스트의 크기와 비용, 답변 품질에 모두 영향을 줍니다.
원문은 멀티모달 모델의 선택, 캐시 적중, 지식 기준 시점, 추론(reasoning) 노력 수준, 도구 호출도 이 영역에 포함합니다. 이런 특성을 알면 모든 요청에 같은 모델과 설정을 적용하는 대신, 작업의 난도와 지연 시간에 맞게 조합할 수 있습니다. 특정 작업에서는 미세조정(fine-tuning)이나 자체 호스팅도 검토할 수 있지만, 먼저 어떤 실패가 모델과 입력에서 비롯됐는지 구분하는 일이 필요합니다.
가령 고객 문의에 답하는 서비스를 만든다면, 최신 환불 규정을 모르는 모델에 문장을 더 잘 쓰라고 지시하는 것만으로는 문제가 풀리지 않습니다. 이는 답변 문체보다 필요한 정보를 제공하는 방식의 문제입니다. 이 예시는 원문의 항목을 설명하기 위해 덧붙인 적용 사례입니다.
필요한 데이터를 연결하는 방법은 하나가 아닙니다
데이터 기반화(grounding models with data) 는 모델의 답을 조직의 문서와 기록에 연결하는 과정입니다. 원문은 벡터 검색을 이용한 검색 증강 생성(RAG)을 초기 접근 가운데 하나로 들면서, 현재의 선택지는 더 넓다고 설명합니다. 어떤 정보를 프롬프트에 고정해 넣고 어떤 정보는 요청 시 도구로 검색하게 할지부터 결정해야 합니다.
자료와 질문의 형태에 따라 벡터 인덱스, 지식 그래프(knowledge graph), 구조화된 데이터 위의 시맨틱 계층이 서로 다른 역할을 합니다. 문서의 의미가 비슷한 대목을 찾는 작업과 고객 레코드에서 정확한 주문 상태를 조회하는 작업은 같은 검색 문제로 취급하기 어렵습니다. 텍스트, PDF, HTML, 이미지를 모델이 사용할 수 있는 입력으로 바꾸고, 원본이 갱신될 때 검색 결과도 최신 상태로 유지하는 파이프라인이 필요합니다.
고객 문의 예시로 돌아가면, 환불 정책 문서와 개별 고객의 주문 상태를 한 덩어리로 검색할 필요는 없습니다. 정책은 문서 검색으로, 주문 상태는 권한을 확인한 뒤 구조화된 데이터 조회로 가져오는 구성이 더 적합할 수 있습니다. 어떤 경로를 택하든 모델이 실제로 참고한 자료를 확인할 수 있어야 이후 오류 분석이 가능합니다.
에이전트 구조는 작업에 필요한 자율성에 맞춰 고릅니다
에이전트 시스템(agentic systems) 은 정해진 순서로 여러 LLM 호출을 실행하는 워크플로부터, 모델이 다음 행동을 반복해서 선택하는 에이전트 하네스까지 범위가 넓습니다. 원문은 모든 문제를 자율 에이전트로 풀라고 권하지 않습니다. 어떤 단계는 코드로 처리하고 어떤 단계에서 모델의 판단을 사용하며, 무엇을 병렬로 실행할지 선택하는 것이 설계의 핵심입니다.
에이전트가 사용할 도구에는 모델 컨텍스트 프로토콜(MCP), 명령줄 인터페이스(CLI), 격리된 실행 환경이 들어갈 수 있습니다. 긴 작업의 컨텍스트와 메모리를 어떻게 관리할지, 단일 에이전트로 충분한지, 여러 에이전트를 조율해야 할지도 결정해야 합니다. 단계가 늘수록 실패 지점과 권한 범위도 늘어나므로, 폴백과 접근 통제를 함께 설계해야 합니다.
고객 지원 시스템이 주문 번호를 조회하고 해당 정책을 인용해 답하는 정도라면 정해진 순서의 워크플로가 요구를 충족할 수 있습니다. 반면 여러 자료를 탐색하며 해결 절차를 계획해야 하는 업무라면 반복적인 도구 사용이 필요할 수 있습니다. 두 방식의 선택은 최신 기술의 선호보다 업무의 복잡성과 검증 가능성에 달려 있습니다.
원문은 프롬프트 인젝션과 데이터 유출을 포함한 위험을 지적합니다. 특히 외부 문서의 문장을 에이전트의 명령으로 받아들이거나, 허용되지 않은 데이터를 도구로 전송하지 않도록 경계를 두어야 합니다. 음성 에이전트, 컴퓨터 사용 에이전트, 생성형 UI 같은 기법은 해당 제품에 필요할 때 검토할 대상입니다.
평가 결과가 다음 개발 단계를 결정해야 합니다
Ng가 특히 강조하는 것은 평가 중심 개발(evaluation-driven development) 입니다. 출력이 불확실한 시스템에서는 코드를 더 작성하기 전에 실제 실패가 어디에서 일어났는지 확인해야 합니다. 그는 뛰어난 AI 개발자를 가르는 중요한 역량으로 평가와 오류 분석을 반복하며 다음 작업의 우선순위를 정하는 능력을 꼽습니다.
평가 항목은 처음부터 고정된 정답 목록으로 주어지지 않습니다. 실행 기록과 출력을 살펴보고, 제품에서 중요한 실패가 무엇인지 정한 뒤 그에 맞는 측정 방법을 선택합니다. 코드로 판정 가능한 항목은 결정적 평가로 확인하고, 정답이 모호한 답변 품질은 사람의 판단이나 LLM 평가자를 활용할 수 있습니다. 평가자 자체가 제품 목표와 맞는지도 계속 점검해야 합니다.
예를 들어 답변 문장만 그럴듯한지를 보는 평가로는 잘못된 환불 금액을 발견하기 어렵습니다. 주문 정보의 정확성, 정책 문서의 인용, 사용자에게 제시한 조치의 적절성을 나누어 확인하면 어떤 구성요소를 고쳐야 할지 더 분명해집니다. 이 사례 역시 원문의 방법을 이해하기 위한 예시이며, 특정 평가 방식이 모든 서비스에 적합하다는 뜻은 아닙니다.
운영 단계에서는 품질뿐 아니라 비용과 지연도 살펴봅니다
운영(operating in production) 에서는 실제 사용자의 입력이 개발 중 예상한 사례와 다르게 나타납니다. 성능을 관찰하고 분포의 변화(drift)를 감지하며, 모델 오류와 악의적인 프롬프트 인젝션에 대응하는 체계가 필요합니다. 회귀 검사와 지속적 통합 및 배포(CI/CD)에도 통계적 평가가 더 많이 들어가며, 검사 강도는 오류가 미치는 위험에 맞춰야 합니다.
비용과 응답 시간도 제품 품질의 일부입니다. 원문은 모델 선택, 증류(distillation), 미세조정, 에이전트 워크플로 단순화 등을 조합해 최적화할 수 있다고 설명합니다. 다만 선택은 사용량과 실제 실패 원인에 따라 달라집니다. 평가 없이 모델을 작게 바꾸거나 단계를 줄이면 지연은 줄어도 중요한 오류가 늘 수 있습니다.
운영 기록은 앞서 설명한 평가로 다시 이어집니다. 사용 중 발견된 실패를 재현 가능한 사례로 남기고, 수정한 뒤 같은 문제가 다시 나타나지 않는지 확인하는 순환이 제품의 신뢰성을 높입니다.
머신러닝 기본기는 LLM 밖의 문제에도 적용됩니다
마지막 축은 머신러닝 기초(machine learning foundations) 입니다. 원문은 지도 학습과 강화 학습, 딥러닝 모델의 특성을 이해하는 일이 LLM 활용에도 도움이 된다고 설명합니다. 정확도, 학습 시간, 추론 속도의 균형을 읽고 학습과 평가 데이터를 설계하는 역량은 전통적인 예측 모델이 필요한 제품에서도 그대로 중요합니다.
특히 편향과 분산(bias and variance), 오류 분석, 데이터 엔지니어링은 출력이 불확실한 시스템을 다룰 때 공통으로 쓰는 사고 틀입니다. 답변이 나쁜 이유를 무조건 프롬프트 탓으로 돌리기보다, 데이터의 범위와 품질, 모델의 한계, 평가 방법을 나누어 보는 데 도움이 됩니다.
여섯 역량은 하나의 개발 반복으로 이어집니다
여섯 항목은 별개의 자격증 목록이 아닙니다. LLM의 특성을 이해해 구성요소를 고르고, 필요한 데이터를 연결하며, 작업에 맞는 실행 구조를 만듭니다. 평가에서 드러난 오류를 근거로 구조와 데이터를 바꾸고, 실제 운영 기록으로 다시 평가를 개선합니다. 머신러닝 기본기는 그 과정의 판단을 뒷받침합니다.
원문이 전하는 핵심은 AI 기능을 한 번 구현하는 속도보다, 결과를 보고 다음 선택을 바로잡는 능력입니다. 다음 글에서는 이 AI 기능을 담는 서비스 전체를 설계할 때 왜 소프트웨어 엔지니어링 기본기가 필요한지 살펴봅니다.
AI 애플리케이션 구축과 운영 역량 원문
AI Engineering Skills Map 전체 개요 원문
더 읽어보기
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글은 
파이토치 한국 사용자 모임
이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일
로도 보내드립니다! 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 