[AX] 비개발자 팀을 위한 첫 Claude Hands-on, 그리고 내가 놓친 것들

AWS Summit 2026 

AWS Summit Seoul 2026에서 여러 세션들을 들은 후, 팀 전체의 AI 활용 능력을 높이는 것이 현재 가진 많은 문제들을 가장 효과적으로 해결할 수 있는 방법이라는 생각을 했다. 이에 대한 배경은 이전글에서 자세히 확인할 수 있다. 

회사에 의견을 공유한 후, 전사 대상 2회 세미나를 진행할 기회를 얻었다. 

 

첫 세미나를 준비하여 나침반이 되어준 글

 

세미나를 기획하는 동안 가장 많이 펼쳐본 글이 있다. 힐링페이퍼 이윤혁 님이 공유한 AX Voyage 2026 라는 글이다.

이 글은 조직 전체가AI 를 도입하고 활용해 나가는 과정을 풀어낸다. 나의 첫 세미나를 준비하면서 내가 고민했던 거의 모든 결정이 이 글에서 출발했다. 같은 맥락의 내용을 담은 인터뷰 youtube 영상도 있다. 이 영상도 준비하는 동안 반복해서 돌려봤고 많은 도움이 되었다. 

 

세미나의 구성을 결정하기까지

내가 이 세미나에서 가장 만들고 싶었던 결과는 두 가지였다. 

• "나도 해볼 수 있겠는데 ?" 라는 감각
  • 글에서 "쟤도 했다 = 나도 할 수 있겠다"의 문법은 어떤 교육보다 강력하다" 라고 설명하는 부분이 있다. 정교한 기술 설명이 아니라, "어, 저 정도면 나도 ?" 하는 심리적 문턱을 낮추는 것이 무엇보다 중요할거라고 생각했다
• AI 를 수족처럼 사용하는 것에 대한 동경
  • "사람들에게 배 만드는 법을 가르치고 싶으면, 배 만드는 매뉴얼을 들이밀지 말고 바다를 동경하게 하라" 

문제는 어떤 형식으로 세미나를 구성해야 이걸 가장 잘 만들어줄 수 있느냐였다. 

단순히 Claude 의 사용법 : Skill 이 무엇인지, Chat/Cowork/Code 가 무엇인지 등을 설명하는 것은 첫 세미나에서는 적절하지 않다고 판단했다. 직접 손으로 뭔가를 만들어보고, "아, 이런게 되는구나 ! 나도 충분히 이런걸 만들 수 있구나 !" 를 느끼는 경험이 가장 빠른 길이라고 봤다. 그래서 Hands-on 형식으로 기획했다.

 

첫 Hands-on 에서 만들기로 결정한 것

세미나에서 진행한 Hands-On 내용은 Github 실습 폴더에서 확인해보실 수 있습니다. 

 

다같이 만들 것은 네이버 파워링크 광고 순위 확인 도구로 정했다. 

이 도구는 팀에서 이미 필요하다는 이야기가 나왔었지만, 우선순위가 높은 개발 feature 가 잔뜩 쌓여서 미뤄지기만 했던 기능이었다. 

만들고 나서 실제로 사용하게 될 도구를 만들게 하고 싶었다. (원래 개발팀에 요청하고 한참 있다가 만들어졌는데.. 내가 만들 수 있네 ?)

 

형식은 Skill 하나를 같이 만들어보는 걸로 정했다.

이건 의도가 있었다. "Skill 만드는 게 진짜 어려운 게 아니다"를 보여주고 싶었다.

AI Agent로 뭔가를 만든다고 하면 거창하게 느껴지지만, 실제로는 마크다운 파일 하나로 시작할 수 있다는 걸 손으로 확인하게 하고 싶었다. 그래서 Skill을 더 쉽게 만들 수 있도록 도와주는 Skill 두 개를 미리 준비해뒀다.

• /sharpen : 막연한 아이디어를 명확한 요구사항 명세서로 다듬어주는 Skill
• /productify : 명세서를 받아서 어떤 형태로 만들지(Skill인지, 스크립트인지) 결정해주는 Skill

이건 김윤혁님이 공유해주신 자료에서 가져왔다(귀한 자료 공유해주셔서 정말X100 감사합니다 ㅠㅠ) 

사용자가 요구사항을 명확하게 정의하는 게 어렵다는 걸 알았기 때문에, 이 부분 자체를 AI가 도와주도록 설계된 Skill이었다.

 

그리고 만에 하나 시간 안에 완성하지 못하는 분들을 위한 대비도 했다. Git 저장소에 두 개의 브랜치를 준비해뒀다 (세션의 목표가 "직접 만들어보는 경험"이긴 했지만, 못 만든다고 해서 빈손으로 돌아가게 하고 싶지 않았다)

 

