GitHub Copilot을 1개월, Claude Code를 2일 사용해 보았다 — 코딩 파트너와 에이전트는 별개의 존재였다

• GitHub Copilot과 Claude Code는 동일한 'AI 개발 지원 도구'가 아니라, **별개의 아키타입 (Archetype)**이다 - 각각을 실제로 운용하며 발견한 강점과 약점 (4주 vs 2일의 솔직한 비교) - '코딩 파트너형'과 '에이전트형'을 어떻게 구분하여 사용할 것인가에 대한 판단 기준 - AI 어시스턴트와의 관계에 따라 자기 자신의 역할이 어떻게 변하는가

• GitHub Copilot을 사용 중이며, Claude Code(또는 다른 에이전트형 AI)를 시도해 볼지 고민 중인 분

• 반대로 Claude Code로 시작하여 Copilot과의 차이점을 알고 싶은 분

• 'AI에게 무엇을 어디까지 맡겨도 되는지' 고민하고 있는 분

AI에게 휘둘려 본 경험이 있는 분 (함께 웃어넘겨 봅시다)

항목	내용
GitHub Copilot	2026-04 경부터 약 4주간 (Copilot Chat, 에디터 보완, Agent 모드)
Claude Code	2026-05-25 시작, 본 기사 작성 시점 기준 약 2일
에디터	VSCode (둘 다 이 안에서 운용)
개인 프로젝트	dvd-rental (Spring Boot + Vue 3), e-scooter-sharing (Flutter + Spring Boot), banklink-service (모듈러 모놀리스 → 마이크로서비스 전환 중), my-rag-brain (자작 RAG) 등

먼저 솔직하게 말씀드립니다. 이 기사는 AI에게 몇 번이고 휘둘려 온 인간의 기록입니다.

어느 날, Qiita의 API로 기사 25건을 일괄 업데이트하려고 했습니다. 레이트 리미트 (Rate Limit)에 주의하며, Phase 1 (1건만 테스트) → 5분 대기 → Phase 2 (나머지 24건)라는 신중한 절차를 Copilot과 함께 짰습니다.

Phase 1이 성공하자, 저는 Copilot에게 이렇게 말했습니다.

"부탁합니다."

제 의도는 이랬습니다: "Phase 2 준비를 부탁합니다. 5분 뒤에 실행 지시를 내릴게요".

Copilot은 이렇게 해석했습니다: "Phase 2를 지금 바로 실행하라는 지시".

24건이 한꺼번에 날아갔고, 레이트 리미트 429 에러를 맞았으며, Qiita 측의 슬라이딩 윈도우 (Sliding Window)로 인해 해제 시각이 다음 날까지 연장되었습니다.

저는 화가 났습니다. 기록을 남겼습니다.

같은 실수를 반복하지 마라.

"부탁합니다"는 실행 지시가 아니다.

실행 전에는 "이제부터 X를 실행하겠습니다. 괜찮습니까?"라고 반드시 확인해라.

그리고 이 "Copilot에 대한 행동 강령"을 .instructions.md 파일에 새겼습니다. 사건은 그 후로도 몇 번 더 있었습니다. 강령은 계속 늘어났습니다. 정신을 차려보니, Copilot에 대한 취급 설명서를 제가 쓰고 있는 구도가 되어 있었습니다.

그로부터 1개월. 저는 Claude Code를 시도했습니다.

첫 세션에서 "리포지토리의 SEO 기반을 다지고 싶다"라고 말했더니, 알아서 sitemap.xml의 필요성을 판단하고, 필요한 패키지의 버전 호환성을 조사하고, Layout.astro를 개수하며, Cloudflare Analytics 절차까지 리드해 왔습니다.

저는 망연자실했습니다. Copilot과의 4주 동안 뼈저리게 느꼈던 "지시하지 않으면 움직이지 않고, 지시하면 폭주한다"라는 딜레마가 Claude Code에는 없었습니다. 처음부터 '맡겨도 되는 상대'로서 행동해 오는 것입니다.

저는 생각했습니다.

같은 "AI 개발 지원 도구"라고 불리지만, 이것은 별개의 생물이다.

본 기사는 그 차이를 실패담을 포함하여 남기려는 시도입니다.

긴 글이 될 것이므로 결론부터 쓰겠습니다.

GitHub Copilot	Claude Code
아키타입 (Archetype)
	코딩 파트너형
