두 번째 의뢰가 첫 번째보다 빠른 이유 — 맥락이 남는 구조

컨설팅이 끝나고 며칠, 또는 몇 주 지나서 같은 분에게 다시 연락이 오는 경우가 있습니다. "이번엔 이 부분도 가능한지 여쭤보고 싶어서요." 두 번째 연락이 왔을 때 느끼는 것이 있습니다. 첫 번째보다 빠릅니다. 그 이유를 이 글에 씁니다.

두 번째 프로젝트는 다른 문제를 해결하는 일이지만, 진행 과정 자체가 달라집니다. 첫 번째 프로젝트에서 쌓인 것들이 두 번째를 빠르게 만들고, 더 정밀하게 만듭니다. 어떤 것이 쌓이는지, 그것이 왜 차이를 만드는지를 실제 사례와 함께 설명합니다.

첫 번째 프로젝트에서 쌓이는 것들

코드나 시스템 말고도 쌓이는 것들이 있습니다. 눈에 보이지 않지만 두 번째 프로젝트의 속도를 만드는 것들입니다.

업무 언어의 번역본

대표나 담당자가 쓰는 말을 개발 언어로 번역하는 작업이 처음에는 시간이 걸립니다. "이 파일이 오면 알아서 처리해줘"라는 말의 의미를 정확히 파악하는 것이 첫 번째 프로젝트의 많은 부분을 차지합니다. 어떤 상황이 "이 파일이 오는" 경우인지, "알아서 처리"의 기준은 무엇인지를 확인하는 과정입니다.

두 번째 프로젝트가 오면 이 번역 과정이 이미 되어 있습니다. "이런 방식으로 말하면 이런 의미"라는 이해가 쌓여 있기 때문에, 요구사항을 파악하는 데 드는 시간이 크게 줄어듭니다. 첫 번째 프로젝트에서 요청사항이 명확해지기까지 주고받은 대화들이 두 번째 프로젝트에서는 없어집니다.

기존 도구와 구조에 대한 이해

첫 번째 프로젝트에서 어떤 도구를 쓰는지, 어떤 파일 형식인지, 어떤 방식으로 업무가 돌아가는지를 파악합니다. 이 이해가 두 번째 프로젝트에서도 유효합니다. 새로운 문제를 해결할 때 "기존 엑셀 구조는 이렇고, 기존 흐름은 저렇기 때문에 여기에 연결하는 것이 자연스럽다"는 판단을 빠르게 할 수 있습니다. 처음 보는 구조였다면 파악에 시간이 걸렸을 판단이 이미 되어 있는 것입니다.

신뢰 기반의 소통 방식

첫 번째 프로젝트 이후 서로 어떻게 소통하면 효율적인지가 정해집니다. 어느 수준으로 설명해야 이해가 되는지, 어디에서 확인이 필요한지, 어느 부분은 맡겨도 되는지가 쌓입니다. 두 번째 프로젝트는 이 소통 방식이 이미 있는 상태에서 시작됩니다. 서로 확인하느라 왕복하는 시간이 줄어듭니다.

세 가지 사례에서 나타난 패턴

지금까지 구축한 사례를 보면 공통된 패턴이 있습니다. 세 경우 모두 첫 번째 구축이 끝난 뒤 추가 의뢰나 개선 요청으로 협업이 이어졌습니다.

보험설계사 PDF 자동화에서 보장분석표까지

처음 의뢰는 보험사에서 오는 견적 PDF를 기존 엑셀 템플릿에 자동으로 입력하게 만드는 것이었습니다. 매일 반복하던 수작업 입력을 없애는 것이 목표였고, 구축 후 하루 2시간 걸리던 작업이 3분으로 줄었습니다. 구축이 끝난 뒤 설계사분이 혼자서 운영할 수 있도록 인수인계까지 함께 했고, 이후에도 재구매 의사와 함께 연락이 이어졌습니다.