• handson 브랜치 : 실습용. 처음부터 같이 만들어 나가는 출발점
• main 브랜치 : 완성본. 실습이 막히더라도 main으로 이동하면 동작하는 결과물을 바로 써볼 수 있게 해둠

 

Hands-on 기술 스택 선택 : Claude Code + VS Code + 터미널

이 결정이 나중에 가장 큰 실수로 돌아왔다.
나는 Claude Desktop 보다 Claude Code (터미널 방식)를 쓰는 게 훨씬 낫다고 판단했다. 이유는 아래와 같았다

• Skill을 만들고 확인하는 게 훨씬 쉽다
• 내가 만들어둔 Skill들이 GitHub에 있어서 `git clone`으로 바로 받을 수 있다
  • 실습 중 skill 만들기에 실패할 경우 main 브랜치로 이동하여 완성된 skill 을 사용해볼 수 있다.
• GitHub 중심의 Claude Code 생태계와 잘 맞는다

내가 그동안 참석했던 개발자 Hands-on 들이 대부분 이런 방식이었다. 미리 준비된 저장소를 clone 받고, 브랜치를 따라가면서 단계별로 실습하는 흐름. 내 입장에서는 이게 가장 따라가기 쉬운 방식이었고, 막혔을 때 다음 브랜치로 넘어가서 계속 진행할 수 있다는 점이 특히 좋았다. 그래서 이번 세션도 자연스럽게 같은 방식으로 설계했다 (빅 미스테잌 ,,)

 

Hands-on 구성

세션은 크게 세 파트로 나눴고, 발표 자료는 Notion 으로 준비했다. 

 

Part 1. 왜 AI인가 — 기술이 아니라 태도에 대한 이야기

두 가지를 전달했다.

1. AI를 잘 활용하는 사람은 기술을 잘 아는 사람이 아니라, 문제를 잘 정의하는 사람이다.
   • AI 는 결국 위임이고, 위임을 잘 하려면
     1. 정확한 디렉션
     2. 결과를 평가할 줄 아는 눈, 이 두가지가 필요하다
2. 여러분은 도메인을 알고 있다.
   • AE 분들과 대화하면서 느낀 건, 이미 문제가 뭔지 알고 어떻게 해결해야 할지도 어느 정도 알고 계신다는 것. 그러니 AI 활용법만 조금 더해지면 충분히 효율적으로 일할 수 있다.

 

그리고 — "꼭 해야 한다"고 말하고 싶지 않았다

내가 세션 내내 강조한 메시지가 있었다. 

AI를 사용하지 않으면 비효율적으로 일하는 거다,
AI를 쓰는 사람과 안 쓰는 사람은 앞으로 더 격차가 벌어질 거다
— 오늘 이런 얘기는 하지 않겠습니다 !!!

 

요즘 어디서든 AI 관련 기술을 안 쓰면 큰일 난다는 식의 이야기가 너무 많다. 

솔직히 나도 그런 메시지에 좀 지쳐 있는 상태였다(AI 라는 단어가 이젠 좀 징그럽기도 하다)

세션을 준비하면서 가장 경계한 게 이거였다. 나도 싫어하는 말을 말을 굳이 다른 사람에게 하고 싶지 않았다.

 

사람마다 변화를 받아들이는 속도는 다르고, 각자 잘하는 영역도 다르다.

AI 활용이 누군가에게는 빠르게 와닿을 수 있지만, 다른 누군가에게는 조금 더 시간이 필요한 일일 수 있다. 

그래서 톤을 이렇게 잡았다.

오늘은 그냥 가볍게 ! 쟤가 무슨 말 하는지 들어나 보자 ~
그냥 가볍게 찍먹해 보자, 하는 마음으로 임해주셨으면 좋겠습니다.

 

 

이 메시지를 처음에 명확하게 깔아둔 이유는, 압박감을 느끼는 상태에서는 어떤 내용도 제대로 들어오지 않는다고 생각했기 때문이다. 

"지금 안 하면 큰일 난다"는 분위기에서 학습이 일어나기는 어렵다. 

그보다는 부담을 내려놓은 상태에서 한두 가지라도 자기 것으로 가져갈 수 있다면 그게 훨씬 더 가치 있다고 봤다.

 

 

Part 2. 데모 먼저 — "이게 되는구나"부터 보여주기

이론을 끝낸 직후, 바로 완성된 Skill을 시연했다.

 

/naver-ad-rank 비염치료기 / 무선 비염치료기, 노즈굿

 

이 한 줄을 입력하면 Claude가 네이버 파워링크 광고 순위를 가져와서 알려주는 모습을 보여줬다. 

결과를 먼저 본 다음에 만드는 과정으로 넘어가는 순서를 의도적으로 짰다.

