옥수라는 이름으로 일하는 이유 — 브랜드에 담은 약속

이름이 있기 전에 원칙이 있었다

처음부터 "어떤 이름으로 일할까"를 고민한 게 아닙니다. 어떻게 일할 것인가를 먼저 정했고, 그 방식에 어울리는 이름을 찾았습니다. 옥수(OAKSOO)라는 이름은 그 순서의 결과입니다.

일하는 방식에 관한 원칙이 생기기 시작한 건 첫 번째 컨설팅에서였습니다. 보험설계사분이 보험사에서 오는 견적 PDF를 매일 2시간씩 엑셀에 손으로 옮기고 있었습니다. 처음에는 새 프로그램을 제안할 수도 있었습니다. 그런데 그분이 쓰던 엑셀 템플릿은 수년간 다듬어진 본인만의 형식이었고, 그것을 버리게 하면 오히려 불편이 늘어날 상황이었습니다. 그래서 템플릿은 그대로 두고, PDF에서 필요한 항목을 추출해 그 템플릿에 바로 들어가도록 만들었습니다.

결과적으로 하루 2시간 걸리던 입력 작업이 3분으로 줄었습니다. 그런데 그것보다 더 기억에 남는 것은, 그분이 프로젝트가 끝난 뒤에도 혼자 운영할 수 있었다는 점입니다. 만들어주고 떠난 게 아니라, 본인이 직접 다룰 수 있을 때까지 인수인계를 했기 때문입니다.

그 경험에서 확인한 것이 있습니다. "기술을 팔러 간 게 아니라 불편을 없애러 갔다." 이 감각이 이후 모든 프로젝트의 기준이 됐습니다.

중소기업 AI 자동화에서 자주 보이는 어려움

2026년 현재 AI 자동화에 관심을 갖는 중소기업이 빠르게 늘고 있습니다. 그런데 상담을 하면서 같은 패턴의 어려움도 반복해서 보이기 시작했습니다.

첫 번째 어려움은 소통의 단절입니다. IT 외주에서 발생하는 프로젝트 실패의 가장 흔한 원인 중 하나가 바로 이 소통 부재입니다. 사장님이 원하는 것과 개발자가 만드는 것 사이의 간극이 생각보다 큰 경우가 많습니다. "자동화해달라"는 말만으로는 아무것도 만들 수 없습니다. 어떤 파일에서 어떤 항목을, 어느 타이밍에, 어떤 형식으로, 어디로 보내야 하는지를 알아야 만들 수 있습니다. 이 번역 과정 없이 진행하면 납품을 받고 나서야 "제가 원하던 게 이게 아닌데요"가 됩니다.

두 번째 어려움은 기존 업무 방식의 무시입니다. 자동화를 도입하면서 새 소프트웨어를 배우게 하거나, 기존 업무 흐름을 통째로 바꾸도록 요구하는 경우가 있습니다. 직원들 입장에서는 배워야 할 것이 늘고, 사장님 입장에서는 "이게 왜 더 복잡해졌지?"라는 의문이 생깁니다. 이 상황이 반복되면 "자동화는 우리 같은 회사엔 안 맞는다"는 결론으로 이어집니다. 그런데 그것은 자동화가 안 맞는 게 아니라, 도입 방식이 잘못된 것입니다.

세 번째 어려움은 사후 지원의 부재입니다. 만들어주고 나면 연락이 끊기는 방식이 많습니다. 담당자가 바뀌거나 업무가 조금만 변경되면 시스템이 제대로 돌아가지 않는데, 수정을 요청할 곳이 없어집니다. 그러면 결국 그 자동화 시스템은 쓰이지 않게 됩니다.

옥수가 세 번의 프로젝트를 통해 굳힌 원칙은 이 세 가지 어려움을 직접 겨냥합니다.

"새 도구를 배우게 하지 않는다"는 말의 실제 의미

