Learning Opportunities - Claude Code와 Codex에서 의도적 기술 개발을 돕는 스킬

• 에이전틱 코딩을 하면서 프로젝트만이 아니라 사용자의 전문성도 키우도록 돕는 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로 추가한 뒤 /plugin install learning-opportunities@learning-opportunities를 설치하고 재시작해 활성화함
• learning-opportunities-auto는 Linux와 macOS에서 git commit 뒤 Claude가 연습 제안을 고려하게 하는 선택형 훅이며, Windows도 추가 설정으로 사용할 수 있음
• orient 스킬은 새 저장소를 배울 때 orientation.md를 만들고, 프로그램 이해와 코드베이스 탐색 연구에 기반한 추천 레슨을 제공함
• Learning-Goal과 함께 쓰기 좋으며, 해당 스킬은 MCII 기법으로 반구조화된 대화형 학습 목표 설정을 돕는다고 소개됨
• 팀 실험에는 MEASURE-THIS.md를 함께 사용할 수 있고, 검증된 설문 문항, 결과 해석 가이드, 리더십 공유용 “team boast” 템플릿, Claude.md 통계 엄밀성 넛지를 제공함
• Creative Commons Attribution 4.0 International License로 라이선스됨

[GN⁺]

Hacker News 의견들

• 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를 너무 많이 쓰면서 두뇌 유출 같은 느낌을 강하게 받았고, 이게 완전한 해결책은 아니지만 하루에 몇 가지 연습을 하는 것만으로도 꽤 도움이 될 수 있다고 봄