https://www.jblog.me/posts/ai-development-direction
요즘 AI 관련 글이나 뉴스를 보면 대부분 이런 이야기가 많습니다.
- “모델이 더 똑똑해졌다.”
- “이제 코딩도 더 잘한다.”
- “이미지를 보고 이해한다.”
- “추론 능력이 좋아졌다.”
물론 맞는 말입니다. AI 모델 자체는 정말 빠르게 좋아지고 있습니다. 하지만 개발자 입장에서 보면, AI의 발전을 단순히 “모델이 더 똑똑해지는 것”만으로 설명하기는 조금 부족하다고 느꼈습니다. 실제로 요즘 나오는 도구들을 보면, 모델 자체를 새로 만드는 것보다 이미 있는 AI를 어떻게 더 잘 사용하게 만들 것인가에 초점이 맞춰져 있는 경우가 많습니다.
예를 들어 Superpowers 같은 도구는 AI 코딩 에이전트에게 무작정 코드를 작성하게 하는 것이 아니라, 먼저 계획을 세우고, 테스트를 만들고, 구현하고, 검토하는 흐름을 따르게 합니다. MCP는 AI가 외부 도구나 데이터에 접근할 수 있도록 연결 방식을 정리하려는 시도입니다. Vercel AI SDK는 AI 응답을 실제 웹 애플리케이션 안에서 streaming UI나 tool calling과 함께 다루기 쉽게 만들어줍니다. Guardrails AI나 Pydantic AI 같은 도구들은 AI의 출력이 원하는 형식과 규칙을 지키는지 검증하려고 합니다.
이런 흐름을 보면, 요즘 AI 개발은 단순히 모델을 호출하는 수준을 넘어서고 있습니다. 그래서 저는 현재 AI의 발전 방향을 크게 네 가지로 나눠볼 수 있다고 생각했습니다.
- AI Model
- Context
- AI Application Architecture
- AI Infra
!image.png
1. AI Model - AI 자체를 더 똑똑하게 만들기
첫 번째는 가장 익숙한 방향입니다. AI 모델 자체를 더 똑똑하게 만드는 것입니다. 더 좋은 모델 구조를 만들고, 더 좋은 데이터를 학습시키고, reasoning 능력이나 coding 능력, multimodal 이해 능력을 높이는 일입니다.
예를 들면 이런 것들이 여기에 포함됩니다.
- 더 좋은 Foundation Model 만들기
- 더 좋은 학습 데이터 만들기
- Fine-tuning
- Reasoning 성능 개선
- 이미지, 영상, 음성을 함께 이해하는 Multimodal Model
- 작은 모델을 더 빠르고 효율적으로 만드는 연구
이 영역은 주로 AI 연구자나 ML 엔지니어에 가까운 역할이라고 생각합니다. 핵심 질문은 단순합니다. 어떻게 하면 AI 모델 자체를 더 똑똑하게 만들 수 있을까? 하지만 대부분의 개발자는 모델을 직접 만드는 사람이 아닙니다. 이미 만들어진 모델을 가져와서 서비스에 붙이고, 실제 문제를 해결해야 하는 경우가 더 많습니다.
그래서 다음 영역이 중요해집니다.
2. Context - AI에게 좋은 기준을 주기
두 번째 방향은 AI에게 더 좋은 Context를 주는 것입니다. 여기서 말하는 Context는 단순히 프롬프트만 의미하지 않습니다. 저는 오히려 앞으로는 테스트, 린트 규칙, 성능 지표, 보안 정책 같은 측정 가능한 기준을 AI에게 함께 제공하는 것이 더 중요해질 것이라고 생각합니다. AI에게 “좋은 코드로 작성해줘”라고 말하는 것은 너무 애매합니다. 사람마다 좋은 코드의 기준이 다르고, 프로젝트마다 지켜야 할 규칙도 다르기 때문입니다.
그래서 실제 개발에서는 기준이 더 구체적이어야 합니다.
- 테스트를 통과해야 한다.
- 린트 규칙을 위반하면 안 된다.
- 기존 아키텍처 경계를 지켜야 한다.
- FCP/LCP가 일정 기준 이상 나빠지면 안 된다.
- 보안상 위험한 코드가 있으면 안 된다.
이런 기준이 있어야 AI가 만든 결과를 평가할 수 있습니다. 테스트가 실패하면 잘못된 코드이고, 린트 규칙을 위반하면 프로젝트의 기준을 지키지 못한 코드입니다. 기능은 동작하더라도 FCP나 LCP 같은 성능 지표가 나빠졌다면, 그것 역시 좋은 결과라고 보기 어렵습니다.
이 흐름은 요즘 AI 개발 도구에서도 많이 보입니다.
예를 들어 OpenAI Evals는 LLM 애플리케이션을 평가하기 위한 프레임워크입니다. 공식 문서에서도 eval을 만들고, 테스트 입력으로 실행하고, 결과를 평가하는 흐름을 설명합니다. 즉, AI 결과를 감으로 판단하는 것이 아니라 평가 케이스와 기준을 만들어 검증하는 방식입니다.
Langfuse는 prompt, trace, eval, metric을 함께 관리합니다. 어떤 prompt와 context로 결과가 나왔는지 추적하고, prompt 버전별 metric과 evaluation을 연결할 수 있습니다.
또한 Vercel AI SDK처럼 schema 기반 structured output을 지원하는 도구도 있습니다. 모델이 만든 결과를 정해진 schema로 검증해서 type safety와 correctness를 보장하려는 흐름입니다.
이런 도구들이 보여주는 방향은 분명합니다. AI 시대의 Context는 단순히 “프롬프트 문장”이 아니라, AI가 따라야 할 테스트, 평가 기준, 스키마, 성능 지표, 실패 조건까지 포함합니다. 결국 사람이 해야 할 중요한 역할은 AI에게 일을 시키는 것만이 아닙니다. 무엇을 성공으로 볼지, 무엇을 실패로 볼지 기준을 세우는 것입니다.
AI가 코드를 작성할 수는 있지만, 테스트를 어떻게 구성할지, 린트 규칙을 어떻게 둘지, 성능 기준을 어디까지 허용할지, 어떤 결과를 regression으로 볼지는 사람이 정해야 합니다. 그래서 저는 앞으로의 AI 개발에서 중요한 능력은 단순한 프롬프트 작성 능력이 아니라, AI가 만든 결과를 측정하고 평가할 수 있는 기준을 설계하는 능력이라고 생각합니다.
3. Architecture - AI가 일하는 흐름을 설계하기
세 번째 방향은 AI Application Architecture입니다.
AI 서비스를 만든다는 것은 단순히 모델 API를 호출하는 일이 아닙니다.
AI가 실제 서비스 안에서 하나의 작업을 수행하려면, 백엔드에서는 안정적인 실행 파이프라인이 필요하고, 프론트엔드에서는 그 과정을 사용자에게 잘 보여주는 구조가 필요합니다.
예를 들어 RAG 기반 문서 검색 서비스라면 백엔드에서는 다음과 같은 흐름이 필요합니다.
- 질문 분석
- 문서 검색
- 관련 문서 필터링
- 답변 생성
- 근거 검증
- 응답 반환
- 로그 저장
- 평가 데이터 적재
이런 작업은 한 번의 API 호출로 끝나지 않습니다. 중간에 실패할 수도 있고, 시간이 오래 걸릴 수도 있고, 특정 단계에서는 사람의 승인이 필요할 수도 있습니다. 그래서 백엔드에서는 queue, retry, timeout, workflow, 상태 저장, tool 권한 제어, 로그 저장 같은 구조가 중요해집니다.
하지만 이것만으로는 부족합니다. 사용자 입장에서는 AI가 지금 무엇을 하고 있는지 알 수 있어야 합니다. 예전 웹 애플리케이션에서는 상태가 비교적 단순했습니다.
- Loading
- Success
- Error
하지만 AI 서비스에서는 상태가 더 세분화됩니다.
- 문서를 찾는 중
- 답변을 생성하는 중
- 근거를 검증하는 중
- 테스트를 실행하는 중
- 사람의 승인을 기다리는 중
- 재시도하는 중
- 완료됨
- 실패함
프론트엔드에서는 이런 상태를 사용자에게 자연스럽게 보여줘야 합니다. AI가 어떤 도구를 호출했는지, 어디까지 진행됐는지, 왜 실패했는지, 사용자가 승인해야 하는 작업은 무엇인지 보여주는 UX가 필요합니다. 또한 streaming 응답, 중간 결과 표시, 작업 취소, 재시도, 승인/거절 같은 인터랙션도 중요해집니다. 그래서 AI Application Architecture에서는 다음 질문들을 함께 고민해야 합니다.
- AI 작업을 동기/비동기 중 어떻게 처리할 것인가?
- 실패한 작업은 어디서부터 재시도할 것인가?
- 중간 결과와 실행 로그를 어디에 저장할 것인가?
- AI가 호출할 수 있는 tool의 권한을 어떻게 제한할 것인가?
- 사용자에게 어떤 진행 상태를 보여줄 것인가?
- 사람의 승인이 필요한 작업은 어디서 멈출 것인가?
- 생성된 결과를 어떻게 검증한 뒤 사용자에게 전달할 것인가?
이런 흐름은 요즘 도구들에서도 확인할 수 있습니다.
Temporal, Inngest, Trigger.dev 같은 도구들은 긴 작업, 재시도, 실패 복구, workflow 실행을 다루는 데 사용됩니다. Vercel AI SDK는 streaming UI, tool calling, generative UI처럼 AI 응답을 사용자 인터페이스 안에서 다루는 방식을 지원합니다. LangGraph, Mastra, Pydantic AI, OpenAI Agents SDK 같은 도구들은 agent의 상태, tool 호출, 여러 단계의 작업 흐름을 구성하는 방향으로 발전하고 있습니다.
결국 Architecture의 핵심은 단순히 AI 답변을 화면에 보여주는 것이 아닙니다. 백엔드에서는 AI가 안정적으로 작업을 수행할 수 있는 실행 파이프라인을 만들고, 프론트엔드에서는 그 과정을 사용자가 이해하고 개입할 수 있는 상태와 UX를 설계하는 것입니다. 즉, AI Application Architecture는 AI가 실제 서비스 안에서 안정적으로 일하고, 사용자가 그 과정을 신뢰할 수 있게 만드는 구조라고 볼 수 있습니다.
4. Infra - AI를 실행하기 위한 컴퓨팅 자원
네 번째 방향은 AI Infra입니다. AI가 발전할수록 모델 자체만큼이나 중요한 것이 컴퓨팅 자원이라고 생각합니다. 아무리 좋은 모델이 있어도, 그 모델을 빠르고 안정적으로 실행할 수 있는 GPU, 메모리, 네트워크, 데이터센터가 없다면 실제 서비스로 운영하기 어렵기 때문입니다.
이 흐름은 요즘 빅테크 기업들의 움직임에서도 잘 보입니다. Meta는 AI 인프라와 데이터센터 투자를 크게 늘리고 있고, xAI도 Colossus라는 대규모 AI training supercomputer를 구축했고, 공식 사이트에서는 200,000개의 H100 GPU를 하나의 클러스터로 연결했다고 설명합니다. NVIDIA 역시 Blackwell 같은 AI GPU를 중심으로 데이터센터용 컴퓨팅 시장의 핵심 위치에 있습니다.
이런 사례를 보면, AI 경쟁은 단순히 “누가 더 좋은 모델을 만들었는가”만의 문제가 아닙니다. 이제는 누가 더 많은 컴퓨팅 자원을 확보하고, 그것을 얼마나 효율적으로 사용할 수 있는가의 경쟁이기도 합니다. 서비스를 만드는 입장에서도 마찬가지입니다. AI 모델을 실제 제품에 넣으려면 다음과 같은 고민이 필요합니다.
- 어떤 요청을 큰 모델로 보낼 것인가?
- 어떤 요청은 작은 모델로 처리할 수 있는가?
- GPU 자원을 어떻게 나눠서 사용할 것인가?
- 동시에 많은 요청이 들어오면 어떻게 처리할 것인가?
- 응답 속도와 비용 사이에서 어떤 선택을 할 것인가?
- caching, batching, quantization을 적용할 수 있는가?
그래서 AI Infra는 단순히 서버를 띄우는 일이 아닙니다. AI 모델이 실제 서비스에서 빠르고 안정적으로 동작할 수 있도록 GPU, 메모리, 네트워크, 스토리지 같은 컴퓨팅 자원을 효율적으로 관리하는 영역입니다. 이 흐름은 vLLM, TensorRT-LLM, Ray, Kubernetes 기반 GPU scheduling, model serving system 같은 도구들에서도 확인할 수 있습니다. 이 도구들은 제한된 GPU 자원을 더 잘 활용하고, 모델을 더 빠르게 실행하며, 많은 요청을 안정적으로 처리하기 위해 사용됩니다.
AI Infra에서 중요한 질문은 이것이라고 생각합니다. AI 모델을 어떻게 더 빠르고, 싸고, 안정적으로 실행할 것인가? AI 시대에는 모델을 잘 고르는 것만큼이나, 그 모델을 어떤 컴퓨팅 환경에서 어떻게 실행할 것인지도 중요한 개발 문제가 되고 있습니다.
마무리
AI의 발전 방향을 정리하면서, 개발자인 저에게 특히 중요하게 느껴진 부분은 Context와 AI Application Architecture였습니다. 결국 AI 시대의 개발자는 단순히 AI에게 일을 시키는 사람이 아니라, AI가 만든 결과를 평가할 기준을 세우고, 그 기준을 만족하도록 구조를 설계하는 사람에 가까워진다고 생각합니다. 그래서 앞으로 개발을 하거나 블로그 글을 작성할 때도, 단순히 “무엇을 개발했다”에서 끝내기보다 무엇을 기준으로 좋아졌다고 말할 수 있는지, 그리고 그것을 어떻게 측정했는지를 중심으로 기록해보려고 합니다.
