옅어지는 경계에서, AI 엔지니어로서의 나의 무기가 뭘까?

요즘 일하면서 자주 드는 생각이 있습니다. 직군 사이의 경계가 점점 옅어지고 있다는 생각입니다.

몇 년 전에는 AI 엔지니어가 모델을 만들고 서빙까지 하면, 그걸 실제 서비스에 붙이는 건 다른 직군의 엔지니어가 맡는 경우가 많았습니다. 그런데 요즘은 AI 엔지니어가 모델을 서비스에 직접 붙이고, 필요하면 서비스 코드까지 직접 수정하는 일이 많아졌습니다. 저 역시 모델을 만들고 서빙하는 걸 넘어, 서비스 쪽 코드를 직접 고치는 일들을 자연스럽게 하고 있습니다.

반대로 백엔드, 프론트엔드, 데이터 분석가, PM 등 다른 직군분들도 본업뿐만 아니라, 필요하면 AI 기능도 직접 만들어보는 일이 자연스러워졌습니다. LLM API로 프롬프트 몇 줄이면 그럴듯한 AI 기능이 뚝딱 만들어지는 건 물론이고, 요즘은 AI와 대화하면서 데이터를 준비하고 모델을 직접 학습시키는 케이스도 많이 늘었습니다. 예전에는 AI 엔지니어의 영역이라고 여겨지던 모델 학습까지, 이제는 AI의 도움을 받으면 누구나 시도해볼 수 있는 일이 된 것 같습니다.

그래서 요즘 이런 생각이 들곤 합니다. 이렇게 옅어져 가는 경계에서, AI 엔지니어인 나는 어떤 걸 무기로 가져갈 수 있을까? 그리고 반대로 무엇이 부족할까? 이번 글에서는 이에 대한 저의 생각을 회고처럼 정리해보려고 합니다.

AI 엔지니어로서 가져갈 수 있는 무기

AI를 만드는 건 원래 제 메인 역할이니, 다른 직군 분들보다 AI를 더 잘 만들 수 있다는 건 어찌 보면 당연한 얘기입니다. 물론 요즘은 AI가 많은 걸 도와주지만, 무엇을 물어봐야 하는지, AI가 내놓은 답이 맞는지를 판단하는 건 여전히 경험에서 나온다고 생각합니다. 그래서 “AI를 더 잘 만든다”는 말을 조금 더 쪼개서, 구체적으로 어떤 감각과 습관, 경험을 제가 가지고 있는지를 정리해봤습니다.

1. 확률적 시스템을 다루는 태도

전통적인 소프트웨어 시스템은 기본적으로 deterministic한 세계입니다. 같은 입력이 들어오면 같은 결과가 나와야 하고, 그렇지 않으면 버그입니다. 반면 AI는 틀릴 수 있다는 게 전제입니다.

AI를 오래 해오다 보니 “AI는 몇 % 정도는 무조건 틀릴 거다”를 깔고 시스템을 설계하는 게 자연스럽습니다. 예를 들면 이런 것들입니다.

• threshold를 어디에 둘지, precision과 recall 중 어느 쪽을 더 챙길지 (미탐과 오탐 중 뭐를 더 중요하게 여길지)
• confidence가 낮은 케이스는 룰이나 사람 검수(human-in-the-loop)로 넘기는 fallback 설계
• 모델이 틀렸을 때 서비스에 어떤 영향이 가는지, 그 비용이 어느 쪽이 더 큰지

2. 평가

AI를 해왔던 사람들에게는 모델 성능 평가가 너무 당연하지만, 다른 직군분들에게는 생소할 수 있습니다. train / valid / test로 나누는 기본적인 세팅조차도 저희에겐 당연한 거지만, AI를 하지 않았던 분들에게는 낯선 개념일 수 있습니다.