이후 진행된 두 번째 작업은 보장분석표 자동화였습니다. 고객이 가입한 보험마다 담보 구성이 달라 표 하나를 채우는 데 짧아도 1시간, 보통은 3시간 이상 걸리던 작업이 10분으로 줄었습니다. 구축 이후 소득이 40% 이상 늘었다는 피드백을 받았습니다.

이 두 번째 작업이 빠르게 진행될 수 있었던 이유가 있습니다. 어떤 엑셀 구조를 쓰는지, Claude를 어떻게 활용하는지, 설계사분이 어떤 방식으로 업무를 진행하는지가 이미 파악되어 있었기 때문입니다. 처음부터 시작했다면 더 많은 시간이 필요했을 파악 과정이 없었습니다.

업무 지시 기록 자동화의 추가 요청

ChatGPT와 Claude를 회사에서 이미 쓰던 스프레드시트에 연결해서 구두 지시가 자동으로 기록·정리되는 시스템을 만들었습니다. 지시한 사람은 "분명히 말했는데"가 되고, 받은 사람은 "못 들었는데"가 되는 상황이 사라지는 것이 목표였습니다. 구축 이후 어떤 구조로 시트가 운영되는지, 어디서 AI가 개입하는지, 담당자가 어떤 방식으로 쓰는지가 파악되어 있습니다.

이후 추가 자동화 문의로 협업이 이어지고 있습니다. 두 번째 요청은 "이 부분도 자동화가 될까요?"라는 형태로 옵니다. 기존 시스템과 어떻게 연결되어야 하는지가 이미 파악되어 있어 범위와 방식을 결정하는 속도가 다릅니다. 기존 시트 구조를 그대로 두면서 새 기능을 추가하는 것이 어디까지 가능한지를 빠르게 판단할 수 있습니다.

블로그 콘텐츠 자동화의 개선 요청

기술 서비스 업체 T사는 현장 경험이 많지만 글 쓸 시간이 없는 상황이었습니다. WordPress와 Claude를 연결해 말로 풀면 블로그가 발행되는 시스템을 구축했습니다. "블로그 해야 하는데"가 "말만 하면 올라가는데"로 바뀌는 것이 목표였습니다.

구축 이후에도 추가 개선 요청으로 협업이 이어지고 있습니다. 어떤 WordPress 설정을 쓰는지, 발행 흐름이 어떻게 되어 있는지, T사가 어떤 방식으로 현장 경험을 공유하는지가 파악되어 있기 때문에 개선 요청이 왔을 때 기존 시스템과 충돌하지 않게 연결하는 방식을 빠르게 설계할 수 있습니다.

세 사례에서 맥락이 구체적으로 어떻게 작동했는가

위 세 사례에서 맥락이 실제로 어떻게 적용됐는지 더 구체적으로 보면 패턴이 보입니다.

보험설계사 사례에서는 두 번째 작업인 보장분석표 자동화를 설계할 때 첫 번째 구축에서 파악한 것들이 바로 적용됐습니다. 설계사분이 사용하는 엑셀 템플릿의 구조, 데이터를 어떤 형식으로 입력하는지, Claude에게 어떤 방식으로 지시하면 원하는 결과가 나오는지가 이미 파악된 상태였습니다. 두 번째 요청이 왔을 때 "어떤 방식으로 만들면 실제로 쓰이겠다"는 판단이 처음보다 빠르게 나왔습니다. 처음 보는 상황이었다면 엑셀 구조 파악과 테스트 단계에서 추가 시간이 필요했을 것입니다.

업무 지시 기록 사례에서는 어떤 종류의 스프레드시트 구조를 회사에서 쓰는지, 담당자들이 자동화 도구를 어느 수준으로 이해하는지가 파악되어 있었습니다. 두 번째 요청이 왔을 때 "이 구조에서 이렇게 연결하면 기존 흐름을 건드리지 않는다"는 판단을 빠르게 할 수 있었습니다. 기존 시트와 충돌할 수 있는 지점이 어딘지를 이미 알고 있었기 때문입니다.