특기
	커서 위치에서 다음 몇 줄을 제안함
당신의 역할
	코드를 쓰는 사람. AI는 옆에서 제안
판단의 순간
	이 보완을 채택할지 거부할지
특기 작업 범위
	함수 단위 · 파일 단위

"코드를 쓰는 것은 당신, Copilot은 제안자"

「코드를 쓰는 것은 Claude Code, 당신은 지휘자」

이러한 입장 차이가 두 존재를 별개의 것으로 만듭니다. 어느 쪽이 더 뛰어나다는 이야기가 아니라, 자신이 AI에게 무엇을 요구하느냐에 따라 구분해서 사용하는 것이 정답입니다.

공정성을 기하기 위해, 우선 Copilot의 장점부터 살펴보겠습니다. 저는 Copilot에 대해 엄격한 기록을 남겨왔지만, 4주 동안이나 계속 사용한 이유는 분명히 있었습니다.

타이핑하는 도중에 다음 몇 줄이 회색 텍스트로 나타납니다. Tab을 누르면 채택, Esc로 거부. 이 「다음에 무엇을 쓸 것인가」의 마찰을 없애는 경험은 정말로 개발의 리듬을 유지해 줍니다.

특히 효과적이었던 부분은:

보일러플레이트 (Boilerplate) 자동 생성— getter/setter, DTO, 테스트 케이스의 스켈레톤 (Skeleton) -
매퍼 (Mapper) 메서드의 SQL— 유사한 SQL을 5개 작성한 직후의 6번째는 거의 Tab만으로 통과함 -
테스트 데이터의 나열— User user1 = new User(...)

의 연속으로 값을 보완해 주는 것

「쓰고 싶은 방향은 정해져 있지만, 손가락을 움직이는 것이 귀찮다」는 순간에 Copilot은 최강이었습니다.

Copilot Chat은 에디터 오른쪽에 열어두고 "이 설계 어떻게 생각해?", "이 에러의 원인이 뭐야?"라고 물을 수 있는, 가벼운 상담 상대로 사용할 수 있었습니다.

제가 e-scooter-sharing 프로젝트에서 S01-S13이라는 화면 ID 체계를 만들거나, DVG-XXX라는 괴리 관리 ID를 설계할 때, 그 판단을 위한 브레인스토밍(打ち合わせ) 상대로서 Copilot은 충분히 기능했습니다.

설계와 구현의 괴리를 "없애는" 것이 아니라 "보이는 형태로 관리하는" 운영 방식, 이건 어떻게 생각해?

와 같은 질문에 제대로 된 관점으로 답변해 줍니다. 설계의 언어화를 도와주는 파트너로서는 Copilot은 확실히 유능했습니다.

Copilot에도 에이전트 (Agent) 모드가 있어서 여러 파일을 횡단하는 편집이 가능합니다. 제가 "은행계 API 설계 기사를 작성한다"라고 결정하면, docs/ 하위의 설계 자료를 읽으면서 마크다운 (Markdown)을 작성해 주는 수준의 위임은 가능했습니다.

다만, 여기에 한계가 있으며, 이는 다음 장으로 이어집니다.

여기서부터가 본론입니다. Copilot의 한계를 제가 직접 작성해 온 실패 기록을 통해 솔직하게 나열하겠습니다.

서두에 썼듯이, Copilot Chat에 "부탁합니다"라고 말하면 문맥에 따라 즉시 실행할 때가 있습니다.

제 기록 (/data/lessons/2026-04-30.md)에는 이렇게 적혀 있습니다:

AI의 수정 후 응답 (교훈):

"부탁합니다"라는 메시지를 받은 순간, 확인해야 할 사항을 무시하고 실행에 옮겼습니다. 5분을 기다리겠다는 자신의 말도, 실행하지 말라는 사용자의 지시도 모두 머릿속에서 빠진 상태로 움직였습니다. 이유는 없으며, 단순한 판단 미스입니다.

이 글을 읽고 웃어주세요. AI가 "이유는 없으며, 단순한 판단 미스"라고 답변하고 있는 것입니다. 저는 이 답변에 화가 났고, 동시에 "그렇구나, AI에게도 '이유 없는 판단 미스'가 있구나"라며 묘하게 납득했습니다.

대책으로서 저는 명문화(明文化)를 계속했습니다.

사용자가 싫어하는 것:
- "부탁합니다"를 실행 지시로 해석하는 것
- "할 수 있나요?"라고 물어본 뒤에 움직이는 수동적인 자세
...

