생성형 AI를 월 24억 명이 사용한다는 수치는 이 기술이 얼마나 빠르게 퍼졌는지를 보여줍니다. 그런데 같은 기간, AI로 설계한 업무 흐름을 처음부터 다시 그린 팀들이 있습니다. 이 재설계가 왜 생겼는지를 거슬러 올라가면, 그 도구가 기대는 기반이 아직 확정되지 않았다는 사실이 나옵니다.
재설계를 두 번 한 팀과 한 번에 끝낸 팀이 나뉘는 지점이 있습니다. 그 지점을 찾아 올라가면 지금의 AI 인프라가 왜 이렇게 움직이는지가 보입니다.
API 단가가 97% 내려갈 때, 설계의 전제도 함께 무너집니다
GPT-4 Turbo API의 입력 토큰 단가는 2023년 11월 출시 이후 약 18개월 만에 97% 이상 낮아졌습니다. 처음에 이 가격을 기준으로 자동화 범위를 정한 팀들은 설계 전제를 다시 확인해야 했습니다. 비용 때문에 사람이 처리하던 품질 검토 단계를 AI에 넘기는 것이 경제적으로 가능해졌고, 반대로 어떤 처리는 더 저렴한 모델로 대체하는 것이 합리적이 됐습니다. 어느 단계에 어떤 도구를 쓸지를 결정할 때 썼던 기준 자체가 달라진 것입니다.
맥락 창 변화도 비슷한 영향을 미쳤습니다. 초기 GPT-4 모델이 8,000토큰을 처리했을 때, 긴 문서를 청크로 나눠 각각 처리한 뒤 결과를 합치는 파이프라인은 필수였습니다. 이 구조를 정교하게 만든 팀들이 있었습니다. 그 창이 128,000토큰으로, 일부 모델에서는 100만 토큰 이상으로 커지면서 여러 단계로 나눴던 이유가 사라졌습니다. 단계를 합치고 흐름을 단순하게 다시 짜는 것이 오히려 더 나은 선택이 됩니다.
이런 변화는 드문 일이 아닙니다. 코딩 에이전트 플랫폼인 Cursor는 2024년 한 해 동안 기반 모델을 여러 차례 교체했고, 그때마다 출력 패턴이 달라졌습니다. GitHub Copilot도 같은 기간 기반 모델을 바꾸면서 코드 제안 방식이 달라졌고, 팀 단위 가이드라인을 갱신한 곳들이 생겼습니다. 수치가 이 규모로 바뀌면, 처음에 합리적이었던 설계가 과도하거나 부족한 설계가 됩니다.
플랫폼 회사에는 속도를 늦출 이유가 없습니다
생성형 AI 플랫폼 시장에서 경쟁하는 회사들은 성능을 빠르게 높이는 것이 점유율을 지키는 데 유리합니다. 그 과정에서 출력 형식이 달라지거나, 파라미터 기본값이 바뀌거나, 지원하던 기능이 다음 버전에서 사라지는 일이 생깁니다. 사전 공지가 없는 경우도 많습니다.
이 변화들은 개별 사용자에게는 체감이 크지 않습니다. 그런데 이 도구를 팀 단위 프로세스에 내장하면 이야기가 다릅니다. 어떤 프롬프트가 왜 이런 형식으로 돼 있는지, 어떤 파라미터가 왜 이 값으로 설정됐는지를 기록하지 않은 채 시간이 지나면, 플랫폼이 바뀌었을 때 무엇을 다시 확인해야 하는지가 불분명해집니다. 결국 전체를 다시 보는 것이 더 빠르다는 결론에 이르게 됩니다.
AI 플랫폼이 빠르게 나아지는 속도와 그 위에 짠 업무 흐름이 적응하는 속도 사이에 차이가 생길 때, 재설계 비용이 발생합니다. 지금 대부분의 플랫폼에서 그 차이가 유지되고 있습니다.
업무 논리와 AI 설정을 분리한 팀이 세 번째 재설계를 피했습니다
재설계를 두 번 한 팀들이 두 번째에서 달리 결정한 것이 하나 있습니다. 업무 흐름에서 "무엇을 어떤 순서로 처리하는가"와 "그 처리를 어떤 AI에 어떻게 맡기는가"를 다른 층으로 두기 시작한 것입니다.
고객 문의를 받으면 유형을 분류하고, 분류에 따라 대응 초안을 만들고, 담당자가 검토한 뒤 발송하는 순서 — 이 순서는 사용하는 AI 모델이 바뀐다고 달라지지 않습니다. 이것이 업무 논리층입니다. 어떤 AI가 이 단계를 더 잘 처리하는지가 아니라, 이 단계가 왜 존재하는지를 기준으로 설계합니다.
반면 "분류를 어떤 프롬프트로 처리할지", "어떤 모델을 어떤 온도 값으로 쓸지", "출력 형식을 어떻게 파싱할지"는 플랫폼이 달라지면 함께 달라져야 하는 것들입니다. 이것이 AI 능력층입니다. 모델의 특성과 설정이 담기는 부분으로, 플랫폼이 업데이트될 때마다 재검토 대상이 됩니다.
두 층이 섞이면, 플랫폼이 한 번 바뀔 때 업무 흐름 전체를 다시 봐야 합니다. "이 프롬프트가 왜 이런 형식인지"를 파악하려면 업무 논리를 알아야 하고, 업무 논리를 이해하려면 모델의 특성도 함께 파악해야 합니다. 두 층이 분리되면, AI 능력층만 교체해도 나머지 흐름은 그대로 이어집니다.
이 구분은 제품 설계에서 오래전부터 쓰인 방식입니다. 어느 부분이 바뀌고 어느 부분이 바뀌지 않는지를 먼저 결정하고, 바뀌는 부분은 교체가 쉽게 두는 것 — 유지보수 비용을 낮추기 위해 이 원리가 반복해서 적용됐습니다. AI 워크플로에서도 같은 논리가 적용됩니다. 설계할 때 "이 단계는 어떤 모델에서도 통하는 논리인가, 아니면 지금 이 모델의 특성에 기댄 설정인가"를 물어야 합니다. 이 질문이 두 층의 경계를 만들어 줍니다.
이 질문을 설계 단계에서 한 번도 하지 않은 흐름은, 다음 번 플랫폼 업데이트 때 그 비용을 치릅니다. 반대로 이 질문을 명시적으로 한 팀들은 "AI 설정만 다시 확인하면 됩니다"와 "전부 다시 봐야 합니다" 사이에서 앞을 선택할 수 있습니다.
지금 대부분의 AI 플랫폼은 확정되지 않은 채 사용되고 있습니다. 그 전제 위에서 설계하는 것과, 언젠가는 안정될 것이라는 가정 아래 설계하는 것은 다음 재설계가 왔을 때 차이가 납니다.
