들어가며

우아한테크코스 레벨 2 마지막 주, 제이크가 물류 분야의 문제를 인공지능으로 해결하는 해커톤인 MOVE-AI CHALLENGE 2026을 소개해 주었습니다.

평소 해커톤에 참여하는 것을 좋아하기도 했고, 무엇보다 AI를 활용해 실제 문제를 해결해 보는 경험을 해보고 싶었습니다.

그렇게 팀원을 모았고, 제이크와 아티 그리고 저까지 세 명이 가자IT이라는 팀으로 참가하게 되었습니다.

이번 해커톤은 카카오모빌리티, 한국철도공사, 현대글로비스가 제시한 물류 현장의 문제를 주제로 진행되었습니다. 저희 팀은 그중 카카오모빌리티 트랙에 지원했습니다.

본격적인 해커톤에 앞서 참가자를 대상으로 Build with AI 워크숍이 열렸습니다.

처음에는 Google AI Studio나 Claude Code 같은 도구를 어떻게 사용하는지 배우는 자리라고 생각했습니다. 그런데 막상 다녀오고 보니 특정 도구의 기능보다, AI 시대에 제품을 어떻게 만들어야 하는지에 관한 이야기가 더 오래 기억에 남았습니다.

이번 글에서는 워크숍에서 들었던 내용과, 그 과정에서 제가 어떤 생각을 했는지 정리해 보겠습니다!

<br>

1. Build with AI 워크숍 참가!

워크숍은 Google for Developers가 지원하는 글로벌 AI 캠페인의 하나로, Google AI Studio를 활용한 바이브 코딩 실습과 Claude Code의 실무 활용 사례를 다루는 자리였습니다.

팀 대표로 제가 참석하게 되었고, 2026년 7월 22일 현대글로비스 본사 32층으로 향했습니다.

건물에 도착해 등록을 마치고, 팀 이름이 적힌 명찰도 받았습니다.

가자IT 최고~

행사가 시작되기까지 시간이 조금 남아 건물 내부도 구경했습니다.

행사장이 있는 32층에서는 서울이 한눈에 내려다보였습니다. 역시 한강뷰는 좋은 것 같습니다ㅎㅎ

워크숍에 오기 전에는 AI Studio나 Claude Code의 새로운 기능, 프롬프트 작성법 같은 내용을 많이 배우게 될 것이라고 생각했습니다.

그래서 새로운 기능이 나올 때마다 열심히 메모해야겠다는 생각으로 왔는데, 예상과는 조금 달랐습니다.

워크숍에서 가장 많이 메모한 내용은 특정 모델의 성능이나 도구의 사용법이 아니었습니다. 오히려 AI를 활용해 어떤 방식으로 제품을 만들어야 하는가에 관한 이야기였습니다.

최근 저도 AI를 이용해 여러 아이디어를 구현하고 있었기 때문에, 단순한 도구 설명보다 제품을 만드는 방식에 관한 내용이 더 재미있게 들렸던 것 같습니다.

<br>

2. 코드를 짜지 않고, 지휘합니다

강연이 시작되고 가장 먼저 들었던 문장은 다음과 같았습니다.

코드를 짜지 않고, 지휘합니다.

처음에는 AI가 대신 코드를 작성해 준다는 의미 정도로 이해했습니다.

하지만 강연을 계속 듣다 보니, 단순히 코드를 직접 작성하지 않아도 된다는 이야기는 아니었습니다.

AI가 구현을 맡더라도 무엇을 만들어야 하는지 결정하고, 결과물이 올바른 방향으로 가고 있는지 판단하는 일은 여전히 사람이 해야 합니다.

앞으로의 개발자는 모든 코드를 직접 작성하는 사람이라기보다, 제품의 구조와 목적을 이해한 뒤 AI에게 적절한 역할을 맡기는 사람이 되어야 한다는 이야기로 들렸습니다.

