러닝 오퍼튜니티스 - 클로드 코드와 코덱스에서 의도적 기술 개발을 돕는 스킬

에이전틱 코딩을 하면서 프로젝트만이 아니라 사용자의 전문성도 키우도록 돕는 클로드 코드 및 코덱스용 스킬 새 파일 생성, 스키마 변경, 리팩터링 같은 아키텍처 작업을 마친 뒤 클로드가 10~15분짜리 선택형 학습 연습을 제안함 연습은 예측, 생성, 인출 연습, 간격… 러닝 오퍼튜니티스 - 클로드 코드와 코덱스에서 의도적.

스킬의 목적

에이전틱 코딩을 하면서 프로젝트만이 아니라 사용자의 전문성도 키우도록 돕는 클로드 코드 및 코덱스용 스킬 새 파일 생성, 스키마 변경, 리팩터링 같은 아키텍처 작업을 마친 뒤 클로드가 10~15분짜리 선택형 학습 연습을 제안함 연습은 예측, 생성, 인출 연습, 간격… 러닝 오퍼튜니티스 - 클로드 코드와 코덱스에서 의도적 기술 개발을 돕는 스킬 (github.com/DrCatHicks)11P by GN⁺ 19일전 | ★ favorite | 댓글 1개 에이전틱 코딩을 하면서 프로젝트만이 아니라 사용자의 전문성도 키우도록 돕는 클로드 코드 및 코덱스용 스킬 새 파일 생성, 스키마 변경, 리팩터링 같은 아키텍처 작업을 마친 뒤 클로드가 10~15분짜리 선택형 학습 연습을 제안함 연습은 예측, 생성, 인출 연습, 간격 반복 같은 학습과학 기법을 사용하며, 사용자의 실제 프로젝트 작업에서 반쯤 풀린 예제를 만들어 줌 인공지능 코딩 도구가 생성 코드 수용, 유창성 착각, 장시간 몰아치기, 메타인지 부족, 자기 테스트 감소를 유발할 수 있다는 문제를 줄이도록 설계됨 클로드는 “이 주제로 짧은 학습 연습을 해볼까요?

약 10~15분입니다”처럼 묻고, 사용자가 수락하면 대화형 연습을 진행함 핵심 설계 원칙은 클로드가 자기 질문에 답하지 않고 사용자 입력을 기다리는 것이며, 빠른 agentic coding과 다른 반성·탐색 모드를 만들도록 의도됨 연습 유형에는 예측→관찰→성찰, 생성→비교, 실행 경로 추적, 디버깅 예측, 새 개발자에게 설명하기, 이전 세션 내용 인출 점검이 포함됨 현재 제안된 억제 조건은 한 세션에서 이미 연습을 거절했거나, 한 세션에서 연습을 2번 완료했을 때 학습 기회를 다시 제안하지 않는 것임 러닝 오퍼튜니티스-auto는 Linux와 macOS에서 git commit 뒤 클로드가 연습 제안을 고려하게 하는 선택형 훅이며, Windows도 추가 설정으로 사용할 수 있음 orient 스킬은 새 저장소를 배울 때 orientation.md를 만들고, 프로그램 이해와 코드베이스 탐색 연구에 기반한 추천 레슨을 제공함 Learning-Goal과 함께 쓰기 좋으며, 해당 스킬은 대화형 목표 설정 방식 기법으로 반구조화된 대화형 학습 목표 설정을 돕는다고 소개됨 팀 실험에는 MEASURE-THIS.md를 함께 사용할 수 있고, 검증된 설문 문항, 결과 해석 가이드, 리더십 공유용 “team boast” 템플릿, 클로드.md 통계 엄밀성 넛지를 제공함 Creative Commons Attribution 4.0 International License로 라이선스됨 GeekNews Weekly에 포함된 글입니다.

에디터 코멘트 보기 이제 공부도 클로드 코드로 해보세요!

학습 진행 방식