블로그 자동화 사례에서는 WordPress 설정의 어떤 부분이 T사의 발행 방식과 연결되어 있는지, 어떤 형태의 콘텐츠를 자주 다루는지, 시스템을 어떤 방식으로 운영하는지가 파악되어 있었습니다. 개선 요청이 왔을 때 기존 설정과 충돌하지 않게 연결하는 방안이 처음 설계 때보다 훨씬 빠르게 나왔습니다.

세 사례 모두에서 두 번째 작업이 빠르게 진행된 이유는 기술적인 재사용 때문만이 아닙니다. 이 고객이 어떻게 일하는지, 어떤 도구를 편하게 쓰는지, 어떤 종류의 설명이 이해하기 좋은지를 알고 있는 것이 핵심이었습니다.

맥락이 없을 때 무슨 일이 일어나는가

비교를 위해 반대 경우를 생각해봅니다. 처음 보는 회사의 두 번째 과제를 맡게 되는 경우입니다.

도구가 무엇인지 파악해야 합니다. 어떤 버전의 엑셀인지, 구글 시트인지, 어떤 방식으로 파일이 관리되는지. 업무 방식을 파악해야 합니다. 어떤 순서로 일이 이루어지는지, 어디에서 담당자가 직접 개입하는지, 어디가 병목인지. 소통 방식을 맞춰야 합니다. 얼마나 기술적인 수준으로 설명해야 하는지, 어느 정도 구체적으로 요구사항을 말하는지.

이 모든 것을 처음부터 파악하는 시간이 필요합니다. 고객 입장에서는 여러 차례의 설명 반복이 되고, 컨설턴트 입장에서는 파악 과정이 됩니다. 이 과정이 필요 없어지는 것이 두 번째 프로젝트의 가장 큰 차이입니다.

맥락이 있다는 것은 단순히 기존 코드를 재사용한다는 뜻이 아닙니다. 이 회사가 어떤 방식으로 일하고, 어떤 도구를 편하게 쓰고, 어떤 종류의 설명이 이해하기 좋은지를 아는 것입니다. 이 이해가 쌓여 있으면 두 번째 프로젝트는 처음부터가 아니라 중간부터 시작됩니다.

첫 번째 프로젝트와 두 번째 프로젝트의 차이

이 차이가 속도뿐 아니라 결과 품질에도 영향을 줍니다. 맥락을 아는 상태에서 만든 시스템은 이 회사의 실제 업무 방식에 맞게 설계됩니다. 처음 보는 상황에서 설계한 시스템보다 운영이 자연스럽게 이어지는 경우가 많습니다.

두 번째 의뢰가 가능해지는 조건

두 번째 의뢰가 생기려면 첫 번째가 실제로 작동해야 합니다. 구축이 끝났지만 담당자가 쓰지 않는 시스템, 운영하다가 멈춰버린 자동화는 두 번째 의뢰로 이어지지 않습니다.

첫 번째가 계속 작동하는 이유는 인수인계를 구축의 일부로 보기 때문입니다. 담당자가 혼자서도 운영할 수 있는 수준이 될 때까지 전달합니다. 보험설계사분이 Claude를 직접 쓸 수 있게, 업무 지시 기록 시스템을 직원들이 직접 활용할 수 있게, 블로그 발행 흐름을 T사가 운영할 수 있게 만드는 것이 구축의 끝입니다.

이 단계까지 되어야 시스템이 실제로 쓰이고, 쓰이면서 다음 필요가 보이고, 다음 필요가 두 번째 의뢰가 됩니다. 구축이 끝난 뒤에 담당자가 "이건 어떻게 하나요?"라고 계속 묻는 상황이 생긴다면, 인수인계가 충분하지 않은 것입니다. 그 상황이 되면 두 번째 의뢰 대신 첫 번째 구축에 대한 불만이 쌓입니다.