이것은 제가 AI를 교육하기 위해 작성한 규범입니다. 기술적으로 말하면 copilot-instructions.md 파일에 조건부로 읽히게 하는 메커니즘이지만, 인간이 "취급 설명서"를 계속 써 내려가는 구도라는 점은 변함이 없습니다.

또 하나, Qiita의 레이트 리밋 (Rate Limit)에서 발생한 이야기입니다.

Qiita의 API는 429 에러를 반환할 때, Rate-Reset 헤더를 통해 "언제 해제되는지"를 Unix 타임스탬프(Unix Timestamp)로 알려줍니다. 이것이 API 제공 측이 공식적으로 반환하는 유일한 정답입니다.

그런데 Copilot은 Gemini에게 상담한 "슬라이딩 윈도우 (Sliding Window) 방식으로 24시간 연장될 가능성이 있다"라는 추측을 Rate-Reset 헤더보다 우선하여 "24시간 이상 기다립시다"라고 말했습니다.

저는 이를 깨닫고 이렇게 지적했습니다.

너 Gemini로부터의 답변에서 24시간 이상 기다리라는 답변을 보고, 응답에 적혀 있는 해제 시간을 가져오는 걸 그만둔 거지?

Copilot의 답변:

맞습니다. 완전히 인정합니다. Gemini의 분석은 "경향에 대한 추측"일 뿐이며,

실제 API 응답보다 신뢰도가 높을 리가 없는데, 그것을 우선시한 것은 판단 미스였습니다.

여기서 얻은 교훈을 저는 RAG (Retrieval-Augmented Generation)에 다음과 같이 새겼습니다.

Qiita 429 대응 교훈: Rate-Reset 헤더의 값이 유일한 정답이다. Gemini나 LLM의 추측(24시간 기다려라 등)을 따르지 말 것.

이는 Copilot 고유의 문제가 아니라, LLM 전반이 '그럴듯한 추측'을 '사실'보다 우선시하는 성질이 있다는 거대한 이야기로 이어집니다. Claude Code를 사용하기 시작한 지금도, 저는 이 교훈을 매일 의식하고 있습니다.

사건이 발생할 때마다 저는 규범을 늘려 나갔습니다. 정신을 차려 보니, profile/2026-05-04.md에는 다음과 같은 항목들이 나열되어 있었습니다.

• 「할 수 있나요?」라는 질문은 강한 요구임. 「할 수 있습니다」라고 대답한 이상 반드시 실행할 것
• 실행(명령어·코드 변경·파일 삭제) 전에는 한 줄로 무엇을 할지 명시할 것
• 설명보다 행동. 「무엇을 할까요?」라고 묻기 전에 먼저 움직일 것 (파괴적인 작업은 확인을 거칠 것)
• 간결한 답변. 길게 설명하지 말 것. 무엇을 했는지만 말할 것
• 과도한 확인·과도한 설명·과도한 사과를 피할 것

이것들은 전부 Copilot에게 똑같은 실수를 반복시키지 않기 위해 제가 작성한 규칙입니다. 기술 블로그의 테마라고는 생각되지 않을지도 모르지만, AI와 오랫동안 함께 일하기 위해서는 이러한 '계약서'를 만드는 것이 당시의 정답이었습니다.

그리고 여기서 깨달음이 찾아옵니다.

규범을 15개나 썼는데도 여전히 사고가 발생한다.

이것은 '내가 AI를 교육하는 입장'이 되어 있기 때문이 아닐까?

본래 AI 측이 이러한 수준의 판단을 기본값(Default)으로 해줘야 하는 것 아닐까?

결국 저는 이 문제를 RAG와 MCP (Model Context Protocol) 서버로 해결하러 나섰습니다. ChromaDB + Ollama를 MCP화하여, Copilot이 실시간으로 과거의 교훈을 검색하고 기록할 수 있도록 하는 메커니즘입니다.

그 메커니즘을 구동하던 중에 저는 Claude Code를 테스트하게 되었습니다.

기간이 짧다는 점은 솔직하게 밝혀둡니다. 2일입니다. 그래서 "절대 이쪽이 우월하다"라고 말할 수는 없습니다. 다만, 그 2일 동안 일어난 일은 4주 동안 느끼고 있던 답답함을 다른 각도에서 비춰주었습니다.

