AI를 잘 쓴다는 것은 무엇일까요? 새로운 모델과 기능이 등장할 때마다 관련 내용을 찾아보고 직접 사용해보며, 어느 정도까지 알아야 하는지 고민해왔는데요. 클로드코드(Claude Code)와 코덱스(Codex) 같은 코딩 에이전트부터 에이전트, 워크플로우, 스킬, MCP까지. AI를 잘 써보려고 할수록 오히려 공부할 것이 더 늘어나는 느낌이었습니다.
문제는 새로운 개념을 안다고 해서 반드시 AI를 더 잘 쓰게 되는 것은 아니었다는 것입니다. 유료 스터디부터 수많은 강의까지 시간을 내어 들었음에도 막상 내 업무에서는 무엇을 써야 하는지 여전히 의문이었습니다.
그러다 문득, 생각이 들었습니다. 나는 지금 AI라는 도구를 공부하고 있는 걸까, 아니면 일을 더 잘하고 싶어서 AI를 공부하고 있는 걸까?
일을 더 잘하고 싶어 공부한다면 접근이 달라져야 했습니다. 모든 개념의 원리를 깊게 이해하기보다, 어떤 문제가 생겼을 때 어떤 개념이 필요한지 아는 것이 더 중요했던거죠. 내 업무가 한 번의 질문으로 끝난다면 프롬프트면 충분할 수 있고, 반복되는 절차가 있다면 스킬이 유용할 수 있습니다. 회사 내부 자료를 참고해야 한다면 RAG를 고민해야 하고, AI가 다른 서비스까지 사용해야 한다면 API나 MCP가 필요할 수 있습니다.
그렇게 하나씩 연결해보니 따로 보이던 개념들이 조금 다르게 보이기 시작했습니다. 각각이 독립적으로 떠다니는 개념이라기보다, AI의 쓰임이 넓어지면서 하나의 업무 흐름 안에서 만나게 되는 개념들에 가까웠습니다.
저는 이를 크게 세 가지 흐름으로 나누어 이해해보려 합니다.
기술의 발전을 나열하기 보단, 업무를 맡기는 사람의 입장에서 ‘무엇이 부족해서 다음 개념이 필요해지는가’를 이해하기 위해 재구성한 것에 가깝습니다.

가장 먼저 출발점이 되는 것은 LLM(Large Language Model)입니다. 우리가 ChatGPT나 Claude 같은 서비스에 무언가를 질문하거나 요청했을 때 ‘문맥’을 바탕으로 답변을 생성하는 모델인데요. 대부분 이렇게 질문을 입력하고, 답을 받는 형식으로 생성형 AI를 처음 경험하게 됩니다.
그런데 같은 모델을 쓰더라도 요청하는 방식에 따라 결과의 품질은 크게 달라집니다. “보고서를 써줘”라고 요청할 때와, 목적과 독자, 참고 자료, 원하는 형식까지 설명했을 때의 결과가 다른 것처럼 말입니다. 그래서 프롬프트엔지니어링(Prompt Engineering)이 중요해졌습니다. 원하는 결과를 얻을 수 있도록 충분한 맥락과 명확한 지시를 제공하는 방법입니다. OpenAI 역시 프롬프트 작성에서 맥락, 원하는 결과, 길이와 형식 등을 구체적으로 제시하는 것을 기본적인 원칙으로 안내합니다.
그런데 AI를 실제 업무에 반복적으로 사용하다 보니 다른 문제가 생겼습니다. 매번 비슷한 설명을 다시 해야 했습니다. 프롬프트를 매번 잘 작성하는 것보다, 반복되는 업무의 방법 자체를 저장해두고 필요할 때 다시 사용할 수 있는 형태가 필요해진거죠.
이 과정에서 등장한 것이 스킬(Skill)입니다. Skill이라는 이름과 구현 방식은 서비스마다 다르지만, 최근에는 반복되는 지침과 절차, 필요한 자료나 스크립트를 하나의 재사용 가능한 단위로 묶는 방식으로 사용되고 있습니다. Anthropic은 Agent Skills를 지침·스크립트·리소스를 묶어 특정 업무에 필요한 전문성과 절차를 에이전트가 필요할 때 불러오는 구조로 설명합니다.
프롬프트가 ‘이번 일을 어떻게 해달라’는 요청이라면, Skill은 ‘이런 종류의 일은 앞으로 이렇게 한다’는 업무 방식을 남기는 것에 더 가깝습니다. 여기서부터 AI 활용은 일회성 대화에서 반복 가능한 업무 방식으로 넘어가기 시작합니다.
실제 일은 하나의 절차만으로 끝나지 않습니다. 자료를 찾고, 내용을 검토하고, 분석하고, 결과물을 만든 뒤 다시 확인해야 합니다. 상황에 따라 도구도 달라지는데요, 이처럼 하나의 목표를 위해 여러 단계의 일을 연결해서 수행해야 할 때 Agent라는 개념이 중요해집니다.
OpenAI는 Agent를 LLM이 워크플로의 실행을 관리하면서 상황에 따라 판단하고, 필요한 외부 도구를 선택해 정보를 얻거나 행동할 수 있는 시스템이라고 설명합니다. 기본적으로 모델과 지침, 도구가 결합하고, 필요한 경우 여러 번 실행하며 목표를 완성하는 구조입니다. 이를 루프(Loop)라는 개념으로 따로 설명하기도 합니다. AI가 결과를 확인하고, 부족하면 다시 시도하는 과정입니다.
프롬프트의 복잡도가 높거나 에이전트가 작동하는 시간이 길다고 좋은 것은 아닌데요, 오히려 Anthropic은 단순한 프롬프트로 해결할 수 있는 문제에는 단순한 방식을 사용하고, 부족한 경우에만 다단계 에이전트 시스템으로 복잡성을 높일 것을 권합니다.
즉, 멋진 에이전트를 만드는 것보다 내가 맡기려는 일이 프롬프트로 충분한지, 스킬이 필요한지, 에이전트까지 필요한지를 구분할 수 있어야 한다는 뜻이죠.
행동의 흐름만 놓고 보면 이렇게 정리할 수 있습니다.

