AI 엔지니어가 되기 위해 알아야 할 6가지 스킬
오늘은 AI 엔지니어를 꿈꾸는 분들을 위해, AI 엔지니어가 되기 위해 쌓아야 할 스킬에 관한 로드맵을 하나 소개해드리려고 합니다. 바로 그렉 캄라트(Greg Kamradt)의 유튜브 영상에서 소개된 "Become An AI Engineer in 2025 | The 6 Step Roadmap"인데요.
그렉 캄라트는 세일즈포스(Salesforce)에서 수십억 달러 규모 제품의 분석을 담당하는 데이터 과학자 팀을 이끌었습니다. 만 명 이상의 개발자에게 첫 AI 애플리케이션 구축 방법을 가르치기도 했고, 현재는 AI 구축과 교육을 하고 있다고 합니다.

그렉은 영상에서 “AI와 언어 모델이 성공적인 엔지니어가 되기 위해 필요한 기술들을 변화시키고 있다”며 이러한 변화에 맞춰 엔지니어가 갖춰야 할 ‘6가지 새로운 AI 엔지니어링 기술’을 제시합니다. 그리고 이 기술을 습득하기 위해 참고해보면 좋을 자료와 팔로우하면 좋을 전문가 목록을 알려주는데요. 자신이 LLMs 작업에 대해 알았으면 좋았을 것들을 담았다고 합니다.
이제부터 그 내용을 소개해보도록 하겠습니다.

AI 엔지니어에게 필요한 6가지 스킬 로드맵
1단계: 모델 다루기 (Working with Models)
AI 엔지니어 스킬 로드맵의 첫 번째 단계는 모델과 함께 작업하는 것입니다. 현재 대표적인 모델을 제공사는 OpenAI, Anthropic, Meta, Google 네 곳인데요. 각각의 모델은 고유한 특성(persona)을 가지고 있다고 합니다. 예를 들어, ResiDesk의 CEO 아르준 카난(Arjun Canan)에 따르면,
- OpenAI 모델은 최고의 분석가 경향이 있고,
- Anthropic 모델은 최고의 작가 경향이 있으며,
- Gemini 모델은 대체로 최고의 탐정 경향이 있다고 하는데요 (방대한 맥락에서 바늘을 찾는 데 탁월하다고)
각각의 특성을 이해하고 다룰 수 있어야 합니다.