강연에서는 이를 Build Your Own Agent라는 표현으로 설명했습니다.

좋은 에이전트는 세상에서 가장 똑똑한 에이전트가 아니라, 나와 나의 업무를 가장 잘 이해하는 에이전트라고 했습니다.

이를 위해서는 다음과 같은 요소가 필요했습니다.

1. 컨텍스트
2. 스킬과 루틴
3. MCP 연결
4. 권한과 가드레일
5. 피드백
6. 도메인 전문성

반복해서 수행하는 업무는 에이전트의 루틴으로 만들고, 자주 사용하는 도구는 연결해야 합니다.

업무를 이해하는 데 필요한 배경지식도 충분히 제공해야 합니다. 동시에 에이전트가 어디까지 행동할 수 있는지 권한을 정하고, 중요한 결정에는 사람이 개입할 수 있도록 해야 합니다.

생각해 보니 저도 AI를 사용할 때 프롬프트를 어떻게 작성할지만 많이 고민했던 것 같습니다.

하지만 좋은 에이전트는 프롬프트 한 번을 잘 작성한다고 만들어지는 것이 아니었습니다.

AI가 나의 업무를 이해할 수 있도록 필요한 맥락을 제공하고, 반복되는 일의 방식을 알려주고, 결과에 대한 피드백을 계속 쌓아야 합니다.

앞으로는 AI에게 일을 요청할 때 단순히 질문을 잘 작성하는 데서 그치지 않고, 이 AI가 업무를 수행하는 데 필요한 정보와 환경이 충분한지도 함께 살펴봐야겠다는 생각이 들었습니다.

<br>

3. AI 지도를 읽고, 필요한 것을 골라 쓰기

AI 도구는 정말 빠르게 늘어나고 있습니다.

새로운 모델이 출시될 때마다 한 번씩은 사용해 봐야 할 것 같고, 그렇지 않으면 뒤처지는 것 같은 기분이 들 때도 있습니다.

저도 새로운 AI 모델이나 도구가 나오면 어떤 기능이 있는지 찾아보고, 일단 한 번씩 사용해 보는 편이었습니다.

강연에서는 이런 상황을 두고 Read the Map이라는 표현을 사용했습니다.

모든 AI 도구를 모으고 사용해 보는 것보다, 지금 해결하려는 문제에 어떤 도구가 적합한지 판단할 줄 알아야 한다는 이야기였습니다.

코드를 빠르게 작성하고 싶은지, 자료를 정리하고 싶은지, 반복되는 업무를 자동화하고 싶은지에 따라 필요한 AI는 달라집니다.

생각해 보면 저는 순서를 반대로 두고 있었던 것 같습니다.

새로운 AI가 나왔으니 이걸 어디에 사용해 볼지를 고민했는데, 사실은 내가 어떤 문제를 해결하고 싶은지를 먼저 정해야 했습니다.

새로운 도구를 많이 알고 있는 것도 도움이 되겠지만, 모든 도구를 다 사용할 필요는 없습니다.

앞으로는 새로운 AI가 출시될 때마다 무작정 따라가기보다, 지금 하고 있는 일에서 무엇이 불편한지부터 생각해 보려고 합니다.

그다음에 그 문제를 해결하는 데 가장 적합한 도구를 골라 사용하는 편이 훨씬 나을 것 같습니다.

<br>

4. AI가 빨라진 만큼 더 많이 틀려볼 수 있다

강연에서 특히 인상 깊었던 수치가 있었습니다.

AI로 빨라졌다 = 91%
결과에 확신한다 = 15%

AI를 활용하면서 업무와 개발 속도는 빨라졌지만, 만들어진 결과가 정말 올바른지 확신하는 비율은 낮다는 의미였습니다.

AI가 빠르게 결과물을 만들어준다고 해서 좋은 제품이 자동으로 만들어지는 것은 아닙니다.