이 원칙이 처음에는 단순한 편의 제공처럼 보일 수 있습니다. 그런데 실제로는 프로젝트의 성패를 가르는 결정입니다.

보험설계사분의 엑셀 템플릿을 그대로 유지한 이유를 예로 들면, 그분이 몇 년간 다듬어온 형식 안에는 고객별 비교 방식, 보험사별 항목 정리 방식, 본인만의 메모 구조가 녹아 있었습니다. 이것을 새 프로그램으로 옮기면, 형식은 달라지더라도 그 안에 쌓인 맥락은 사라집니다. 기존 도구를 유지했기 때문에 그 맥락이 그대로 남았고, 시스템이 그 위에서 작동할 수 있었습니다.

운영팀 업무 지시 관리 사례도 마찬가지였습니다. ChatGPT·Claude를 연결할 때 새 협업 툴을 도입하는 대신, 이미 쓰고 있던 스프레드시트에 AI를 얹는 방식을 택했습니다. 직원들 입장에서는 달라진 것이 없고, 결과만 달라졌습니다. 지시사항이 자동으로 정리되어 시트에 쌓이는 것을 보고 나서야 "이게 자동화구나"를 실감했다고 합니다.

WordPress 블로그 자동화 사례에서도 기존에 운영 중인 WordPress를 교체하지 않았습니다. 이미 운영 중인 도메인, 기존 글, SEO 설정이 다 거기에 있었고, 그것을 버리는 것이 더 큰 손실이었습니다. Claude와 WordPress를 직접 연결해서 검토를 마친 글이 자동으로 발행되는 구조를 그 안에서 만들었습니다.

세 사례 모두 같은 결론입니다. 기존 도구에 자동화를 얹는 방식이, 새 도구를 도입하는 것보다 저항이 없고, 기존 데이터와 경험이 유지되며, 실제로 쓰이는 시스템이 됩니다.

안 된다고 말할 수 있는 이유

30분 무료 진단을 하면서 "이건 어렵습니다"라고 말한 적이 여러 번 있습니다. 진단에서 가능 여부를 정직하게 말하는 것이 신뢰의 출발입니다.

안 된다고 말하는 기준은 명확합니다. 규칙이 없는 업무는 자동화가 어렵습니다. 매번 담당자가 판단해야 하는 일, 예외가 너무 많아 규칙화할 수 없는 일, 데이터가 정리되지 않아 입력이 제각각인 상태에서 자동화를 얹으면 오류만 늘어날 업무가 그 경우입니다. 이런 업무를 "됩니다"라고 하고 진행하면, 결과물이 나와도 실제로 쓰이지 않는 시스템이 됩니다.

안 된다고 말하면 그 자리에서 계약이 성사되지 않을 수도 있습니다. 그런데 실제로는 반대의 일이 더 자주 일어났습니다. 진단에서 솔직하게 말했을 때 "이렇게 말해주는 곳이 없었다"는 반응이 나오고, 이후에 실제로 자동화가 되는 다른 업무로 다시 연락이 오는 경우가 많았습니다. 세 번의 구축 사례 모두 구축 이후 추가 의뢰나 협업 지속으로 이어진 것이 그 결과입니다.

이것은 장기적으로 더 나은 방식이기도 합니다. 안 되는 것을 됩니다 하고 진행하면, 납품 이후 고객에게 "역시 우리 회사에는 자동화가 안 맞나 봐요"라는 인식을 남깁니다. 그것보다 "이건 어렵고, 저건 됩니다"라는 정확한 판단을 주는 쪽이 더 오래 신뢰를 유지합니다.

세 번의 구축에서 보인 공통된 결과

세 사례 모두 구축 이후 협업이 계속되고 있습니다.

보험설계사 사례(자세한 내용 보기)에서는 하루 2시간 걸리던 PDF 입력 작업이 3분으로 줄었고, 프로젝트 이후 재구매 의사와 함께 지속적으로 연락이 이어지고 있습니다.

