# Learning Opportunities - Claude Code와 Codex에서 의도적 기술 개발을 돕는 스킬 > Clean Markdown view of GeekNews topic #29531. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29531](https://news.hada.io/topic?id=29531) - GeekNews Markdown: [https://news.hada.io/topic/29531.md](https://news.hada.io/topic/29531.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-05-15T10:29:29+09:00 - Updated: 2026-05-15T10:29:29+09:00 - Original source: [github.com/DrCatHicks](https://github.com/DrCatHicks/learning-opportunities) - Points: 2 - Comments: 1 ## Topic Body - **에이전틱 코딩**을 하면서 프로젝트만이 아니라 **사용자의 전문성**도 키우도록 돕는 Claude Code 및 Codex용 스킬 - 새 파일 생성, 스키마 변경, 리팩터링 같은 **아키텍처 작업**을 마친 뒤 **Claude가 10~15분짜리 선택형 학습 연습을 제안**함 - 연습은 **예측, 생성, 인출 연습, 간격 반복** 같은 학습과학 기법을 사용하며, 사용자의 실제 프로젝트 작업에서 반쯤 풀린 예제를 만들어 줌 - AI 코딩 도구가 생성 코드 수용, 유창성 착각, 장시간 몰아치기, 메타인지 부족, 자기 테스트 감소를 유발할 수 있다는 문제를 줄이도록 설계됨 - Claude는 “이 주제로 짧은 학습 연습을 해볼까요? 약 10~15분입니다”처럼 묻고, 사용자가 수락하면 **대화형 연습**을 진행함 - 핵심 설계 원칙은 Claude가 자기 질문에 답하지 않고 **사용자 입력을 기다리는 것**이며, 빠른 agentic coding과 다른 반성·탐색 모드를 만들도록 의도됨 - 연습 유형에는 예측→관찰→성찰, 생성→비교, 실행 경로 추적, 디버깅 예측, 새 개발자에게 설명하기, 이전 세션 내용 인출 점검이 포함됨 - 현재 제안된 억제 조건은 한 세션에서 이미 연습을 거절했거나, 한 세션에서 연습을 2번 완료했을 때 학습 기회를 다시 제안하지 않는 것임 - Codex에서는 `codex plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git`로 마켓플레이스에 추가할 수 있고, `learning-opportunities`, `learning-opportunities-auto`, `orient`가 포함됨 - Claude Code에서는 [Claude Code plugin marketplace](https://docs.claude.com/en/docs/claude-code/plugins)로 추가한 뒤 `/plugin install learning-opportunities@learning-opportunities`를 설치하고 재시작해 활성화함 - `learning-opportunities-auto`는 Linux와 macOS에서 git commit 뒤 Claude가 연습 제안을 고려하게 하는 선택형 훅이며, Windows도 [추가 설정](https://github.com/DrCatHicks/learning-opportunities-auto/README.md#windows-setup)으로 사용할 수 있음 - `orient` 스킬은 새 저장소를 배울 때 `orientation.md`를 만들고, 프로그램 이해와 코드베이스 탐색 연구에 기반한 추천 레슨을 제공함 - [Learning-Goal](https://github.com/DrCatHicks/learning-goal)과 함께 쓰기 좋으며, 해당 스킬은 MCII 기법으로 반구조화된 대화형 학습 목표 설정을 돕는다고 소개됨 - 팀 실험에는 [MEASURE-THIS.md](https://github.com/DrCatHicks/learning-opportunities/docs/MEASURE-THIS.md)를 함께 사용할 수 있고, 검증된 설문 문항, 결과 해석 가이드, 리더십 공유용 “team boast” 템플릿, Claude.md 통계 엄밀성 넛지를 제공함 - [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/)로 라이선스됨 ## Comments ### Comment 57525 - Author: neo - Created: 2026-05-15T10:29:30+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48130679) - Skills는 잘 모르지만, 저장소를 보니 커밋 뒤 실행되는 bash 스크립트 안의 짧은 프롬프트 하나에 비해 **장식적인 코드와 텍스트**가 과해 보임 핵심은 사용자가 방금 커밋했으니 새 파일, 스키마 변경, 아키텍처 결정, 리팩터링, 낯선 패턴이 있으면 **10~15분짜리 학습 연습**을 제안하라는 내용에 가까움 - Skills는 반복 가능한 작업 흐름을 표준적으로 설명하고, 점진적 공개로 문맥을 아끼며, 프롬프트를 공유하고, 잘 안 쓰이지만 비결정적인 부분을 스크립트 같은 **결정적 절차**로 묶는 데 유용함 개념적으로는 남이 만든 마법을 가져다 쓰는 게 아니라 **점진적으로 키우는 소프트웨어**로 봐야 함 [https://alexhans.github.io/posts/series/evals/building-agent...]() 코딩 하네스에는 SkillBuilder 에이전트 스킬이 있는 경우가 많아서 만들기 쉽고 계속 발전시킬 수 있음 자기 고충에 맞게 직접 만드는 걸 추천하며, 평가를 통해 자동화의 정확도를 충분히 끌어올리는 간단한 예도 있음 [https://alexhans.github.io/posts/series/evals/sketch-to-text...]() - 이런 도구의 대부분은 결국 프롬프트에 끼워 넣는 또 다른 **Markdown 파일**이고, 대규모 언어 모델이 동작하는 방식상 정상적인 구조임 그래서 Claude로 자기만의 비슷한 도구를 만들라고 권하고 싶음. 처음엔 토큰을 쓰지만 이후에는 자체 도구로 의미 있는 작업에 필요한 토큰과 호출을 크게 줄일 수 있음 도구 호출도 더 안전하게 잠그고, 에이전트 작업을 재시도 가능하게 만들고, 실패 모드도 줄 수 있음. 노트북이 작업 중 꺼지면 에이전트가 어디까지 했는지 되살리느라 토큰을 많이 태우는 상황도 피할 수 있음 - 어떤 Skills는 정확한 절차나 해야 할 일을 쓰지도 않고, 특정 작업에서 모델이 더 나은 텍스트를 내도록 **동기부여 연설**처럼 프라이밍만 하는 수준이라 놀랐음 Claude가 쓰는 frontend design skill도 좋은 글꼴을 고르고 디자인을 일관되게 하라고 거의 부탁하는 정도이며, 어떤 글꼴을 쓰거나 색상 팔레트와 레이아웃을 어떻게 만들라는 구체성은 없음 [https://github.com/anthropics/claude-code/blob/main/plugins/...]() - 코드 작성 에이전트에는 **반복적인 부채**가 생길 수 있음. 코딩 어시스턴트의 결과를 맞는지 확인하지 않고 받아들이면 자기 코드베이스에 대한 지식이 사라짐 CLAUDE.md 같은 문맥 파일, 마이그레이션 프로토콜, 인증 프로토콜은 그것들을 제대로 갱신할 만큼 충분히 이해하고 있을 때만 잘 작동함 에이전트가 만든 코드를 두 시간 동안 맹목적으로 받아들인 뒤, 코드베이스가 어떻게 돌아가는지 잊어서 새 문맥 파일을 만들 수 없었던 적이 있음. 이런 **스킬 부채**는 diff에는 안 보이고, 에이전트를 이끌어야 하는 순간 드러남 - 반복적이라기보다 재귀적인 것 아닐까 싶음 큰 기능 변경을 할 때는 에이전트에게 코드를 쓰게 하기 전에 먼저 채팅에서 해결하려는 **비즈니스 도메인 문제**에 합의하는 게 좋음. 외주 개발사 담당자와 앉아 원하는 것을 정리하는 느낌임 그다음 에이전트와 함께 계층형 bullet의 설계 문서를 실제 `.md` 파일로 작성하고, 에이전트가 대부분 생성·수정하게 하되 문제와 모호한 결정을 꼼꼼히 따져서 설계 수준의 결정을 여기서 미리 끝내야 함 이어서 설계 명세를 BDD 명세 테스트 묶음의 골격으로 바꾸게 하고, 구현하면서 채우게 함 구현 단계에서는 단위 테스트와 통합 테스트를 추가·수정·삭제해도 되지만, 설계 명세 파일과 거기서 파생된 BDD 테스트 구조는 고정해야 함. 완료 전에는 BDD 테스트가 라벨에 맞는 로직으로 채워지고 모두 통과해야 함 프로젝트가 매우 크면 새 비즈니스 요구사항 정의, 설계 수정, BDD 묶음 추가 같은 과정을 다시 반복하는 스프린트를 돌릴 수 있음. 또는 2단계와 3단계 사이에 설계를 마일스톤으로 나누고, 현재 마일스톤에 대해서만 BDD 항목을 만들고 해결하게 할 수 있음 결국 LLM에는 **워터폴 방식**을 쓰자는 얘기임. 전체 과정이 한 시간 안에 끝난다면 워터폴도 꽤 쾌적할 수 있음 핵심은 프로젝트나 마일스톤이 끝난 뒤 에이전트가 작성한 코드를 채팅에서 설명하게 하되, 설계에서 이미 드러난 내용은 설명하지 말라고 제한하는 것임 그러면 놀라운 부분에 대한 설명을 코드 주석으로 바꾸게 할 수 있고, 그 결과는 형식적인 쓰레기 주석이 아니라 사람이 쓸 법한 주석이 됨 - **벤치마크와 평가**가 없는데 `/create-skill`보다 더 나은 결과를 낸다는 걸 어떻게 알 수 있나? 순진한 테스트로는 신뢰가 생기지 않음 - 여기서 말하는 건 사람의 **스킬 개발**인 것 같음. 사용자에게 학습 기회를 제공하는 기능임 아키텍처 작업을 끝냈을 때 Claude가 근거 기반 학습 과학에 기반한 선택적 10~15분짜리 연습을 제안한다는 설명이 있음. 예측, 생성, 인출 연습, 간격 반복 같은 기법을 써서 자기 프로젝트 작업에서 반쯤 완성된 예제를 제공하는 방식임 이름은 헷갈림 - LLM에 너무 절어 있어서 관련 용어만 나와도 **파블로프식 반응**이 튀어나오는 상태 같음 - 평가를 꺼낸 건 좋은데, 지금은 뭘 쓰거나 무엇을 찾는지 궁금함. 직접 만들고 있는지, 기존 **평가 프레임워크**를 쓰는지도 알고 싶음 - 아직 이 토끼굴에 안 들어간 사람들을 위해 말하면, Skills는 좁은 범위의 작업을 어떻게 처리할지 설명하는 **구조화된 Markdown 파일**임 예를 들어 API 엔드포인트를 특정 방식으로 작성한다면, 그 절차를 skill에 적어둠. 나중에 에이전트가 이 skill을 보고 현재 채팅 문맥에 관련 있다고 판단하면 불러와서 지시된 대로 수행함 도구 호출과 비슷하지만 호출 가능한 함수가 아니라 그 “스킬”을 수행하는 방법에 대한 지침임 적어도 내가 쓰는 Cline에서는 Skills를 전역 또는 프로젝트 수준 로컬로 정의할 수 있음 - Skills에는 **frontmatter**라는 헤더도 있고, 그 일부가 CLAUDE.md 파일처럼 문맥 초반에 공유됨 여기서 들은 바로는 skill 로드가 압축 이후에도 남는 등 문맥에 별도 영향을 줄 수 있음 여러 skill을 로드하면 세션에 영구적으로 로드된 상태가 될 수도 있음 subagent와 잘 맞는다고 봄. subagent가 skill을 로드해 작업을 끝내고 결과만 제시하면, 오케스트레이터 에이전트는 그 내용을 몰라도 됨 - **adaptive dynamic textbook approach**가 정확히 뭔지 모르겠음. 예시가 필요함 생성된 코드를 받아들이고 스스로 코드를 덜 만들면 이해를 쌓는 능동 처리를 건너뛰게 된다는 말은 정말 맞음 - 이런 멋진 아이디어를 만들면서 **데모나 샘플 출력** 링크를 안 넣는 수고를 왜 감수하는지 이해가 안 됨. HN에서 매일 보는 패턴임 이 skill이 실제로 어떻게 보이는지 확인하려면 직접 내려받아 실행하는 방법뿐인가? 그러고 싶진 않음 - 아직은 skill 사용이 AGENTS.md의 명확한 지시보다 훨씬 덜 안정적으로 느껴짐 관련 없을 때 skill을 추가하지 않아 문맥 비대를 피한다는 아이디어는 이해하지만, AGENTS.md에 명시적 지시가 없으면 에이전트가 skill을 쓴다는 보장이 없음. 그러면 어느 위치에 참조된 Markdown 파일과 다를 바가 적어짐 [https://www.agentkanban.io]()를 만들면서, GitHub Copilot 통합 작업 보드에 지시를 어디에 둘지 많이 실험했음 AGENTS.md에서 한 단계 떨어진 구조는 꽤 잘 작동했음. 작업별 ID를 에이전트가 안정적으로 집어오게 해야 해서, 도구가 관리하는 파일 안에 `INSTRUCTION.md`를 두는 방식으로 정착했고 AGENTS.md 오염도 줄일 수 있었음 Skills도 실험했지만 너무 자주 건너뛰어서, 지금 방식만큼 안정적으로 도구를 작동시키기 어려웠음 - `SKILL.md`가 바로 있으니 그냥 읽어보면 무엇을 하는지 알 수 있음 - 아이디어가 정말 마음에 듦. Claude에게 오픈소스 교재와 문서를 써서 즉석에서 교재를 만들게 한 적이 있음 이 skill을 더 일반적인 **학습·응용 영역**으로 확장할 수 있는지, 아니면 코드에 특화된 것인지 궁금함 - 여기 반응이 흥미로운데, 대부분 핵심을 놓치는 것 같음 나에게 중요한 교훈은 다른 사람들이 **Skills를 어떻게 쓰는지** 보고 배우는 데 있음. 어제 Matt Pocock의 에이전트 활용 수업을 보는데, 제품 요구사항 문서를 발전시키기 위해 “grill-me” skill을 쓰는 식으로 Skills를 보여줬음 그가 하는 걸 그대로 하지는 않겠지만, 요구사항을 만들고 구현하는 방식에 대한 내 아이디어는 생겼음 Anthropic 엔지니어들의 표현대로 Claude는 재능 있는 엔지니어 같지만 전문성이 부족함. Skills는 전문성을 쌓는 폴더와 파일임 Pocock에게서 배운 또 하나는 문맥이나 토큰 크기가 길어질수록 응답이 멍청해지는 경향이 있다는 것임. 그래서 Skills는 문제를 LLM에 압축된 형태로 제시하고 최적화된 응답을 얻는 또 다른 방법임 Claude에는 행동 특성도 있음. 누군가 반복적으로 skill을 만들면 다른 사용자에게 잘 이식되지 않을 가능성이 큼. 각자 Claude와 대화하는 방식이 다르기 때문임 그래서 내 skill 폴더를 동료들에게 공유하는 건 망설여짐. 대신 내가 만든 것을 데모로 보여줘서 가능한 일을 보고 각자 자기 작업 흐름을 찾게 할 생각임 가치는 다른 사람이 Claude로 어떻게 만드는지 보고 자기 방식으로 흉내 내는 데 있음. 처음 프로그래밍을 배울 때 Kernighan과 Ritchie의 C 책에서 코드를 베껴 치고, 동작을 이해하려고 바꿔보다가 나중에 목적에 맞게 고쳤던 것과 비슷함 행동 특성을 꺼낸 또 다른 이유는 저자가 심리학자라서 Claude와 상호작용하는 방식이 프로그래머와 꽤 다를 가능성이 흥미롭기 때문임 관련해서 저자와 여러 분야 전문가들이 오래전에 Twitter를 떠났다고 하니, bsky나 Mastodon을 설치해서 팔로우하려 함. 전문가인 비프로그래머들이 LLM을 어떻게 쓰는지 지켜보는 게 중요하다고 생각함 - 좋은 아이디어라서 오늘 아침에 이것저것 탐색해 봤음 AI를 너무 많이 쓰면서 **두뇌 유출** 같은 느낌을 강하게 받았고, 이게 완전한 해결책은 아니지만 하루에 몇 가지 연습을 하는 것만으로도 꽤 도움이 될 수 있다고 봄