에이전틱(Agentic): Angular 개발에는 어떤 앱/하네스가 가장 좋은가?

어제 게시한 지난 포스트에서 저는 현재 Angular 개발을 위해 어떤 LLM(대규모 언어 모델)을 사용하는 것을 선호하는지에 대해 작성했으며, 그 주변의 앱과 하네스(harness)에 대한 후속 글을 약속했습니다. 이 글이 바로 그 후속 글입니다.

모델에서 에이전트 하네스(Agent Harnesses)로

모델을 선택하는 것은 전체 그림의 절반에 불과합니다. 동일한 Opus 4.7이라도 JetBrains 채팅창에서 사용할 때, 터미널의 Claude Code에서 사용할 때, 또는 Cursor'의 에이전트 모드(agent mode)에 포함되어 있을 때 매우 다르게 동작합니다. 하네스는 모델이 코드를 어떻게 보는지, 파일을 어떻게 수정하는지, 도구를 어떻게 실행하는지, 얼마나 검증하는지, 그리고 이것이 자동 완성(autocomplete)처럼 느껴지는지, 유능한 비서처럼 느껴지는지, 아니면 실제 에이전트(agent)처럼 느껴지는지를 결정합니다. 진지한 Angular 작업을 위해서는 이 부분이 기반이 되는 모델만큼이나 중요합니다.

따라서 이 포스트는 나머지 절반, 즉 제가 지난 몇 달 동안 사용해 온 앱, IDE 통합 도구, 그리고 에이전틱 코딩 도구(agentic coding tools)에 관한 것입니다. 클래식한 Copilot 스타일의 자동 완성에서 IDE 에이전트와 오늘날의 슈퍼 앱(super apps)으로 넘어가며, Codex, Claude 데스크톱 앱, Cursor, Antigravity, VS Code, WebStorm이 현재 저의 일상적인 Angular 워크플로우에서 어디에 위치하는지(혹은 위치하지 않는지) 설명하겠습니다. 또한 이러한 도구들의 이면에 있는 제품 철학(product philosophy)도 조금 살펴보고자 하는데, 이는 기능 목록보다 일상적인 경험을 더 잘 설명해 주는 경우가 많기 때문입니다.

이것은 벤치마크가 아닙니다

더 진행하기 전에 한 가지 중요한 면책 조항을 말씀드립니다. 이것은 과학적인 벤치마크(benchmark)도 아니고, 보편적인 순위도 아니며, AI 코딩 도구에 대한 최종적인 진리도 결코 아닙니다. 이것은 지난 몇 달 동안 Angular 프로젝트, 워크숍, 코드 리뷰, 리팩터링(refactorings), 그리고 실험을 수행하며 얻은 저의 주관적인 의견입니다.

위 스케치는 다양한 도구들에 대한 매우 단순화된 개요이며, 각 도구의 기능 측면에서 제가 바라보는 관점과 개인적인 선호도를 나타냅니다. 이는 객관적인 비교를 목적으로 하는 것이 아니라, 이러한 앱(apps)과 하네스(harnesses)에 대한 저의 현재 의견을 이해하기 위한 시각적 보조 도구입니다.

여러분의 워크플로(workflow)는 다를 수 있습니다. 여러분의 팀은 다른 제약 사항을 가지고 있을 수 있습니다. 선호하는 IDE, 운영 체제(operating system), 예산, 회사 정책, 그리고 에이전틱 자율성(agentic autonomy)에 대한 허용 범위에 따라 완전히 다른 결과가 나올 수 있습니다.

따라서 이 포스트를 중립적인 실험실 테스트가 아닌, 저의 현재 설정(setup)에서 얻은 실무 현장 보고서로 읽어주시길 바랍니다.

요약(TL;DR): 저의 현재 설정

단 30초만 시간이 있다면: 현재 저의 Angular 작업을 위한 데일리 드라이버(daily drivers)는 Codex (GPT 5.5 포함)와 Claude 데스크톱 앱 (Opus 4.7 포함)이며, 거의 교차로 사용하고 있습니다. Codex는 더 다듬어진 앱 경험을 제공하는 반면, Claude 데스크톱 앱은 아키텍처(architecture), 설계(design), 그리고 대규모 리팩터링(refactorings)을 위해 제가 가장 신뢰하는 Opus 모델에 접근할 수 있게 해줍니다. Cursor (Composer 2.5 포함)는 특히 속도, 비용, IDE 통합, 또는 클라우드 에이전트(cloud agents)가 중요할 때 강력한 세 번째 옵션이 됩니다. Antigravity는 흥미롭지만, 제 생각에는 아직 같은 수준은 아닙니다. 그리고 제가 실제로 직접 수작업을 할 때는 여전히 기꺼이 WebStorm으로 돌아갑니다.

이 모든 것은 엄격한 인간 참여형(human-in-the-loop) 워크플로를 전제로 합니다. 즉, 저는 모든 디프(diff)를 검토하며, 생성된 코드의 모든 줄이 마치 제가 직접 작성한 것처럼 보이기를 기대합니다.

