CES 혁신상 팀에서 배운 것, 중소기업 자동화에 그대로 씁니다

옥수를 시작하기 전 이야기

옥수를 시작하기 전, AI 개발자로 일하면서 CES 혁신상을 받은 팀에 있었던 적이 있습니다. CES는 매년 라스베이거스에서 열리는 세계 최대 가전·기술 박람회입니다. 혁신상(Innovation Awards)은 그 중에서도 심사위원단이 설계, 기술적 완성도, 인간공학적 특성, 기능성, 소비자 매력도를 기준으로 선별하는 상입니다. 2026년 기준으로 전 세계 3,600개 이상의 제품이 출품되었고 AI 분야 출품 수만 전년 대비 29% 늘었습니다. 한국 기업이 전체 혁신상의 약 60%를 차지했으며, 수상 기업의 80% 이상이 중소기업이었습니다. 그 경쟁에서 살아남는다는 것이 무엇을 의미하는지 — 팀 안에서 직접 일하면서 배운 것들이 있습니다.

그리고 그 배움이 지금 중소기업 자동화를 하는 방식에 그대로 녹아 있다는 것을 요즘 자주 느낍니다. 이 글은 그 이야기입니다. 화려한 이력을 말하려는 것이 아니라, "그 경험이 지금 여기서 어떤 형태로 작동하는가"를 솔직하게 쓰겠습니다. 경력은 배경이고, 중요한 것은 그 배경이 지금 어떻게 쓰이느냐입니다.

CES 혁신상이 실제로 평가하는 것

많은 분들이 CES 혁신상을 "기술력이 뛰어난 제품에 주는 상"으로 이해하십니다. 반은 맞습니다. 하지만 심사 기준을 들여다보면 다른 그림이 나옵니다.

공식 심사 항목에는 혁신적 설계와 엔지니어링, 기술적 특성 외에도 인간공학적 특성이 명시되어 있습니다. 아무리 기술적으로 뛰어나도 실제로 사람이 쓰기 어렵다면 높은 점수를 받기 어렵습니다. "이 제품이 현실에서 사용될 수 있는가"를 묻는 것입니다.

팀 안에서 일하면서 이 기준이 얼마나 일관되게 작동하는지 봤습니다. 기술적으로 가장 복잡한 기능이 심사에서 가장 높은 점수를 받는 것은 아니었습니다. 되려 "이 기능이 없으면 안 되는가, 쓰는 사람이 원하는 방식으로 작동하는가"를 계속 물어보는 문화가 있었습니다. 기능을 추가할 때보다 기능을 뺄 때 더 많은 논의가 있었습니다.

그 문화가 제 개발 방식을 바꿨습니다.

첫 번째 교훈: "사용하는 사람이 판단한다"

CES 혁신상을 받는 제품들의 공통점이 있습니다. 기능 목록이 아니라 시나리오로 설계된다는 것입니다. "이 상황에서 이 사람이 무엇을 원하는가, 어디서 막히는가"를 먼저 쓰고 그것을 해결할 기술을 찾습니다. 거꾸로 기술을 먼저 정하고 거기에 맞는 사용 시나리오를 찾는 방식과는 결과가 다릅니다.

이것이 중소기업 자동화에서는 어떻게 보이냐면, 상담에서 "어떤 기술을 도입할까"가 아니라 "지금 어디에서 막히고 있는가"를 먼저 듣는 방식으로 나옵니다.

보험설계사분과의 작업이 좋은 예입니다. 처음 상담에서 받은 질문은 "AI를 도입하고 싶다"였습니다. 하지만 이야기를 들어보니 문제는 분명했습니다. 보험사에서 PDF로 오는 견적서를 자체 엑셀 템플릿에 한 칸씩 손으로 옮기는 작업 때문에 고객 응대에 써야 할 시간이 계속 새고 있었습니다. 그분이 원한 것은 최신 AI 기술이 아니라 "그 옮기는 작업이 없어지는 것"이었습니다.