가장 많이 사용되는 방식은 텍스트를 입력받아 텍스트를 출력하는 Text-to-Text 방식이지만, Text-to-Speech, Text-to-Image, Video-to-Image 등 다양한 형태(modality)의 작업이 가능하며 이것이 바로 멀티모달(Multimodal)의 개념인데요. 추론 모델이나 비추론 모델 등 각 모델을 다양하게 실험하다 보면 어디에 쓸 수 있는지 프롬프트를 어떻게 작성해야 할지에 관해 감이 생길 것입니다.
모델 API를 다루는 방법을 이해하는 것도 중요합니다. openai.chat.completions.create
와 같은 코드를 자주 보게 될 텐데요. GPT-4o, Whisper, Sona, HiKU, Opus 등 다양한 모델 유형이 있다는 것을 알아야 합니다. 오픈AI의 플레이그라운드를 사용해보고, API 문서나 최신 쿡북 예제를 살펴보는 것이 좋습니다. API 문서와 SDK 사이에는 약간 차이가 있을 수 있어서, 예제를 살펴보는 것이 중요하다고 해요.
자체 인프라에서 모델을 실행할 수도 있습니다. OpenRouter나 Ollama 같은 도구가 좋은 예시입니다. 하지만 모델 학습(training), 파인튜닝(fine-tuning), 모델 라우팅(model routing)은 AI 엔지니어가 시작 단계에서 걱정해야 할 부분은 아니라고 그렉은 말합니다. 이는 나중에 배울 수 있는 최적화(optimization) 기술에 가깝다는 거죠.
더불어 참고하면 좋은 자료와 팔로우를 추천하는 전문가를 아래처럼 제시합니다.
[비디오와 팟캐스트]
- 그렉의 이전 AI Show and Tell 시리즈 영상
- 렉스 프리드먼(Lex Friedman) 팟캐스트(Cursor 팀 편),
[블로그와 팔로우하면 좋은 사람]
- Applied LLM: 응용 AI 분야 최고 전문가들 모임
- swyx’s Latent Space: 고급 연구와 학회 내용을 폭넓게 다루는 올인원 커뮤니티, 블로그, 팟캐스트 등의 플랫폼
- Jason Liu: Instructor의 창립자. 컨설팅 회사를 운영하면서 실제로 일을 수행하는 데 필요한 실용적인 조언(tactical advice)을 많이 공유합니다.
- 유진 얀(Eugene Yan): 아마존 시니어 응용 과학자(Sr. Applied Scientist). 기계학습(ML)과 추천 시스템(Recommendation Systems) 분야의 전문가입니다.
- 저스틴 튜니(Justine Tunney) : 로우레벨 기술을 꿰뚫는 해커
- Deedy Dass: Menlo Ventures의 벤처캐피탈리스트(VC)
2단계: 프롬프트 기술 이해 (Understanding the Art of Prompting)
두 번째는 프롬프트 기술을 이해해야 한다고 합니다. 프롬프트가 중요하지 않거나 일시적인 유행이라고 생각하는 사람들도 많지만, 그렉은 프롬프트가 모델로부터 원하는 행동(behavior)을 이끌어내는 기술이라고 봅니다. 오늘날 그것이 영어일 뿐, 미래에는 다른 형태가 될 수도 있고요. 중요한 것은 효과적인 프롬프트, 즉 모델로부터 원하는 행동을 이끌어내는 기술 자체가 필요하다는 것입니다.
그렉은 자신에게 효과적이었던 네 가지 기법을 공유했습니다.
- Chain of Thought(사고의 사슬)또는 Think Out Loud(소리 내어 생각하기). 모델이 답을 바로 도출하기 전에 생각 과정을 먼저 설명하도록 하는 기법입니다.
To give my best complete final answer to the task use the exact following format:
Thought: I now can give a great answer
Final Answer: Your final answer must be the great and the most complete as possible, it must be outcome described.
- 예시 포함하기. 예시를 포함하지 않으면 프롬프트 성능을 얻기 어렵다고 해요.
<Example 1>
Input: "Timeseries data is missing several days of data. This problem is happening only during the afternoons sometimes."
Output: true
</Example 1>
<Example 2>
Input: "Your ceo needs a haircut"
Output: false
</Example 2>
- input에 구조화된 요소 사용. XML 태그를 사용하거나 미리 채워진 프롬프트 메시지를 사용하는 등의 트릭도 있습니다.
- 구조화된 출력(Structured Outputs). 컴퓨터는 JSON이나 표 같은 구조화된 데이터를 잘 다루지만, 언어 모델은 기본적으로 일반 텍스트를 다룹니다. 하지만 언어 모델이 JSON 같은 구조화된 형식으로 응답한다면, 이를 다른 프로그램에 전달하거나 언어 모델 외부의 도구를 사용할 수 있습니다. 즉 언어 모델이 검색 쿼리를 사용하거나 도구를 이용하는 등 다른 시스템과 통합되도록 하려면 아웃풋을 구조화된 형식으로 출력해야 합니다.
특히 구조화된 출력과 관련해, 사업체를 800만 달러에 매각한 경험이 있는 티보 루이 루카스(Tibo Louis-Lucas)라는 한 사업가의 사례를 소개했는데요. 그가 가장 많이 타이핑하는 문장은 output in JSON; do not output anything else about it.
이라고 합니다. 나아가 오픈AI의 예제를 참고하면 구조화된 출력을 만드는 법을 알 수 있다고 합니다.
이후에는 프롬프트 작성을 넘어 프롬프트 관리(Prompt Management)도 이해해야 한다고 합니다. AI 엔지니어는 결국 프롬프트를 최적화하고 관리할 필요를 느끼게 된다고 하는데요. 보통 다들 처음에는 코딩 안에 프롬프트를 넣고, 그 다음에는 txt 파일을 사용하다가, 결국 PromptLayer 같은 외부 프롬프트 관리자를 사용하게 되는 과정을 거친다고 합니다.
프롬프트 관리와 관련해 그렉이 추천하는 목록은 다음과 같습니다.
- 유진 얀(Eugene Yan)의 최적화 프롬프트 소개 글
- 엘비스(Elvis)의 프롬프트 엔지니어링 가이드
- 구글의 프롬프트 관련 연구 논문 등
3단계: 컨텍스트와 검색 (Context and Retrieval)
세 번째는 컨텍스트와 검색(Retrieval)의 필요성과 작동 원리를 이해해야 합니다. 모델을 만지다 보면, 모델이 미리 학습한 데이터에만 의존하기보다 내가 원하는 것과 관련된 컨텍스트를 제공해 응답의 질을 높이고 싶어집니다. 이를 위해 데이터를 검색(retrieve)하여 언어 모델에 전달함으로써 더 나은 응답을 생성하게 하는데, 이것이 바로 RAG(검색 증강 생성, Retrieval Augmented Generation)입니다. 생성(Generation)에 검색(Retrieval)을 추가하는 것이죠. 결국 RAG을 이해해야 한다는 건데요.
RAG이라는 용어가 복잡하게 들릴 수 있지만, 그렉은 “이것은 말 그대로 다른 분석을 할 때처럼 프롬프트에 데이터를 넣는 것”이라며 겁 먹지 말라고 조언합니다. 그렉은 챗GPT에 자신의 정보를 복사+붙여넣는 것 역시, 수동적인 형태이긴 하지만 retrieval 하는 거라고 말합니다. 더 궁금하시면 저는 요즘IT에 올라온 <10분 만에 RAG 이해하기>도 이해에 도움이 됐습니다.
가장 일반적인 RAG 구현 방식은 사용자의 쿼리를 기반으로 관련 문서를 찾는 것인데, 이때 사용자의 쿼리가 충분히 상세하지 않거나, 앱이 질문에 답하기 위한 정확한 컨텍스트를 반환하지 못하거나, 프롬프트에 불필요한 내용이 너무 많아 원하는 결과가 나오지 않는 문제에 맞닥뜨릴 수 있습니다.
이를 해결하기 위해 검색 전에 사용자의 쿼리를 개선하거나, 원시 데이터의 청킹(chunking) 전략(긴 텍스트를 작은 조각으로 나누는 방법)이나 색인(index) 전략을 개선하는 기법들을 활용한다고 합니다. 어떻게 맥락을 제공해 검색 결과의 질을 높일 수 있는지를 고민해야 하는 단계죠.
추천 자료 목록은 다음과 같습니다.
- 그렉이 만든 검색 시리즈 https://fullstackretrieval.com/,
- LangChain 문서,
- 다양한 청킹 기법을 시각화하는 chunkviz.com
4단계: 오케스트레이션 (Orchestration)
오케스트레이션을 알아야 합니다. 이는 단순히 모델 API를 한 번 호출하는 것을 넘어, 여러 시스템이 함께 작동하는 시스템을 구축하는 것입니다. 기본적인 수준에서는 랭체인(LangChain)과 같은 오케스트레이션 프레임워크를 사용하는 것부터 시작합니다. 가장 간단한 형태는체인(Chains)으로, 여러 모델 호출을 순차적으로 연결하는 것입니다.
고급 버전은 에이전트(Agents)의 세계로 넘어가는 것입니다. 에이전트는 도구에 접근하여 특정 작업이 완료되었는지 스스로 결정할 수 있는 언어 모델이라고 할 수 있는데요. 에이전트의 정의에 대해 아직 논의가 분분하지만, 랭체인 CEO 해리슨 체이스(Harrison Chase)의 정의에 따르면, 에이전트의 핵심은 언어 모델을 추론 엔진으로 사용하여 무엇을 할지, 그리고 외부 세계와 어떻게 상호작용할지 결정하는 것입니다.

