Claude Code 생태계에는 흥미로운 패턴이 있어요. 커뮤니티가 불편함을 해결하기 위해 도구를 만들면, 얼마 지나지 않아 Claude Code가 그 기능을 흡수하여 공식적으로 제공합니다.
반복 실행을 위한 Ralph Loop, 모바일 제어를 위한 Happy, 스킬 활성화를 위한 Hook 패턴, 멀티에이전트 오케스트레이션을 위한 Swarm과 GSD, 병렬 격리를 위한 Worktree 패턴, 세션 간 기억을 위한 Handoff 마크다운까지. 생태계가 원해서 만들었던 것을 Claude Code가 흡수하는 일이 반복되고 있죠.
이번 글에서는 생태계에서 시작해 Claude Code에서 공식 지원하는 몇 가지 기능을 언급하고 분석하려 합니다. 그리고 이 모든 변화 속에서 변하지 않는 것, 즉 개발자가 진짜 키워야 할 역량에 대해 이야기해볼게요.
Claude Code에 "이 작업을 계속해"라고 말할 수 없던 시절이 있었습니다. 작업이 끝나면 세션이 종료되고, 사용자가 다시 프롬프트를 입력해야 했거든요. 이 문제를 해결한 것이 Geoffrey Huntley의 Ralph Wiggum Loop입니다.
https://ghuntley.com/ralph/이름은 심슨즈 캐릭터에서 따왔지만, 개념은 단순하면서도 강력해요. while true 루프로 Claude Code에 프롬프트를 반복 투입하는 bash 스크립트입니다.
Ralph Loop는 빠르게 바이럴됐습니다. 이런 기사들이 있었습니다.
그리고 Anthropic은 결국 공식 Ralph Wiggum 플러그인을 직접 만들었습니다.
https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum이 밖에도 Continuous Claude(Ralph + PR 자동화), runCLAUDErun(macOS 네이티브 스케줄러) 등 다양한 변형이 생태계에 등장했습니다.
그리고 2026년 3월, Claude Code에 /loop 명령어가 공식적으로 추가됐습니다.
/loop 5m check the deploy처럼 간격과 프롬프트를 전달하면 세션 내 cron 작업으로 반복 실행됩니다. 세션당 최대 50개 태스크, 3일 후 자동 만료. bash 스크립트를 짤 필요도, 플러그인을 설치할 필요도 없어졌어요.
커뮤니티에서 시작된 아이디어가 공식 플러그인을 거쳐 네이티브 명령어가 되기까지. 이 흐름이 이 글 전체를 관통하는 패턴이에요.
로컬에서만 동작하는 Claude Code의 특성상, "어디서든 Claude Code를 돌리고 싶다"는 욕구는 강렬했습니다. 커뮤니티는 다양한 방법을 시도했어요.
SSH + tmux + Tailscale
커뮤니티에서 핫했던 방식은 SSH + tmux + Tailscale 조합이었습니다. Android의 Termux나 iOS의 Termius로 SSH 접속해서 tmux 세션에 붙는 방식이죠. Harper Reed는 이 방식으로 tmux에서 12개 Claude Code 인스턴스를 동시에 돌렸는데, 본인 말로는 "2000년대 초반 프로그래밍 같다"고 했습니다.
- https://www.skeptrune.com/posts/claude-code-on-mobile-termux-tailscale/
- https://petesena.medium.com/how-to-run-claude-code-from-your-iphone-using-tailscale-termius-and-tmux-2e16d0e5f68b
Telegram/Discord Bot
Telegram/Discord 봇을 만들어 메시징 앱에서 Claude Code를 제어하는 방식도 등장했습니다. Claude-Code-Remote는 Email, Discord, Telegram을 통해 원격 제어하고 완료 알림까지 받을 수 있었어요.
Happy
그러다 Happy가 등장합니다. E2E 암호화, 푸시 알림, 음성 입력까지 갖춘 오픈소스 모바일 클라이언트예요.
https://happy.engineering/저도 사실은 Telegram/Discord Bot까지의 UI/UX가 마음에 들지 않아 개인적으로 remote 환경 GUI를 만들고 있었습니다. 가명은 claude-code-everywhere였죠.
그리고 Happy를 보고 관뒀습니다. 충분히 제 니즈를 만족할만한 서비스였거든요.
2026년 2월 25일, Anthropic이 공식 Remote Control을 발표했습니다(Max 구독 대상 Research Preview). claude remote-control 명령어 하나로 로컬 세션을 claude.ai나 모바일 앱에서 이어서 사용할 수 있게 됐어요.
SSH 터널도, 서드파티 앱도 필요 없습니다. outbound-only HTTPS, short-lived credentials 기반의 보안 아키텍처로 방화벽 규칙 변경도 불필요해요. VentureBeat는 이를 "Claude Code의 모바일 버전"이라고 보도했습니다.
SSH+tmux로 20분을 세팅하던 시절에서, 명령어 한 줄이면 끝나는 시대가 됐어요. 제가 직접 만들던 도구도, Happy 같은 서드파티도, 모두 네이티브에 흡수되는 흐름이에요. 저는 정말 잘 활용하고 있습니다.
Claude Code의 스킬 시스템에는 근본적인 문제가 있었어요. 스킬은 공식적으로 "model-invoked", 즉 Claude가 자율적으로 판단해서 로딩하는 구조입니다. 그런데 실제로는 잘 발동되지 않았어요.
650건의 자동화 테스트 결과, 기본 활성화율은 약 50%에 불과했습니다. 동전 던지기 수준이죠. GitHub 커뮤니티 논의에서는 런타임 오케스트레이터의 공격적 최적화가 원인이라는 분석이 나왔어요. context saturation을 방지하려고 정적 프롬프트(스킬 설명)를 무시하는 거였습니다. 버그가 아니라 의도된 최적화의 부작용이에요.
커뮤니티는 여러 방향으로 해결을 시도했습니다.
첫 번째 접근은 description 최적화였어요. "ALWAYS invoke when..." 같은 Directive 스타일 설명문이 100% 활성화를 달성할 수 있다는 것이 밝혀졌습니다. 하지만 이 방식은 모든 스킬을 항상 로딩하려는 부작용이 있었죠.
두 번째는 UserPromptSubmit Hook을 이용한 강제 평가입니다. 프롬프트가 제출될 때마다 Hook이 가로채서 "evaluate → activate → implement" 3단계 시퀀스를 주입하는 방식이에요.
https://gist.github.com/umputun/570c77f8d5f3ab621498e1449d2b98b6이 패턴으로 84-100% 활성화율을 달성할 수 있었고, Coding Nexus, claudefa.st 등에서 다양한 변형이 공유됐습니다. Scott Spence는 forced-eval과 llm-eval 두 접근법이 Sonnet 4.5 환경에서 모든 테스트 케이스에 대해 완벽한 활성화를 달성했다고 보고했어요.
세 번째는 subagent 기반 명시적 평가 시스템입니다. 저도 이 문제를 직접 겪었고, skill-manager라는 subagent를 만들어 해결했어요. Main Agent가 모든 판단을 직접 수행하면 context window 압박으로 스킬 발동이 누락되는 문제가 있었거든요. 그래서 매 요청마다 skill-manager가 trigger 키워드와 의도를 분석해서 어떤 스킬을 활성화할지 명시적으로 평가하고, 결과를 summary.json에 캐싱하는 구조를 만들었습니다.
이 과정을 별도 포스트로 정리하기도 했는데, 핵심은 "암묵적 판단에 의존하지 말고 명시적으로 확인하라"는 거였어요. 실제로 이 방식으로 스킬 발동 누락, 순서 오류, 일관성 부족 문제가 많이 개선되었습니다.
이외에도 cc-plugin-eval(4단계 평가 프레임워크), claude-skills-cli(CLI로 Hook 생성/스킬 관리) 등 다양한 도구가 등장했습니다.
2026년 3월 3일, Anthropic이 skill-creator에 Eval, Benchmark, Improve 모드를 추가했습니다.
https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills4개의 서브에이전트(executor, grader, comparator, analyzer)가 병렬로 스킬을 평가하고, Blind A/B 비교까지 수행해요. 코드를 작성하지 않아도 스킬의 활성화율과 품질을 정량적으로 테스트하고 개선할 수 있게 된 거예요.
https://tessl.io/blog/anthropic-brings-evals-to-skill-creator-heres-why-thats-a-big-deal/Minko Gechev는 이를 "AI 에이전트 스킬에 대한 유닛 테스트"라고 표현했습니다. 모델 업데이트 시 스킬 회귀를 자동 감지하고 수정할 수 있는 인프라가 갖춰진 거죠. /simplify, /batch 같은 번들 스킬도 추가되며, 스킬 시스템 자체의 안정성도 계속 높아지고 있어요.
커뮤니티가 Hook 패턴과 CLI 도구로 해결하던 스킬 활성화 문제를, 이제 Anthropic이 공식 eval 인프라로 풀어가고 있어요. 저도 skill-manager subagent를 직접 만들어 쓰고 있지만, 이런 네이티브 지원이 확대되면 결국 더 간단한 방식으로 수렴하게 될 거예요.
subagent의 구조적 구성은 subagent 등장 이후 커뮤니티에서 뜨거운 감자였습니다. 커뮤니티의 많은 개발자들이 여러 에이전트가 팀으로 협업하는 시스템을 만들기 시작했어요.
Swarm 계열 도구들이 먼저 등장했습니다. ccswarm은 Rust로 작성된 멀티에이전트 오케스트레이션 시스템으로, Frontend, Backend, DevOps, QA 등 전문화된 에이전트 풀을 worktree 격리 환경에서 조율합니다. Claude Squad는 여러 AI 터미널 에이전트를 별도 워크스페이스에서 관리하는 터미널 앱이고요.
GSD(Get Shit Done)는 다른 접근을 취했어요. "Lean Orchestrator" 패턴으로 오케스트레이터는 컨텍스트의 15%만 사용하고, 나머지는 신선한 서브에이전트에 위임합니다. 컨텍스트 부패(context rot)를 방지하기 위해 상태를 파일로 외부화하는 게 핵심이에요.
https://github.com/gsd-build/get-shit-doneSuperpowers는 TDD, 체계적 디버깅, 브레인스토밍, 서브에이전트 기반 코드 리뷰 등을 조합 가능한 스킬로 제공하는 프레임워크입니다. Anthropic 공식 플러그인 마켓플레이스에도 등록됐어요.
https://github.com/obra/superpowers이 밖에도 Oh My Claude Code(OMC)(32개 특화 에이전트, 40개 스킬), Agent Farm(20개+ 에이전트 병렬 실행) 등 다양한 도구가 쏟아졌습니다.
2026년 2월 5일, Opus 4.6 출시와 함께 Claude Code가 Agent Teams를 공식적으로 지원하기 시작했습니다(Research Preview). 서브에이전트의 단방향 통신을 넘어, 에이전트 간 양방향 메시징이 가능한 구조예요.
https://code.claude.com/docs/en/agent-teams리드 세션이 팀을 조율하고, 공유 태스크 리스트로 의존성을 추적하며, 메일박스 시스템으로 에이전트끼리 직접 소통합니다. Addy Osmani는 연구/리뷰, 새 모듈 개발, 디버깅, 크로스레이어 조율 등의 효과적인 사용 사례를 정리하기도 했어요.
https://alexop.dev/posts/from-tasks-to-swarms-agent-teams-in-claude-code/커뮤니티가 만든 Swarm, GSD, Superpowers의 핵심 아이디어가 네이티브 Agent Teams에 녹아들었어요. Task Tool → Subagent → Agent Teams로 이어지는 진화 과정은 생태계와 네이티브의 공진화를 잘 보여줍니다.
여러 Claude Code 세션을 동시에 돌리면 서로의 코드를 덮어쓰는 문제가 있었습니다. 헤비유저들은 git worktree를 활용해 각 세션에 독립된 작업 디렉토리를 제공하는 패턴을 만들어냈어요.
Parallel Code는 Claude Code, Codex CLI, Gemini CLI를 각각의 worktree에서 나란히 실행하는 도구를 만들었고, xlaude는 Rust CLI로 worktree를 자동 생성/관리하는 도구를 제공했습니다. incident.io는 실무에 이 패턴을 적용해 배포 속도를 높인 경험을 공유하기도 했어요.
커뮤니티의 수요가 얼마나 강했는지는 GitHub Issues에서 잘 드러납니다. worktree 기본값 설정, bare repository 지원, submodule 호환성 등 수십 개의 요청이 올라왔거든요.
2026년 2월 19일(v2.1.49), Claude Code가 --worktree (또는 -w) 플래그를 공식 지원하면서, 별도 도구 없이도 격리된 환경에서 병렬 작업이 가능해졌습니다.
Desktop 앱에서는 "+ New session" 클릭만으로 각 세션이 자동으로 독립된 worktree를 받습니다. 서브에이전트에도 worktree 격리를 적용할 수 있고, WorktreeCreate/WorktreeRemove 훅으로 커스텀 설정까지 가능해요.
Anthropic 엔지니어링 블로그에서는 16개의 병렬 Claude 에이전트가 약 2,000개의 세션을 통해 10만 줄 규모의 Rust C 컴파일러를 만든 사례를 공개했는데, 이것이 바로 worktree 격리의 가능성을 보여준 대표적인 프로젝트입니다.
https://www.anthropic.com/engineering/building-c-compiler한 개발자는 자신이 만든 커스텀 worktree 스킬을 Claude Code 공식 훅으로 대체한 경험을 공유했어요. 네이티브가 생태계를 흡수하는 전형적인 사례죠.
Claude Code의 가장 큰 약점 중 하나는 세션이 종료되면 이전 맥락을 잊는다는 거였어요. 커뮤니티는 다양한 방식으로 이 문제를 해결하려 했습니다.
가장 단순한 방법은 Handoff Markdown이었습니다. 세션 종료 전에 "HANDOFF.md에 남은 계획, 시도한 것, 성공한 것, 실패한 것을 작성하라"고 지시하는 패턴이에요.
https://blackdoglabs.io/blog/claude-code-decoded-handoff-protocol https://github.com/thedotmack/claude-mem이 수동 패턴을 자동화한 도구들도 등장했습니다. claude-mem은 세션 중 Claude의 모든 행동을 자동 캡처하고, AI로 압축한 뒤 다음 세션에 관련 컨텍스트를 자동 주입합니다.
(저는 도입 후 모든 파일마다 CLAUDE.md가 생성되는 오류를 발견해 다시 걷어냈던 경험이 있습니다.)
Supermemory는 에피소드/시맨틱 메모리와 80% 컨텍스트 사용 시 자동 요약 기능까지 제공했어요. memsearch는 시맨틱 벡터 검색 기반의 3계층 메모리 시스템을, Mengram은 시맨틱/에피소드/절차적 3가지 메모리 타입과 29개 MCP 도구를 제공하기도 했죠.
더 구조적인 접근도 있었습니다. claude-diary는 /reflect 명령으로 다이어리 항목을 분석하고 CLAUDE.md를 자동 업데이트하는 방식이고, 제가 종종 언급하는 정구봉님의 session-wrap도 /wrap 명령으로 CLAUDE.md를 업데이트하는 방식입니다.
episode-memory는 세션별 경험을 에피소드 단위로 저장합니다. 이 두 도구는 Anthropic 직원들의 내부 패턴에서 영감을 받은 것이기도 해요.
2026년 2월 5일, Opus 4.6과 함께 Claude Code가 Auto Memory 시스템을 공식적으로 도입했습니다. 두 가지 메모리 계층으로 구성돼요.
https://code.claude.com/docs/en/memory- CLAUDE.md — 사용자가 직접 작성하는 프로젝트 지침
- MEMORY.md — Claude가 스스로 작성하는 노트.
~/.claude/projects/<project>/memory/경로에 자동 생성
Claude는 빌드 명령어, 디버깅 인사이트, 아키텍처 노트, 코딩 스타일 선호도를 스스로 기록하고, 200줄을 넘으면 debugging.md, patterns.md 같은 토픽 파일로 분리합니다. PreCompact 훅은 컨텍스트 압축 직전에 작업 상태를 스냅샷으로 저장해서 Auto Memory가 커버하지 못하는 시나리오를 보완해요.
Handoff → claude-mem → Supermemory → Auto Memory. 수동 마크다운에서 시작해 네이티브 자동 기억까지, 기억의 문제를 해결하려는 생태계의 여정이 하나의 공식 기능으로 수렴했어요.
지금까지 최근 1달간 핫했던 몇 가지 사례를 살펴봤습니다.
커뮤니티가 만든 도구를 Claude가 공식적으로 흡수하는 패턴은 반복적입니다. Claude를 넘어 어떤 AI 플랫폼도 모두 빠르게 적응하며 몸집을 키우고 있습니다. 그렇다면 지금 생태계에서 가장 뜨거운 주제인 하네스 엔지니어링은 어떨까요?
https://aakashgupta.medium.com/2025-was-agents-2026-is-agent-harnesses-heres-why-that-changes-everything-073e9877655e"2025년은 에이전트의 해, 2026년은 에이전트 하네스의 해"라는 프레이밍이 업계 공통 인식이 됐습니다. 이 표현을 증명하듯, 최근 제 LinkedIn, Thread는 실제로 하네스 관련 포스팅으로 뒤덮여 있습니다.
하네스(Harness)란 모델을 감싸서 장시간 작업을 관리하는 인프라예요. 모델은 응답을 생성하고, 하네스는 그 외 모든 것을 처리합니다. 생명주기 관리, 상태 추적, 도구 오케스트레이션, 안전장치, 컨텍스트 윈도우 간 메모리 단절 해결 같은 것들이죠.
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents- The importance of Agent Harness in 2026에서는 하네스를 "에이전트가 신뢰성 있게 작동하도록 하는 운영 체제"에 비유했어요.
- Martin Fowler - Harness Engineering에서는 OpenAI가 하네스를 만드는 데 5개월이 걸렸다는 점을 강조하며 "심각한 엔지니어링 활동"이라고 역설했고요.
- Harness Engineering Is Not Context Engineering에서는 "컨텍스트 엔지니어링은 에이전트가 무엇을 아는지를 다루고, 하네스 엔지니어링은 에이전트가 감독 없이 작동할 수 있는 장소를 만든다"고 구분했습니다.
커뮤니티에서는 이미 수많은 하네스 도구가 등장했어요. claude-code-harness(Plan → Work → Review 자율 순환), everything-claude-code(해커톤 우승작), Trail of Bits의 claude-code-config(보안 중심 하네스) 등이 대표적이에요.
하지만 앞서 살펴본 패턴을 떠올려보면, 이 하네스 생태계의 핵심 기능들도 결국 Claude Code가 공식적으로 흡수할 거라고 생각해요.
생태계가 검증한 것은 Claude Code가 따라잡아요. 지금의 하네스 엔지니어링도 마찬가지일 거예요. 실제로 Claude Code는 이미 Skills, Hooks, Subagents, Agent Teams라는 하네스 구성요소를 공식적으로 제공하고 있거든요.
모든 도구적 기능은 결국 플랫폼에 흡수됩니다. 그렇다면 우리가 투자해야 할 것은 도구가 아니라, 도구가 바뀌어도 변하지 않는 근본적인 능력이에요.
아마존의 창립자 Jeff Bezos는 "앞으로 10년간 변하지 않을 것은 무엇인가?"가 "무엇이 변할 것인가?"보다 더 중요한 질문이라고 했어요. (출처) 고객이 더 낮은 가격, 더 빠른 배송을 원하지 않을 미래는 상상할 수 없듯, 개발에도 변하지 않는 근본이 있습니다.
수집한 레퍼런스들을 관통하는 공통 메시지를 정리해보겠습니다.
https://addyo.substack.com/p/critical-thinking-during-the-ageAddy Osmani의 글에서는 AI 시대에 비판적 사고가 그 어느 때보다 중요하다고 강조합니다. AI의 결과물을 "Who, what, where, when, why, how" 프레임워크로 평가하는 능력이 핵심이라는 거예요.
Anthropic의 자체 연구도 이를 뒷받침합니다.
https://www.anthropic.com/research/AI-assistance-coding-skillsAI를 사용한 개발자는 이해력 테스트에서 17% 낮은 점수를 기록했어요. 다만 AI에 개념적 질문을 던진 그룹은 65%+를 유지한 반면, 코드 생성만 위임한 그룹은 40% 미만으로 떨어졌습니다. 사용 방식이 핵심인 거죠.
프롬프트 엔지니어링의 본질은 명확한 글쓰기입니다. 시니어 프론트엔드 개발자로 유명한 테오님은 velog에 이런 글을 쓰셨습니다.
https://velog.io/@teo/ai-and-developer테오님은 "내 맥락을 담아 구체적인 내용을 구조적으로 표현하는 능력"이 AI가 모방할 수 없는 핵심 역량이라고 말했습니다. 저는 조만간 이마저도 따라잡힐 거라는 생각이지만 말이에요.
https://www.ibm.com/think/prompt-engineeringIBM의 프롬프트 엔지니어링 가이드도 같은 결론을 냅니다. 좋은 프롬프트를 작성하려면 결국 비판적 사고와 명확한 커뮤니케이션 능력이 필수적이라고요. LinkedIn 데이터에 따르면 프롬프트 엔지니어링 관련 채용 공고가 250% 증가하기도 했어요.
흥미로운 생각이 들었는데, 그래서 AI에게 잘 설명하는 능력은 비개발자도 충분히 따라잡을 수 있는 영역이어서 요새 Claude 해커톤에서도 비개발자들이 상을 휩쓰는 게 아닌가 싶습니다.
https://martinfowler.com/articles/exploring-gen-ai/13-role-of-developer-skills.htmlMartin Fowler 블로그에서 Birgitta Böckeler는 AI가 코드를 작성하는 "supervised agent" 모드에서도 개발자의 경험과 판단력이 필수적임을 사례로 증명했어요. 코드 작성은 개발자 업무의 일부일 뿐, 비즈니스 도메인 이해와 아키텍처 결정이 더 본질적이라는 거죠.
https://github.blog/news-insights/octoverse/the-new-identity-of-a-developer-what-changes-and-what-doesnt-in-the-ai-era/GitHub Octoverse는 개발자 역할이 "코드 생산자"에서 "코드의 크리에이티브 디렉터"로 변화하고 있다고 분석합니다. 핵심 스킬은 구현이 아니라 오케스트레이션과 검증이에요.
https://toss.tech/article/will-ai-replace-developersLinkedIn에서 핫했던 토스 개발자 정세훈님의 글입니다. AI에게 업무를 위임하는 것 자체가 추상화 행위이며, 좋은 추상화를 설계하는 능력이 AI 시대 핵심 역량이라는 내용이죠. 판단, 맥락, 조율은 아직까지는 AI가 대신할 수 없어요.
https://tech.kakao.com/posts/735카카오 CTO 정규돈님께서도 비슷한 결론을 냈습니다. AI 시대에도 논리적 사고력, 문제 정의 능력, 소통과 협업 능력은 AI가 대체할 수 없는 인간 고유의 영역이라고요.
그리고 한 가지 더. AI 트렌드를 지속적으로 따라가는 능력이 이렇게 급변하는 AI 시대에 뒤쳐지지 않기 위한 역량입니다.
AI의 등장 이후 도구는 매달 바뀝니다. 모든 산업, 특히 IT 직군은 AI의 폭발적 생산성을 등에 업고 매일 변화를 이룩하고 있습니다. 이 변화의 속도를 따라가지 못하면, 커뮤니티가 이미 해결한 문제를 혼자 고민하게 됩니다.
https://newsletter.pragmaticengineer.com/p/the-future-of-software-engineering-with-aiGergely Orosz(Pragmatic Engineer)는 Martin Fowler, Kent Beck 등 50년 이상 경력의 베테랑들도 "이렇게 빠른 변화는 처음"이라 언급했다고 전합니다.
https://addyosmani.com/blog/ai-coding-workflow/Addy Osmani의 글에서는 견고한 소프트웨어 엔지니어링 기본기를 갖추고 있으면 AI가 생산성을 몇 배로 증폭시킨다고 했어요. 기본기 없이 AI만 의존하면 오히려 생산성이 떨어진다고도 했고요.
미리 예고하자면 다음 글에서는 AI 트렌드를 효과적으로 따라가는 방법을 다룰 예정이에요.
제가 팔로우하고 있는 AI 인플루언서를 소개하려 합니다. 최근 제 주변에는 AI 트렌드에 올라탄 비개발자 분들이 많이 계시거든요. 개발자니까 도움이 되어야죠.
글의 내용을 정리해보겠습니다.
생태계가 원한 것은 Claude Code가 곧바로 공식적으로 지원했어요. 이 패턴은 앞으로도 계속될 거예요. 지금의 하네스 엔지니어링도 마찬가지일 겁니다.
그렇다면 도구 자체에 매몰되기보다, 변하지 않는 것에 에너지를 투자해야 해요.
- 비판적 사고와 판단력
- 글쓰기와 커뮤니케이션
- 아키텍처와 시스템 설계
- 추상화와 문제 정의
- AI 트렌드를 따라가는 능력
도구는 바뀌지만, 도구를 다루는 사람의 역량은 변하지 않습니다.