geo-seo-claude - 클로드 코드용 GEO 우선 SEO 스킬 클로드 코드 에도 /goal 기능 추가 첫 시도는 95%가 쓰레기: 클로드 코드와 함께한 Staff Engineer의 여정 클로드 코드를 만들며 배운 것: 우리가 Skills를 사용하는 방법 Skills는 잘 모르지만, 저장소를 보니 커밋 뒤 실행되는 bash 스크립트 안의 짧은 프롬프트 하나에 비해 장식적인 코드와 텍스트가 과해 보임 핵심은 사용자가 방금 커밋했으니 새 파일, 스키마 변경, 아키텍처 결정, 리팩터링, 낯선 패턴이 있으면 10~15분짜리 학습 연습을 제안하라는 내용에 가까움 Skills는 반복 가능한 작업 흐름을 표준적으로 설명하고, 점진적 공개로 문맥을 아끼며, 프롬프트를 공유하고, 잘 안 쓰이지만 비결정적인 부분을 스크립트 같은 결정적 절차로 묶는 데 유용함 개념적으로는 남이 만든 마법을 가져다 쓰는 게 아니라 점진적으로 키우는 소프트웨어로 봐야 함

코딩 하네스에는 SkillBuilder 에이전트 스킬이 있는 경우가 많아서 만들기 쉽고 계속 발전시킬 수 있음 자기 고충에 맞게 직접 만드는 걸 추천하며, 평가를 통해 자동화의 정확도를 충분히 끌어올리는 간단한 예도 있음

이런 도구의 대부분은 결국 프롬프트에 끼워 넣는 또 다른 Markdown 파일이고, 대규모 언어 모델이 동작하는 방식상 정상적인 구조임 그래서 클로드로 자기만의 비슷한 도구를 만들라고 권하고 싶음.

설치와 제약

처음엔 토큰을 쓰지만 이후에는 자체 도구로 의미 있는 작업에 필요한 토큰과 호출을 크게 줄일 수 있음 도구 호출도 더 안전하게 잠그고, 에이전트 작업을 재시도 가능하게 만들고, 실패 모드도 줄 수 있음.

노트북이 작업 중 꺼지면 에이전트가 어디까지 했는지 되살리느라 토큰을 많이 태우는 상황도 피할 수 있음 어떤 Skills는 정확한 절차나 해야 할 일을 쓰지도 않고, 특정 작업에서 모델이 더 나은 텍스트를 내도록 동기부여 연설처럼 프라이밍만 하는 수준이라 놀랐음 클로드가 쓰는 frontend design skill도 좋은 글꼴을 고르고 디자인을 일관되게 하라고 거의 부탁하는 정도이며, 어떤 글꼴을 쓰거나 색상 팔레트와 레이아웃을 어떻게 만들라는 구체성은 없음 코드 작성 에이전트에는 반복적인 부채가 생길 수 있음.

코딩 어시스턴트의 결과를 맞는지 확인하지 않고 받아들이면 자기 코드베이스에 대한 지식이 사라짐 CLAUDE.md 같은 문맥 파일, 마이그레이션 프로토콜, 인증 프로토콜은 그것들을 제대로 갱신할 만큼 충분히 이해하고 있을 때만 잘 작동함 에이전트가 만든 코드를 두 시간 동안 맹목적으로 받아들인 뒤, 코드베이스가 어떻게 돌아가는지 잊어서 새 문맥 파일을 만들 수 없었던 적이 있음.

팀 활용 포인트

이런 스킬 부채는 diff에는 안 보이고, 에이전트를 이끌어야 하는 순간 드러남 반복적이라기보다 재귀적인 것 아닐까 싶음 큰 기능 변경을 할 때는 에이전트에게 코드를 쓰게 하기 전에 먼저 채팅에서 해결하려는 비즈니스 도메인 문제에 합의하는 게 좋음.

외주 개발사 담당자와 앉아 원하는 것을 정리하는 느낌임 그다음 에이전트와 함께 계층형 bullet의 설계 문서를 실제 .md 파일로 작성하고, 에이전트가 대부분 생성·수정하게 하되 문제와 모호한 결정을 꼼꼼히 따져서 설계 수준의 결정을 여기서 미리 끝내야 함 이어서 설계 명세를 BDD 명세 테스트 묶음의 골격으로 바꾸게 하고, 구현하면서 채우게 함 구현 단계에서는 단위 테스트와 통합 테스트를 추가·수정·삭제해도 되지만, 설계 명세 파일과 거기서 파생된 BDD 테스트 구조는 고정해야 함.

완료 전에는 BDD 테스트가 라벨에 맞는 로직으로 채워지고 모두 통과해야 함 프로젝트가 매우 크면 새 비즈니스 요구사항 정의, 설계 수정, BDD 묶음 추가 같은 과정을 다시 반복하는 스프린트를 돌릴 수 있음.

원문: GeekNews 기사 보기