운영팀 업무 지시 관리 사례에서는 말로 오가던 지시사항이 자동으로 스프레드시트에 정리되기 시작했고, 이후 추가 자동화 의뢰로 협업이 계속되고 있습니다.

블로그 자동화 사례에서는 "말하면 블로그 글이 된다"는 구조가 만들어졌고, 구축 이후에도 추가 개선 요청으로 협업이 이어지고 있습니다.

세 사례 모두 "구축 후 추가 의뢰·협업 지속"이 공통입니다. 이것은 우연이 아닙니다. 처음 진단에서 정직하게 가능 여부를 말하고, 기존 도구를 유지하면서 반복 작업만 줄이고, 인수인계까지 마쳐서 스스로 운영할 수 있게 만들었기 때문에, 다음에 다른 업무에서도 비슷한 어려움이 생기면 다시 연락이 오는 구조가 됩니다.

옥수가 하는 것과 하지 않는 것

이 두 열의 차이는 기술 역량의 문제가 아닙니다. 일하는 방식의 선택입니다. "하지 않는 것" 쪽이 단기적으로는 더 많은 계약을 만들 수 있습니다. 그런데 지금까지의 세 사례를 통해 확인한 것은, "하지 않는 것"을 지킬수록 장기적으로 고객이 남는다는 것입니다.

인수인계가 끝나야 프로젝트가 끝난다

세 번의 구축 사례에서 공통적으로 시간을 가장 많이 쓴 단계가 인수인계입니다. 시스템이 완성된 이후, 담당자가 혼자서도 운영할 수 있을 때까지 실제로 써보면서 진행했습니다.

보험설계사분의 경우, PDF를 넣으면 엑셀에 자동으로 입력되는 흐름이 완성된 뒤에 인수인계가 시작됐습니다. 어떤 PDF가 들어왔을 때 추출 오류가 날 수 있는지, 그럴 때 어떻게 확인하는지, 새 보험사 양식이 추가되면 어떻게 대응하는지를 직접 시나리오를 만들어 설명했습니다. 그분이 혼자 해보고 문제가 없다는 것을 확인하고 나서야 프로젝트를 마쳤습니다.

운영팀 사례에서도 마찬가지였습니다. AI가 업무 지시를 정리해 스프레드시트에 쌓는 구조가 만들어진 뒤, 직원들이 직접 써보면서 "이 경우는 어떻게 되나요?" 같은 질문에 답하고, 실제 상황에서 발생하는 예외를 함께 처리해보는 과정이 있었습니다.

이것이 시간이 드는 과정인 것은 맞습니다. 그런데 이 단계를 생략하면, 납품 이후 담당자가 바뀌는 순간 시스템이 멈춥니다. 인수인계는 친절의 문제가 아니라, 시스템이 실제로 지속되기 위한 조건입니다.

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

세 번의 프로젝트 모두 구글 미트 원격으로 진행했습니다. 현장 방문 없이 상담·설계·구축·인수인계까지 전 과정을 원격으로 마쳤습니다.

원격을 기본으로 하는 데는 이유가 있습니다. 지역 제한 없이 필요한 곳에 닿을 수 있어야 하기 때문입니다. AI 자동화 컨설팅은 서울 외 지역에서 접근하기 어려운 경우가 많습니다. 가까운 곳에 전문가가 없거나, 온다고 해도 출장비와 이동 시간이 추가되어 부담이 커집니다. 원격으로도 품질이 같다면, 현장 방문이 필요한 이유는 없습니다.

다만 현장을 직접 봐야 상황 파악이 더 정확한 경우도 있습니다. 그런 경우에는 출장비를 받고 대면으로 진행합니다. 기본이 원격이고, 필요할 때만 현장 방문입니다.

세 사례 모두 원격으로 진행하면서 "원격이라 아쉬웠다"는 이야기가 나오지 않았습니다. 화면 공유로 업무 흐름을 보고, 파일을 함께 열어서 설계하고, 테스트 결과를 실시간으로 확인하는 방식이 대면 못지않게 잘 작동했습니다.