에이전트와 관련해 인기 있는 프레임워크는 LangGraph, CrewAI, Haystack이며, 노코드(no-code) 도구로는 Lindy.ai, Langflow, Hoe.ai 같은 것들이 있습니다.
에이전트와 작업할 때 또 다른 중요한 부분은 장기 기억(Long-term memory)입니다. LangChain에 좋은 블로그 글이 있지만, 이 분야는 아직 모두가 알아내려고 노력 중이며 명확히 정해진 답은 없다고 합니다.
추천 자료는 다음과 같습니다.
- LangChain이 발표한 에이전트 도입 현황 보고서(State of Agents report): 특히 창업을 고려하는 이들이라면 현재 기업의 에이전트 채택 현황을 파악하고 자신의 비즈니스에 적용하는 데 도움을 얻을 수 있다고 합니니다.
- 이 분야 전문가로는 해리슨 체이스(Harrison Chase)과 알렉스 레입먼(Alex Reibman)를 추천했습니다.
5단계: 평가 및 관찰성 (Evaluations and Observability)
다섯 번째는 평가(Evaluations)와 관찰성(Observability)을 알아야 하는데요. 이 분야 전문가인 제이슨 리우(Jason Liu)는 “AI 제품이 평가를 필요로 하지 않는다면, 그 제폼은 근본적으로 흥미 없고 쓸모 없는 것일 수 있습니다”라며 평가의 중요성을 강조했습니다.