거창한 시스템을 새로 만들지 않았습니다. 이미 쓰던 엑셀 템플릿과 Claude만으로 PDF 내용이 템플릿 구조에 맞게 자동으로 들어가는 흐름을 만들었습니다. 도구를 바꾼 것이 아니라 그분이 하던 방식을 그대로 두고 그 안에서 수작업만 없앴습니다. 사례 전체 보기

기술이 중심이 아니라 일하는 사람의 시나리오가 중심이었습니다. CES에서 배운 것이 여기서 그대로 나왔습니다.

이것은 상담 초반에 구체적인 질문을 드리는 방식으로도 나타납니다. "어떤 업무를 자동화하고 싶으세요?"가 아니라 "지금 가장 시간이 많이 걸리는 일이 무엇인가요, 그 일을 어떤 순서로 하고 계신가요, 그 중 제일 불편한 부분이 어디인가요"를 차례로 묻습니다. 대답이 쌓이다 보면 자동화해야 할 곳이 명확해집니다.

두 번째 교훈: "완성보다 작동이 먼저다"

CES 혁신상에 출품하는 제품들이 발표 단계에서 완전하지 않은 경우를 자주 봤습니다. 프로토타입 상태인데도 심사를 통과하는 것들이 있습니다. 이유는 하나입니다 — 핵심이 되는 기능 하나가 제대로 작동했기 때문입니다.

처음부터 100% 완성된 시스템을 목표로 하면 리스크가 커집니다. 만드는 시간도 길어지고, 실제로 써보기 전까지 뭐가 필요하고 뭐가 불필요한지 알기 어렵습니다. 핵심 하나가 돌아가는 것을 먼저 확인하고, 거기서 확장하는 것이 현실적입니다.

이 원칙이 옥수의 2주 파일럿 방식으로 이어졌습니다. 자동화 전체를 한꺼번에 설계하고 납품하는 방식을 쓰지 않습니다. 가장 효과가 클 것 같은 업무 하나를 골라서 2주 안에 작동하는 것을 보여드리고, 거기서부터 범위를 넓힙니다. 큰 비용을 쓰기 전에 "이게 우리 회사에서 실제로 되는지"를 눈으로 확인하는 것이 서로에게 안전합니다.

업무 지시 자동화를 구축한 회사도 그렇게 시작했습니다. 구두와 메신저로 오가던 지시사항이 누락되는 문제였는데, 기존에 쓰던 스프레드시트에 ChatGPT와 Claude를 연결해서 지시사항이 자동으로 기록되는 흐름을 먼저 만들었습니다. 새 툴을 도입하지 않았고, 기존 업무 방식을 크게 바꾸지도 않았습니다. "지시사항이 자동으로 정리된다"는 딱 하나의 문제를 먼저 해결하고, 그 이후 추가 자동화로 협업이 이어졌습니다.

세 번째 교훈: "남는 시스템이 좋은 시스템이다"

CES 혁신상을 받은 제품들을 몇 년 후에 보면, 살아남는 것과 그렇지 않은 것이 나뉩니다. 구조적으로 유지 비용이 낮고, 쓰는 사람이 학습 없이도 계속 쓸 수 있는 제품들이 남습니다.

자동화도 같습니다. 만들어놓고 아무도 안 쓰거나, 담당자가 바뀌면 멈추거나, 서비스 하나가 업데이트되면 전체가 무너지는 것들을 실무에서 자주 봤습니다. 좋은 시스템은 만든 사람이 없어도 돌아갑니다.

이것이 옥수에서 월 이용료를 받지 않는 구조와 연결됩니다. 의뢰인이 직접 운영할 수 있을 수준으로 인수인계하고, 그 이후는 스스로 돌아가게 만드는 것이 목표입니다. 구독료를 계속 내야 하는 구조가 아니라, 한 번 구축하면 스스로 유지되는 구조입니다.