상담에서 자주 받는 질문들

Q. AI 지식이 없어도 상담할 수 있나요?

AI를 모르셔도 됩니다. 상담에서 물어보는 것은 기술이 아니라 업무입니다. "어떤 일을 매일 반복하고 있는지", "그 일에 몇 시간이 드는지", "결과물이 어떤 형태여야 하는지"를 이야기해 주시면 됩니다. 기술로 번역하는 것은 저의 몫입니다.

Q. 이미 외주를 맡겨봤는데 잘 안 됐어요. 또 다를 수 있을까요?

이전에 어떤 방식으로 진행했는지에 따라 다르지만, 같은 실수를 반복하지 않으려면 진단에서 그 이유를 먼저 찾아야 합니다. 이전 구축에서 무엇이 잘 안 됐는지를 이야기해 주시면, 그 이유가 기술의 문제인지 설계의 문제인지 소통의 문제인지를 진단에서 파악할 수 있습니다.

Q. 시스템이 만들어진 뒤 뭔가 바뀌면 어떻게 하나요?

업무는 바뀝니다. 담당자가 바뀌고, 거래처 양식이 달라지고, 새 플랫폼이 생깁니다. 인수인계 단계에서 이런 상황에 어떻게 대응하는지를 미리 다룹니다. 소소한 변경은 담당자가 직접 대응할 수 있게 만드는 것이 목표입니다. 큰 변경이 필요하면 그때 별도로 진행합니다.

Q. 어떤 업종에서 의뢰가 많이 오나요?

지금까지 보험(PDF 입력 자동화), 사무·운영(업무 지시 관리), 기술 서비스(블로그 자동화)에서 구축 사례가 있습니다. 업종보다 중요한 것은 업무의 패턴입니다. "같은 작업을 매일 반복하는가", "결과의 형태가 정해져 있는가"가 자동화 가능 여부를 결정합니다. 업종은 크게 상관없습니다.

Q. 구축 기간은 얼마나 걸리나요?

기본 파일럿은 2주로 설계합니다. 2주 안에 실제로 작동하는 것을 확인할 수 있는 범위로 설계하고 시작합니다. 2주 안에 결과가 나오지 않는 규모라면, 처음부터 범위를 나눠서 단계적으로 진행합니다. 한 번에 많이 만들려다 아무것도 완성되지 않는 것이 더 큰 손실이기 때문입니다.

직접 만들고 직접 상담하는 이유

옥수는 1인 구조입니다. 상담을 받는 사람과 실제로 만드는 사람이 같습니다. 처음 진단에서 이야기 나눈 내용이 설계에 그대로 반영되고, 만든 사람이 직접 인수인계를 합니다.

이 구조에는 분명한 한계가 있습니다. 동시에 여러 프로젝트를 진행하면 품질이 흔들릴 수 있고, 수요가 몰리면 대기가 생깁니다. 그래서 의도적으로 작게 유지합니다. 한 번에 감당할 수 있는 규모에서만 진행합니다.

이 한계를 감수하는 이유는, 상담자와 구축자가 분리되는 순간 처음 대화에서 얻은 맥락이 손실되기 때문입니다. 상담에서 "이 엑셀 템플릿의 이 컬럼이 특히 중요하다"고 했던 말이 PM을 거쳐 개발자에게 전달될 때 희석되는 경우가 많습니다. 처음 대화를 한 사람이 직접 만들면 그 맥락이 그대로 살아 있습니다.

구축을 마친 뒤 같은 고객이 새로운 업무로 다시 연락할 때 이전에 쌓인 맥락이 있기 때문에, 처음보다 훨씬 빠르게 다음 프로젝트를 시작할 수 있습니다. 세 번의 사례에서 모두 이 패턴이 반복됐고, 그것이 1인 구조를 유지하는 실질적인 이유이기도 합니다.