AI에게 점점 복잡한 일을 맡길 수 있게 되었지만, 일을 수행하는 능력과 그 일을 위한 정보를 가지고 있는 것은 별개의 문제입니다.
예를 들어, AI에 “우리 회사의 개인정보 처리 기준에 맞춰 이 문서를 검토해줘”라고 요청한다면? 일반적인 개인정보 보호 원칙에 대해서는 꽤 자연스럽게 답하겠지만, 우리 회사가 정한 내부 규칙과 최신 정책 문서를 AI가 가지고 있지 않다면 정확한 판단을 기대하기 어렵습니다.
하지만 AI는 충분한 근거가 없는 상황에서도 그럴듯한 내용을 생성할 수 있습니다. 할루시네이션(Hallucination)이라고 부르죠. 그래서 업무에 AI를 적극적으로 활용할수록 단순히 ‘모델이 얼마나 똑똑한가’보다 ‘무엇을 근거로 답하게 할 것인가’가 중요해집니다.

그래서 같이 중요해진 것이 RAG(Retrieval-Augmented Generation)라는 개념입니다. 필요한 정보를 자료에서 먼저 검색하고, 찾아온 내용을 모델의 답변 생성 과정에 포함하여 함께 제공하는 방식인데요. 모델 내부에 저장된 지식만으로는 필요한 정보를 정확하게 활용하거나 최신 지식을 반영하고 근거를 제시하는 데 한계가 있기 때문에 외부에서 관련 정보를 검색, 참고하여 답변하는 것이죠. 쉽게 말하면 AI에게 모든 것을 기억하라고 하는 대신, 필요할 때 모델 외부의 자료를 찾아보고 답하게 하는 것입니다.
하지만 회사 문서를 수백 개 넣어두었다고 해서 필요한 자료를 자동으로 잘 찾아내는 것은 아닙니다. 이때 긴 문서를 적절한 단위로 나누는 청킹(Chunking)이나, 텍스트의 의미적 유사성을 비교할 수 있도록 수치 표현으로 변환하는 벡터화(Vectorization) 같은 방법이 활용됩니다. 모두 필요한 자료를 더 잘 찾아 AI에게 제공하기 위한 기술입니다.
마지막으로 AI가 내 파일과 자료를 넘어 외부 서비스에서 정보를 가져오거나 행동해야 한다면 ‘연결’이 필요해집니다.
흔히 사용하는 방식은 API(Application Programming Interface)연결 입니다. 서로 다른 소프트웨어가 정해진 규칙에 따라 데이터를 주고받거나 특정 기능을 사용할 수 있게 하는 인터페이스입니다. AI가 사내 시스템의 데이터를 조회하거나 일정을 등록하고, 다른 서비스의 기능을 실행하려면 이런 연결 수단이 필요합니다.
최근 자주 언급되는 MCP(Model Context Protocol)도 같은 ‘연결’이라는 맥락에서 이해하면 쉬워지는데요, MCP는 AI 애플리케이션이 외부의 데이터 소스와 도구를 사용할 수 있도록 연결 방식을 표준화한 공개 프로토콜입니다.
API가 각 소프트웨어의 기능을 외부에서 사용할 수 있게 만든 인터페이스라면, MCP는 AI가 여러 데이터와 도구를 보다 공통된 방식으로 발견하고 사용하도록 연결해주는 규칙에 가깝습니다.