"내가 두 시간 뒤에 완성할 수 있는 것" 을 미리 눈으로 볼 수 있게 했다. 

 

 

Part 3. 환경 설정

Node.js, Git, Claude Code 설치 및 로그인.

준비한 GitHub 저장소를 clone 받고, `handson`

 브랜치로 이동시키는 것까지가 이 단계의 목표였다.

 

 

Part 4. 직접 만들기 — Skill을 Skill로 만든다

이 파트가 이번 세션에서 보여주고 싶었던 핵심이었다. 흐름은 이렇게 짰다.

 

1단계. MVP 개념 공유

"네이버 광고 1위를 유지한다"는 큰 목표를 그대로 만들려고 하면 끝이 없다는 걸 먼저 짚었다. 

업무를 작은 단위로 쪼개고, 작게 시작해서 동작하는 걸 확인하는 게 먼저라는 메세지를 전달하고 싶었다. 

2단계. SKILL.md 구조 보여주기

Claude의 Skill은 .claude/skills/ 폴더 안에 SKILL.md 파일 하나로 만들어진다는 걸 보여줬다. (마크다운 파일 하나면 된다 !)

Skill 이 사실 거창한 게 아니라는 걸 시각적으로 확인하게 하는 게 목표였다.

3단계. /sharpen으로 아이디어 다듬기

여기서부터가 이번 세션의 가장 보여주고 싶었던 흐름이었다. 

아이디어를 다듬는 것은 /sharpen 스킬과 함께라면 아래와 같이 막연한 한 줄로 시작할 수 있다.  

네이버 파워링크 광고 순위를 확인하고 싶습니다. 
키워드와 내 광고 제목을 입력하면 현재 몇 위인지 알려주는 것을 만들고 싶어요. /sharpen

/sharpen이 문답으로 누가, 왜, 어떤 조건에서, 어디까지를 묻기 시작한다. 

몇 번의 대화만으로 막연했던 아이디어가 명확한 요구사항 명세서로 정리되는 과정을 직접 보여주고, 경험할 수 있게 했다. 

 

 

4단계. /productify로 형태 결정하기

/sharpen이 만든 명세서를 /productify에 넘긴다. 

이 skill 은 명세서를 받아서 "이걸 Claude Skill로 만들지, 파이썬 스크립트로 만들지, 단계별 로드맵은 어떻게 가져갈지"를 결정해주는 역할을 한다. 가장 작은 형태로 시작할 수 있도록 범위를 잡아준다.

 

5단계. 실제 Skill 생성

 

/productify가 결정한 형태대로 실제 SKILL.md가 만들어진다. 즉, Skill을 만드는 데 Skill을 사용하는 흐름이었다. 

AI Agent로 뭔가를 만든다는 게 거창하게 느껴질 수 있지만, 결국 대화 몇 번이면 목표 지점에 도달할 수 있다는 걸 손으로 확인하게 하고 싶었다.

6단계. 만든 Skill 사용해보기

마지막으로, 방금 만든 Skill을 직접 실행해보고 동작하는지 확인한다. 

처음에 보여줬던 데모와 같은 결과가, 이번엔 본인이 만든 Skill로 나오는 순간이 이 세션의 도착점이었다.

 

진행하고 나서

솔직히 말하면, Part 2. 환경 설정에서 무너졌다 ! 

 

처음 환경 설치에만 40~50분이 걸렸고, 진행이 막힌 분들이 있었지만 모두 해결하고 갈 수 없다고 판단되어 설명은 계속 이어졌다. 

나중에 피드백으로 들은 말이 "제가 진행하는 과정은 멈춰있는데 설명은 이어나가셔서 혼동이 있었다"였다.

 

근본 원인은, 내가 개발자 입장에서 "이 정도면 쉬울 것"이라고 판단한 방식이, 사실은 전혀 쉬운 게 아니었다. 미리 준비된 저장소를 clone 받고 브랜치로 이동하는 흐름은 내가 그동안 좋다고 느꼈던 방식이었지만, 그 판단의 기준 자체가 이미 개발자 중심이었다.

비개발자 입장에서는 그 흐름의 어떤 부분도 자연스럽지 않을 수 있다는 걸 처음부터 인지하면 좋았을텐데.. 

 

세션이 끝나고 받은 질문은 그 사실을 가장 분명하게 보여줬다.

그래서 "VS Code랑 터미널이 어떻게 다른 건가요?"

 

이 질문을 받은 순간 좀 띵했다. 완전히 잘못 설계했구나 싶었다. 

나는 세션 초반에 "VS Code는 텍스트 편집기예요"라고 짧게 설명하고 넘어갔는데, 그게 전혀 와닿지 않았던 거다. 