6년간 엔지니어로 일하면서 의료 AI 플랫폼을 혼자 설계·개발·운영했고, 그 플랫폼이 CES 2025 혁신상 수상에 기여했습니다. 만들어주고 떠나는 방식이 아니라, 만든 것을 몇 년간 책임지고 운영해 본 경험이 컨설팅 방식에 그대로 영향을 줍니다. 시스템은 만들고 나서도 계속 관리해야 합니다.

브랜드가 지키려는 것

컨설팅을 받는 분들이 가장 두려워하는 것 두 가지가 있습니다.

하나는 "돈은 냈는데 쓸 수 없는 시스템이 나오는" 상황입니다. 이를 방지하기 위해 30분 무료 진단에서 가능 여부를 먼저 확인하고, 구축은 파일럿 형태로 작게 시작합니다. 작은 단위로 시작해 결과를 직접 확인하고, 좋으면 확장하는 방식입니다.

다른 하나는 "나중에 수정비가 추가되는" 상황입니다. 옥수는 범위를 먼저 확정하고 나서 견적을 냅니다. 범위가 정해진 뒤 금액이 달라지지 않습니다. 이 구조가 고객 입장에서도 예측 가능한 비용을 만들어줍니다.

그리고 월 구독료나 유지비를 받지 않는 구조입니다. 만든 시스템은 고객의 것입니다. 계속 쓰려면 돈을 내야 하는 방식이 아니라, 한 번 만들면 담당자가 직접 운영하는 구조로 설계합니다. 보험설계사분이 프로젝트 이후 스스로 운영하고 있는 것이 그 실증입니다.

이 세 가지가 옥수라는 이름으로 일하면서 지키려는 약속입니다. 말이 아니라 구조로 만들어야 신뢰가 됩니다.

비슷한 고민을 하고 계신다면

"우리 회사에 AI 자동화가 맞는지 모르겠다"는 분들이 많습니다. 이 불확실성이 시작을 막는 가장 큰 요인입니다.

30분 무료 진단에서 하는 일은 단순합니다. 지금 가장 시간이 많이 드는 반복 업무를 이야기해 주시면, 자동화가 가능한지, 가능하다면 어느 수준까지 되는지, 얼마나 걸리는지를 그 자리에서 답해드립니다. 가능하지 않다면 가능하지 않다고 말씀드립니다.

진단 후 구매를 권유하는 연락은 드리지 않습니다. 결정은 진단을 받은 분이 하는 것이고, 그 결정을 위한 정보를 드리는 것이 진단의 역할입니다.

요금 구조가 궁금하시다면 요금 안내에서 먼저 확인하실 수 있습니다. 준비가 되셨다면 30분 무료 진단으로 시작하세요.

마지막으로

옥수가 계속 작게 유지되는 것은 한계가 아닙니다. 의도적인 선택입니다. 크게 성장하는 것보다, 진행한 프로젝트마다 담당자가 직접 운영할 수 있는 시스템이 남는 것이 더 중요하다고 생각합니다.

지금까지 진행한 세 번의 프로젝트 모두, 고객분들이 프로젝트가 끝난 뒤에도 연락을 이어가고 있습니다. 이것이 이름 뒤에 담으려는 것입니다. 한 번의 거래로 끝나지 않고, 다음 어려움이 생겼을 때 다시 연락할 수 있는 관계. 그 관계를 만드는 방법은 처음 상담에서부터 솔직하게, 만들 수 있는 것과 없는 것을 정확히 말하는 것이라는 걸 세 번의 경험에서 확인했습니다.

비슷한 어려움이 있는 분들과 계속 그런 방식으로 일하고 싶습니다. 어떤 반복 업무가 시간을 빼앗고 있는지, 30분 무료 진단에서 이야기 나눠볼 수 있습니다. 이미 구축이 됐지만 제대로 쓰이지 않는 시스템이 있다면 그 이야기도 괜찮습니다. 상담 후 영업 연락은 없습니다.