평가는 언어 모델 애플리케이션의 단위 테스트(Unit tests) 역할을 합니다. 일반적인 소프트웨어 코드는 문제가 생기면 어디가 잘못됐는지 비교적 명확히 파악하기 쉽죠. 하지만 언어 모델은 결과가 비결정적(Non-deterministic)이고, 좋고 나쁨이 마치 "바이브 기반(Vibe based)"처럼 느껴져서 문제가 발생했을 때 원인을 찾기가 훨씬 어렵습니다. 바로 이럴 때 평가가 꼭 필요하다는 것이 그렉의 주장입니다.
많은 개발자들이 일반 코드 단위 테스트도 피하는 것처럼, 언어 모델 평가 역시 쉽지 않고 까다롭다고 느껴져 기피하는 경향이 있다는데요. 특히 요약문의 품질이나 자연어 출력처럼 명확한 기준이 없는 결과물을 철저히 평가하는 것은 분명 어려운 일입니다. 하지만 다행히도 이 분야의 모범 사례들이 빠르게 발전하고 있다고 합니다. 그렉은 평가 분야의 최고 전문가 중 한 명인 하멜 후세인(Hamel Husain)의 “Your AI Product Needs Evals” 같은 자료를 참고하는 것을 강력히 추천했습니다.

다음으로 관찰성(Observability)은 AI 애플리케이션 내부가 어떻게 돌아가고 있는지 속을 들여다보는 능력이라고 생각하시면 됩니다. 관찰성은 크게 두 가지 핵심 기능을 제공합니다.
- 트레이싱(Tracing): 이건 말 그대로 애플리케이션에서 발생하는 모든 언어 모델 호출 기록을 남기는 것입니다. 어떤 LLM 호출이 언제 일어났고 결과가 어땠는지 등을 기록해두면, 나중에 디버깅할 때 정말 유용합니다. 예를 들어, 앱 성능이 갑자기 떨어졌을 때 어떤 LLM 호출 때문에 문제가 생긴 건지 파악하기가 훨씬 쉬워지죠.LangSmith같은 관찰성 프레임워크에 연결하고 호출에 필요한 정보(metadata)를 많이 추가해두면, 어떤 호출이 문제인지 빠르게 찾아내고 분석할 수 있습니다.
- 비용 관리(Cost Management): LLM API는 사용할 때마다 비용이 발생하죠. 만약 이걸 제대로 추적하지 않으면 나중에 예상치 못한 큰 지출에 직면할 수도 있습니다. 관찰성 도구들은 각 LLM 호출에 대한 정확한 비용, 응답 지연 시간(latency), 발생한 오류 등을 상세히 추적하고 보여주기 때문에, 효율적으로 비용을 관리하는 데 큰 도움이 됩니다.
그렉은 관찰성 도구로 랭스미스(LangSmith)를 가장 추천합니다. 무료 티어도 제공하고 사용하기 매우 쉽다고 하네요.