거꾸로, 담당자가 혼자 쓸 수 있고 작동하는 것을 경험하면 다음 불편한 것이 보입니다. "이것도 이렇게 되면 좋겠는데"가 생기는 것이 자연스럽습니다. 그것이 두 번째 의뢰의 시작점입니다.

자주 받는 질문

Q. 첫 번째 구축이 끝난 뒤 얼마 만에 두 번째 의뢰가 생기나요?

일정하지 않습니다. 구축이 끝난 직후 다음 달에 바로 두 번째 요청이 온 경우도 있고, 몇 달 뒤에 새로운 불편이 생기면서 연락이 오는 경우도 있습니다. 타이밍은 고객이 첫 번째 시스템을 실제로 운영하면서 자연스럽게 다음 필요를 발견하는 시점에 달려 있습니다. 구축이 잘 작동하면 더 빠르게, 작동하지 않으면 두 번째 의뢰 대신 문제 해결 요청이 먼저 옵니다.

Q. 두 번째 의뢰가 첫 번째와 전혀 다른 분야라면 어떻게 되나요?

전혀 다른 분야라도 업무 언어 번역본과 기존 환경 파악은 계속 유효합니다. 예를 들어 첫 번째가 PDF 문서 처리였고 두 번째가 주간 보고서 자동화라면, 도구가 달라도 이 회사에서 쓰는 스프레드시트 구조, 담당자가 어떤 수준의 설명을 원하는지, 어떤 방식으로 운영을 선호하는지는 그대로 적용됩니다. 완전히 처음부터 시작하는 것은 아닙니다.

Q. 기존에 구축한 시스템이 고장났는데, 고치는 것도 되나요?

됩니다. 기존 구축 고객의 경우 시스템 상태 확인부터 시작합니다. 어디서 오류가 났는지, 플랫폼 업데이트나 파일 형식 변경으로 기존 흐름이 깨진 것인지 확인합니다. 기존 구조를 알고 있기 때문에 어디를 봐야 하는지를 빠르게 파악할 수 있습니다. 처음 보는 시스템을 진단하는 것보다 시간이 적게 걸립니다.

Q. 두 번째 의뢰는 진단이 따로 필요한가요?

상황에 따라 다릅니다. 첫 번째 구축에서 이미 환경이 파악된 경우라면 간단한 확인 대화로 충분할 수 있습니다. 그러나 새로운 업무 영역이거나 첫 번째 구축 이후 조직이나 도구가 크게 바뀐 경우라면 진단이 도움이 됩니다. 판단이 어렵다면 30분 무료 진단에서 먼저 현황을 보고 그 자리에서 진단 범위를 결정합니다.

Q. 처음부터 여러 가지를 한꺼번에 구축하면 두 번째 프로젝트가 필요 없지 않나요?

한꺼번에 여러 가지를 구축하면 각각을 제대로 이해하고 인수인계하는 데 시간이 많이 필요합니다. 담당자가 소화하지 못하면 여러 시스템 중 일부는 결국 안 쓰이게 됩니다. 하나를 제대로 쓰이는 것을 확인한 뒤 다음을 추가하는 방식이 실제로 더 많이 사용되는 자동화를 만들어냅니다. 두 번째 의뢰를 없애는 것보다, 첫 번째가 확실히 쓰이는 것이 더 중요합니다.

Q. 두 번째 의뢰 때도 계약과 범위 정의를 처음부터 다시 해야 하나요?

두 번째 프로젝트도 별개의 작업 범위로 진행되기 때문에 해당 작업에 맞는 범위 정의와 진행 방식 확인이 필요합니다. 다만 서로 어떻게 소통하는지, 어떤 방식으로 범위를 정하는지가 이미 파악되어 있어 확인 단계가 처음보다 빠릅니다. 첫 번째 의뢰에서 범위 정의 자체에 여러 차례 확인이 필요했다면, 두 번째는 같은 방식으로 훨씬 빠르게 정해지는 경우가 많습니다. 첫 번째 프로젝트에서 어떤 수준의 결과물을 만들었는지를 서로 이미 알고 있기 때문입니다.