오히려 구현이 쉬워질수록 어떻게 만들 것인지보다, 무엇을 만들 것인지가 더 중요해지는 것 같습니다.

예전에는 하나의 기능을 구현하는 데 많은 시간과 비용이 들었습니다. 방향을 잘못 잡더라도 이미 들인 비용이 커서 쉽게 다시 시작하기 어려웠습니다.

하지만 AI를 활용하면 작은 아이디어를 실제로 동작하는 결과물로 만드는 시간이 많이 줄어듭니다.

방향이 틀렸을 때 다시 만드는 부담도 예전보다 작아졌습니다.

강연에서는 제품을 만드는 과정을 다음과 같이 설명했습니다.

1. 문제 정의
2. 설계
3. 구현
4. 검증
5. 정제

이 과정을 한 번만 순서대로 수행하는 것이 아니라, 가능한 한 빠르게 반복해야 한다고 했습니다.

3주 동안 진행되는 해커톤이라면 마지막 주에야 완성품을 내놓는 방식보다, 첫 주부터 작게라도 실제로 동작하는 결과물을 만드는 편이 좋습니다.

사용자에게 보여주고, 반응을 확인하고, 방향이 틀렸다면 다시 수정할 수 있기 때문입니다.

최근 저도 제품 아이디어를 검증하며 작은 실험을 여러 번 진행하고 있었습니다.

그 과정에서 느낀 점도 비슷했습니다.

처음부터 많은 기능을 만들기보다 작게 만들고, 빠르게 보여주고, 틀린 부분을 빨리 확인하는 편이 훨씬 나았습니다.

AI는 실패하지 않게 해주는 도구라기보다, 이전보다 더 적은 비용으로 여러 번 시도할 수 있게 해주는 도구에 가까운 것 같습니다.

AI로 아낀 시간을 기능을 더 많이 만드는 데만 사용하기보다, 사용자에게 더 자주 보여주고 가설을 더 많이 확인하는 데 써야겠다는 생각이 들었습니다.

<br>

5. 이론이 아니라 실제로 동작하는 결과물

워크숍에서는 바이브 코딩을 통해 실제 비즈니스 결과로 이어진 사례도 소개되었습니다.

첫 번째는 별도의 개발자 없이 만들어진 물류 솔루션 기업 윌로그의 웹사이트 개선 사례였습니다.

기존 웹사이트에서는 중요한 정보가 여러 페이지에 흩어져 있었고, 사용자가 원하는 솔루션의 상세 정보를 확인하기까지 여러 번 이동해야 했습니다.

이를 개선하기 위해 사용자가 세 번 이내의 이동으로 필요한 정보에 도달할 수 있도록 구조를 단순화했습니다.

짧은 시간 안에 자신에게 적절한 솔루션을 찾을 수 있는 기능도 만들었습니다.

콘텐츠 마케터가 직접 콘텐츠를 관리할 수 있도록 구조를 나누었고, 실제 구현은 AI와 함께 진행했다고 합니다.

약 2개월 동안 한 명이 웹사이트를 구축하고 직접 운영할 수 있었으며, 기존보다 몇 배 높은 효율로 작업할 수 있었다고 소개했습니다.

처음에는 개발자 없이 사이트를 만들었다는 점이 가장 눈에 들어왔습니다.

그런데 내용을 계속 듣다 보니, AI로 사이트를 만들었다는 사실 자체가 가장 중요한 것은 아니었습니다.

기존 웹사이트에서 정보가 제대로 전달되지 않는다는 문제를 발견하고, 사용자가 더 적은 단계로 원하는 정보에 도달하도록 구조를 개선했다는 점이 핵심이었습니다.

AI가 빠른 구현을 도와주었지만, 어떤 부분이 문제인지 찾고 어떻게 바꿀지 결정한 것은 사람이었습니다.

두 번째 사례는 물류 현장의 정보를 보여주는 데모였습니다.

