데이터 사이언티스트에서 AI 아키텍트로

Source: Towards Data Science

데이터 과학자의 역할 진화

그리 오래 전은 아니었지만, 데이터 과학자는 노트북 안에서 살아가며 하이퍼파라미터를 마치 생명이 달린 것처럼 조정했습니다—왜냐하면, 많은 경우에 전체 프로젝트 그에 달려 있었기 때문이죠.

• 그 밤새 진행하던 그리드 서치를 기억하시나요?
• 과학이라기보다 예술에 가까운 피처 엔지니어링 파이프라인을 만들던 때?
• XGBoost 모델에서 **0.7 %**의 정확도를 추가로 끌어내던 순간?

2019년 당시, 그것이 바로 데이터 과학자의 일이었습니다. 강력한 모델을 원한다면 스스로 만들거나 제대로 만들기 위해 열심히 일해야 했으니까요. 진정한 가치는 얼마나 잘 튜닝하고, 최적화하며, 데이터를 이해하느냐에 달려 있었습니다.

오늘의 상황

이제 “최첨단(state‑of‑the‑art)”은 API 호출 한 번이면 됩니다:

• 최고 수준의 언어 모델이 필요하나요? 바로 제공됩니다.
• 임베딩이나 멀티모달 추론이 필요하나요? 역시 바로 제공됩니다.

모델링의 가장 어려운 부분들은 이제 확장 가능한 엔드포인트가 처리합니다—대부분의 팀이 스스로 구축하기에는 너무나도 큰 규모이죠.

질문: 모델은 이미 존재하는데, 작업은 어디로 갔을까?

이제 가치는 어디에 있는가

가치는 이제 모델 자체에만 있지 않습니다. 모든 구성 요소가 어떻게 연결되고, 소통하며, 적응하느냐에 있습니다. 이 변화는 데이터 과학자의 역할을 완전히 재구성하고 있습니다.

어떻게일까요? 바로 이 글이 다루는 내용입니다.

Source: …

무엇이 바뀌었나요?

1. .fit() 메서드 우회

현대 AI 프로젝트의 코드를 보면 실제 모델링 작업이 거의 없다는 것을 금방 알 수 있습니다. LLM이나 임베딩 모델을 호출하는 코드를 볼 수는 있지만, 그것이 주요 과제인 경우는 드뭅니다. 실제 작업은 데이터 수집, 라우팅, 컨텍스트 조합, 캐싱, 모니터링, 재시도 처리 등에 있습니다.

즉, 이제 .fit()을 사용하는 것이 코드에서 가장 흥미롭지 않은 부분 중 하나가 되었습니다.

2. 새로운 구성 요소에 적응하기

오늘날 우리는 모델 내부에 집중하기보다, 준비된 구성 요소들을 조합해 시스템을 구축합니다. 전형적인 모델링 스택은 이제 다음과 같습니다:

• 벡터 데이터베이스 (예: Pinecone, Milvus)
• 프롬프트 엔지니어링
• 메모리 레이어
• 함수/에이전트 호출

큰 그림을 보면, 이것은 전통적인 모델링이 아니라 시스템 설계입니다. 이러한 구성 요소 각각은 단독으로는 특별히 유용하지 않으며, 함께 오케스트레이션될 때 비로소 강력해집니다.

3. 모든 것을 하나로 묶기

오늘날 대부분의 데이터 사이언스 코드는 선형 대수, 최적화, 혹은 통계보다 조각들을 연결하는 데 초점이 맞춰져 있습니다. 즉, 다음과 같은 작업을 수행하는 코드를 작성하는 것입니다:

• 구성 요소 간 데이터 이동
• 입력 포맷팅 및 출력 파싱
• 상호작용 로그 기록
• 분산 시스템 전반에 걸친 상태 관리

코드 실행 시간을 측정하면, 모델 사용(API 호출, 추론)에 **10–20 %**만 소요되고, **80–90 %**는 오케스트레이션—데이터 흐름, 통합, 인프라 관리—에 사용된다는 것을 알 수 있습니다.

Source: …

데이터 사이언티스트에서 AI 아키텍트로의 전환

오늘날 가장 큰 사고 방식의 변화는 더 이상 단순히 함수를 최적화하는 것이 아니라는 점입니다.
이제 전체 시스템을 설계하면서 지연 시간, 비용, 신뢰성, 그리고 사용자가 어떻게 상호작용하는지를 고민합니다.

다음과 같이 묻는 대신,

“모델 성능을 어떻게 개선할까?”

우리는 이제 이렇게 묻습니다.

“이 전체 시스템이 실제 상황에서 어떻게 작동할까?”