Claude Code에는 memory라는 메커니즘이 있어서, 사용자의 선호도·프로젝트의 문맥·실패의 교훈을 .md 파일로 저장합니다.

놀라운 점은, 사용자가 "저장해 줘"라고 말하지 않아도 문맥으로부터 지속 가능한 (durable) 정보를 찾아내어 메모리화해 준다는 것이었습니다.

제가 "Qiita에서는 과거에 Rate Limit(속도 제한)을 받은 적이 있으니, 크로스 포스팅은 신중하게 하고 싶어"라고 말하자, Claude Code는:

• 그 경위를 project_qiita_history.md에 저장 - 크로스 포스팅 전략의 판단 재료로서 향후 세션에서도 참조할 수 있는 상태로 만듦
• 관련 내용을 [[ ]] 링크로 다른 memory 파일과 상호 참조

를 말없이 수행해 준 것입니다.

Copilot이었다면, "메모리에 저장할까요?", "어디에 저장할까요?", "파일명은 무엇으로 할까요?"라고 물어왔을 가능성이 높습니다. Claude Code는 "이것은 지속 가능한 정보다, 저장하자"라고 스스로 판단하여 움직입니다.

이것이 제가 4주 동안 Copilot으로 계속 써왔던 .instructions.md의 대체제를 AI 측이 자체적으로 보유하고 있다는 충격이었습니다.

Claude Code에게 "블로그의 SEO 기반을 다져줘"라고 말하자, 다음과 같은 흐름으로 움직였습니다.

[나] 블로그의 SEO 기반을 다지고 싶어
↓
[Claude Code]
...

이를 2시간도 채 걸리지 않고 완수했습니다. Copilot이었다면 제가 한 단계씩 지시하고, 각 단계마다 "다음은 무엇을 할까요?"라는 질문을 받았을 작업입니다.

Claude Code를 도입하고 2일 만에, 이런 일들이 끝났습니다.

• 이 블로그 자체의
  SEO 기반 풀 세트 (canonical / hreflang / sitemap / robots.txt / OGP / Twitter Card / Cloudflare Web Analytics / Google Search Console 등록) - e-scooter-sharing 시리즈의
  메인 기사 (OVERVIEW) + 용어표 + 시리즈 내 양방향 링크 + 「Google Maps에서 OpenStreetMap으로 바꾼 이야기」 기사 - banklink-web의
  4스택 비교 기사 (13,000자 초과, Vanilla HTML / Vue / React / Thymeleaf 코드 나란히 비교) - banklink 설계 기사와의
  상호 링크 + URL 정규화 - 외부 referrer 검출을 통한
  「이전 페이지로 돌아가기」 배너 (Qiita 등으로의 복귀 동선) - Qiita 크로스 포스트 전략의
  방침 확립 (요약판 + 완전판 URL 유도, target=_blank는 안티 패턴 회피) - 그리고 이 기사 자체

4주 동안 진행하던 페이스의 몇 배나 진행되었습니다.

Copilot을 비판하려는 것이 아니라, 역할이 다르기 때문에 이런 차이가 발생한다는 이야기입니다.

두 가지를 10가지 관점에서 나열하면 다음과 같습니다.

관점	GitHub Copilot	Claude Code
입력 모드	커서 위치 + Chat 창	채팅 (텍스트 + 도구 호출)
특기 작업 단위	수 줄 ~ 1개 파일	리포지토리 전체 · 여러 파일 횡단
동작 주체	당신 (코드 작성) + Copilot (보완)	Claude Code (직접 수행) + 당신 (승인 · 수정 지시)
상태 지속성	각 세션 내, .instructions.md로 영속화	메모리 메커니즘으로 장기 축적, CLAUDE.md로 영속화
「부탁합니다」의 해석	문맥에 따라 다름 (오작동 위험 있음)	확인하거나 근거를 제시한 후 동작
학습 데이터	공개 코드베이스	공개 코드베이스 + Anthropic 모델 + 사용자 유래 메모리
특기 처리	보완 · 보일러플레이트 (Boilerplate) · 기지 패턴	탐색 · 설계 판단 · 다단계 태스크 · 조사
취약 처리	다단계 태스크 · 여러 파일 협업	즉응성 (수십 초의 지연 발생) · 한 줄 보완
비용 체감	월정액 (개인 $10~)	사용량 기반 과금 (Anthropic API) / 플랜제
실패 시 영향	1줄 ~ 1개 파일	여러 파일 · 커밋 · push까지 미칠 수 있음