두 명으로 구성된 작은 팀이 다섯 개의 화면과 두 개의 주요 시나리오를 만들었다고 합니다.

사용자가 자연어로 질문하면 현재 상황을 분석하고, 발생할 수 있는 위험을 예측한 뒤 필요한 조치를 제안하는 방식이었습니다.

기존에는 문제가 발생한 뒤 데이터를 확인했다면, 새롭게 만든 데모는 실시간으로 상황을 관찰하고 외부 정보까지 활용해 위험을 예측할 수 있도록 했습니다.

이 데모는 발표로 끝나지 않고, 여러 고객사의 개념 검증으로도 이어졌다고 합니다.

화면은 다섯 개뿐이었지만 고객이 겪고 있는 문제와, 제품을 사용한 뒤 달라지는 모습을 충분히 보여주었습니다.

이 사례를 보며 좋은 데모가 반드시 모든 기능을 갖춘 제품일 필요는 없다는 생각이 들었습니다.

고객이 어떤 문제를 겪고 있고, 제품을 사용하면 무엇이 달라지는지를 하나의 흐름으로 보여줄 수 있다면 적은 수의 화면으로도 제품의 가치를 전달할 수 있었습니다.

해커톤에서도 기능의 개수보다, 우리가 해결하려는 문제를 얼마나 분명하게 보여줄 수 있는지가 더 중요할 것 같습니다.

<br>

6. 화려한 기능보다 명확한 문제

워크숍에서 가장 반복해서 들었던 표현은 Find the Pain이었습니다.

사용자가 실제로 겪고 있는 문제를 먼저 찾아야 한다는 이야기였습니다.

AI 덕분에 기능을 구현하는 일은 점점 쉬워지고 있습니다.

하지만 무엇을 만들어야 하는지는 여전히 사람이 결정해야 합니다.

강연자님께서 내부 해커톤을 진행하며 얻은 교훈으로는 다음 네 가지가 소개되었습니다.

• 자신의 업무에서 문제 찾기
• 빠르게 검증하기
• 뚜렷한 콘셉트 만들기
• 적은 공수로 큰 임팩트 만들기

무엇보다 발표 자료로 끝나는 아이디어보다, 실제로 동작하는 결과물이 중요하다고 했습니다.

내부 해커톤에서 시작한 AI 비서, 회의 전에 제품 요구사항 문서(PRD)를 자동으로 만드는 기능, 공급망 관련 질문에 답하는 봇 등이 이후 사내 제품으로 발전한 사례도 있었습니다.

해커톤을 준비하다 보면 눈에 띄는 기술이나 화려한 기능부터 생각하게 됩니다.

저 역시 카카오모빌리티 트랙을 선택한 뒤 어떤 AI 기능을 넣을 수 있을지 먼저 고민했습니다.

그런데 강연을 듣고 나니 순서가 반대였다는 생각이 들었습니다.

먼저 현장에서 반복해서 발생하는 불편을 찾아야 합니다. 그다음에 그 불편을 해결하는 데 AI가 필요한지 판단해야 합니다.

기능이 많은 서비스보다, 사용자가 화면을 보자마자 “이거 필요했는데”라고 느낄 수 있는 서비스가 더 좋은 결과를 만들 수 있습니다.

아주 작은 기능이더라도 반복되는 불편을 정확히 해결한다면 실제 현장에서는 큰 가치를 만들 수도 있습니다.

이번 해커톤에서도 AI를 사용했다는 사실을 보여주는 것보다, 사용자가 왜 이 기능을 필요로 하는지 분명하게 보여주는 데 더 신경 써야겠습니다.

<br>

7. 물류와 AI가 만나는 지점

물류 분야에서 AI가 잘 활용될 수 있는 영역은 크게 네 가지로 정리되었습니다.

1. 가시성 대시보드
2. 예외 상황과 알림 로직
3. 운영 자동화
4. 개념 검증을 위한 데모