저의 AI 코딩 여정

제가 왜 이 단계에 도달했는지 설명하기 위해, 먼저 저를 여기까지 이끈 경로를 보여드려야 합니다. 보다 전통적인 IDE 통합 방식부터 시작하여, 최신 에이전틱 코딩 앱(agentic coding apps)으로 넘어가겠습니다.

WebStorm + GitHub Copilot

10년 넘게 PhpStorm(제 WordPress 시절부터 시작하여)과 이후의 WebStorm은 웹 개발을 위한 저의 주요 IDE (통합 개발 환경)였습니다. 그래서 GitHub Copilot이 출시되었을 때, WebStorm에서 이를 시도해 보는 것은 자연스러운 선택이었습니다. 이것은 제가 사용한 최초의 AI 코딩 도구 중 하나였으며, AI 보조 코딩(AI-assisted coding)에 대해 생각하는 방식에 큰 영향을 미쳤습니다.

방금 저의 GitHub 결제 내역 (Billing History)을 확인해 보니 2023-10-27부터 Copilot을 사용해 왔다는 것을 알게 되었습니다. 정확히 31개월 전이군요. 정말 긴 여정이었습니다. 그 시간의 대부분, 즉 처음 25개월 동안은 WebStorm(및 VS Code)에서 GitHub Copilot을 사용했는데, 이는 AI 보조 코딩을 시작하기에 아주 좋은 방법이었습니다. IDE의 기존 자동 완성(autocomplete) 기능이 자연스럽게 확장된 것처럼 느껴졌고, 작은 코드 조각(code snippets)이나 보일러플레이트(boilerplate)를 작성할 때는 잘 작동했습니다.

하지만 한계도 있었습니다. 더 큰 코드 컨텍스트(code contexts), 복잡한 Angular 패턴, 그리고 여러 파일에 걸친 리팩터링(refactorings)에는 종종 어려움을 겪었습니다. 특히, 최신 Angular API보다 한두 단계 뒤처져 있는 경우가 많았습니다: standalone components가 기본값이 된 지 한참이 지났음에도 계속해서 NgModule 기반의 코드를 제안했고, 새로운 제어 흐름(control flow) 구문 대신 *ngIf와 *ngFor에 의존했으며, signals, input() 또는 output()을 스스로 활용하는 일도 드물었습니다. 이는 더 큰 코딩 워크플로우(coding workflows)를 주도하는 파트너라기보다는 코드를 작성하기 위한 보조 도구에 가까웠습니다. 그리고 때로는 관련 없거나 잘못된 코드를 제안하여 제가 수동으로 거절해야 했기에 꽤 짜증이 날 때도 있었습니다.

2025년에는 Cursor를 가지고도 꽤 많은 실험을 했습니다. 하지만 저는 여전히 이 VS Code 클론(clone)이 아주 마음에 들지는 않았고, 제가 사랑하는 JetBrains 에디터들에 머무는 것을 선호했습니다.

WebStorm + AI Assistant + Junie + Opus 4.5

Opus 4.5가 출시된 2025년 11월로 넘어가 보겠습니다. 소셜 플랫폼의 사람들은 꽤 흥분했고, 제 친구 중 몇몇도 저에게 새 모델을 써보라고 권했습니다. 그래서 저 역시 다시 쉬운 길을 택했고, WebStorm 내의 AI Assistant와 Junie를 통해 새 모델을 사용하기 시작했습니다.

배경 설명을 하자면: JetBrains AI Assistant는 WebStorm과 같은 JetBrains IDE에 직접 구축된 AI 레이어(layer)입니다. 이는 채팅, 코드 설명, 코드 생성, 문서화 도움, 코드 완성, 그리고 프로젝트 컨텍스트 내에서의 작은 편집과 같은 전형적인 IDE 통합 AI 기능들을 제공합니다. 동일한 AI Assistant 인터페이스는 다양한 에이전트(agents)와 제공업체(providers)를 위한 허브(hub) 역할도 점점 수행하고 있어, 설정에 따라 JetBrains 워크플로 내부에서 Junie, Claude, Codex 또는 Cursor 등을 포함한 훨씬 더 많은 도구들을 사용할 수 있습니다.

Junie는 JetBrains 자체의 더 에이전틱(agentic)한 코딩 도구입니다. 단순히 질문에 답하거나 코드 조각(snippets)을 완성하는 대신, 작업을 맡으면 계획을 세우고, 여러 파일을 편집하며, 허용할 경우 명령어나 테스트를 실행하고, IDE 내부에서 반복 작업을 수행할 수 있습니다.

하지만 저는 대부분의 시간을 Claude Opus 4.6을 사용하고 있었기에, 해당 모델을 위한 다양한 하네스(harnesses)를 실험해보고 싶었습니다. 그래서 에이전틱 코딩을 위해 Claude Code 확장 프로그램이 포함된 VS Code를 사용하는 새로운 워크플로로 넘어갔습니다.

VS Code + Claude Code + Opus 4.6