WordPress 블로그 자동화를 구축한 T사가 좋은 예입니다. 현장 이야기를 말로 풀면 블로그 초안이 만들어지고 자동 발행되는 구조를 만들었는데, 핵심은 T사 대표가 별도의 기술 지식 없이 직접 이 흐름을 운영할 수 있다는 점이었습니다. 구축이 끝난 후 "이제 어떻게 하면 되나요?"가 아니라 "이미 하고 있는데요"가 되어야 인수인계가 완성된 것입니다.

CES 원칙이 옥수에서 어떻게 작동하는가

세 가지 교훈을 중소기업 자동화에 적용하면 구체적인 방식 차이가 생깁니다.

이 차이를 가장 잘 설명하는 것은 "기존 도구를 버리게 하지 않는다"는 원칙입니다. 보험설계사분은 기존 엑셀 템플릿을 그대로 썼고, 업무 지시 자동화를 구축한 회사도 기존 스프레드시트를 그대로 썼습니다. T사도 기존 WordPress를 유지했습니다. 세 사례 모두 새 시스템 도입이 아니라 기존 방식 위에 자동화가 얹혔습니다.

이것이 CES에서 배운 "쓰는 사람 기준"의 실제 모습입니다. 사람이 도구에 맞추는 것이 아니라 도구가 사람에게 맞춰야 합니다.

"안 됩니다"라고 말하는 것도 같은 원칙에서 나온다

CES 혁신상을 받는 팀에서 일하면서 배운 또 다른 것이 있습니다. "이 기능은 넣으면 안 된다"고 말할 수 있는 것도 실력이라는 점입니다. 기능이 많아질수록 복잡해지고, 복잡해질수록 유지가 어려워지고, 유지가 어려워지면 결국 아무것도 남지 않습니다.

이것이 진단에서 "안 됩니다"라고 답하는 이유와 연결됩니다. 기술적으로 만들 수는 있어도 유지하기 어렵거나, 만들고 나서 아무도 안 쓸 것 같은 자동화는 만들지 않는 것이 낫습니다. 그 판단을 솔직하게 말씀드리는 것이 첫 번째 역할이라고 생각합니다.

진단에서 "안 됩니다"라고 답했을 때 대부분의 분들이 오히려 신뢰해주시는 경우가 많습니다. 다 된다고 말하는 곳보다 안 되는 것을 명확히 말해주는 곳이 드물기 때문입니다. 이것이 재구매와 추가 의뢰로 이어지는 이유입니다.

경험이 실제로 남기는 것

개발 경력이 길어질수록 확신하게 되는 것이 있습니다. 기술 자체보다 기술을 어떤 문제에, 어떤 방식으로 적용하는지가 결과를 가릅니다. CES 혁신상 팀에서 일하면서 그것을 가장 명확하게 배웠습니다.

화려한 기술을 쓰고 싶은 개발자와, 그 기술이 자신의 업무에 실제로 맞는지 모르는 사업주 사이에 생기는 간극이 있습니다. 그 간극을 메우는 것이 상담의 역할이라고 생각합니다. 사장님 말을 기술 언어로 번역하는 것이 아니라, 현장 문제를 듣고 그것에 맞는 기술을 고르는 것입니다.

"최신 AI 기술을 도입하고 싶다"가 아니라 "월말에 영수증 정리하는 데 담당자가 이틀을 쓰고 있는데 이게 자동화가 되나요"처럼 구체적인 문제를 들고 오실수록 진단이 정확해집니다. 현장 경험이 많으신 대표님들이 그 구체성을 가장 잘 갖고 오십니다.

지금 가장 불편한 일이 뭔지 말씀해 주시면 됩니다