이 영역에는 공통점이 있었습니다.

모두 물류 현장에서 반복해서 발생하는 확인과 판단을 줄여주는 일이었습니다.

물류 현장에서는 수많은 상품과 차량, 일정과 예외 상황이 동시에 움직입니다.

현재 어떤 일이 일어나고 있는지 한눈에 파악하기 어렵고, 작은 이상 상황을 놓치면 더 큰 문제로 이어질 수도 있습니다.

그래서 현재 상태를 잘 보여주는 가시성, 이상 상황을 놓치지 않는 정확성, 반복 업무를 줄이는 생산성이 중요하다고 했습니다.

AI는 흩어진 정보를 정리해 보여주고, 평소와 다른 상황을 찾아내고, 이후에 필요한 행동을 제안하는 데 활용할 수 있습니다.

물론 AI를 적용한다고 모든 판단을 AI에게 맡길 수 있는 것은 아니었습니다.

물류 AI를 만들 때는 데이터 분리, 사람의 승인, 규제 대응도 함께 고려해야 한다고 했습니다.

특히 물류에는 기업과 고객사의 중요한 데이터가 포함될 수 있기 때문에 서로 다른 데이터가 섞이지 않도록 해야 합니다.

배송이나 안전처럼 실제 사람과 물건에 영향을 미치는 결정은 AI가 독단적으로 수행하기보다, 사람이 최종적으로 확인하는 구조가 필요합니다.

강연에서는 이를 Human in the Loop라고 설명했습니다.

규제와 관련된 조건도 문제가 발생한 뒤 확인하는 것이 아니라, 처음부터 에이전트가 참고해야 하는 정보에 포함해야 합니다.

생각해 보면 AI를 잘 만드는 것과, 실제 현장에서 사용할 수 있는 AI를 만드는 것은 꽤 다른 문제였습니다.

기술적으로 동작하더라도 현업의 업무 흐름과 용어를 이해하지 못하면 제대로 된 판단을 하기 어렵습니다.

어떤 판단이 위험으로 이어지는지, 어디에서 반드시 사람이 확인해야 하는지 알려면 도메인에 대한 이해도 필요합니다.

AI가 많은 일을 대신해 주는 시대에도 도메인 지식이 계속 중요하다는 점이 인상 깊었습니다.

<br>

8. 좋은 에이전트 시스템은 좋은 조직을 닮았다

워크숍에서 가장 마음에 들었던 표현은 다음 문장이었습니다.

좋은 에이전트 시스템은 좋은 조직을 닮았다.

여러 개의 에이전트를 연결한다고 해서 자동으로 좋은 시스템이 만들어지는 것은 아닙니다.

각 에이전트가 어떤 역할을 맡는지, 어디까지 행동할 수 있는지, 어떤 기준을 따라야 하는지, 언제 사람이 개입해야 하는지가 명확해야 합니다.

강연에서는 오케스트레이션(Orchestration) 이라고 표현했습니다.

개별 에이전트를 많이 만드는 것보다, 서로 다른 역할을 가진 에이전트를 하나의 목적에 맞게 움직이도록 만드는 일이 더 중요했습니다.

생각해 보면 사람으로 구성된 조직도 비슷합니다.

능력이 좋은 사람이 많다고 해서 반드시 좋은 팀이 되는 것은 아닙니다.

각자의 역할과 권한이 명확해야 하고, 모두가 같은 목표를 바라보고 있어야 합니다.

에이전트 시스템에도 비슷한 요소가 필요했습니다.

• 각각의 역할
• 행동할 수 있는 권한
• 따라야 하는 원칙
• 사람이 개입해야 하는 지점
• 함께 달성해야 하는 목적

앞으로 개발자는 에이전트를 많이 만드는 능력뿐 아니라, 문제를 적절하게 나누고 각 에이전트에게 역할을 맡기는 능력도 필요할 것 같습니다.