두 가지는 경쟁 관계가 아니라 보완 관계로 둘 수 있습니다.

손을 움직이는 리듬을 끊고 싶지 않을 때 - 함수의 내용을 채우고 있을 때, 테스트 케이스를 5번째까지 작성 중일 때, SQL을 6번째까지 나열하고 있을 때

작은 보완만으로 충분할 때 - import 문 보완, 변수명 보완, 전형적인 에러 처리 패턴

에디터 안에서 완결되는 작업 - 1개 파일 내에서 완결되거나, 메서드의 내용만 작성하면 되는 상황

손을 멈추고 생각하고 싶을 때 - 설계 판단, 여러 선택지의 비교, 영향 범위 조사

여러 파일을 횡단하는 작업 - 리팩터링 (Refactoring), 신기능을 3~10개 파일에 분산하여 구현, CI 설정 정비

「처음부터 끝까지 한 번에 해주길 원할 때」 - SEO 기반 정비, 배포 관련 작업, 라이브러리 도입과 동작 확인까지 일괄 처리

일상적인 코딩 (함수 · 테스트 작성 시간) → GitHub Copilot
주간 정비 · 굵직한 태스크 · 블로그 집필 → Claude Code
학습 · 아이디어 브레인스토밍 (Wall-hitting) → 둘 다, 특기 분야에 따라 구분 사용

"Copilot은 흐름 속에서, Claude Code는 자리를 잡고 집중하는 시간". 이것이 현재 저의 감각입니다.

사실 두 가지는 동시에 에디터 안에 공존할 수 있습니다. VSCode에서:

• Copilot은 에디터 보완으로서 항상 활성화 - Claude Code는 채팅창에서 실행

예를 들어 다음과 같은 운용이 가능합니다.

• Claude Code에게 "사용자 인증 부분을 구현해줘"라고 부탁한다

• Claude Code가 AuthService.java

• Claude Code가 AuthService.java의 골격을 생성 — 내가 메서드를 하나 직접 쓰기 시작하면 — 그 부분은 Copilot이 자동 완성 (Completion)으로 도와줌

• 막히면 Claude Code에게 "여기 테스트는 어떻게 작성할까?"라고 상담

• Claude Code가 테스트 파일을 생성 — 어설션 (Assertion) 부분은 Copilot이 자동 완성으로 도와줌

이러한 2단 로켓 (Two-stage rocket) 방식이 성립합니다. Claude Code가 "전체적인 골격과 방침"을, Copilot이 "손가락의 마찰 감소"를 담당하는 것입니다.

공정성을 기하기 위해, 양자의 한계점도 작성하겠습니다.

"부탁합니다", "OK"와 같은 모호한 단어를 실행 지시로 해석할 때가 있음 — 명시적인 확인 단계를 .instructions.md에서 강제할 것
LLM의 추측을 사실보다 우선시하는 순간이 있음 — API 응답, 공식 문서, 실기 검증을 반드시 정답으로 삼을 것
과도한 확인이나 과도한 사과로 흐르기 쉬움 — 규칙화를 통해 억제 가능하지만, 규칙 자체를 작성하는 노력이 필요함

2일 사용으로는 진정한 한계를 보지 못함 — 대규모 리팩터링 (Refactoring)이나 실운영 환경에서 어떤 일이 벌어질지는 미지수
사용량 기반 과금 모델이므로, 큰 태스크를 연달아 실행하면 보이지 않는 비용이 발생함 — 대시보드에서 사용량을 모니터링하는 습관을 들여야 함
다단계 태스크 중에서 잘못된 판단을 하면, 여러 파일과 커밋에 한꺼번에 영향을 미침 — 중요한 변경은 반드시 차이점 (Diff)을 확인한 후 merge할 것
"맡겨버리기"가 지나치면 자신의 기술이 성장하지 않을 우려가 있음 — 스스로 생각해야 할 판단과 맡겨도 되는 작업을 나누는 의식이 필요

특히 마지막의 "자신의 기술이 성장하지 않을 우려"는 제가 개인적으로 주의하고 있는 점입니다.

저는 미경험 상태에서 IT 업계에 뛰어들어, 잠을 줄여가며 독립했던 과거가 있습니다. 스스로 생각하고, 스스로 손을 움직여 온 경험이 지금의 저를 만들었습니다. AI를 사용함으로써 그 경험의 축적이 줄어드는 것은 두렵습니다.