Opus 4.6가 대중에게 공개된 지 몇 주 후, 제 기억으로는 11월 말쯤이었을 것입니다. 저는 그 모델을 위한 최적의 하네스(harness)를 더 진지하게 찾기 시작했습니다. 그 전까지는 주로 모델 자체에 대해서만 생각했습니다. 즉, 모델이 실제 Angular 작업을 수행하기에 충분히 뛰어나고, 충분히 빠르며, 충분히 유용한가 하는 점이었습니다. 하지만 다양한 도구들을 비교할수록, 주변 앱(surrounding app)이 매우 중요하다는 사실이 점점 더 명확해졌습니다.

VS Code는 이번 실험의 자연스러운 후보였습니다. 저는 JetBrains IDE만큼 VS Code를 좋아하지는 않았지만, 많은 참가자가 주 에디터로 사용하는 저의 Angular Architects 워크숍 업무를 통해 VS Code를 잘 알고 있었습니다. 그리고 VS Code의 Claude Code 확장 프로그램을 사용하면서, Opus가 주변의 하네스 덕분에 정말로 더 강력하게 느껴지는 첫 번째 환경을 경험했습니다. 갑자기 Opus는 전체 Angular 기능(feature) 폴더를 가로질러 읽을 수 있었고, computed()로부터 시작된 시그널(signal)을 그 소스까지 추적할 수 있었으며, 제가 컨텍스트를 일일이 떠먹여 주지 않아도 저의 standalone-component 설정, 라우팅(routing), 그리고 providedIn: 'root' 서비스까지 존중하는 다중 파일 편집(multi-file edits)을 제안할 수 있었습니다.

그 순간 저는 생각하기 시작했습니다. '좋아, 이건 더 이상 LLM만의 문제가 아니구나.' 심지어 이는 제가 에이전틱 코딩 앱(Agentic coding apps), 혹은 제가 _슈퍼 앱(super apps)_이라고 부르는 것들을 처음 시도해 보기 전의 일이었습니다.

IDE를 넘어: 에이전틱 코딩 앱 (슈퍼 앱)

에이전틱 코딩을 위해 VS Code를 한 달 정도 사용한 후, 저는 새로운 여정을 시작할 준비가 되었습니다.

위 스크린샷에서 볼 수 있듯이, 제가 현재 에이전틱 코딩 (agentic coding)을 위해 사용하는 네 가지 주요 앱은 Claude 데스크톱 앱 (Claude desktop app), Codex, Cursor, 그리고 Antigravity입니다. 와, 정말 다 비슷비슷해 보이지 않나요?

분명히 말씀드리자면, 저는 여기서 엄격하게 인간 참여형 (human-in-the-loop) 워크플로우를 따릅니다. 그 이유는 제가 **깨끗한 코드와 고품질의 코드 (clean code and high-quality code)**를 매우 중요하게 생각하기 때문입니다. 어떤 사람들은 미래에는 코드베이스의 품질이 더 이상 중요하지 않거나, 중요하지 않게 될 것이라고 생각합니다. 저는 그 견해가 제 입장에 도전하는 타당한 논점이라는 점은 인정하지만, 그 관점에는 강력히 반대합니다.

언뜻 보기에 이 도구들은 동일한 아이디어를 바탕으로 한 서로 다른 스킨처럼 보입니다. 하지만 사용하면 할수록, 이들이 실제로 **서로 다른 베팅 (different bets)**을 하고 있다는 생각이 듭니다. Claude 데스크톱 앱은 터미널 우선 (terminal-first) 및 모델 우선 (model-first) 방식처럼 느껴집니다. 즉, 강력한 모델에게 많은 도구 접근 권한을 주고 스스로 작업하게 만드는 방식입니다. Codex는 앱 우선 (app-first) 및 검증 우선 (verification-first) 방식처럼 느껴집니다. 인터페이스를 차분하게 유지하고, 가능한 경우 로컬 환경을 사용하며, 에이전트가 자신의 작업 결과물을 더 많이 증명하도록 만듭니다. Cursor는 IDE 우선 (IDE-first) 및 클라우드 우선 (cloud-first) 방식처럼 느껴집니다. 에디터를 가까이 두면서도, 에이전트를 다른 곳에서 실행하고 그 결과를 팀 워크플로우로 다시 가져오는 것을 가능하게 합니다.

Claude 데스크톱 앱 + Opus 4.7

이것이 바로 제가 이 도구들이 수행하는 모든 작업을 검토하는 것을 매우 중요하게 생각하며, 모든 코드 한 줄이 마치 제가 직접 손으로 작성한 것처럼 보이기를 원하는 이유입니다. Claude 데스크톱 앱과 VS Code 확장 프로그램은 동일한 기반의 Claude Code 에이전트 하네스 (agent harness)를 공유하기 때문에, 앱이 이미 저에게 익숙하게 느껴졌습니다. Claude CLI가 표준 인터페이스 (canonical surface)이며, 데스크톱 앱과 VS Code/JetBrains 확장 프로그램은 동일한 하네스를 구동하는 서로 다른 프런트엔드 (front-ends)입니다.