🤖
1308 in / 3777 out / 5085 total tokens
Claude Code가 개발자 학습 도구로 쓰이기 시작했고, Simon Willison이 AI 벤더 락인 문제가 완화되고 있다고 진단했다. Mitchell Hashimoto의 발언도 같은 맥락에서 주목받고 있다. 하나씩 파보자.
🔥 핫 토픽
Claude Code와 Codex를 활용한 의도적 스킬 개발 도구
https://github.com/DrCatHicks/learning-opportunities
핵심은 "그냥 코드 짜달라"가 아니라, AI를 의도적으로 학습 파트너로 쓰는 프레임워크를 만들었다는 거다. 이 저장소는 Claude Code와 OpenAI Codex에 프롬프트 스킬을 부여해서, 개발자가 특정 기술을 deliberate practice(의도적 수련)할 수 있게 도와준다. 단순히 "이거 해줘"가 아니라, 학습 목표를 설정하고 AI가 그 목표에 맞는 과제를 생성하고 피드백을 주는 식이다.
게임 개발에 비유하자면, 그냥 몬스터 잡는 거랑 훈련장에서 스탯 찍으며 콤보 연습하는 거의 차이다. 전자는 경험치는 오르는데 실력은 모르겠고, 후자는 약하지만 정확하게 성장한다. 이 도구는 후자의 방식을 AI 코딩에 적용한 셈이다.
실무 관점에서 보면, Claude Code 같은 도구는 이미 "일단 코드 뱉어" 용도로 널리 쓰이고 있다. 그런데 이걸 학습 컨텍스트로 재구성한 게 의미 있다. 특히 주니어 개발자들이 시니어의 코드 리뷰를 받기 어려운 환경에서는, AI가 그 역할을 부분적으로 대체해줄 수 있다. 프롬프트 스킬 구조를 보면, 단순히 정답을 주는 게 아니라 질문을 던지고 사고 과정을 유도하는 방식으로 설계되어 있다.
UE5 C++ 작업할 때도 비슷한 접근이 가능하다. 예를 들어 "언리얼의 가비지 컬렉션 시스템을 이해하고 싶다"고 하면, AI가 UPROPERTY 매크로 하나하나 왜 필요한지 물어보면서 과제를 줄 수 있다. 물론 AI가 완벽한 멘토는 아니지만, 적어도 방향을 잡아주는 나침반 역할은 한다. 이 프로젝트가 Hacker News에서 218점을 받은 건, 많은 개발자가 "AI를 어떻게 학습에 써야 할지" 고민하고 있었다는 방증이다.
기술 배경을 조금 덧붙이면, 이건 Claude Code의 커스텀 스킬 시스템을 활용한 거다. Claude Code는 사용자가 정의한 규칙과 컨텍스트를 프로젝트 단위로 관리할 수 있다. 이 저장소는 그 기능을 학습 특화 프롬프트로 확장한 것이다. 비슷한 접근을 다른 도구에도 적용할 수 있어서, 확장성이 좋은 아이디어다.
출처: learning-opportunities - GitHub
"더 이상 락인이 아니다" — Simon Willison의 분석
https://simonwillison.net/2026/May/14/not-so-locked-in/#atom-everything
Simon Willison이 AI 생태계의 벤더 락인이 크게 완화되었다고 분석했다. 핵심 주장은, Claude, GPT, Gemini 같은 모델 간 전환이 예전보다 훨씬 쉬워졌다는 거다. OpenAI API 쓰다가 Anthropic으로 옮기는 게 더 이상 엄청난 공사가 아니다.
왜 그러냐면, 프롬프트 엔지니어링이 표준화되고 있고, 래퍼 라이브러리들이 추상화 계층을 제공하기 때문이다. LiteLLM 같은 도구 하나면 provider만 바꿔서 여러 모델을 같은 인터페이스로 쓸 수 있다. 이건 게임 서버 아키텍처에서 말하는 "인터페이스 기반 설계"랑 같은 원리다. 특정 구현체(모델)에 종속되지 않게 추상화해두면, 나중에 교체할 때 드는 비용이 최소화된다.
실제로 Willison은 자신의 프로젝트에서 여러 모델을 섞어 쓰고 있다고 한다. Claude는 긴 컨텍스트 분석에, GPT는 코드 생성에, Gemini는 멀티모달 작업에. 이런 식으로 모델별 강점을 조합하는 패턴이 점점 일반화되고 있다. 개발자 입장에서는 하나의 벤더에 올인할 필요가 없어진 거다.
서버 개발자 시각에서 보면 이건 진짜 중요하다. 게임 서버 만들 때 AWS에 락인되는 게 무서워서 멀티클라우드 아키텍처를 고민하잖나. AI도 마찬가지다. 어느 날 OpenAI가 가격 올리거나 Anthropic이 API 정책 바꾸면, 대안이 없으면 치명타다. 그런데 이제 전환 비용이 낮아졌으니, 협상력이 개발자에게 넘어온 셈이다.
물론 완전히 락인이 사라진 건 아니다. 각 모델의 특성에 맞춘 프롬프트 튜닝은 여전히 필요하고, 모델별 미묘한 차이(예: Claude는 시스템 프롬프트를 다르게 처리함)는 존재한다. 하지만 방향성은 분명히 열린 생태계 쪽으로 가고 있다. Willison이 이걸 강조한 건, 개발자들이 "불안해서 하나의 모델에 종속되는" 패턴에서 벗어나야 한다는 메시지 때문이다.
앞서 언급한 Claude Code 학습 도구와도 연결된다. 저 도구는 Claude Code와 Codex(OpenAI)를 동시에 지원한다. 이게 가능한 것 자체가 락인 완화의 증거다. 하나의 모델에 종속되지 않고 여러 AI를 학습 파트너로 활용하는 접근이 자연스러워지고 있다.
출처: Not so locked in any more - Simon Willison
Mitchell Hashimoto가 말하는 AI 인프라의 현재
https://simonwillison.net/2026/May/14/mitchell-hashimoto/#atom-everything
Mitchell Hashimoto는 HashiCorp 공동창업자이자 인프라 업계의 살아있는 전설이다. Vagrant, Terraform 만든 사람. 이런 사람이 AI 인프라에 대해 발언했다는 것 자체가 시사점이 크다. 인프라 설계의 관점에서 AI를 어떻게 바라보고 있는지를 엿볼 수 있기 때문이다.
Hashimoto의 핵심 포인트는 AI 모델이 인프라의 새로운 계층으로 자리잡고 있다는 거다. 클라우드가 IaaS, PaaS, SaaS로 나뉘듯이, AI도 모델 계층, 오케스트레이션 계층, 애플리케이션 계층으로 분화되고 있다. 그리고 각 계층에서 상호운용성이 중요해지고 있다. 이건 앞서 Willison이 말한 "락인 완화"와 같은 방향이다.
게임 서버 개발자 입장에서 흥미로운 건, Hashimoto가 강조하는 "인프라 as code" 철학이 AI에도 적용된다는 거다. Terraform으로 AWS 리소스를 코드로 관리하듯, AI 파이프라인도 코드로 정의하고 버전 관리해야 한다. 모델 선택, 프롬프트 템플릿, 평가 메트릭을 모두 코드로. 이렇게 하면 모델 교체도, A/B 테스트도, 롤백도 가능하다.
실무적으로는, AI 사이드프로젝트를 만들 때 이 구조를 처음부터 고려해야 한다. 나도 처음엔 Claude API를 하드코딩해서 호출하다가, 나중에 Gemini로 바꾸려고 수정하다가 지옥을 경험했다. Hashimoto 식으로 말하면, 그건 인프라를 코드로 관리하지 않은 것이다. 추상화 계층을 하나 두면, API 키 교체나 모델 변경이 설정 파일 수정 하나로 끝난다.
또 한 가지 주목할 점은 Hashimoto가 AI의 비결정성을 인프라 문제로 접근한다는 거다. 같은 입력에 다른 출력이 나오는 건, 전통적인 인프라에서는 버그지만 AI에서는 피처다. 이걸 어떻게 관리할 것인가. 그의 제안은 관측 가능성(observability)을 높이는 거다. AI 호출 로그, 응답 품질 메트릭, 비용 추적을 체계적으로 해야 한다는 거다. 게임 서버에서 플레이어 행동 로그를 수집하는 것과 같은 원리다.
세 개의 뉴스를 관통하는 키워드는 "개발자 주권"이다. Claude Code 학습 도구는 AI를 수동적 도구가 아니라 능동적 학습 파트너로 쓰는 방법을 보여주고, Willison의 분석은 벤더 종속 없이 여러 모델을 자유롭게 선택할 수 있는 환경을 설명하며, Hashimoto의 관점은 그 선택을 인프라 레벨에서 체계적으로 관리하는 방법을 제시한다. 개발자가 AI를 더 주도적으로, 더 현명하게 활용하는 방향으로 생태계가 진화하고 있는 거다.
출처: Quoting Mitchell Hashimoto - Simon Willison
AI는 도구다. 주인이 아니다. Claude든 GPT든, 내가 선택하고 내가 제어하고 내가 학습에 쓴다. 그게 개발자 주권이다.