Q. 첫 번째 의뢰 이후 담당자가 바뀌었는데, 두 번째 의뢰가 여전히 빠른가요?

담당자 변경은 일부 영향을 줍니다. 소통 방식과 업무 언어 파악은 담당자 기준으로 쌓이기 때문입니다. 새 담당자와의 소통 방식을 다시 맞춰가는 과정은 필요합니다. 그러나 도구 환경, 엑셀 구조, 회사가 사용하는 시스템의 특성은 담당자가 바뀌어도 유효합니다. 기존 환경 파악이 되어 있어 완전히 처음부터 시작하는 것보다는 빠릅니다. 조직 내에서 자동화 수요나 운영 방식 자체가 바뀌었다면, 그 부분을 다시 파악하는 과정이 추가될 수 있습니다.

처음 의뢰를 고려하는 분들께

처음 문의를 하시는 분께도 이 점이 참고가 될 수 있습니다. 지금 당장 해결하고 싶은 한 가지 문제로 시작하는 것이 맞습니다. 회사 전체의 자동화를 한꺼번에 계획하는 것보다, 지금 가장 번거로운 하나를 제대로 해결하는 것이 장기적으로 더 효율적입니다.

그 이유가 있습니다. 하나를 해결하는 경험이 쌓이면, 이후 두 번째를 의뢰할 때 처음보다 빠르고 정밀한 결과를 얻을 수 있습니다. 처음부터 큰 범위를 잡으면 구축 기간이 길어지고, 그 사이에 필요한 것이 바뀌는 경우도 생깁니다. 작게 시작해서 실제로 작동하는 것을 확인한 뒤 범위를 넓히는 방식이 안정적입니다.

세 사례 모두 처음 의뢰는 하나였습니다. "PDF 입력 하나를 없애고 싶다", "업무 지시가 기록에 남지 않는 문제 하나를 해결하고 싶다", "블로그 발행 시간을 없애고 싶다"로 시작했습니다. 그 하나가 제대로 해결되고 작동하는 것을 경험하면서 다음이 보였습니다.

자동화 외주를 처음 의뢰할 때 막막한 분들께는 자동화 외주 전 확인 체크리스트가 도움이 될 수 있습니다. 구축 전에 어떤 질문을 해야 하는지, 무엇을 준비하면 진단이 빠르게 진행되는지를 실무적으로 담았습니다.

비슷한 상황의 독자를 위한 안내

이미 한 번 구축을 했고 추가 개선이 필요한 분은 별도 진단이 필요하지 않을 수 있습니다. 기존 구축 내용이 파악되어 있다면 상황을 설명하는 시간 없이 바로 작업 범위 이야기로 들어갈 수 있습니다.

처음 문의를 하시는 분도 걱정하지 않아도 됩니다. 첫 번째 프로젝트에서 맥락을 쌓는 과정이 있고, 그 과정이 두 번째를 빠르게 만드는 기반이 됩니다. 처음이 느리다고 느껴지는 것은 자연스럽습니다. 처음부터 빠를 수가 없고, 처음이 제대로 끝나야 두 번째가 빠릅니다. 첫 번째 프로젝트에서 담당자가 실제로 운영할 수 있는 수준까지 완성하는 것을 목표로 하는 이유가 여기에 있습니다.

구축이나 추가 개선을 생각하고 있다면 30분 무료 진단에서 먼저 이야기 나눠보시면 됩니다. 기존 구축 고객이든 처음 문의하시는 분이든 동일하게, 가능 여부부터 솔직하게 말씀드립니다. 영업 전화는 없습니다.