그래서 세션이 다 끝나고 나서야 이 질문이 나온 거였고.

 

이 질문 자체가 신호였는데, 세션이 끝나는 시점에 이 질문이 나왔다는 건, 처음부터 마지막까지 그 차이를 이해하지 못한 채로 따라오고 있었다는 뜻이었다.

환경 설정도, Skill 만들기도, 결국 어디서 무엇을 하는 건지 명확히 잡히지 않은 상태에서 진행됐던 거다.

 

그래서 2회차부터는 Claude Desktop으로 전환하여 설명하도록 계획을 변경했다. 

 

피드백으로 보는 1차 Hands-on

• 전반적 만족도: 평균 4.7점 / 5점
• 어려웠던 부분: 3명 중 2명이 환경 설정, 1명이 "스킬이 뭔지 이해하기"
• 다음 세션 참여 의사: 3명 중 2명 "네, 이미 써볼 업무가 떠올랐어요"

의도한 메시지가 통했던 지점

• "문답 방식의 AI만 보다가 처음 보는 형식의 AI 사용 방식이 신선해서 기억에 남습니다."
  • 이건 Part 4에서 보여주려던 흐름이 그대로 닿았다는 신호였다. 챗봇처럼 묻고 답하는 게 전부가 아니라, 명령어 한 줄로 동작하는 도구를 직접 만들 수 있다는 감각.
• "AI가 요구사항을 구체화 하는 과정에서 질문사항의 퀄리티가 높아서 잘 사용하면 업무에 많은 도움이 되겠다라고 생각되었습니다."
  • 이 응답이 개인적으로 가장 반가웠다. Part 1에서 "AI를 잘 활용한다는 건 문제를 잘 정의하는 것"이라고 말로 했지만, 그건 사실 말로 해서는 잘 안 와닿는 부분이다. 근데 `/sharpen`이 직접 문답하면서 막연한 요구사항을 다듬어가는 모습을 보면서 그 메시지를 참여자가 직접 체감한 거였다. 

 

의도한 메시지가 통하지 않은 지점

• "오늘 가장 어려웠던 부분: 스킬이 뭔지 이해하기"
• "개발 기초 지식이 없어 스킬이라는 자체를 어떻게 만들어야 할지 어렵게 느껴집니다. 다른 사람이 만든 걸 복사 붙여넣기 한다고 해도 어디를 커스텀, 수정하면 내 스킬로 만들 수 있을지 모르겠습니다."

이게 환경 설정 문제보다 더 본질적인 실패였다.

이번 세션의 가장 큰 의도가 "Skill 만드는 게 어렵지 않다"를 보여주는 거였는데,

정작 한 분은 Skill 개념 자체가 손에 잡히지 않은 채로 세션이 끝났다.

 

원인을 돌이켜보면, 환경 설정에서 시간을 너무 많이 쓴 영향이 컸다. 

정작 핵심이었던 Part 4에 도달할 즈음에는 이미 집중력이 흩어진 상태였다. 

결과적으로 Skill을 만드는 과정이 참여자가 따라오는 속도보다 빠르게 흘러갔고, "이게 어떻게 동작하는 건지"를 충분히 짚어주지 못했다.

준비할 때 가장 보여주고 싶었던 것이 정작 가장 덜 전달된 부분이 됐다는 게 아쉬웠다.

단순히 환경 설정 설치가 오래 걸린 것 보다, 가장 중요한 대목인 Part 4 에 도달할 에너지를 깎아먹은 게 문제였다. 

 

 

준비하면서 배운 것

• 상대방의 '당연함'을 기준으로 설계해야 한다.
  • 나한테 당연한 것들이 상대방에겐 전혀 당연하지 않았다. 터미널, 영어 에러 메시지, VS Code와 터미널의 차이. 이걸 처음에 몰랐다.

• 첫 번째 시도는 언제나 뭔가를 잘못 전제하고 있다.
  • 1회차에서 명확하게 틀린 지점이 드러났다. 이 경험이 없었다면 2회차도 같은 방식으로 갔을 거다.
  • 결국 첫 시도가 가지는 가치는 "어디가 안 통하는지"를 알게 되는 거였다.

준비를 10시간이나 했음에도 환경 설정에서 무너진 게 속상하긴 하다.. 

그렇지만 이런건 14시간을 더 써서 시뮬레이션을 돌렸봤어도 혼자서는 알 수 없었을 부분이라고 생각한다. 

실제 사람을 앞에 두고 진행해봐야만 보이는 것들이 있었다.

 

 

앞으로

2회차에서는 기술 스택을 전부 바꿨다. 터미널과 VS Code, Git을 모두 빼고 Claude Desktop으로 간다 !

그 과정과 결과는 ~ 에 별로도 정리했다.