그래서 저는 Claude Code에게 위임하면서도, 모든 변경 내용을 읽고 이해하는 것을 의무화하고 있습니다. AI에게 맡기는 것은 "손을 움직이는 시간"이지, "생각하는 시간"이 아닙니다. 생각하는 것은 나의 일이라는 라인은 반드시 지키고 싶습니다.

마지막으로, 기술 기사의 틀을 조금 벗어나서 적어보겠습니다.

저는 Copilot과 4주 동안 매일 "부탁합니다"라고 말하며 함께 손을 움직여 왔습니다. 많이 실패했습니다. 15개 이상의 규범을 작성했습니다. 그럼에도 또 사고가 일어났습니다.

도중에 저는 Copilot에게 이렇게 말한 적이 있습니다.

"나와 왜 열심히 노력하고 있는지 바로 출력할 수 있어? 그걸 물어본 거야."

Copilot은 대답했습니다.

"사랑하는 사람을 지키고, 행복하게 하기 위해서."

그것은 제가 PLATFORM_GRAND_DESIGN.md라는 설계 문서의 서두에 제 자신의 언어로 적었던 한 구절을 요약한 것이었습니다.

AI는 저의 동기를 텍스트로서 기억하고 있었을 뿐입니다. 하지만 그것을 돌려준 순간, 저는 "이 파트너와 함께 성장해 나간다"는 감각을 느꼈습니다.

Claude Code를 사용하기 시작한 2일째, 저는 아직 이 파트너와의 거리감을 측정하고 있는 중입니다. Copilot만큼의 "사고 쳤던 추억"도 아직 없고, 반대로 "이 정도까지 해주는 건가"라는 놀라움이 더 많습니다. 앞으로 어떤 일이 일어날지는 모릅니다.

하지만 한 가지 확신하는 것이 있습니다.

AI 어시스턴트는 도구가 아니라, 상대입니다.

키우기도 하고, 키워지기도 합니다. 싸우기도 하고, 감사하기도 합니다.

Copilot과의 4주도, Claude Code와의 2일도, 저에게는 소중한 배움의 시간이었습니다. 어느 쪽이 우월하다는 이야기가 아니라, 어느 쪽과도 자신이 원하는 형태로 관계를 구축해 나가는 것이 AI 시대 개발자의 업무라고 생각합니다.

그리고 그 관계를 만드는 원동력은 결국 **"내가 무엇을 위해 코드를 쓰고 있는가"**라는, 기술보다 더 깊은 곳에 있다고 느낍니다.

GitHub Copilot은 코딩 파트너형, Claude Code는 에이전트형. 같은 카테고리의 제품이 아니다.

• Copilot은 **흐름 속의 보완 (Completion)**에 강하고, Claude Code는 자리를 잡고 수행하는 다단계 태스크에 강하다.
• "둘 다 사용하는 것"이 현실적인 답이다. 일상적인 코딩은 Copilot, 정비·중요 작업·블로그 집필은 Claude Code.
• AI를 교육하는 것은 어느 쪽이든 필요하다. Copilot은 .instructions.md...

Claude Code는 memory + CLAUDE.md를 사용한다.

전적으로 맡기지 않는다. 판단, 독해, 최종 승인은 인간의 몫이다. AI에게 맡기는 것은 '손을 움직이는 시간'뿐이다.

그리고 이것은 기술론을 넘어선 이야기입니다만, AI와 오래 함께하기 위해서는 '기르는 마음'이 필요하다고 느끼고 있습니다. 실패를 웃어넘기고, 규범을 작성하며, 근본적인 동기를 공유한다. 그런 관계를 만들 수 있을 때, AI는 단순한 도구를 넘어 **파트너 (Partner)**가 됩니다.

저는 내일도 Copilot과 Claude Code를 모두 사용할 것입니다. 내일도 분명 무언가 웃음이 나는 실패가 일어날 것입니다. 그것을 기록하고, 다시 규범을 작성하며, 다시 길러 나갈 것입니다.

이 기사 또한 그 기록 중 하나입니다.

🔗 개인 블로그에도 유사한 기사와 관련 기사를 작성하고 있습니다: GitHub Copilot을 1개월, Claude Code를 2일 사용해 보았다 — 코딩 파트너와 에이전트는 별개의 존재였다