AI가 만든 결과를 그대로 받아들이지 않고, 각 결과가 하나의 목적에 맞게 연결되고 있는지도 판단해야 합니다.

저도 평소 AI에게 큰 작업을 한 번에 요청하고 결과를 기다릴 때가 많았습니다.

앞으로는 작업을 더 작게 나누고, 각 단계에서 어떤 역할을 맡길지 정한 뒤 결과를 확인하는 방식으로 사용해 봐야겠습니다.

<br>

9. AI가 만드는 것은 70%, 나머지는 사람의 안목이다

강연 후반부에는 Taste Is the Multiplier라는 표현이 소개되었습니다.

AI는 결과물의 기본적인 완성도를 빠르게 높여줍니다.

과거에는 많은 시간과 경험이 필요했던 결과물도 이제는 AI를 이용해 비교적 짧은 시간 안에 일정 수준까지 만들 수 있습니다.

강연에서는 AI를 활용하면 결과물의 약 70%까지는 빠르게 완성할 수 있다고 설명했습니다.

다만 나머지 30%는 AI가 알아서 채워주지 않습니다.

어떤 문제를 선택할지, 어떤 사용자 경험이 더 자연스러운지, 어떤 기능을 추가하고 무엇을 제거할지, 어디까지 자동화하고 어느 지점에서 사람이 확인할지, 이런 결정은 결국 사람이 내려야 합니다.

같은 AI를 사용하더라도 사람마다 결과물이 달라지는 이유도 여기에 있는 것 같습니다.

어떤 사람은 기능을 계속 추가하고, 어떤 사람은 핵심만 남깁니다.

어떤 사람은 새로운 기술을 먼저 보여주려 하고, 어떤 사람은 사용자가 겪고 있는 불편을 먼저 살펴봅니다.

생각해 보니 AI가 빠르게 만들어준 초안을 수정하는 과정에서도 비슷한 경험을 자주 했습니다.

AI가 작성한 결과가 틀린 것은 아니지만, 제가 원하는 느낌과는 다른 경우가 많았습니다.

어떤 문장을 남기고 지울지, 어떤 흐름이 더 자연스러운지, 사용자에게 정말 필요한 기능이 무엇인지는 결국 제가 판단해야 했습니다.

AI가 일정 수준의 결과물을 빠르게 만들어준다면, 그다음부터는 그동안 쌓아온 경험과 취향이 결과물의 차이를 만드는 것 같습니다.

이제 AI를 잘 사용하는 방법만큼, 좋은 제품과 좋은 사용자 경험을 구분할 수 있는 안목도 함께 길러야겠다는 생각이 들었습니다.

<br>

마치며

이번 워크숍은 AI Studio나 Claude Code의 사용법만 배우는 자리가 아니었습니다.

본격적인 해커톤을 시작하기 전에, AI 시대에 제품을 만드는 방식을 다시 생각해 볼 수 있는 시간이었습니다.

특히 다음 세 가지를 실제 해커톤 준비 과정에서도 계속 기억해 보려고 합니다.

• AI로 아낀 시간은 더 많은 가설을 검증하는 데 사용하기
• 화려한 기능보다 현장에서 반복되는 불편 하나를 제대로 해결하기
• 물류 도메인 지식에 대해 공부하고 이해하기

그리고 이번 해커톤에서는 멋진 기능을 많이 만드는 것보다, 사용자가 실제로 불편하게 느끼는 문제 하나를 끝까지 해결해 보고 싶습니다.

AI를 이용해 빠르게 만들되, 지금 만들고 있는 것이 정말 필요한 것인지는 계속 의심해 보려고 합니다.

워크숍을 마친 뒤에는 참가 기념품으로 카카오 캐릭터가 그려진 마우스패드도 받았습니다. 아주 귀엽네요.

이번 글은 여기서 마무리 하겠습니다! 긴 글 읽어주셔서 감사합니다~!