생각이 들겠지만—이는 완전히 다른 도전 과제입니다! 이 변화가 처음 일어났을 때 저를 포함한 많은 사람들에게 불편함을 주었습니다.

오늘날의 스택에 발맞추려면 통계와 머신러닝만으로는 부족합니다. 다음에 익숙해져야 합니다:

• APIs (예: FastAPI, Flask) – 서비스 및 라우팅
• 컨테이너화 (Docker) – 배포
• 비동기 프로그래밍 (asyncio) – 다중 요청 처리
• 클라우드 인프라 – 확장 및 모니터링
• 데이터 엔지니어링 기본 – 파이프라인 및 저장소

이것이 백엔드 엔지니어링과 많이 닮았다고 생각한다면, 맞습니다. 데이터 사이언티스트와 엔지니어 사이의 경계가 흐려졌고, 양쪽 모두에서 편하게 일할 수 있는 사람들이 성공합니다.

기존 방식 vs. 새로운 방식

지금 핵심 질문은: 코드 수준에서 이 전환은 어떻게 보일까? 입니다.

레거시 프로젝트 (2019): 감성 분석

1. 라벨이 달린 데이터셋을 수집한다.
2. 특징 엔지니어링 수행 (TF‑IDF, n‑grams).
3. 분류기 학습 (로지스틱 회귀, XGBoost).
4. 하이퍼파라미터 튜닝.
5. 모델을 배포한다.

성공은 데이터셋의 품질과 모델에 달려 있습니다.

최신 프로젝트 (2026): 자동화 고객 피드백 에이전트

1. 실시간으로 고객 메시지를 수집한다.
2. 임베딩을 벡터 데이터베이스에 저장한다.
3. 관련된 과거 컨텍스트를 검색한다.
4. 프롬프트를 동적으로 구성한다.
5. 도구 접근 권한이 있는 LLM에 라우팅한다 (예: CRM 업데이트, 티켓 시스템).
6. 대화 메모리를 유지한다.
7. 출력물의 품질과 안전성을 모니터링한다.

무엇이 빠졌는지 눈치채셨나요? 힌트: 학습 루프가 없습니다.

AI 아키텍트처럼 사고하기 시작하는 방법

1. 엔드‑투‑엔드 구축, 컴포넌트만이 아니다

“모델을 학습했다”는 생각 대신, “입력을 받아 처리하고 값을 반환하는 시스템을 만들었다”는 목표를 잡으세요. 이제는 하나의 작업이 아니라 전체 그림을 보는 것이 중요합니다.

2. 위험할 정도로 충분히 백엔드를 배우기

• 간단한 API 만들기 (FastAPI면 충분합니다)
• 비동기적으로 요청 처리하기
• 로깅 및 오류 처리 구현하기
• Docker + 클라우드 플랫폼으로 배포하기

3. 모호함에 익숙해지기

현대 AI 시스템은 전통적인 모델처럼 결정론적이지 않습니다. 행동을 디버깅하고, 프롬프트를 반복하며, 폴백 메커니즘을 설계하고, 출력을 정성적으로 평가하게 됩니다. 단순히 정량적인 지표만 보는 것이 아니라죠.

4. 실제로 중요한 것을 측정하기

정확도만이 주요 지표는 아닙니다. 지연 시간, 요청당 비용, 사용자 만족도, 작업 완료율 등을 고려하세요. 정확도가 95 %라도 프로덕션에서 사용할 수 없으면, 정확도가 85 %이면서 신뢰할 수 있는 시스템이 더 낫습니다.

이미지는 저자에 의해 제공되었습니다

최종 생각

항상 가장 “기술적”이라고 느껴지는 것을 쫓고 싶은 유혹이 있습니다: 최신 모델, 가장 큰 벤치마크, 가장 화려한 아키텍처.

하지만 이 일에서 가장 가치 있는 부분은 언제나—그리고 앞으로도—인간적인 측면입니다: 문제를 이해하는 것. 우리가 해결하려는 것이 무엇인지 아는 것이 데이터나 모델보다 더 중요합니다.

다음과 같은 질문을 해보세요:

• 여기서 필요한 것이 무엇인가?
• 사용자는 무엇에 관심이 있나요?
• 맥락에서 “좋음”이 실제로 의미하는 바는 무엇인가?

이 질문들은 당신이 만드는 것에 큰 차이를 만듭니다. 그 부분을 API 뒤에 숨기거나 외주를 줄 수 없으며, 자동화해서 없앨 수도 없습니다.

그러니 단순히 자동차 엔진을 만드는 것에만 목표를 두지 마세요. 자동차가 어디로 가야 하는지를 이해하고, 그곳에 도달하도록 시스템을 구축하는 사람이 되세요.