"나중에 하면 되죠"가 가장 비쌌습니다
"나중에 하면 되죠"가 가장 비쌌습니다
AI로 개발 속도는 빨라졌습니다. 그런데 왜, 빨리 만든 제품일수록 6개월 뒤에 더 비싼 청구서가 날아올까요. 우리가 직접 치른 대가와 그 안에서 배운 판단 기준을 풀어봅니다.
혹시 이런 경험, 한 번쯤 있으시지 않나요?
킥오프 미팅. 일정은 빠듯하고, 보여줄 데모는 필요합니다. 누군가 자연스럽게 말합니다. "그건 나중에 붙이면 되죠. 일단 돌아가는 것부터 만들죠."
그 말에 아무도 반박하지 않습니다. 합리적으로 들리거든요.
그리고 반년 뒤, 그 "나중"이 청구서가 되어 돌아옵니다. 영어 버전 하나 붙이는 데 며칠이 걸리고, 트래픽이 몰리자 협업 기능 하나가 로그인 전체를 멈춰 세웁니다.
문제는 팀이 일을 못해서가 아닙니다. 미뤄도 되는 것과, 미루면 안 되는 것을 구분하지 않은 채 전부 "나중에"로 넘긴 것이 문제였습니다.
미룬 결정은 '소급'이 안 됩니다
기능은 나중에 추가할 수 있습니다. 버튼 하나, 페이지 하나는 언제든 붙일 수 있어요. 하지만 구조에 대한 결정은 다릅니다. 코드가 쌓인 뒤에 구조를 바꾸는 건, 처음에 잡는 것과 비교할 수 없는 비용입니다.
AI가 이 함정을 더 깊게 팝니다. 코드를 순식간에 뽑아주니 "일단"의 결과물이 그 어느 때보다 그럴듯하거든요. 하지만 AI는 무엇을 미루면 안 되는지는 알려주지 않습니다. 그 판단은 여전히 사람의 몫입니다.
결국 필요한 건 '더 많은 기능'이 아니라 '더 선명한 구조 판단'입니다
좋은 파트너는 기능을 더 많이 찍어내는 팀이 아닙니다. 무엇을 지금 결정해야 하고, 무엇은 진짜 나중으로 미뤄도 되는지를 가려내는 팀입니다.
이 판단은 코드를 한 줄도 쓰기 전에 가능합니다. 그리고 그 30분이, 나중의 며칠짜리 리팩토링을 통째로 없앱니다.
발주 전, 이 네 가지만 확인하세요
지금 필요한 건 화려한 기능 목록이 아니라, "이건 미뤄도 됩니다 / 이건 지금 잡아야 합니다"를 명확히 말해주는 한 사람입니다.
우리도 같은 고민을, 먼저 겪었습니다
저 청구서들은 가정이 아닙니다. 우리가 직접 받아본 것들입니다.
"좋은 팀은 빨리 만드는 팀이 아니라, 어디서 멈춰서 구조를 잡아야 하는지 아는 팀이라고 믿습니다."
그 믿음을 만들어가며 실제로 우리가 한 일들입니다.
01. 다국어, "나중에"의 대가를 직접 치렀습니다
글로벌 IP 유통 플랫폼에서 "다국어는 나중에"로 시작했다가, 수십 페이지가 한글로 하드코딩된 뒤 수백 개 키를 며칠에 걸쳐 재구조화했습니다. 그 후로 우리는 번역을 정적/동적으로 분리하고 키 네이밍을 초기에 합의하는 구조를 표준으로 만들었습니다. 같은 실수를, 두 번 하지 않기 위해서요.
02. 장애 격리, 한 기능의 죽음이 전체를 멈추지 않게
프로젝트 관리 플랫폼에서 실시간 협업 서버를 메인 API와 한 프로세스에 뒀더니, 협업 과부하가 로그인·결제까지 함께 멈춰 세웠습니다. 우리는 협업 서버를 별도 프로세스로 분리해, 특정 기능이 실패해도 그 영향이 어디까지만 번질지 경계를 치는 설계로 바꿨습니다.
03. AI 비용·관측, 출시 전에 이미 '보이게' 만들었습니다
16개의 AI Agent를 올리면서, 비용 추적을 첫 번째 호출 전부터 구조에 녹였습니다. 어떤 기능이 토큰을 얼마나 쓰는지, 품질이 떨어지는지를 처음부터 추적합니다. 관측을 "나중에 붙이면" 소급 적용이 안 된다는 걸, 우리는 이미 알고 있었으니까요.
04. 그래서, 그 판단을 대신 해드립니다
겪어봤기 때문에 압니다. 어떤 질문이 미뤄도 되고, 어떤 질문이 지금 답해야 하는지를. 그 판단을 발주자께 미루지 않는 것 — 그게 우리가 생각하는 파트너의 일입니다.
빠르게 만드는 건 누구나 합니다. 안 무너지게 만드는 게 실력입니다.
지금 "일단 빨리"로 시작하려는 프로젝트가 있다면, 시작하기 전에 딱 한 번 점검해보세요. 무엇을 미루면 안 되는지. 그 30분의 대화가, 반년 뒤의 청구서를 바꿉니다. 우리는 그 대화를 함께 할 준비가 되어 있습니다.
다양한 성공 사례가 궁금하다면?
"'나중에'는 틀린 말이 아닙니다. 다만, 그 나중이 얼마나 비싼지 알고 내리는 결정이어야 합니다."
