사장님 말을 개발 언어로 번역하는 일 — 컨설턴트가 하는 일

"어떤 걸 원하세요?"

자동화 상담을 시작하면 반드시 하는 질문입니다. 그런데 이 질문에 바로 답하기 어려운 분이 많습니다. "이 작업이 자동화됐으면 좋겠는데 어떻게 말로 설명해야 할지 모르겠어요"라는 말이 자주 나옵니다. "설명을 들을 때는 이해가 됐는데, 막상 무엇을 만들어달라고 해야 하는지 잘 모르겠어요"라는 경우도 있습니다.

자동화 컨설팅에서 컨설턴트가 하는 가장 중요한 일은 코드를 짜는 것이 아닙니다. 사장님이 머릿속에 갖고 있는 문제를 개발자가 이해하고 만들 수 있는 형태로 바꾸는 일입니다. 이 번역이 잘 이루어져야 결과물이 처음부터 방향을 제대로 잡습니다.

2026년 현재 AI 에이전트가 내부 업무 효율화로 빠르게 확산되면서, 자동화에 관심을 갖는 중소기업이 많아졌습니다. 하지만 관심이 실제 구축으로 이어지지 못하는 경우도 여전히 많습니다. 가장 큰 이유 중 하나가 "내가 원하는 것을 개발자에게 어떻게 설명해야 하는지 모르겠다"는 것입니다. 이 번역을 해주는 것이 컨설턴트가 하는 일입니다.

번역이 왜 필요한가 — 말로는 전달되지 않는 것들

IT 프로젝트가 실패하는 첫 번째 공통 패턴은 사업 요구사항을 명확히 정의하지 않은 경우입니다. "보고서를 자동화해달라"는 말은 개발자에게 아무 정보도 없는 말과 같습니다. 어떤 데이터를, 어떤 형식으로, 어느 타이밍에, 어떤 사람에게, 어떤 형태로 전달하는 보고서인지를 알아야 만들 수 있습니다.

발주사가 "이런 느낌으로 해주세요"라고 설명하면, 개발자는 자신이 이해한 방식으로 만들어 납품합니다. 결과물을 받고 나서야 서로 다른 것을 생각하고 있었다는 것을 알게 됩니다. 이 상황이 반복되면 비용과 시간이 쌓이고, 결국 "자동화는 우리 회사에는 안 맞는다"는 결론에 이르게 됩니다. 이것은 기술이 안 되는 것이 아니라, 번역이 이루어지지 않아서 생기는 문제입니다.

번역이 이루어지면 다릅니다. 사장님이 "매일 아침 30분씩 하는 이 작업"이라고 말할 때, 컨설턴트는 그 30분 안에 어떤 파일이 어디서 오는지, 어떤 순서로 처리되는지, 처리된 결과가 어디로 가는지, 예외 상황은 어떤 경우인지를 확인합니다. 이것이 개발자가 이해하고 실제로 만들 수 있는 형태의 요구사항이 됩니다.

요구사항을 단계적으로 분해하고 맥락과 제약 조건을 명확히 전달하는 능력이 2026년 현재 AI 자동화 프로젝트의 성패를 가르는 핵심이 되고 있습니다. 이 과정을 사장님 혼자 하기는 어렵습니다. 어떻게 물어봐야 하는지를 아는 사람이 있어야 제대로 된 요구사항이 나옵니다.

번역은 어떻게 이루어지는가 — 상담에서 설계까지

상담에서 번역은 질문으로 이루어집니다. "지금 어떤 파일이 들어오나요", "그 파일에서 어떤 내용을 꺼내야 하나요", "꺼낸 내용이 어디에 들어가야 하나요", "예외 상황은 어떤 경우인가요", "담당자가 혼자서도 계속 운영할 수 있어야 하나요" — 이 질문들로 사장님 머릿속의 문제가 개발 가능한 형태로 바뀝니다.

