AI Engineering이라는 새로운 길 위에서
컴퓨터 비전 개발자가 본 LLM 시대의 소프트웨어 엔지니어링 변화
이 글은 Pragmatic Engineer 뉴스레터 – AI Engineering in the Real World를 바탕으로, 제가 느낀 인사이트와 실천할 수 있는 방법을 정리해 본 글입니다.
AI Engineering이라는 단어는 이제 익숙하지만, 여전히 정의가 모호합니다. 머신러닝 모델을 만드는 ML 엔지니어를 말하는 걸까요? LLM을 다루는 데이터 과학자? 아니면 LLM 위에 프로덕트를 얹는 소프트웨어 엔지니어?
Chip Huyen은 자신의 저서 『AI Engineering』에서 이 용어를 “LLM을 활용한 응용프로그램을 만드는 일”로 정의합니다. 전통적인 소프트웨어 엔지니어링과 머신러닝 엔지니어링 사이 어딘가에 존재하지만, 실상은 소프트웨어 엔지니어링에 훨씬 가깝습니다. 특히 API 기반으로 LLM 기능을 끌어다 쓰는 지금의 현실에서는 더욱 그렇습니다.
AI Engineer는 어떤 프로덕트를 만드는가?
보고서에는 총 7개의 회사 사례가 소개되었는데, 공통점은 ‘기존 제품의 일부분에 AI를 더한 경우’와 ‘AI를 핵심 기능으로 삼는 경우’로 나뉜다는 점입니다. 흥미로운 것은, 많은 회사가 RAG (Retrieval-Augmented Generation) 기반의 기능을 만들고 있다는 점입니다.
Incident.io: 실시간 사고 대응 중 AI가 노트를 정리하고, 로그와 이전 사건을 분석해 원인을 제시합니다.
Sentry: 버그를 추적하고 코드 패치를 자동 제안하는 Autofix 기능을 LLM 기반으로 제공합니다.
Wordsmith: 계약서를 분석하고 수정 제안을 표시하는 '법률 AI 도구'를 제공합니다.
Elsevier: 각 부서의 독립적인 시도를 통합해, 전사적인 RAG 플랫폼을 구성했습니다.
DSI (HR 스타트업): 직원 피드백을 요약해 주는 기능으로 AI를 처음 도입했습니다.
저는 주로 Computer Vision 분야에서 일해왔고, 최근에는 이미지 초해상화(Super-resolution) 모델에 LoRA(Low-Rank Adaptation)를 적용해 도메인 특화 성능 향상을 시도한 경험이 있습니다. 이 과정에서 느낀 건, 복잡한 전체 모델을 새로 학습시키기보다 ‘작고 명확한 문제 정의’를 기반으로 한 경량화 전략이 훨씬 실용적이라는 것이었습니다.
이와 유사하게, 위 사례들 역시 거대한 LLM을 직접 다루기보다는 기존 워크플로우에 잘 녹이는 구조 설계에 더 집중하고 있다는 점이 인상 깊었습니다.
개발자에서 AI Engineer로 전환하기
글에서 특히 인상 깊었던 사례는 25년 차 백엔드 개발자 Ryan Cogswell입니다. 그는 외부 AI 업체의 복잡한 설계 제안 대신, 직접 자료를 찾아보며 사내 첫 AI 기능을 만들었습니다.
“처음 제안받은 아키텍처는 SageMaker, Langfuse, Lambda, DB 두 개에 다양한 파이프라인을 포함해, 도입비용이 기존 인프라 전체보다 높았습니다.”
하지만 결국 그는 AWS Bedrock + PostgreSQL(pgvector) + Cohere Embedding + Java 백엔드 + React 프런트엔드 조합으로, 단순하고 실용적인 구조를 완성했습니다.
아직 저는 LLM을 본격적으로 활용해 본 적은 없지만, 이 사례에서 중요한 건 ‘스택의 복잡성’이 아니라 개발자가 문제를 얼마나 자기 언어로 풀어낼 수 있느냐라는 점입니다.
CV 모델을 다루면서도 경험한 바와 같이, LoRA든 ONNX export든, 실제 적용은 복잡한 논문보다 훨씬 더 ‘단순화 능력’이 요구됩니다. Ryan처럼 처음엔 모르더라도, 읽고 만들고 확인해 보는 실천이 결국 길을 만듭니다.
기술 스택은 다양하지만, 공통점은 있다
7개 회사의 기술 스택을 보면 다음과 같은 트렌드가 눈에 띕니다.
AWS Bedrock + Postgres + pgvector 조합은 사실상의 표준처럼 보입니다.
LangChain은 일부 회사에서 사용되지만, 오히려 안 쓰고 직접 구성하는 사례도 많습니다.
고성능이 필요한 경우엔 Groq와 같은 초고속 응답 AI 인프라로 전환하는 경우도 있습니다.
Fine-tuning까지 진행하는 회사는 거의 예외 없이 PyTorch + CUDA + GCP or NVIDIA GPU를 씁니다.
Vision 쪽에서도 고성능 inference가 필요한 경우, 결국엔 ONNX, TensorRT, FP16/INT8 최적화 같은 '하드웨어 친화적인 설계'가 필요해집니다.
AI Engineering도 마찬가지로, 클라우드 API로 시작하되, 성능·비용 문제가 커지면 자연스럽게 직접 세팅하는 방향으로 이동하게 됩니다.
이 흐름은 CV든 NLP든 동일한 ‘스케일의 단계’라는 점에서 유사합니다.
LLM을 다룰 때 발생하는 새로운 엔지니어링 이슈
기존 소프트웨어 개발과는 다른 점이 여러 가지 있지만, 가장 대표적인 것은 다음 네 가지였습니다.
비결정성 (Non-determinism): 같은 입력에도 매번 다른 결과가 나옵니다.
Evaluation: 결과가 정답이 있는 문제가 아니므로 정량적 평가가 어렵습니다.
Latency: 모델이 클수록 응답속도가 느립니다.
비용: 사용량이 늘면 곧바로 비용이 문제로 떠오릅니다.
Vision 쪽 inference는 보통 deterministic 합니다. 같은 이미지 입력에 대해 항상 같은 결과가 나오죠. 하지만 GAN 기반 모델이나 diffusion 기반 생성 모델에서는 LLM과 유사하게 random seed나 temperature 같은 파라미터에 따라 결과가 달라지기도 합니다.
그래서인지 LLM의 ‘비결정성’ 문제는 전혀 낯설지 않았고, 오히려 결과 다양성을 어떻게 UX로 풀어낼지가 중요한 고민 포인트가 될 거라 생각합니다.
도메인은 달라도, 본질은 같다
이 글을 통해 얻은 가장 큰 통찰은 이렇습니다.
“AI Engineer는 새로운 직무가 아니라, 기존 개발자가 AI를 프로덕트에 녹이는 방법을 익히는 과정이다.”
저처럼 Computer Vision 기반의 경력을 가진 개발자라면, LLM이라는 도구는 아직 생소할 수 있습니다. 하지만 결국 중요한 건 모델이 아니라 문제 정의, 아키텍처가 아니라 흐름을 설계하는 감각입니다.
지금까지의 경험을 발판 삼아, 텍스트 기반 AI로의 확장을 하나의 성장 경로로 삼을 수 있다면, AI Engineering이라는 흐름은 더 이상 낯설지 않을 것입니다.
