규칙 기반의 하드코딩으로 모든 예외 상황을 통제하려는 팀과 AI의 확률적 추론을 시스템의 핵심에 녹여내는 팀은 결과물이 나오는 속도부터 다르다. 10년 전만 해도 우리는 '모든 것을 코드로 통제할 수 있다'는 믿음 아래 살았지만, 지금 그 차이를 깨닫지 못한 개발자는 점점 더 거대한 기술 부채의 늪으로 빠져들고 있다.
규격화된 세계와 If-Else 문의 낭만
내가 스타트업을 처음 시작했을 때만 해도 자연어 처리(NLP)는 거창한 영역이었다. 사용자 질문에 답변하는 챗봇 하나를 만들려고 해도 정규표현식(RegEx) 수백 개를 이어 붙이거나, 형태소 분석기를 돌려 명사만 추출해 DB에서 검색하는 식이었다. 솔직히 그때는 그게 정답인 줄 알았다. 결과가 100% 예측 가능했으니까. 특정 키워드가 들어오면 무조건 특정 답변이 나가는 구조는 디버깅이 쉬웠고, 서버 자원도 거의 먹지 않았다.
당시 개발자들이 이런 방식을 고수했던 이유는 명확하다. 하드웨어 성능은 제한적이었고, 딥러닝 모델을 프로덕션에 올리는 건 대기업이나 하는 사치처럼 느껴졌기 때문이다. 우리는 확정적인 로직이 주는 안정감을 사랑했고, 그 안에서 서비스의 뼈대를 세웠다.
스케일업의 벽과 지저분해지는 코드베이스
문제는 서비스가 커지면서 터져 나왔다. 사용자의 언어는 정규표현식 따위로 가둘 수 있는 게 아니었다. "결제 취소하고 싶어요"라는 문장은 잡아내도, "어제 산 거 돈으로 다시 돌려받을 수 있나요?" 같은 우회적인 표현에는 시스템이 먹통이 됐다. 이를 해결하려고 If-Else 문을 추가할 때마다 코드는 누더기가 됐다.
기존 방식의 치명적인 단점은 '맥락'을 이해하지 못한다는 것이었다. 대화가 길어질수록 이전 상태를 관리하기 위해 Redis에 복잡한 세션 데이터를 쌓아야 했고, 이는 곧 유지보수 비용의 폭증으로 이어졌다. 실제로 내가 운영하던 서비스에서 자연어 처리 로직의 복잡도가 임계치를 넘었을 때, 단순한 오타 하나를 수정하는 데만 수 시간이 걸리는 지경에 이르렀다.
범용 지능이 가져온 설계의 단순화
지난 10년 동안 OpenAI를 필두로 한 AI 모델들의 진화는 이 지저분한 'If-Else 지옥'을 청산할 기회를 줬다. 이제 우리는 수만 줄의 하드코딩 대신, 잘 짜인 프롬프트 하나와 임베딩 벡터 검색으로 문제를 해결한다.
가장 체감되는 변화는 개발 생산성이다. GPT-4o 같은 모델을 사용하면 과거에 수개월이 걸렸을 분류 작업을 단 몇 분 만에 API 호출로 끝낼 수 있다. 실제로 GPT-4o는 이전 세대인 GPT-4 Turbo 대비 2배 빠른 추론 속도를 보여주며 비용 또한 50% 수준으로 낮아졌다 (출처: OpenAI 공식 API 가격 페이지 및 릴리즈 노트).
# [과거 방식] 수십 개의 조건문과 정규표현식
def classify_intent_old(text):
if "취소" in text or "환불" in text:
return "CANCEL_ORDER"
# ... 끊임없는 조건문 ...
# [현재 방식] LLM을 활용한 의도 파악 (OpenAI SDK v1.x 기준)
from openai import OpenAI
client = OpenAI()
def classify_intent_new(text):
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": f"Identify intent: {text}"}]
)
return response.choices[0].message.content마이그레이션의 딜레마와 주의할 점
그렇다고 모든 로직을 당장 AI로 바꾸는 게 능사는 아니다. 막상 해보니 가장 큰 걸림돌은 레이턴시(Latency)와 비용이다. 밀리초(ms) 단위로 응답해야 하는 핵심 로직에 LLM을 박아 넣었다가는 사용자 경험이 박살 난다. 또한, 모델의 '환각(Hallucination)' 현상은 여전히 실무에서 가장 골치 아픈 문제다.
나는 다음과 같은 마이그레이션 전략을 추천한다.
- 하이브리드 구조: 정규표현식으로 처리 가능한 명확한 패턴은 그대로 두고, 모호한 자연어만 LLM으로 넘긴다.
- 비동기 처리: 실시간 응답이 필요 없는 데이터 라벨링이나 요약 작업부터 AI를 도입한다.
- 비용 모니터링: API 호출 횟수가 늘어날수록 비용은 기하급수적으로 증가한다. 캐싱(Caching) 레이어를 반드시 구축해야 한다.
의외로 많은 개발자가 AI를 도입할 때 '전부 아니면 전무(All or Nothing)'의 태도를 취하곤 하는데, 이는 위험한 발상이다. 기존의 견고한 엔지니어링 원칙 위에 AI라는 유연한 지능을 얹는다는 느낌으로 접근해야 한다.
지난 10년이 AI의 가능성을 확인하는 시간이었다면, 앞으로의 10년은 이 지능을 얼마나 효율적으로 우리 코드 속에 녹여내느냐의 싸움이 될 것이다. 이제는 코드를 '어떻게 짤까'보다, 이 문제를 해결하기 위해 '어떤 지능을 어디에 배치할까'를 고민하는 설계자가 살아남는다.
지금 당장 당신의 코드베이스에서 가장 지저분한 If-Else 뭉치를 찾아보라. 거기가 바로 당신의 첫 번째 AI 마이그레이션 포인트다.
참고: OpenAI News