모델의 본질부터 아키텍처, 비즈니스 전략까지
AI 기술이 급변하면서 단순히 프롬프트를 작성하는 것을 넘어, 소프트웨어 아키텍처 내에 AI를 어떻게 녹여내고 서비스화할 것인가가 개발자들의 핵심 과제가 되었습니다.
특히 사이드 프로젝트나 실무에서 AI를 도입하려 할 때, 막연한 기대감보다는 기술의 한계와 적절한 구현 전략을 명확히 아는 것이 중요합니다.
오늘은 AI 모델의 근본적인 동작 원리부터 기존 머신러닝과의 차이점, 서비스 구현을 위한 아키텍처 전략, 그리고 AI 프로덕트를 기획하는 멘탈 모델까지 실무 관점에서 총정리해 보겠습니다.
1. 어텐션 알고리즘과 LLM의 본질
최근 AI 열풍의 핵심인 LLM(거대 언어 모델)과 임베딩 모델의 근간에는 어텐션 알고리즘이 있습니다. 이 알고리즘의 동작은 다음 세 단계로 요약됩니다.
- 입력 벡터화: 텍스트, 이미지 등 다양한 모달리티를 토큰화하고 벡터로 변환합니다.
- 벡터 변환: 모델 내 어텐션 연산을 통해 문맥을 파악하고 벡터를 변형합니다.
- 추상화 및 활용: 변형된 벡터를 바탕으로 다음 토큰의 조건부 확률 분포를 만들어 샘플링하거나, 변형 벡터 자체를 출력합니다.
결국 AI 엔지니어링의 기본은 "무엇을 어떻게 벡터화하고, 어떻게 변형하여, 어디에 활용할 것인가?"로 귀결됩니다.
이제는 디코더 신경망 구조 하나만으로 검색, 분류, 회귀, 생성이 모두 가능한 시대입니다.
전통적인 머신러닝은 끝났는가?
그렇지 않습니다. 문제의 성격에 따라 구형 ML과 LLM을 명확히 구분해야 합니다.
- 결정론적 문제: 결과에 대한 명확한 해석이 필요하거나, 제한된 도메인에서 고속으로 병렬 처리가 필요할 때 적합합니다.
예: 대출 승인 여부, 암 판정 분류 등 - LLM: 사람이 감당할 수 없는 엄청난 양의 입출력 엔트로피를 처리해야 하거나, 다양한 변형에 대응하는 '통합적 위임 업무'가 필요할 때 사용합니다.
왜 그런 결과가 나왔는지 완벽한 추적은 어렵지만, 확률적 생성 능력이 뛰어납니다.
2. AI 엔지니어링의 3계층과 실무 개발 전략
AI 서비스는 기존 웹 애플리케이션 구조에 AI 특화 요소가 더해진 형태를 띕니다.
① 인프라 레이어
GPU, 모델 서빙 서버, 벡터 데이터베이스 등 AI 구동을 위한 기반 시설입니다.
② 모델 레이어
어떤 파운데이션 모델을 사용할지, 데이터셋을 어떻게 구축할지 결정합니다. 모델의 사전 학습/사후 학습 구조를 이해해야 우리 서비스에 맞는 튜닝을 진행할 수 있습니다.
③ 애플리케이션 레이어
AI 모델은 응답 시간이 깁니다. 짧게는 수 초에서 길게는 1~2분이 소요됩니다.
-
백엔드: 이 긴 시간을 버티기 위해 SSE를 활용한 스트리밍 구조나 WebFlux 같은 비동기형 서버 환경이 필수적입니다.
전통적인 스레드 풀 방식으로는 커넥션이 금방 고갈됩니다. -
프론트엔드: 사용자가 지루하지 않도록 스트리밍 텍스트를 실시간으로 렌더링하고, 중간중간 마크다운을 파싱하는 등 UX 제어가 고도화되어야 합니다.
무조건 빨리 만들어라
AI 생태계에서는 모든 것을 직접 개발하려다가는 런칭 전에 사장됩니다.
RAG나 컨텍스트 증강 파트는 직접 짜기보다 Spring AI나 LangChain 같은 프레임워크를 적극 도입하고, 데이터셋 가공은 외주를 주며, 프론트엔드/백엔드 기본 골격도 오픈소스를 활용해 속도전을 펼쳐야 합니다.
3. 서비스에 적합한 LLM 선택과 API 활용법
모델을 직접 서빙할지, API를 사용할지 결정하는 것은 프로젝트의 비용과 직결됩니다.
-
메이저 업체 API: 가장 강력하고 범용적입니다.
단순히 텍스트 채팅만 제공하는 것이 아니라 데이터 분석, 이미지/음성 처리, 전용 에이전트 생성 등 방대한 기능을 제공합니다.
요금이 비싸다고 느껴질 수 있지만, 이 비용이 부담될 정도로 서비스가 성장했다면 이미 성공한 것입니다. -
특화 업체 API: 문서 인식, 특정 이미지 후처리 등에 특화된 모델들입니다.
예: 업스테이지의 문서 인식 API 메이저 모델과 병행해서 사용하면 비용은 낮추고 품질은 극대화할 수 있습니다.
예를 들어, AI 기반 문서 검색 시스템을 구축할 때 텍스트 추출은 특화 API에 맡기고, 요약 및 추론은 메이저 API에 맡기는 식입니다.
-
오픈소스 API: 서구권 중심의 상용 모델과 달리 특수 목적 19금 해제, 특정 페르소나 부여 등으로 튜닝된 모델을 저렴하게 이용할 수 있습니다.
-
자체 구축: VLLM, Ollama 등을 로컬 장비에 올려 서비스하는 방식입니다.
하지만 실서비스 수준의 동시 접속자를 감당하려면 엄청난 전력비와 인프라 비용 슈퍼카 한 대 값 이상 이 발생합니다.
프로토타입 연구나 테스트 목적이 아니라면 가급적 API 사용을 권장합니다.
4. AI 서비스를 기획하는 3가지 멘탈 모델
개발할 시스템의 방향성을 잡을 때, 다음 세 가지 접근 방식 중 하나를 선택하게 됩니다.
-
모델 중심 사고: "이 API가 이미지 인식과 음성 출력을 지원하네? 그럼 이걸 엮어서 시각장애인용 길안내 앱을 만들어볼까?" 모델이 제공하는 기능의 교집합을 찾아 새로운 서비스를 기획하는 방식입니다. 백지 상태에서 아이디어를 구상할 때 유리합니다.
-
서비스 중심 사고: "우리가 제공하던 기존 웹 서비스의 고객 센터에 AI 챗봇을 도입해서 응답률을 높이자." 기존 서비스의 편익을 극대화하기 위해 AI를 도구로써 결합하는 방식입니다.
가장 익숙한 접근이지만, 자칫하면 혁신적인 AI 서비스로 인식되지 못할 수 있습니다. -
에이전트 중심 사고: 서비스 자체를 하나의 자율적인 '에이전트'로 봅니다.
사용자의 컨텍스트를 파악하고, 필요한 API를 알아서 호출하며, 최종 결과물을 워크플로우 형태로 제공합니다.
아직 일반 B2C 사용자들에게는 생소한 개념이지만, B2B 기업 시장이나 복잡한 파이프라인 처리가 필요한 분야에서는 핵심 트렌드로 자리 잡고 있습니다.
5. 누구를 타겟팅할 것인가?
모든 것을 해내는 ChatGPT의 존재 때문에 범용 B2C 시장은 이미 레드오션입니다.
실제 매출이 발생하는 AI 특화 사업은 대부분 프로슈머와 B2B 도메인에 집중되어 있습니다.
코딩 에이전트, 전문 디자인 생성 도구, 판례나 증례를 검토해야 하는 막대한 인력 대체 시스템 등, 확실한 비용 절감이나 생산성 향상을 담보하는 영역에서 기회를 찾아야 합니다.
과거 IT 혁명이 기존 산업을 소프트웨어로 '재정의'했다면, 이제는 이미 존재하는 IT 서비스를 'AI 기반'으로 다시 재정의하는 시기입니다.
마치며
AI가 코드를 작성해 주는 시대가 왔지만, "무엇을 어떻게 만들 것인가"에 대한 아키텍처 설계와 제품의 정의는 여전히 인간 개발자의 고유 영역입니다.
설계 지식을 바탕으로 의존성을 제거하고, 문제를 작게 분할하여 AI에게 명확한 구현 지시를 내릴 수 있는 능력이 앞으로 소프트웨어 엔지니어의 가장 강력한 무기가 될 것입니다.
