
최근 IT 업계의 가장 큰 화두는 단연 AI와 대형 언어 모델 입니다.
하지만 많은 이들이 기술의 겉모습이나 화려한 결과물에만 집중할 뿐, 이 기술이 기존 머신러닝과 어떻게 다르며 소프트웨어 개발과 비즈니스의 구조를 어떻게 바꾸고 있는지 본질적으로 이해하지 못하곤 합니다.
기술 패러다임이 바뀔 때 엔지니어와 기획자가 견지해야 할 시각은 '현상'이 아닌 '원리'를 보는 것입니다.
어텐션 알고리즘의 본질부터 시작해, AI 기반 사업의 확장성과 변화하는 개발 프로세스까지 깊이 있게 파헤쳐 보겠습니다.
모든 현대적 AI 아키텍처의 핵심에는 어텐션 알고리즘이 있습니다.
어텐션의 본질을 가장 직관적으로 요약하면 다음과 같은 세 단계의 데이터 추상화 과정입니다.
LLM과 임베딩 모델이 구동되는 정밀한 메커니즘을 살펴보면 이 원리가 명확해집니다.
토큰화: 텍스트, 이미지 등의 멀티모달 데이터를 모델이 처리할 수 있는 최소 단위인 '토큰'으로 쪼갭니다.
벡터화: 분리된 토큰들을 고차원 공간상의 숫자인 '벡터'로 변환합니다. 이 벡터는 데이터의 고유한 의미적 특징을 담고 있습니다.
벡터 변환과 어텐션 연산: 모델 내부에서 어텐션을 포함한 수많은 행렬 연산이 수행되며, 이 과정에서 주변 토큰들과의 관계성을 반영하여 초기 벡터를 계속해서 '변형'해 나갑니다.
최종 활용:
LLM: 변형된 최종 벡터를 기반으로 다음에 올 토큰의 조건부 확률 분포를 계산하고, 이 분포 안에서 다음 토큰을 확률적으로 '샘플링'하여 문장을 생성합니다.
임베딩 모델: 변형된 벡터 그 자체를 최종 출력물로 반환하여 시맨틱 검색이나 비교에 활용합니다.
이 원리를 이해하면 세상의 모든 문제를 완전히 새로운 시각으로 바라볼 수 있습니다.
어떤 도메인의 문제를 풀든 결국 아래의 세 가지 질문으로 귀결되기 때문입니다.
결과적으로 잘 설계된 디코더 신경망 구조 하나만 있으면 검색, 분류, 회귀, 생성 등 과거에는 각각 별도의 알고리즘으로 풀던 문제들을 모두 해결할 수 있게 되었습니다.
다만, 모든 곳에 무조건 거대한 신경망을 쓰는 것이 정답은 아니며, 상황에 따라 '구형 ML' 구조를 적절히 배합해야 하는 선택의 기로에 서게 됩니다.
현업에서 문제를 해결할 때 구형 ML을 써야 할지, 아니면 LLM을 도입해야 할지 결정하는 것은 리소스 관리와 아키텍처 설계의 핵심입니다.
두 기술은 지향점과 특성이 완전히 다릅니다.
구형 로지스틱 회귀, 의사결정나무 등 은 다음과 같은 명확한 강점과 사용처를 가집니다.
고속 실행이 필수적인 환경: 어텐션 계열 아키텍처에 비해 연산량이 압도적으로 적습니다. CPU 환경에서도 밀리초() 단위로 실행이 가능하며, 순차적 토큰 생성이 아닌 병렬 텐서 연산이 기본이므로 서빙 비용이 매우 저렴합니다.
입출력 정규화와 결정론적 문제: 대출 승인 여부 판별, 암 진단 등 문제 정의가 명확하고 정답이 결정론적인 경우에 적합합니다. 제한된 도메인의 정규화된 입력값만 받기 때문에 범용성은 떨어지지만, 입력을 해석할 때 발생하는 엔트로피 가 거의 없습니다.
신경망의 최종 출력 구조를 그대로 사용하여 출력단에서의 해석 엔트로피도 최소화됩니다.
데이터셋이 제한적인 경우: 수천에서 수만 개의 샘플만으로도 충분히 학습이 가능합니다. LLM 역시 아주 작은 크기의 모델에 얕은 레이어로 LoRA 학습을 진행할 수 있지만, 데이터 효율성 측면에서는 한계가 있습니다.
결과에 대한 설명 가능성: 금융이나 의료 분야처럼 결과의 이유를 추적해야 할 때 필수적입니다. 예를 들어 로지스틱 회귀는 각 피처의 가중치()를 확인하여 "왜 이러한 분류 결과가 나왔는지" 명확하게 설명할 수 있습니다.
반면 LLM은 복잡하고 모호한 현실 세계의 문제를 다룰 때 진가를 발휘합니다.
확률적 샘플링 기반의 유연성: 매 실행마다 고정된 답을 내는 것이 아니라 확률적 분포 내에서 샘플링하므로, 인간의 언어처럼 수많은 변형과 예외가 존재하는 현실 세계의 데이터에 유연하게 대응합니다.
높은 입출력 해석 능력: 인간이 일일이 규칙으로 감당할 수 없는 수준의 방대한 입출력 해석 엔트로피를 모델 자체가 흡수합니다.
통합적 위임 업무: 구체적인 규칙을 지정하지 않고 "알아서 적절히 잘해봐"와 같은 형태의 통합적인 업무 위임이 가능합니다.
단순한 문제 해결을 넘어, 문제 자체를 스스로 정의하고 구조화하는 단계까지 수행할 수 있습니다.
요약하자면, ML은 정해진 규칙과 데이터를 다루는 '결정문제'에 가깝고, LLM은 문맥과 복잡성을 다루는 '해석문제'에 가깝다고 볼 수 있습니다.
AI 서비스를 설계할 때 자체적인 신경망을 구축할 것인가, 아니면 범용 프론티어 모델을 그대로 두고 컨텍스트를 주입할 것인가의 기술적 핵심 전략을 세워야 합니다.
자체 데이터를 확보하여 가중치를 직접 업데이트하는 방식은 초기 비용이 크게 발생합니다.
ML의 경우 데이터를 확보하고 정제하는 데 많은 예산과 인력을 배정해야 합니다.
LLM을 가인튜닝할 경우의 장단점은 다음과 같습니다.
인퍼런스 효율화: 모델 자체가 지식을 내포하게 되므로, 추론 시점에 프롬프트에 구구절절 배경지식을 적어줄 필요가 없습니다.
이는 컨텍스트 토큰 사용량을 크게 줄여주고 실행 속도를 고속화합니다.
출력 제어: 학습된 범위 내에서 비교적 정확하고 일관된 형태로 출력을 통제할 수 있습니다.
모델 내부의 가중치를 건드리지 않고 외부에서 필요한 정보를 주입하는 방식입니다.
런타임의 다양성: RAG 나 MCP 등을 활용하여 런타임 환경에서 실시간으로 다양한 데이터 소스를 연결하고 컨텍스트를 확장합니다.
에이전트와의 시너지: 모델 튜닝 배제에 따른 할루시네이션이나 판단 미스는 피드백 루프를 가진 '에이전트' 아키텍처로 보완하는 방향으로 진화하고 있습니다.
비즈니스 레이어에서 AI를 도입할 때는 서비스의 핵심 도메인에서 AI가 차지하는 비중과 비용 구조를 엄밀히 따져야 합니다.
주역 도메인이 AI 중심인 경우: ChatGPT와 같은 채팅형 서비스, 비디오/이미지 생성 등 특수 모달 생성 서비스, AI 기반의 전용 교육 및 추천 시스템, AI가 콘텐츠를 직접 생산하는 서비스가 이에 해당합니다. 검색과 질의응답 자체를 거대 모델로 수행하는 서비스들입니다.
서브 도메인에 신경망이 사용되는 경우: 주요 비즈니스 로직은 전통적인 소프트웨어로 돌아가되, FAQ나 Q&A에 챗봇이 붙거나, 상품 추천 및 자동 댓글 지원 등에 AI가 접목되는 형태입니다. 백오피스 자동화 기능의 일부를 AI로 대체하는 것도 포함됩니다.
작은 부분에만 AI를 사용하는 경우: 제목 자동 생성, 환영 인사말 작성, 폼 작성 시 도움말 생성 같은 부가적인 기능에만 API 형태로 가볍게 활용하고, 분류나 의사결정 등 주요 로직은 전통적인 ML이나 하드코딩된 규칙을 사용하는 단계입니다.
어떤 도메인이 AI 사업으로서 높은 가치를 가질까요? 시장에서 유의미한 비즈니스는 대략 네 가지 범주로 분류됩니다.
AI가 아니면 안 되는 도메인: 코딩 에이전트를 비롯한 자율적 전문가 시스템이나 고도화된 컨텐츠 생성 분야처럼, 기술 자체가 상품인 영역입니다.
사람이 할 수도 있지만 막대한 인력이 필요한 도메인: 판례나 증례, 가이드를 매번 검토해야 하는 업무, 고려사항이 계속 변화하는 차량 배차, 창고 관리, 탄약 관리 등의 물류/작전 수행, 혹은 농업/범죄/보안/주차 관제 등 실시간 모니터링 시스템입니다.
해결이 어렵거나 비용이 큰 문제의 해법을 요구하는 도메인: 기존 도메인의 전통적인 수식으로는 난해했던 분야에서 계산량과 경우의 수를 기하급수적으로 줄여 새로운 경로를 발견해내는 영역입니다.
존재하는 서비스의 재정의: 과거의 스타트업들이 금융이나 배달 등 기존 오프라인 도메인을 'IT 기반'으로 재정의했다면, 이제는 바둑, 피팅, 소프트웨어 개발 등의 영역을 'AI 기반'으로 완전히 재정의하는 비즈니스입니다.
AI 사업이 지속 가능한지 판단하려면 결국 "새로운 매출을 일으키는가?"에 답할 수 있어야 합니다.
제품 차별화 사례: 과거 샤오미가 실용적인 IoT 가전으로 가성비 차별화를 이뤄냈다면, 최근에는 하드웨어에 MimoV2 같은 옴니모달 강화모델을 탑재해 AI 특화 가전으로 차별화를 꾀합니다.
갤럭시 AI 역시 이미지 편집, 실시간 번역, 통화 녹음 요약 등 실생활 체감 기능 위주로 전개해 제품 우위를 점하고 있습니다.
수익 모델의 변화: 클로드를 비롯한 AI 전문 기업들은 비즈니스 구조상 사용자가 최대한 많은 토큰을 소비하도록 만드는 서비스를 연구합니다. 기술의 발전 경로가 단순한 '코드 힌트'에서 '바이브 코딩', '멀티 에이전트', 그리고 시스템 전체를 감싸는 '하네스' 형태로 진화하는 이유도 이와 궤를 같이합니다.
그러나 현시점의 AI 사업은 몇 가지 중대한 문제에 직면해 있습니다. AI가 대부분의 범용적 문제를 쉽게 해결해 주기 때문에 역설적으로 독점적인 '새로운 사업 창출'이 어려워졌습니다.
바이브 코딩의 영향으로 IT 서비스 제품을 만드는 진입장벽이 낮아져 시장에 너무 많은 경쟁자가 쏟아지고 있으며, 유저들은 과거 스마트폰 초창기만큼 서비스를 열성적으로 소비하지 않습니다.
따라서 현재의 시장은 비용 전환의 초기 단계로 볼 수 있습니다.
즉, 완전히 새로운 비즈니스를 만들기보다, 기존 도메인과 운영 프로세스는 그대로 유지한 채 AI를 도입하여 기존의 비용 구조를 AI 비용 구조로 전환함으로써 효율성을 극대화하는 전략이 주류를 이루고 있습니다.
AI가 코드를 짜주는 시대, 소프트웨어 엔지니어링의 본질은 어떻게 변하고 있을까요? 이제 엔지니어의 역할은 '코드를 타이핑하는 것'에서 '문제를 분할하고 구조를 설계하는 것'으로 완전히 이동했습니다.
코드는 AI가 작성하지만, 역설적으로 "무엇을 만들어야 할지" 정의하는 능력이 훨씬 중요해졌습니다.
만약 큰 윤곽만 잡고 제품의 개념이나 정의조차 AI에게 전적으로 맡겨버린다면 다음과 같은 위험에 직면하게 됩니다.
AI에게 더 많은 판단을 맡길수록, AI는 무난하고 안정적인 기존 구현 방식을 따를 가능성이 올라갑니다.
동시에, 겉보기에는 그럴듯하지만 내부 구현 상세는 완전히 엉망인 '할루시네이션 코드'가 섞일 확률도 높아집니다.
모든 코드가 확률적으로 생성되기 때문에 전체 시스템의 유지보수 일관성이 깨지기 쉽습니다.
이를 극복하기 위해 엔지니어에게 요구되는 능력은 구체적인 구현 지식 자체보다는 상세하고 명확한 구현 지시를 내릴 수 있는 설계 능력입니다.
특히 소프트웨어 공학의 고전적 원칙인 의존성 제거와 독립된 작은 문제로의 분할 역량이 핵심입니다.
시스템을 잘게 쪼개어 의존성을 격리하면, AI가 맥락을 파악하기 쉬워져 오류 없이 정확한 코드를 구현해 낼 수 있고 전체 시스템의 유지보수성도 향상됩니다.
이러한 패러다임 속에서 개발자는 어떤 지식을 내재화해야 할까요? 단순히 API 사용법을 아는 것을 넘어 다음 네 가지 계층의 이해가 필요합니다.
┌─────────────────────────────────────────────────────────┐
│ 1. 저수준 신경망 모델별 지식 (LLM과의 고도화된 상담 능력) │
├─────────────────────────────────────────────────────────┤
│ 2. 트랜스포머 아키텍처 원리 (동작 메커니즘 기반의 지시) │
├─────────────────────────────────────────────────────────┤
│ 3. 모델 튜닝 및 학습의 이해 (데이터셋 구성 및 특성 파악) │
├─────────────────────────────────────────────────────────┤
│ 4. 에이전트 및 컨텍스트 증강 (RAG, MCP 아키텍처 설계) │
└─────────────────────────────────────────────────────────┘
저수준 신경망 모델별 지식: 깊이 있는 도메인 지식이 있어야 LLM에게 고도화된 질문을 던지고 올바른 답변을 골라낼 수 있습니다.
트랜스포머 아키텍처의 이해: 과거 개발자들에게 "TCP/IP나 RDB의 물리적 저장 구조를 왜 이해해야 하는가?"라고 물었던 것과 같은 맥락입니다.
모델을 밑바닥부터 직접 개발하지 않더라도, 트랜스포머의 동작 원리를 알아야 LLM이 왜 특정 상황에서 한계를 보이는지 이해하고 올바른 방향으로 지시할 수 있습니다.
이는 다양한 모델 중 최적의 모델을 선택하고 서비스에 깊이 있게 활용할 때 강력한 무기가 됩니다.
모델 튜닝 및 학습의 이해: 각 모델의 파라미터 특성과 용도를 파악하고, 학습 종류별 데이터셋 구조를 이해하여 필요한 경우 자신만의 데이터 파이프라인을 구성할 수 있어야 합니다.
에이전트 및 컨텍스트 증강 분야의 이해: 모델 외적인 AI 시스템 아키텍처를 공부하는 영역입니다.
초기 AI 서비스들은 프론티어 기업들이 만들어 둔 거대한 단일 에이전트 시스템에 의존하는 형태였으나, 시장은 점차 비즈니스 맞춤형 커스텀 에이전트나 독자적인 RAG 구조를 촘촘하게 구축해 나가는 단계로 진입하고 있습니다.
마지막으로 엔지니어는 AI 제품 자체의 속성과 UI/UX의 변화인 AX를 이해해야 합니다.
현재 시장의 AI 제품은 크게 미디엄과 같은 'AI 생성 콘텐츠 소비형 플랫폼'이나, Cursor/Claude 같은 '생산성 도구'로 양분됩니다.
특히 코딩 툴이나 이미지/음성 생성 도구 같은 생산성 제품들은 단순히 독립된 앱으로 쓰이는 것을 넘어, 자사 서비스 내부의 핵심 파이프라인으로 채택되기도 합니다.
개발팀 전체를 대체하는 수준의 툴을 프로세스에 녹여내는 시도도 빈번해지고 있습니다.
이 과정에서 중요한 것이 바로 UI 지식의 재정의, 즉 AX입니다.
AI 시대의 사용자 인터페이스는 과거의 그래픽 UI(GUI)와 완전히 다른 구조를 가집니다.
이제는 사용자가 고정된 버튼을 누르는 것을 넘어, 자유로운 입력과 유연한 피드백을 주고받아야 하므로, UX 설계 자체가 AI의 확률적 특성에 맞춰 유기적으로 변화해야 합니다.
어텐션 알고리즘에서 출발한 벡터의 변환 과정은 단순한 기술적 기교를 넘어, 세상의 모든 데이터를 추상화하고 다루는 새로운 철학을 제시하고 있습니다.
비즈니스 측면에서는 무작정 거대한 모델을 쫓기보다 ML과 LLM의 비용 대비 효과를 냉정하게 따져 비용 구조를 혁신해야 하며, 소프트웨어 엔지니어로서 우리는 코드 작성 자체를 AI에게 위임하는 대신 전체 시스템의 아키텍처를 정교하게 분할하고 설계하는 '설계자'로서의 역량을 갈고닦아야 합니다.
기술의 내면을 관통하는 원리를 파악할 때, 비로소 끊임없이 쏟아지는 새로운 기술 트렌드 속에서 흔들리지 않는 기준을 세울 수 있을 것입니다.