그리고 LLM 시대에 점점 더 평가가 중요해졌다고 느낍니다. LLM을 붙이면 몇 개 넣어보고 “오 잘 되네?” 하고 배포까지 가는 경우가 생각보다 많습니다. 하지만 프롬프트를 단 한 줄 바꿨을 때도 다른 케이스가 깨지지는 않는지 꼭 체크를 해봐야 합니다.

그래서 저는 LLM 기반 기능을 만들 때 자연스럽게 아래 항목들을 챙깁니다.

• 대표 케이스와 엣지 케이스를 모은 eval set 구축
• 각 태스크별로 측정해야하는 평가 metric 설정
• 프롬프트나 모델을 바꿀 때마다 돌릴 수 있는 평가 자동화
• LLM-as-a-Judge를 쓴다면, 그 Judge와 사람 평가 간의 상관관계 검증

3. 데이터에 대한 감각

AI를 하다보면 데이터는 떼려야 뗄 수 없는 관계가 됩니다. 그러다 보니 데이터의 양, 퀄리티, 밸런스 등에 대한 경험적인 감각이 생깁니다.

• 이 정도 데이터로 가능할까? 목표로 하는 태스크가, 지금 가진 데이터 양으로 학습이 가능한지, 얼마나 더 모아야 가능할지에 대한 감이 있습니다.
• 전처리: 중복 제거(de-dup), 노이즈 필터링, 데이터 augmentation 같은 작업을 자연스럽게 떠올립니다.
• 분포: class imbalance는 없는지, train과 test 사이에 data leakage는 없는지 자연스럽게 체크합니다.

다른 직군 분들과 대화하다보면 위와 같은 문제들에 대해서 가장 많은 질문을 받습니다. “어느 정도 데이터가 있어야 학습이 되나요?”, “이 데이터로 학습이 가능할까요?”, “왜 이 데이터로 학습이 잘 안 됐을까요?”와 같은 질문들입니다. 이런 질문들에 대해서 저는 경험적으로 답변을 드릴 수가 있는데, 이런 경험적 감각이 제 무기 중 하나라는 걸 느끼곤 합니다.

4. 에러 분석 습관

지표는 가장 중요하게 봐야 하는 값입니다. 하지만, 지표만으로는 볼 수 없는 정보들이 있다고 생각합니다. 지표가 몇 점 나왔는지만 보고 끝내지 않고, 모델이 틀린 샘플을 직접 하나하나 까보는 습관이 있습니다. 틀린 케이스를 모아보면 패턴이 보이고, 그 패턴에 따라 다음 액션이 달라집니다.

• 특정 유형의 데이터가 부족하다 → 데이터를 추가해야 한다
• 모델이 애매해하는 경계 케이스가 많다 → 라벨 기준 정리 또는 threshold 조정 또는 경계 케이스 데이터 추가해서 학습
• 룰로 쉽게 걸러지는 케이스다 → 굳이 모델로 풀지 않고 룰 추가

그리고 이런 에러를 분석하는 습관이 최종적으로 가장 중요한 지표를 더 높여주는 선순환으로 이어진다고 생각합니다.

5. AI를 적재적소에, 최대한 가볍게

어떤 문제에는 AI가 굳이 필요 없고, 어떤 문제는 AI를 쓰면 너무 쉽게 해결됩니다. 이 문제가 AI로 풀 수 있는 문제인지, AI로 풀어야 하는 문제인지에 대한 경험과 직관이 무기라고 생각합니다.

그리고 AI로 풀어야 한다면, 최대한 가벼운 모델과 방법으로 푸는 쪽을 선호합니다. 요즘은 일단 LLM API를 호출하는 게 가장 쉬운 선택지지만, 비용과 latency를 생각하면 항상 정답은 아닙니다.

• 해시나 간단한 이미지 처리, 혹은 가벼운 모델을 1차 필터로 써서 대부분을 거르고, 애매한 것만 무거운 모델로 넘기는 cascade 구조
• 범용 LLM 대신 작은 모델을 fine-tuning해서 빠르고 싸게 처리하기
• 모델 안에서도 필요한 연산만 하기: 예를 들어 OCR 모델로 텍스트 존재 유무만 알면 되는 경우, detection 단계에서 끝내고 글자 인식(recognition)은 스킵