그 외에도 GenTrace, Arize 같은 도구들이 있고, 특히 제품 팀이라면 Autoblocks, Freeplay도 고려해볼 만합니다.
결론적으로 평가와 관찰성은 AI 애플리케이션을 단순히 만드는 것을 넘어, 제대로 작동하고 신뢰할 수 있으며 효율적인 상태로 유지하기 위한 필수적인 요소라고 그렉은 말합니다.
6단계: 마인드셋 (Mindset)
AI 엔지니어 스킬 로드맵의 마지막 단계는 바로 마인드셋(Mindset)입니다. 이것은 단순한 기술이라기보다는 모든 것을 아우르는메타 스킬에 가깝다고 할 수 있습니다. 그렉은 ‘AI 분야에서 무언가를 구축하기 시작할 때, 새로운 관점과 접근 방식, 즉 새로운 마인드셋을 갖는 것이 매우 중요하다’고 강조하면서, 마인드셋의 네 가지 핵심 축을 제안했습니다.
1)새로운 가능성(capability)과 사용 사례(use cases)를 공부하는 것
LLM은 우리에게 이전에 없던 새로운 가능성을 열어주었는데요. 새로운 세계인 만큼 새로운 사용 사례를 계속 공부해나가야 합니다. 초기 단계에서는 어떤 사용 사례가 가능한지부터 감을 잡아야 하는데요, 그에 도움되는 자료로 다음의 목록을 추천합니다.
- 엘비스의 포스트
- 샘 파(Sam Parr)의 햄튼 AI 보고서(Hampton AI Report)
- 그렉이 직접 정리한 얼리 시그널(early signals)목록
2)'먼저 만들고 빠르게 구축하는 것(Build first and build quickly)'
그렉은 티보(Tibo)를 이 원칙을 잘 보여주는 인물로 소개합니다. 티보는 "떠오르는 첫 번째 아이디어를 바로 작업에 착수해서 가능한 한 빨리 대중에게 선보여야 한다"고 강조합니다. 심지어 결과물이 완벽하지 않고, '형편없거나 그다지 유용하지 않더라도' 일단 만들어서친구들에게 테스트하게 하고 피드백을 받으라고 조언하죠. 지금은 AI 도구 덕분에 아이디어를 현실로 만드는 마찰(friction)이 매우 낮아졌기 때문에 실행력(execution)이 그 어느 때보다 중요한 시대라는 점을 기억해야 합니다.
3)새롭게 등장하는 도구 스택(tool stack)을 꾸준히 이해하려는 노력.
AI 분야는 새로운 도구들이 끊임없이 쏟아져 나옵니다. 예를 들어, 프론트엔드를 구축할 때는 v0처럼 영감을 얻거나 빠르게 시작할 수 있는 도구가 있고, AI 기반 IDE를 찾는다면 커서(Cursor)나 윈드서프를 살펴볼 수 있습니다. 개발자들 사이에서는 앤트로픽의 프로젝트들도 매우 인기가 많다고 합니다. 실제로 헤드 스타트(Head Start) CEO인 니콜 헤들리(Nicole Headley)는 클로드 프로젝트를 극찬하며, ‘그것 없이는 사업 운영이 정말 어려울 것’이라고까지 말했습니다. 변화가 빠르지만 그 유용성이 점점 더 입증되고 있는 만큼 우리도 새롭게 등장하는 도구 스택을 꾸준히 이해하기 위해 노력하는 마인드셋이 필요합니다.
4)LLM 앱을 효율적으로 확장(Scaling)하는 방법을 아는 것.
오픈AI의 데브데이(Dev Day)에서 콜린(Colin Jarvis)과 제프(Jeff Harris)가 공유한 내용에 따르면, LLM 애플리케이션을 성공적으로 확장하기 위해서는 성능 향상(improving performance), 비용 절감(reducing cost), 지연 시간 단축(reducing latency)이라는 세 가지 핵심 영역에 집중해야 합니다. 단순히 기능을 구현하는 것을 넘어, 성장하는 시스템의 효율성, 경제성, 응답성을 미리 고려하고 전략적으로 접근하는 사고 방식이 중요하다는 것입니다.
마치며
저는 현재 백엔드 엔지니어로 일하고 있지만, AI 엔지니어링에도 꾸준히 관심을 가져왔습니다. 다만 그동안은 정보가 너무 많고 변화도 빠르다 보니 어디서부터 손을 대야 할지 막막했고, 여러 모델들을 흥미 삼아 몇 번 써본 게 전부였습니다.
이번 로드맵을 보면서 느낀 건, 단순히 모델을 호출하는 데서 끝나지 않고, RAG 구현이나 오케스트레이션, 에이전트 같은 부분에서도 실제로 손을 많이 써봐야 한다는 점이었습니다. 특히 관찰성(Observability)이나 스케일링 같은 요소들은 그동안 생각도 못했던 부분이라 새롭게 다가왔고요. 영상보다 이 문서에 예시 코드 등과 함께 정리가 더 잘 돼있으니 참고해보시면 좋을 것 같습니다.
앞으로는 저만의 프로젝트를 통해 다양한 실험을 해보면서, 이 로드맵에 나온 기술들을 하나씩 익혀가보려고 합니다. 단순히 AI를 ‘사용’하는 단계를 넘어, 제대로 ‘구축하고 운영’할 수 있는 역량을 갖출 수 있게 되면 좋겠네요. 여러분은 어떠신가요?
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.