상담에서 나온 것이 설계에 그대로 반영됩니다. 상담을 듣는 사람이 직접 만드는 구조이기 때문에, 설명 과정에서 나온 조건이 결과물에 그대로 남아 있습니다. 영업 담당자에게 설명하고, 영업 담당자가 개발팀에 전달하는 방식에서는 이 과정에서 중요한 맥락이 빠집니다. "새 프로그램을 배우지 않아야 한다"는 조건이, 전달 과정에서 "기존 도구와 호환"이라는 말로 단순화되면 설계가 처음부터 다른 방향으로 갑니다.

설계 방향이 잡히면 그것을 다시 사장님 언어로 번역해 드립니다. "구글 스프레드시트 API를 호출해 행을 삽입하는 스크립트"가 아니라, "구글 시트에 새 행이 자동으로 추가됩니다. 양식에 내용을 적으면 지정된 열에 그 내용이 들어갑니다"로 설명합니다. 이 역방향 번역이 있어야 완성된 결과물을 받고 나서도 어떻게 동작하는지 이해하고 직접 운영할 수 있습니다. 담당자가 바뀌어도 인수인계가 가능한 것도 이 과정을 거쳤기 때문입니다.

실제로 이 번역이 어떻게 이루어지는지는 세 가지 사례가 가장 정확하게 보여줍니다.

사례 1 — "분명히 말했는데"가 사라진 회사

사무·운영 업체에서 연락이 왔습니다. 대표가 직원들에게 내리는 업무 지시, 직원들이 받아 적는 업무 내용이 전부 말과 메신저에 흩어져 있었습니다. "분명히 말했는데"와 "못 들었는데"가 반복됐고, 누가 어떤 일을 어디까지 했는지 확인하려면 한 명이 수작업으로 취합해야 했습니다.

처음 상담에서 확인한 것들이 있습니다. 지시가 어떤 방식으로 오가는지, 어떤 스프레드시트를 이미 쓰고 있는지, 담당자는 몇 명인지. 그리고 중요한 조건이 나왔습니다. "새 프로그램을 배우게 하지 않고 싶다"는 것이었습니다.

이 조건이 상담에서 나왔기 때문에 설계 방향이 처음부터 정해졌습니다. 기존에 쓰던 스프레드시트에 ChatGPT와 Claude를 연결해, 업무 지시를 평소처럼 말하거나 메모하면 담당자·기한·내용이 자동으로 구조화되어 시트에 기록되는 방식을 만들었습니다. 새 도구 없이, 기존 시트를 그대로 유지하면서 자동화가 이루어졌습니다. 컨설팅은 구글 미트 원격으로 진행했고, 이후 추가 자동화 문의로 협업이 이어지고 있습니다. 자세한 내용은 업무 지시 자동화 사례에서 확인하실 수 있습니다.

"새 프로그램을 배우지 않아야 한다"는 말이 상담에서 나오지 않았다면 다른 방향을 제안했을 수 있습니다. 별도 프로젝트 관리 앱이나 협업 도구 도입을 권했을 가능성이 있습니다. 상담에서 이 조건이 나왔고, 그것을 들은 사람이 직접 만들었기 때문에 결과물에 반영됐습니다.

사례 2 — 말로 설명하기 어려웠던 "이 작업"

보험설계사분이 연락했습니다. "보험사에서 오는 PDF를 엑셀에 일일이 손으로 옮기는 것을 없애고 싶다"는 것이었습니다. 설명은 간단해 보였지만, 상담에서 확인해야 할 것들이 있었습니다. 어떤 보험사의 PDF인지, PDF 형식이 몇 가지인지, 직접 만들어 쓰는 엑셀 템플릿이 어떻게 생겼는지, 어떤 항목이 어느 셀에 들어가야 하는지를 실제 파일을 화면으로 함께 보면서 확인했습니다.

그리고 가장 중요한 조건이 나왔습니다. "컨설팅 후에 본인이 혼자서도 계속 운영할 수 있어야 한다"는 것이었습니다.