6. AI 구조에 대한 이해

AI를 직접 구현하고 만들어본 경험이 있다 보니, 모델 내부 구조에 대한 이해가 실제 업무에서 도움이 될 때가 많습니다.

• 속도 최적화: TensorRT, OpenVINO 같은 런타임으로 모델을 변환하고, batching이나 quantization으로 처리량을 올리는 작업. 특정 연산 부분을 스킵한다던가 따로 최적화.
• 모델 동작에 대한 이해: LLM이 토큰을 생성할 때 KV Cache가 어떻게 동작하는지 알면, 프롬프트 앞부분을 고정해서 캐시 효율을 높인다든가 하는 최적화를 자연스럽게 떠올릴 수 있듯이 모델이 어떻게 동작하는지를 이해하는게 도움이 될 때가 많습니다.
• 병목 파악: 모델 추론이 느릴 때 이게 연산 문제인지, 메모리 문제인지, 아니면 전후처리 문제인지를 구분할 수 있습니다.

7. 논문을 읽는 습관과 빠른 정보 습득

AI 분야는 변화 속도가 정말 빠릅니다. 몇 달 전의 SOTA가 금방 옛날 방법이 되기도 하고, 새로운 모델과 기법이 거의 매주 쏟아져 나옵니다. AI 엔지니어로 일하다 보면 새로운 논문이나 오픈소스를 탐구하는게 자연스럽게 습관이 됩니다.

그리고 이 습관이 경계에서 일할 때 꽤 큰 무기가 됩니다.

• 누군가는 이 문제를 풀었었겠지: 비슷한 문제를 누군가 이미 풀어둔 경우가 많아서, 바닥부터 고민하기 전에 “이런 문제엔 이런 방법들이 있었지” 하고 후보를 먼저 떠올릴 수 있고, 누군가 이런 문제를 풀지 않았을지 조사부터 해보는 습관이 있습니다.
• 화제성과 실체를 구분: 새로운 모델이나 기법이 나오면 화제성에 비해 실제로는 특정 조건에서만 잘 되는 경우도 많습니다. 논문의 실험 세팅과 한계를 보는 습관이 있으면, 우리 문제에 실제로 쓸 만한지 판단할 수 있습니다.
• 빠른 검증과 적용: 새로 나온 모델이나 기법을 빠르게 검증해보고, 쓸 만하면 실제 서비스에 바로 녹여볼 수 있습니다.

AI의 도움으로 누구나 모델을 만들 수 있게 됐지만, 지금 어떤 방법이 가장 적절한지, 새로 나온 방법이 정말 좋은 방법인지를 체크하는 건 여전히 이런 습관에서 나온다고 생각합니다.

반면에, 아직 부족한 것

장점만 늘어놓으면 반쪽짜리 회고가 될 것 같아서, 경계에서 일하며 느낀 부족한 점도 솔직하게 적어보려고 합니다. 특히 요즘 가장 많이 맞닿아 있는 서비스 개발과 인프라 쪽에서 많이 느끼고 있습니다.

1. On-call과 장애 대응

가장 크게 느끼는 부분입니다. 서비스 코드까지 직접 다루게 되면서 장애 대응이나 on-call도 경계 안으로 들어왔습니다. 모델 쪽에서 생긴 문제는 괜찮습니다. 어디서 문제가 생겼는지, 어떻게 고쳐야 하는지 대부분 감이 옵니다.

문제는 서비스 쪽, 그중에서도 제가 잘 모르는 시스템에서 생긴 문제를 대응해야 할 때입니다. 알림이 울렸는데 이게 어느 서비스에서 시작된 건지, 어떤 로그와 지표부터 봐야 하는지, 롤백을 해야 하는 상황인지조차 판단이 잘 안 서는 경우가 있습니다. 대시보드의 여러 그래프와 숫자 중에서 뭐를 봐야하는지, 어떤 인프라의 로그를 확인해야 되는지 등.. 백엔드 엔지니어분들에게는 경험으로 쌓여 있는 이 감이 저에게는 아직 부족합니다.