그런데 여기까지 정리하고 나니, 애초에 AI가 참고할 Input이 있는가?라는 대전제가 중요해집니다.
회의에서 결정한 내용이 기록되어 있지 않고, 정책이 사람의 머릿속에만 있으며, 프로젝트 자료가 개인 PC 곳곳에 흩어져 있다면 아무리 좋은 시스템을 만들어도 참고할 것이 없습니다. PPT, Excel, PDF, 회의 녹취와 회의록, 사내 정책, 사용자 인터뷰, 업무 메모처럼 우리가 매일 만들어내는 자료가 결국 AI가 일하기 위한 Input이 됩니다.
그래서 AI를 사용할수록 오히려 문서화와 지식 관리의 중요성이 커집니다. 과거에는 자료를 잘 ‘보관하는 것’이 중요했다면, 이제는 필요한 순간에 사람과 AI가 다시 찾아 사용할 수 있는 상태로 남기는 것까지 생각해야 합니다. 결국 업무에서 쓸모 있는 Output을 만들기 위해서는 쓸모 있는 Input이 필요하고, 어떤 정보를 어떻게 남길 것인지를 고민하는 것 자체가 업무 프로세스를 개선하는 중요한 지점이 됩니다.
여기서 한 단계 더 나아가면, AI가 만들어낸 Output 역시 다시 다음 업무의 Input이 됩니다. 잘 만든 보고서나 분석 자료, 업무 기준과 결과물을 어떻게 모으고 다시 활용할 수 있는 형태로 남기느냐에 따라 개인의 일회성 결과물이 될 수도 있고, 조직이 반복해서 활용할 수 있는 자산이 될 수도 있습니다. Input과 Output이 순환하는 구조를 얼마나 잘 만들 수 있는지가 결국 조직의 효율과 성과에도 영향을 미치는 셈입니다.
하지만 그것만으로 곧바로 좋은 업무 자동화가 만들어지는 것은 아닙니다. 무엇을 어떤 순서로 수행하고, 어떤 기준으로 판단해야 하는지가 정리되어 있지 않다면 AI 역시 일을 안정적으로 반복하기 어렵습니다.
그래서 도구보다 먼저 SOP(Standard Operating Procedure), 즉 실제 업무 절차를 정리하는 일이 필요할 때가 있습니다. 어떻게 업무를 시작하고, 어떤 자료를 참고하며, 무엇을 기준으로 판단하는지처럼 그동안 암묵지로 남아 있던 업무 방식을 절차화하는 것입니다. 이 과정을 거치고 나면 어느 부분은 사람이 판단해야 하고, 어느 부분은 Skill이나 Agent에 맡길 수 있을지도 구분할 수 있습니다.
이렇듯 AI를 도입한다는 것은 단순히 사람의 업무를 AI로 치환하는 일이 아닙니다. 오히려 기존 업무가 실제로 어떻게 이루어지고 있었는지 발견하고, 흩어진 지식과 결과물을 모으고, 다시 활용할 수 있는 구조로 만드는 과정에 더 가깝습니다. 결국 AI를 활용한다는 것은 기술을 도입하는 일을 넘어, 우리가 일하고 지식을 축적하는 방식을 다시 설계하는 일이기도 합니다.
이 지점까지 오면 묻는 질문에만 답하던 AI가 실제 업무 환경에 상당히 깊게 들어올 수 있다는 것을 알 수 있습니다. 자료를 참고하고, 업무 절차를 따르고, 파일을 만들고, 여러 도구를 사용하며, 필요하면 외부 시스템에서 실제 행동까지 수행합니다.
다시 정리해 보면,

그런데 이 모든 것을 실제 업무에서 제대로 활용하려면, 결국 AI에게 어떤 Input을 주고 어떤 Output을 만들 것인지, 우리의 일이 어떤 절차로 이루어지는지를 먼저 이해해야 합니다.
결국 AI를 잘 쓴다는 것도 새로운 기술을 가장 많이 아는 일이 아니라, 내 업무 안에서 어떤 기술을 왜 사용하는지 이해하고 필요한 만큼 선택할 수 있는 일이 아닐까요?
무언가 새로 적용하거나 도입하기 위해 우리는 흔히 How to를 찾곤 했습니다. 하지만 이제 How to를 찾는 비용은 이전보다 크게 낮아졌습니다. Skill을 만드는 방법도, RAG를 구축하는 방법도, MCP를 연결하는 방법도 AI에게 물어보면 단계별로 설명해주니까요. 그렇다면 사람에게 남는 중요한 역할 중 하나는 ‘어떻게 만들 것인가’보다 ‘지금 이 문제에 무엇이 필요한가’를 판단하는 일일지도 모릅니다.
ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.