구축한 것은 기존 엑셀 템플릿과 Claude만으로 해결했습니다. PDF를 넣으면 필요한 항목이 템플릿 구조에 맞게 추출되도록 프롬프트 설계와 Claude 세팅을 잡았습니다. 새로운 소프트웨어를 구매하지 않았고, 도구를 팔기보다 설계사 본인이 도구를 다룰 수 있게 만드는 것까지가 컨설팅 범위였습니다. 컨설팅은 구글 미트 원격으로 진행했고, 만족도가 높아 재구매 의사와 함께 지금도 연락이 이어지고 있습니다.

이 사례에서 번역의 핵심은 "혼자 운영해야 한다"는 조건을 처음 상담에서 확인한 것입니다. 이 조건이 없었다면 복잡한 시스템을 만들었을 수도 있습니다. 상담에서 파악한 제약 조건이 설계 방향 전체를 결정했습니다.

사례 3 — "쓸 이야기는 많은데 쓸 시간이 없다"

기술 서비스 업체 T사에서 연락이 왔습니다. 블로그가 마케팅에 필요하다는 것은 알고 있었지만, 현장 일정을 소화하면서 책상에 앉아 글을 쓸 시간은 없었습니다. 상담에서 나온 것은 세 가지였습니다. "쓸 이야기는 많은데 쓸 시간이 없다"는 것, 현재 WordPress를 쓰고 있다는 것, 대표분이 말로 풀어놓은 현장 이야기가 블로그 글에 자연스럽게 녹아들어야 한다는 것이었습니다.

이 세 가지 조건에서 설계 방향이 나왔습니다. WordPress에 올라갈 블로그 글의 초안을 AI가 자동으로 작성하는 구조를 만들었습니다. 대표분이 현장 경험을 두서없이 말로 풀어놓으면, 그 내용이 블로그 글에 녹아들도록 연결하는 방식이었습니다. 클로드와 WordPress를 직접 연결해 검토를 마친 글이 자동으로 발행되도록 했습니다. 구축 이후에도 추가 개선 요청으로 협업이 이어지고 있습니다.

이 사례에서 번역이 이루어진 부분이 있습니다. "쓸 시간이 없다"는 말을 "글쓰기 과정 자체를 없애야 한다"로 바꾼 것입니다. 초안을 쉽게 만들어주는 도구를 소개하는 방향이 아니라, 말로만 해도 글이 되는 구조를 설계하는 방향으로 결정됐습니다. 실제 상황을 상담에서 직접 이해했기 때문에 가능한 방향 전환이었습니다.

세 사례에서 나온 공통점

세 사례 모두 처음 상담에서 나온 조건이 설계 방향을 결정했습니다. 그 조건은 발주사 스스로 "이게 조건입니다"라고 말하지 않았습니다. 상담에서 이야기하다 보니 드러난 것들이었습니다. "새 프로그램을 배우지 않아야 한다", "혼자 운영할 수 있어야 한다", "글쓰기 자체를 없애야 한다" — 이 조건들은 질문을 통해 나온 것이었습니다.

또 세 사례 모두 구축 이후에 추가 의뢰 또는 재연락이 있었습니다. 처음 만든 것과 왜 그렇게 설계했는지를 같은 사람이 기억하고 있기 때문에, 다음에 "이 부분을 더 넓히고 싶다"고 말하면 처음부터 다시 설명하지 않아도 됩니다. 번역이 이루어진 사람이 구축을 했기 때문에, 추가 작업에서도 번역 결과가 그대로 이어집니다.

세 사례 모두 기존 도구를 바꾸지 않은 것도 공통점입니다. 업무 지시 자동화에서는 기존 스프레드시트, 보험설계사 사례에서는 기존 엑셀 템플릿, T사 사례에서는 기존 WordPress를 그대로 유지했습니다. 상담에서 "기존 도구를 바꾸지 않아야 한다"거나 "새 도구를 배우기 어렵다"는 맥락이 나왔기 때문에 설계가 그 방향으로 잡혔습니다.

