<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Agentic-Coding on philipjkim</title><link>https://philipjkim.cc/tags/agentic-coding/</link><description>Recent content in Agentic-Coding on philipjkim</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 04 Aug 2026 08:40:45 +0900</lastBuildDate><atom:link href="https://philipjkim.cc/tags/agentic-coding/index.xml" rel="self" type="application/rss+xml"/><item><title>AI가 코딩을 다 하는 시대, 컴공은 무엇을 배워야 하나 Part 3: 반론 — 2026년 데이터로 다시 본 것들</title><link>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-03/</link><pubDate>Tue, 04 Aug 2026 08:40:45 +0900</pubDate><guid>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-03/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며"&gt;들어가며&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-01/"&gt;Part 1&lt;/a&gt;과 &lt;a href="https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-02/"&gt;Part 2&lt;/a&gt;에서는 서울대 이재욱 교수의 인터뷰 &lt;a href="https://www.youtube.com/watch?v=i0NcKL1JLfg"&gt;〈코딩도 과제도 AI가 다 하는 시대, 컴공에서는 무엇을 배워야 할까?〉&lt;/a&gt;를 일곱 챕터로 나눠 정리하고 각 주장에 외부 근거를 붙였습니다. 이번 편은 방향을 바꿔, 데이터가 뒷받침하지 않는 부분과 영상이 아예 다루지 않은 조각들을 다룹니다.&lt;/p&gt;
&lt;p&gt;한 가지 방법론을 먼저 밝힙니다. &lt;strong&gt;이 글의 근거는 가급적 2026년 자료로 한정했고, 추이를 볼 때는 2023~2026년 구간을 봤습니다.&lt;/strong&gt; 이 분야는 6개월이면 결론이 뒤집히기 때문입니다. 실제로 그렇게 다시 검증해 보니 &lt;strong&gt;반론 하나는 완전히 무너졌고, 나머지는 대부분 훨씬 강해졌으며, 하나는 방향이 반대로 뒤집혔습니다.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>AI가 코딩을 다 하는 시대, 컴공은 무엇을 배워야 하나 Part 2: 교육, 학과의 존재 이유, 그리고 안목</title><link>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-02/</link><pubDate>Tue, 04 Aug 2026 08:33:12 +0900</pubDate><guid>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-02/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며"&gt;들어가며&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-01/"&gt;Part 1&lt;/a&gt;에서는 서울대 이재욱 교수의 인터뷰 &lt;a href="https://www.youtube.com/watch?v=i0NcKL1JLfg"&gt;〈코딩도 과제도 AI가 다 하는 시대, 컴공에서는 무엇을 배워야 할까?〉&lt;/a&gt;의 앞쪽 세 챕터를 다뤘습니다. 요약하면 이렇습니다. 시간의 무게중심이 쓰기에서 읽기로 옮겨 갔고, 코드 작성은 거의 자동화될 수 있지만 무엇을 만들지 정의하는 일은 인간에게 남으며, 바이브 코딩은 프로토타입에는 훌륭하지만 프로덕션에서는 95%가 0%가 됩니다.&lt;/p&gt;
&lt;p&gt;이번 편은 후반부 네 챕터입니다. 교육 현장의 문제, 컴퓨터공학이라는 학과의 존재 이유, 앞으로 중요해질 역량, 그리고 비전공자를 위한 조언입니다. 앞 편과 마찬가지로 영상의 주장을 정리한 뒤 외부 근거를 붙이고, 마지막에 짚어야 할 부분을 덧붙입니다.&lt;/p&gt;</description></item><item><title>AI가 코딩을 다 하는 시대, 컴공은 무엇을 배워야 하나 Part 1: 영상이 짚은 현실과 바이브 코딩의 임계점</title><link>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-01/</link><pubDate>Tue, 04 Aug 2026 08:30:13 +0900</pubDate><guid>https://philipjkim.cc/posts/20260804-ai-era-computer-science-education-01/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;좋은 영상을 알려주신 Eroica 님께 감사드립니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며"&gt;들어가며&lt;/h2&gt;
&lt;p&gt;서울대학교 공식 유튜브 채널의 인터뷰 시리즈 「샤로잡다」 시즌 2 에 &lt;a href="https://www.youtube.com/watch?v=i0NcKL1JLfg"&gt;〈코딩도 과제도 AI가 다 하는 시대, 컴공에서는 무엇을 배워야 할까?〉&lt;/a&gt; 편이 2026년 7월 23일 공개되었습니다. 약 20분 분량이고, 게시 열흘 남짓 만에 조회수 26만 회를 넘겼습니다.&lt;/p&gt;
&lt;p&gt;출연자는 &lt;strong&gt;이재욱 교수&lt;/strong&gt; 입니다. 서울대학교 컴퓨터공학부 교수이며 2025년 9월부터 &lt;a href="https://aiis.snu.ac.kr/sub2_1.php"&gt;서울대학교 AI연구원(AIIS)&lt;/a&gt; 원장을 맡고 있습니다. 컴파일러와 하드웨어 아키텍처, 운영체제를 연구해 온 AI 인프라 전문가라는 점이 중요합니다. 모델을 만드는 사람이 아니라 &lt;strong&gt;모델이 돌아가는 바닥을 만드는 사람&lt;/strong&gt; 의 관점에서 나온 이야기이기 때문입니다.&lt;/p&gt;</description></item><item><title>번역글: Big Design Up Front — 여전히 나쁜 생각입니다</title><link>https://philipjkim.cc/posts/20260728-big-design-up-front-still-a-bad-idea-translation/</link><pubDate>Tue, 28 Jul 2026 14:23:37 +0900</pubDate><guid>https://philipjkim.cc/posts/20260728-big-design-up-front-still-a-bad-idea-translation/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 5 를 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;원문: Pragmatic Programmers Newsletter — &amp;ldquo;Big Design Up Front: Still a Bad Idea&amp;rdquo;&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;blockquote&gt;
&lt;p&gt;우리는 1990년대의 소프트웨어 위기를 불러왔던 그 관행을 그대로 되풀이할 위험에 처해 있습니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;40년 전, 도구와 하드웨어가 발전하면서 우리는 점점 더 큰 시스템을 만들 수 있게 됐습니다. 더 야심 차고, 범위도 넓고, UI도 화려한 시스템들이었습니다. 짜릿한 시절이었습니다.&lt;/p&gt;
&lt;p&gt;하지만 문제가 있었습니다. 시스템이 복잡해질수록 프로젝트는 점점 더 실패했습니다. 일정 추정은 웃음이 나올 만큼 빗나갔고, 기능은 잘려나갔고, 버그는 넘쳐났습니다. 프로젝트는 납품되는 만큼이나 자주 취소됐습니다. 2000년 무렵에는 여섯 개 중 하나 정도만 일정과 예산에 근접하게 마무리됐습니다.&lt;/p&gt;</description></item><item><title>배우는 부분들로 이루어진 배우는 시스템 — Kent Beck × Jessica Kerr 대담 정리</title><link>https://philipjkim.cc/posts/20260626-symmathesy-kent-beck-jessica-kerr/</link><pubDate>Fri, 26 Jun 2026 09:56:51 +0900</pubDate><guid>https://philipjkim.cc/posts/20260626-symmathesy-kent-beck-jessica-kerr/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;이 좋은 리소스를 귀띔해 주신 Luis 님께 감사드립니다. 덕분에 &amp;lsquo;symmathesy&amp;rsquo; 를 몇 번이나 소리 내어 발음해 봤는지 모릅니다 — 혀는 여전히 꼬이지만, 개념만큼은 또렷하게 남았습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;Kent Beck 이 진행하는 팟캐스트 &lt;a href="https://newsletter.kentbeck.com/p/a-learning-system-made-of-learning"&gt;&lt;em&gt;Still Burning&lt;/em&gt;&lt;/a&gt; 의 일곱 번째 에피소드 &lt;a href="https://www.youtube.com/watch?v=e9TABQqiDXU"&gt;&lt;em&gt;A Learning System Made of Learning Parts&lt;/em&gt;&lt;/a&gt; 는, &lt;em&gt;&amp;ldquo;여전히 마음을 쓰고(still care) 여전히 무언가를 하고 있는 괴짜들&amp;rdquo;&lt;/em&gt; 을 위한 자리라는 이 시리즈의 취지에 꼭 맞는 대담입니다. 손님은 Kent 의 오랜 친구이자 시스템 사고(systems thinking)로 잘 알려진 개발자 &lt;strong&gt;Jessica Kerr&lt;/strong&gt;(jessitron) 입니다.&lt;/p&gt;</description></item><item><title>개발자를 위한 Discord 완전정복 Part 3: Discord를 원격 Control Plane으로</title><link>https://philipjkim.cc/posts/20260605-discord-developer-guide-03/</link><pubDate>Fri, 05 Jun 2026 18:09:28 +0900</pubDate><guid>https://philipjkim.cc/posts/20260605-discord-developer-guide-03/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="https://philipjkim.cc/posts/20260605-discord-developer-guide-01/"&gt;Part 1&lt;/a&gt;에서 Discord의 역사를, &lt;a href="https://philipjkim.cc/posts/20260605-discord-developer-guide-02/"&gt;Part 2&lt;/a&gt;에서 개발자에게 풀린 무료 기능들을 살펴봤습니다. 마지막 Part 3에서는 이 기능들을 조합해 &lt;strong&gt;Discord를 원격 control plane(제어 평면)&lt;/strong&gt; 으로 쓰는 실전 활용법을 다룹니다.&lt;/p&gt;
&lt;p&gt;핵심 아이디어는 단순합니다. Discord 봇은 &lt;strong&gt;어디서나 접근 가능한 양방향 메시지 채널&lt;/strong&gt;입니다. 폰에서도, PC에서도 같은 채널에 메시지를 보낼 수 있습니다. 그렇다면 그 메시지를 받아 &lt;strong&gt;내 서버에서 명령을 실행하거나, 장기 실행 작업을 조종하거나, AI 에이전트를 지휘&lt;/strong&gt;할 수 있지 않을까요? 바로 이 발상이 최근 개발자 사이에서 뜨거운 &amp;ldquo;Discord를 control plane으로&amp;rdquo; 패턴입니다.&lt;/p&gt;</description></item><item><title>Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기</title><link>https://philipjkim.cc/posts/20260528-repo-bootstrapping-guide-02/</link><pubDate>Thu, 28 May 2026 19:03:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260528-repo-bootstrapping-guide-02/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="../20260528-repo-bootstrapping-guide-01/"&gt;Part 1&lt;/a&gt; 에서는 2026년 5월 기준 de-facto 가 된 spec 문서들의 지형도와 best practices 를 정리했습니다. 2편에서는 가상의 Go + Templ + HTMX 기반 To-Do 앱 &lt;code&gt;gotodo&lt;/code&gt; 를 새로 부트스트래핑한다고 가정하고, 각 문서를 실제로 어떻게 채우는지 발췌 형태로 따라갑니다.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="가상-프로젝트-gotodo"&gt;가상 프로젝트: &lt;code&gt;gotodo&lt;/code&gt;&lt;/h2&gt;
&lt;p&gt;스택은 다음과 같습니다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Go 1.23&lt;/strong&gt; — 표준 라이브러리 중심&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://templ.guide"&gt;templ&lt;/a&gt;&lt;/strong&gt; — Go 네이티브 SSR 템플릿 (type-safe)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://htmx.org"&gt;HTMX 2.0&lt;/a&gt;&lt;/strong&gt; — 클라이언트 JS 최소화&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;SQLite + &lt;code&gt;modernc.org/sqlite&lt;/code&gt;&lt;/strong&gt; — CGO 없는 순수 Go 드라이버&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;목표는 단순합니다. 할 일 추가/완료/삭제만 되는 SSR 미니멀 앱. 1인 로컬 사용을 가정합니다.&lt;/p&gt;</description></item><item><title>Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 1: AGENTS.md 와 spec 문서 지형도</title><link>https://philipjkim.cc/posts/20260528-repo-bootstrapping-guide-01/</link><pubDate>Thu, 28 May 2026 19:02:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260528-repo-bootstrapping-guide-01/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며-readme-한-장으로-안-되는-시대"&gt;들어가며: README 한 장으로 안 되는 시대&lt;/h2&gt;
&lt;p&gt;신규 서비스를 위한 git repo 를 막 만들었다고 합시다. 2년 전이라면 &lt;code&gt;README.md&lt;/code&gt; 한 장에 빌드 명령과 디렉터리 구조를 적고, 나머지는 코드와 머릿속에서 합의된 관행으로 굴러갔습니다. 새 팀원이 들어오면 옆 자리 동료가 30분쯤 설명해 주고, 그걸로 충분했습니다.&lt;/p&gt;
&lt;p&gt;지금은 그 &amp;ldquo;옆 자리 동료&amp;rdquo; 역할의 절반 이상을 Claude Code, Codex CLI, Gemini CLI, Cursor 같은 에이전트가 맡고 있습니다. 그런데 에이전트는 옆 자리에 앉지 않습니다. 매 세션마다 처음 합류한 신입처럼 repo 에 들어와서, 우리가 적어 둔 텍스트만 읽고 일을 시작합니다. &lt;strong&gt;에이전트에게 &amp;ldquo;이 프로젝트는 이런 곳이고, 이런 규칙으로 일한다&amp;rdquo; 를 전달하는 문서가 부실하면, 에이전트가 만드는 결과물의 품질은 운에 좌우됩니다.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>1년 후의 공동 지능 Part 2: 2026 상반기에 새로 드러난 것들</title><link>https://philipjkim.cc/posts/20260528-co-intelligence-revisited-02/</link><pubDate>Thu, 28 May 2026 16:38:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260528-co-intelligence-revisited-02/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 (1M context) 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며"&gt;들어가며&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://philipjkim.cc/posts/20260528-co-intelligence-revisited-01/"&gt;Part 1&lt;/a&gt; 에서는 에단 몰릭의 4가지 규칙이 1년 후 어떻게 다시 읽히는지를 다뤘습니다. 이 글은 같은 1년 동안 &lt;strong&gt;원래 규칙에는 없었지만 지금은 핵심이 된 다섯 가지 주제&lt;/strong&gt;를 정리합니다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;agentic coding 의 본격화 — 도구 지형의 재편&lt;/li&gt;
&lt;li&gt;vibe coding 과 새로 발견된 보안 문제들&lt;/li&gt;
&lt;li&gt;인지 위축(cognitive atrophy)과 스킬 형성의 비대칭&lt;/li&gt;
&lt;li&gt;MCP — 에이전트 간 표준의 등장&lt;/li&gt;
&lt;li&gt;컨텍스트 엔지니어링 — 새로운 핵심 역량&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;각 주제 끝에서 1년 전의 네 가지 규칙 중 어디와 연결되는지 짚어 두겠습니다.&lt;/p&gt;</description></item><item><title>1년 후의 공동 지능 Part 1: 에단 몰릭의 4가지 규칙은 2026년에도 유효한가</title><link>https://philipjkim.cc/posts/20260528-co-intelligence-revisited-01/</link><pubDate>Thu, 28 May 2026 16:37:26 +0900</pubDate><guid>https://philipjkim.cc/posts/20260528-co-intelligence-revisited-01/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 (1M context) 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며--1년-사이에-일어난-일"&gt;들어가며 — 1년 사이에 일어난 일&lt;/h2&gt;
&lt;p&gt;작년 6월, 저는 &lt;a href="https://philipjkim.cc/posts/20250623-the-four-rules-of-co-intelligence-with-ai/"&gt;에단 몰릭이 말하는 AI와의 &amp;ldquo;공동 지능&amp;quot;을 위한 4가지 규칙&lt;/a&gt;이라는 포브스 인터뷰를 번역해 올렸습니다. 와튼 스쿨의 에단 몰릭(Ethan Mollick) 교수가 자신의 책 &lt;em&gt;Co-Intelligence: Living and Working with AI&lt;/em&gt;(2024)에서 제시한 네 가지 규칙을 설명한 인터뷰였습니다.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;항상 AI를 자리에 초대하라(Always invite AI to the table)&lt;/li&gt;
&lt;li&gt;인간이 (의사결정) 과정에 참여하라(Be the human in the loop)&lt;/li&gt;
&lt;li&gt;AI를 사람처럼 대하되, 어떤 종류의 사람인지 알려줘라(Treat AI like a person, but tell it what kind of person it is)&lt;/li&gt;
&lt;li&gt;이것이 당신이 사용하게 될 최악의 AI라고 가정하라(Assume this is the worst AI you will ever use)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;그로부터 1년 가량이 지난 2026년 5월 현재, 이 규칙들은 여전히 유효할까요? 결론부터 말씀드리면, 큰 틀에서는 맞지만 &lt;strong&gt;세부 작동 방식과 강조점은 상당히 바뀌었습니다.&lt;/strong&gt; 몰릭 자신도 2026년 3월 &lt;a href="https://www.oneusefulthing.org/p/the-shape-of-the-thing"&gt;The Shape of the Thing&lt;/a&gt;이라는 글에서 &amp;ldquo;우리는 AI와 함께 일하는 시대(co-intelligence)에서 AI를 관리하는 시대(managing AIs)로 넘어가고 있다&amp;quot;고 새 프레임을 제시했습니다.&lt;/p&gt;</description></item><item><title>Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계</title><link>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-04/</link><pubDate>Wed, 20 May 2026 16:58:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-04/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="../20260520-superpowers-plugin-guide-01/"&gt;1편&lt;/a&gt; 에서 개요와 설치를, &lt;a href="../20260520-superpowers-plugin-guide-02/"&gt;2편&lt;/a&gt; 에서 핵심 워크플로우를, &lt;a href="../20260520-superpowers-plugin-guide-03/"&gt;3편&lt;/a&gt; 에서 품질 보증 스킬을 다뤘습니다. 마지막 4편에서는 실전에서 가장 자주 부딪히는 질문에 답합니다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&amp;ldquo;이거 그냥 두면 알아서 다 해주는 건가요, 아니면 매번 &lt;code&gt;/superpowers:xxx&lt;/code&gt; 로 호출해야 하나요?&amp;rdquo;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;답은 &lt;strong&gt;&amp;ldquo;대부분 자동이지만, 의도적으로 명시 호출해야 더 잘 작동하는 케이스가 있다&amp;rdquo;&lt;/strong&gt; 입니다. 이 글에서는 두 모드의 비교 분석, 트러블슈팅, 커스터마이즈 방법, 그리고 Java/Go 백엔드 개발 현장에서의 실용 팁과 한계를 정리합니다.&lt;/p&gt;</description></item><item><title>Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬 — TDD, Systematic Debugging, Verification, Code Review</title><link>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-03/</link><pubDate>Wed, 20 May 2026 16:57:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-03/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="../20260520-superpowers-plugin-guide-01/"&gt;1편&lt;/a&gt; 에서 Superpowers 의 개요와 설치를, &lt;a href="../20260520-superpowers-plugin-guide-02/"&gt;2편&lt;/a&gt; 에서 핵심 워크플로우를 다뤘습니다. 3편은 그 워크플로우 안에서 작동하면서 &lt;strong&gt;에이전트의 합리화와 빠져나갈 구멍을 차단&lt;/strong&gt; 하는 품질 보증 스킬들을 자세히 들여다봅니다.&lt;/p&gt;
&lt;p&gt;이 스킬들은 모두 &amp;ldquo;Iron Law&amp;rdquo; 라는 이름의 명문화된 규칙을 갖고 있다는 공통점이 있습니다. 그리고 각 스킬의 문서 안에는 &lt;strong&gt;&amp;ldquo;Red Flags&amp;rdquo; 표&lt;/strong&gt; 가 들어 있어, 에이전트가 빠져나가려 할 때 흔히 하는 합리화의 패턴들을 그대로 박아두었습니다. 이게 결과적으로 모델의 행동을 바꿉니다.&lt;/p&gt;</description></item><item><title>Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우 — Brainstorming부터 Subagent-driven Development까지</title><link>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-02/</link><pubDate>Wed, 20 May 2026 16:56:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-02/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="../20260520-superpowers-plugin-guide-01/"&gt;1편&lt;/a&gt; 에서는 Superpowers 가 무엇이고 어떻게 자동 트리거되는지를 다뤘습니다. 2편은 가장 핵심이라고 할 수 있는 &lt;strong&gt;개발 워크플로우 전체&lt;/strong&gt; 를 깊게 들여다봅니다.&lt;/p&gt;
&lt;p&gt;전체 흐름은 다음과 같습니다.&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code class="language-mermaid" data-lang="mermaid"&gt;flowchart LR
 A[brainstorming] --&amp;gt; B[using-git-worktrees]
 B --&amp;gt; C[writing-plans]
 C --&amp;gt; D{독립 태스크?}
 D --&amp;gt;|yes| E[subagent-driven-development]
 D --&amp;gt;|no/사람 체크포인트 선호| F[executing-plans]
 E --&amp;gt; G[finishing-a-development-branch]
 F --&amp;gt; G

 style A fill:#90EE90,color:#000000
 style B fill:#87CEEB,color:#000000
 style C fill:#FFD700,color:#000000
 style D fill:#FFB6C1,color:#000000
 style E fill:#DDA0DD,color:#000000
 style F fill:#DDA0DD,color:#000000
 style G fill:#FFA07A,color:#000000
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;이 글에서는 각 스킬이 실제로 무엇을 하는지, 그리고 &lt;strong&gt;Go 기반 백엔드 서비스에 새 API 엔드포인트를 추가&lt;/strong&gt; 하는 시나리오를 따라가며 흐름을 체험해 봅니다.&lt;/p&gt;</description></item><item><title>Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학</title><link>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-01/</link><pubDate>Wed, 20 May 2026 16:55:00 +0900</pubDate><guid>https://philipjkim.cc/posts/20260520-superpowers-plugin-guide-01/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며"&gt;들어가며&lt;/h2&gt;
&lt;p&gt;Claude Code, Codex CLI, Cursor 등 코딩 에이전트(coding agent)를 매일 쓰는 백엔드 개발자라면 한 번쯤은 이런 경험이 있을 겁니다. &amp;ldquo;간단한 기능 하나만 추가해줘&amp;rdquo; 라고 했더니, 요구사항 정리 없이 코드를 우다다 쏟아내다가 절반쯤에서 길을 잃고, 테스트도 빠진 채 &amp;ldquo;완료했습니다&amp;rdquo; 라고 보고하는 경우 말입니다. 모델은 똑똑한데, 작업 방식이 들쭉날쭉해서 결과의 품질이 운에 좌우됩니다.&lt;/p&gt;
&lt;p&gt;Jesse Vincent 가 만든 &lt;strong&gt;&lt;a href="https://github.com/obra/superpowers"&gt;Superpowers&lt;/a&gt;&lt;/strong&gt; 는 바로 이 지점을 노린 플러그인입니다. 모델을 더 똑똑하게 만드는 게 아니라, 모델이 &lt;strong&gt;언제, 어떤 순서로, 어떤 규율로&lt;/strong&gt; 일해야 하는지를 강제하는 &amp;ldquo;방법론(methodology)&amp;rdquo; 자체를 플러그인 형태로 주입합니다.&lt;/p&gt;</description></item><item><title>Agentic Coding 시대의 개발방법론 — 더 중요해진 5가지, 무용해진 5가지</title><link>https://philipjkim.cc/posts/20260428-agentic-coding-methodologies-survived-and-faded/</link><pubDate>Tue, 28 Apr 2026 12:40:28 +0900</pubDate><guid>https://philipjkim.cc/posts/20260428-agentic-coding-methodologies-survived-and-faded/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="들어가며-사라진-것이-아니라-재배치되었다"&gt;들어가며: 사라진 것이 아니라 재배치되었다&lt;/h2&gt;
&lt;p&gt;2025년 한 해를 거치면서 백엔드 개발자가 키보드 앞에서 보내는 시간의 모양이 크게 달라졌습니다. Claude Code, Cursor, Codex 같은 에이전트가 대부분의 코드를 직접 작성하고, 사람은 명세를 다듬고, 결과를 검증하고, 다음 작업을 지시하는 시간이 길어졌습니다. Stack Overflow의 &lt;a href="https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/"&gt;2025 Developer Survey&lt;/a&gt;는 응답자의 66%가 &lt;em&gt;almost-right AI code&lt;/em&gt; 를 고치는 데 더 많은 시간을 쓰고 있다고 답했습니다.&lt;/p&gt;
&lt;p&gt;이 변화 앞에서 가장 자주 듣는 잘못된 결론이 &lt;em&gt;&amp;ldquo;이제 SW 엔지니어링 방법론은 다 의미가 없어졌다&amp;rdquo;&lt;/em&gt; 입니다. 하지만 2025년 하반기에서 2026년 초까지 Kent Beck, Birgitta Böckeler, Simon Willison, Armin Ronacher, Steve Yegge처럼 실제로 에이전트와 매일 일하는 시니어 엔지니어들이 남긴 글을 읽어 보면 정반대 그림이 보입니다. &lt;strong&gt;방법론이 사라진 것이 아니라, 어떤 것은 더 중요해지고 어떤 것은 의미를 잃는 형태로 재배치되었습니다&lt;/strong&gt;.&lt;/p&gt;</description></item></channel></rss>