솔직히 아직은 이런 상황에서 AI의 도움 없이는 대응이 쉽지 않습니다. 😅 로그와 에러 메시지를 AI에게 보여주며 원인을 좁혀가고, 처음 보는 시스템의 구조를 파악해가며 겨우겨우 처리하는 수준입니다. 실제로도 가장 부담되고 어려운 부분입니다.

2. 백엔드 인프라에 대한 경험

이전에 창업했던 회사에서 백엔드 경험을 조금 쌓긴 했습니다. 다만 기초부터 차근차근 배운 게 아니라, 당장 돌아가고 있는 시스템을 유지보수하고 새로운 기능을 추가하는 위주로 일하다 보니 “돌아가게 만드는 법”은 알아도 “왜 이렇게 구성하는지”에 대한 이해가 부족합니다.

그래서 Kafka, Grafana처럼 백엔드 엔지니어분들에게는 당연하게 다뤄오던 것들이 저에게는 아직 생소한 부분이 많습니다. 쓸 줄은 알아도, 어떤 상황에서 문제가 생기는지, 더 나은 구성은 무엇인지까지 판단하려면 경험을 더 쌓아야 한다고 느낍니다.

가끔 여러 인프라 용어들이 오가는 회의에 들어가면 저도 모르게 조용해집니다. 대충 무슨 얘기인지는 따라가더라도, 그 위에 제 의견을 얹을 만큼의 이해는 아직 부족하다 보니 듣는 쪽에 머무르게 되곤 합니다.

3. DB 설계

DB를 붙여서 돌아가게 만드는 건 어렵지 않습니다. 하지만 더 좋은 DB 구조를 설계하는 건 또 다른 문제였습니다. 데이터가 쌓이고 요구사항이 바뀌었을 때도 버틸 수 있는 스키마, 쿼리 패턴을 고려한 인덱스 설계 같은 부분은 아직 많이 부족하다고 느낍니다.

마치며

요즘 일을 하며 느끼는 건, 경계는 분명 옅어졌지만 AI 엔지니어에게는 AI 엔지니어로서의 무기가 있고, 다른 직군에게는 각자의 무기가 있다는 점입니다. 확률적인 시스템을 다루는 태도, 평가, 데이터에 대한 감각, 최신 정보 습득이 제 무기라면, 시스템을 안정적으로 운영하는 감각과 장애를 다루는 경험, 확장성을 고려한 설계는 백엔드 엔지니어분들의 무기입니다. 마찬가지로 각 직군마다 그 분야를 오래 해오며 쌓은 저마다의 무기가 있습니다.

재밌는 건, 다른 직군분들이 AI의 도움을 받아 모델을 학습시키듯이, 저도 AI의 도움을 받아 낯선 시스템의 장애에 대응하고 있다는 점입니다. 서로 AI를 빌려 경계를 넘고 있는 셈이지만, 그렇게 넘어간 영역에서는 여전히 그 분야를 오래 해온 사람의 감각이 필요하다는 걸 느낍니다.

그래서 한 사람이 모든 걸 다 잘하는 것보다, 이런 사람들이 팀을 이뤄 각자의 장점을 잘 융화해나가는 게 더 중요해졌다고 느낍니다. 서로의 부족함은 메꿔주고, 서로의 장점은 더 뾰족하게 만들어주는 팀. 경계가 옅어지는 시대에도 결국 필요한 건 이런 팀이라고 느낍니다.

저도 AI 엔지니어로서의 무기는 더 날카롭게 다듬으면서, 부족한 부분은 동료분들께 배우며 채워나가려고 합니다. 다음 회고때는 제가 부족하다고 썼던 부분들이 미래의 무기가 될 수 있도록 노력해보려고 합니다.

이상으로 글을 마치겠습니다. 읽어주셔서 감사합니다!