번역 없이 진행할 때 vs 번역이 있을 때

번역이 없으면 빠르게 시작할 수 있지만, 방향이 처음부터 틀려 있을 가능성이 높습니다. 빠르게 잘못된 방향으로 만드는 것보다, 상담에서 충분히 이야기하고 방향이 맞는 것을 만드는 것이 결과적으로 시간과 비용 모두 덜 듭니다.

전문용어 없이 진행하는 방식

번역을 잘 하려면 한 가지 전제가 있습니다. 개발자 쪽에서 전문용어를 쓰지 않아야 합니다. "API를 연동해서 스크립트를 서버에 배포하면"이라는 설명을 들으면, 사장님 입장에서는 고개를 끄덕이지만 실제로는 이해되지 않은 채로 넘어갑니다. 이해되지 않으면 중요한 조건이나 예외 상황을 추가로 말하기가 어렵습니다. 이해된 척 넘어가면 상담에서 나와야 할 조건들이 나오지 않습니다.

옥수 상담에서 기술 용어를 쓰지 않는 것은 원칙입니다. "API 연동"이 아니라 "프로그램끼리 자동으로 데이터를 주고받게 연결하는 것"으로, "스크립트 배포"가 아니라 "만든 프로그램이 자동으로 실행되도록 설정하는 것"으로 설명합니다. 이해가 안 되는 말은 이해가 될 때까지 풀어서 설명합니다. 이해가 된 상태에서 대화가 이어져야 더 중요한 조건들이 나옵니다.

지금까지 진행한 모든 상담에서 기술 담당자가 동석하지 않았습니다. 개발 배경이 없는 대표님, 실무 담당자와 직접 이야기했습니다. 기술 지식이 없어도 "지금 어떤 작업을 어떻게 하고 있는지"를 설명할 수 있으면 번역은 이루어집니다. 상담 중에 이해가 안 되는 부분이 있으면 바로 말씀해주시면 됩니다. 모르는 용어를 넘어가는 방식은 쓰지 않습니다.

전문용어를 쓰지 않으면 같은 내용을 더 많은 말로 설명해야 합니다. 처음에는 비효율적으로 보일 수 있습니다. 하지만 이 과정에서 중요한 정보가 나옵니다. 이해가 되어야 "아, 그러면 이 경우에는 어떻게 되나요?"라는 질문이 나오고, 그 질문에서 예외 상황과 제약 조건이 드러납니다. 이것이 없으면 납품 후에 발견되는 누락이 생깁니다.

이 방식이 맞는 경우와 맞지 않는 경우

솔직하게 씁니다.

번역 기반의 상담 방식이 잘 맞는 상황이 있습니다. 자동화를 원하는데 어떻게 말해야 할지 모르는 경우, 이전에 개발자와 소통이 잘 안 됐던 경험이 있는 경우, 담당자나 직원이 바뀌어도 스스로 운영할 수 있는 시스템을 원하는 경우, 기존 도구를 바꾸지 않고 자동화를 붙이고 싶은 경우입니다. 지금까지 진행한 세 사례 모두 이 조건에 해당했습니다.

맞지 않는 경우도 있습니다. 이미 개발 스펙이 완성된 상태에서 개발만 의뢰하는 경우, 특정 기술 스택이나 개발 방식이 지정된 경우, 수십 명이 동시에 쓰는 대규모 시스템을 처음부터 새로 만들어야 하는 경우에는 다른 방향을 안내합니다. 진단에서 솔직하게 말씀드립니다.

이 방식이 맞는지 모르겠어도 진단에서 먼저 확인하는 것이 맞습니다. "이건 제 상황에 안 맞겠지"라고 생각하고 오셨다가 방향이 맞는 경우가 있고, 반대로 상담에서 "지금은 자동화보다 다른 것이 먼저입니다"라고 말하는 경우도 있습니다. 어느 쪽이든 추측보다 진단에서 확인하는 것이 낫습니다. 진단 자체가 방향을 정하는 과정입니다.