CES에서 배운 것들이 지금 어떻게 쓰이는지를 가장 잘 보여주는 것은 저의 이야기가 아니라 진단 자리에서 나오는 이야기입니다. 어떤 일이 불편한지, 거기서 시간이 얼마나 나가는지, 담당자는 그것을 어떻게 하고 있는지를 듣는 순간부터 이미 방향이 보이기 시작합니다.

오래 일한 경험이 도움이 되는 것은 "아, 이것은 이렇게 하면 됩니다"가 빨리 나오는 게 아닙니다. "이것은 이 방식으로는 안 되고, 이렇게 접근해야 됩니다, 그리고 이 경우에는 자동화보다 다른 방법이 맞습니다"가 정확하게 나오는 것입니다. 그 정확함이 시간을 아끼는 방법입니다.

진단은 구글 미트 화상으로 30분 진행합니다. 화면 공유로 현재 업무 흐름을 보여주시거나, 말씀으로 설명해 주셔도 됩니다. 따로 미리 준비하지 않으셔도 됩니다. 진단 후 가능·불가능 판단과 대략적인 방향을 드리고, 진행을 원하시면 견적으로 이어집니다. 진단 자체는 아무런 의무가 없습니다.

기술 배경이 어떻든 중소기업 현장에서 실제로 남는 자동화를 만드는 것 — 그것이 CES에서 배운 세 가지 원칙을 실천하는 방식입니다. 박람회 무대가 아니라 실제 업무 현장에서 검증받는 것이 목표입니다.

화려한 경력보다 현장에 남는 것이 중요하다

솔직하게 말씀드리면, CES 혁신상 경험이 중소기업 대표님들에게 직접적으로 의미 있는 것은 아닙니다. 박람회 이야기보다 "지금 우리 회사 문제를 해결해 줄 수 있는가"가 더 중요하신 것이 당연합니다.

그래서 이 글을 쓰는 이유는 경력 자랑이 아닙니다. 배경이 지금 일하는 방식에 어떤 형태로 녹아있는지를 설명하는 것입니다.

"사용하는 사람 기준으로 생각하기" — 이것은 상담에서 어떤 질문을 먼저 하는지에 나타납니다. "어떤 기술을 원하시나요"보다 "지금 어떤 일이 제일 불편하세요"를 먼저 묻습니다.

"작동하는 것을 먼저 보여주기" — 이것은 2주 파일럿 방식으로 나타납니다. 큰 프로젝트를 시작하기 전에 실제로 돌아가는 것을 먼저 확인합니다.

"남는 구조 만들기" — 이것은 인수인계를 구축의 일부로 보는 것으로 나타납니다. 담당자가 바뀌어도, 만든 사람이 없어도 돌아가는 것까지가 완성입니다.

2026년 CES에는 전 세계 4,100개 기업이 참가했고 AI 분야 출품 수는 전년 대비 29% 늘었습니다. 기술 경쟁은 치열해지고 있습니다. 하지만 그 흐름 속에서 중소기업에 실제로 필요한 것은 "화려한 최신 기술"이 아니라 "지금 이 업무 문제를 해결하는 것"입니다.

자주 받는 질문들

상담 전에 자주 받는 질문들이 있습니다. 솔직하게 답하겠습니다.

"큰 회사들만 AI 자동화가 가능한 거 아닌가요?"

현장에서 보면 반대인 경우가 많습니다. 직원이 많은 회사일수록 기존 시스템이 많아서 오히려 자동화 도입이 복잡합니다. 직원 5명 이하의 소규모 사업장이 오히려 빠르게 도입하고 효과를 내는 경우가 많습니다. "우리 같은 작은 회사도 되나요"는 걱정하지 않으셔도 됩니다.

"IT를 잘 모르는데 진단이 가능한가요?"

오히려 IT를 모르시는 분이 더 좋은 진단 결과를 얻는 경우가 많습니다. 기술 용어 없이 "이런 일이 불편하다"고 말씀해 주시는 것이 시작입니다. 기술 번역은 저의 역할입니다.