자주 묻는 질문

Q. 자동화를 원하는지도 모르는 상태에서 상담을 신청해도 되나요?

됩니다. "이 작업이 좀 편해졌으면 좋겠다" 정도의 생각만 있어도 충분합니다. 자동화가 가능한 업무인지, 가능하다면 어떤 방식이 맞는지를 진단에서 함께 확인합니다. 상담 전에 "이게 자동화 대상인지 아닌지"를 먼저 판단하실 필요 없습니다. 그 판단이 진단의 역할입니다.

Q. 이전에 개발자에게 설명했다가 잘 전달이 안 됐던 경험이 있습니다. 괜찮을까요?

오히려 그런 경험이 있다는 것이 이 방식과 잘 맞는다는 신호입니다. "전에 설명했는데 만들어진 것이 달랐어요"라는 경험을 갖고 오시면, 그 과정에서 무엇이 전달되지 않았는지를 같이 살펴볼 수 있습니다. 번역이 잘 이루어지지 않았던 지점을 파악하면, 이번에는 다른 방향으로 접근할 수 있습니다.

Q. 담당자가 바뀌어도 계속 쓸 수 있나요?

담당자가 바뀌어도 쓸 수 있도록 만드는 것이 구축의 기본 조건 중 하나입니다. 세 사례 모두 담당자 본인이 직접 운영할 수 있도록 인수인계가 이루어졌습니다. 담당자가 바뀌는 상황이 예상된다면 진단에서 그 조건을 처음부터 말씀해주시면 됩니다. 그 조건이 설계 방향에 반영됩니다.

Q. 원격으로만 진행해도 되나요?

네. 지금까지 진행한 모든 상담과 구축이 구글 미트 원격으로 진행됐습니다. 화면을 공유하면 실제 파일을 함께 보면서 이야기할 수 있기 때문에, 대면 상담과 정보 전달의 질에서 큰 차이가 없습니다. 오히려 본인 자리에서 실제 파일을 바로 꺼내 보여주실 수 있어 효율적인 경우도 많습니다. 지역에 관계없이 진행 가능합니다.

처음에 무엇을 말하면 되나

사장님이 준비해야 할 것은 많지 않습니다. 지금 가장 귀찮은 수작업이 무엇인지를 생각해두시면 됩니다. 어떤 파일을 어디서 받아서 어디에 넣는지, 하루에 몇 번 반복되는 일인지, 처리하는 데 얼마나 걸리는지. 이 세 가지가 있으면 30분 진단에서 가능 여부와 접근 방식을 정리해드릴 수 있습니다.

기술 배경이나 자동화 지식은 필요 없습니다. "개발자에게 어떻게 설명해야 하는지 모르겠다"는 것이 상담을 시작하는 충분한 이유입니다. 번역은 컨설턴트가 하는 일이고, 사장님이 할 일은 지금 하고 있는 작업을 이야기해 주는 것뿐입니다. 설명을 들으면서 번역하는 것이 컨설턴트의 일입니다. 지금 어떤 작업을 하고 계신지 말씀해주시면, 가능한지 아닌지를 먼저 확인해드립니다. 가능하지 않은 경우에도 이유와 함께 어떻게 하면 가능해지는지를 말씀드립니다.

진단은 30분, 무료입니다. 자동화가 가능하지 않은 경우에는 솔직하게 말씀드립니다. 가능하다면 어떤 방식이 현실적인지, 어디서 시작하는 것이 효율적인지를 함께 정리해드립니다. 영업 전화 없이, 진단 이후의 판단은 보내시는 분이 합니다.

30분 무료 진단 신청하기 — 지금 하는 수작업이 무엇인지 말씀해주시면 됩니다.