"자동화 비용이 얼마나 드는지 먼저 알고 싶습니다."

진단 전에 정확한 비용을 말씀드리기 어렵습니다. 업무 범위와 복잡도에 따라 다르기 때문입니다. 다만 진단에서 현재 상황을 파악하면 바로 견적을 드립니다. 견적은 시작 전에 확정되고, 이후에 추가 비용이 생기지 않는 구조입니다. 비용이 궁금하시다면 서비스 구조 안내 페이지를 먼저 보시는 것도 좋습니다.

"만들어 주고 나서 뭔가 문제가 생기면 어떻게 하나요?"

구축 후 직접 운영하실 수 있도록 인수인계하는 것이 기본입니다. 문제가 생겼을 때 어떻게 대응하는지까지 알려드립니다. 스스로 운영하기 어려운 구조는 처음부터 만들지 않으려 합니다.

어떤 분들이 진단을 찾아오시나

다양한 업종에서 오시지만, 공통점이 있습니다. "이 일이 자동화가 될 것 같은데, 어디서부터 시작해야 할지 모르겠다"는 것입니다.

가장 많은 유형은 특정 반복 업무 하나를 해결하고 싶은 경우입니다. 보험설계사분처럼 PDF를 엑셀로 옮기는 것, 경리 담당자처럼 월말 증빙 정리, 대표님 본인이 다 처리하는 주문 접수와 명세서 발행 같은 것들입니다.

두 번째는 직원이 하나 있는데 그 직원이 반복 업무에 너무 많은 시간을 쓰는 경우입니다. 사람을 더 뽑기 전에 지금 있는 일을 줄일 수 있는지 보고 싶다는 이유로 오시는 분들입니다.

세 번째는 이미 한 번 도구를 도입했는데 제대로 안 된 경우입니다. 앱을 구독했는데 아무도 안 쓴다거나, 자동화를 만들었는데 담당자가 나간 뒤 멈춰있다는 상황입니다. 이런 경우에는 기존에 무엇이 문제였는지 먼저 짚고 시작합니다.

네 번째는 "AI를 써야 한다"는 압박은 느끼지만 어떻게 시작해야 할지 전혀 모르는 경우입니다. ChatGPT를 조금 써봤는데 업무에 어떻게 연결해야 할지 모르겠다는 분들이 여기에 해당합니다. 이런 경우에는 지금 하시는 일 중에서 가장 시간이 많이 걸리는 것 하나를 골라서 거기서부터 시작하는 것을 권합니다.

어떤 상황이든 30분 진단이 목적은 같습니다. 현재 상황을 정확하게 파악하고, 어떤 방향이 맞는지 솔직하게 말씀드리는 것입니다. "됩니다" "안 됩니다" 중 하나가 반드시 나오고, 됩니다면 어떤 방식으로 접근하면 좋은지와 대략적인 기간까지 말씀드립니다.

이런 경우 도움이 됩니다

AI 개발 경험이 있는 분에게 맡기고 싶은데, 실제로 중소기업 업무를 이해하는지 확신이 안 서는 경우가 있습니다. 반대로, 현장 업무는 잘 이해하는데 기술적으로 어떤 것이 가능한지 모르는 경우도 있습니다.

상담에서 자주 받는 이야기는 이렇습니다. "어디선가 자동화가 된다는 말은 들었는데, 우리 회사에 실제로 되는지 모르겠다." 이런 경우에 30분 무료 진단이 도움이 됩니다. 현재 겪고 있는 업무 문제를 그대로 말씀해 주시면, 어디까지 되고 어디서는 안 된다는 것을 솔직하게 말씀드립니다.

됩니다 안 됩니다를 판단하는 것 자체가 출발점입니다. 그 판단을 30분 안에 드리는 것이 진단의 목적입니다.

30분 무료 진단 신청 — 영업 전화 없습니다.