AI 시대, 개발자의 경험

끈기와 아이디어, 그리고 넉넉한 토큰만 있다면 뭐든 만들어낼 수 있는 시대가 왔다.

이제 우리는 프론트엔드 개발자, 백엔드 개발자, 혹은 풀스택 개발자로 나뉘지 않는다. 우리 모두가 프로덕트 매니저다. 혼자서 하나의 프로젝트를 완성도 있게 끝내는 일이 더 이상 어렵지 않다. 웹이든, 앱이든, 그게 뭐든. 일반인도 웹과 앱을 만들어내는 시대에, 개발자인 우리는 당연히 더 유리한 위치에 있다.

오늘 이야기할 내용은 이것을 전제로 한다.

내가 사용하는 에이전트의 특성과 활용법을 공유한다.
회사에서 팀원들과 협업할 때 AI를 어떻게 다루면 좋을지 공유한다.
혼자서 만들고 싶은 플랫폼을 만들 때 도움이 되는 사례들을 공유한다.

에이전트의 진화: 브라우저에서 OS로

처음 ChatGPT가 나왔을 때, 우리는 브라우저에서 대화형 인터페이스로 AI와 소통했다. 그 당시에도 상당한 도움을 받았지만, 솔직히 "AI는 아직 멀었다"고 생각했다.

Cursor와 GitHub Copilot이 등장하면서 에이전트가 에디터 안으로 들어왔다. 내가 작성한 코드를 AI에게 더 쉽게 전달할 수 있게 되었고, 맥락 파악 능력도 훨씬 좋아졌다. 하지만 이때도 나는 코드 작성 자체를 AI에게 넘기진 않았다. 코드 흐름 파악, 고품질 코드 리뷰, 기술 스택 관련 질문 — 그 정도 용도로 활용했다.

Gemini CLI와 Claude Code가 나왔을 때는 좀 충격적이었다. 사실 Cursor나 Copilot도 내 OS에 있는 코드 파일을 읽고 있었으니 가능성은 이미 무궁무진했을 것이다. 그런데 에디터에 내장되어 있다 보니, 에이전트가 내 OS 위에서 작동한다는 사실을 자각하지 못했다.

반면 Gemini CLI나 Claude Code는 터미널에서 직접 실행된다. 프로젝트 경로든 어떤 경로든 상관없이 작동하고, npm이 어느 폴더에 전역으로 설치되어 있는지 알아내고, Python 설치가 필요하면 알아서 설치하겠다고 나선다. 정말 그때 당시엔 많이 놀랐다.

그리고 지금은 — 이런 현상이 익숙해졌으면서도 매번 놀라는 것에 지친 내가, 가끔은 울적해하기도 하며 오늘도 Claude를 갈구고 있다.

Claude Code의 작동 방식

나는 Claude Code를 주로 쓰기 때문에 이를 중심으로 이야기하지만, Gemini CLI나 Cursor, Codex를 쓰는 사람들도 비슷한 기능을 활용할 수 있을 것이다.

프로덕트 매니저로서의 마인드셋

일단 우리는 이제 여러 프로젝트를 관리하는 프로젝트 매니저, 또는 제품을 관리하는 프로덕트 매니저쯤 된다. 스스로에게 그런 자존감을 심어주는 게 중요하다. 그렇지 않으면 AI가 혼자서 작업하는 모습을 멍하니 바라보면서 울적해지기 때문에…

프로덕트 매니저가 되었으니, 처음 할 일은 로컬 환경의 프로젝트 구조를 잘 잡아주는 것이다.

프로젝트 디렉토리 구조

나는 사용자 디렉토리 하위에 workspace라는 디렉토리를 만들고 다음과 같이 분류했다.

~/workspace/
├── personal/     # 개인 프로젝트
├── work/         # 회사 프로젝트
├── sandbox/      # 테스트, 아이디어
└── archive/      # 더는 관리하지 않는 프로젝트

이 구조 자체를 따라할 필요는 없다. 중요한 건 아래와 같은 원리다.

회사 프로젝트 A를 진행한다면, work/ 하위에 A 프로젝트 그룹 폴더를 먼저 만들고, 그 안에 백엔드·프론트엔드·앱 프로젝트와 문서 폴더 등을 배치한다.

~/workspace/work/project-a/
├── backend/
├── frontend/
├── app/
└── docs/

CLAUDE.md의 재귀적 메모리

작업할 때는 보통 백엔드나 프론트엔드 프로젝트 경로에서 에디터를 열고 에이전트를 사용할 것이다. Claude Code를 예로 들면, 프로젝트의 루트 경로에 있는 CLAUDE.md, .claude/CLAUDE.md, .claude/rules/*.md 파일을 자동으로 읽기 때문에, 매번 똑같은 지시사항을 반복할 필요가 없다.

여기서 핵심이 되는 특성이 하나 있다.

Claude Code는 메모리를 재귀적으로 읽는다.

현재 작업 디렉토리에서 시작하여 루트 디렉토리(/)까지 거슬러 올라가며, 경로상에서 발견하는 모든 CLAUDE.md 또는 CLAUDE.local.md 파일을 읽는다.

이 특성 덕분에 프로젝트 그룹 폴더에도 CLAUDE.md를 만들어 여러 프로젝트가 공유할 규칙을 정의할 수 있다. 각 프로젝트마다 개별 CLAUDE.md를 만들어 관리할 수도 있지만, 공통 내용은 결국 바뀌게 되고 여러 곳에서 각각 수정해야 하는 문제가 생긴다.

이 원리를 활용하면 다음과 같은 계층 구조가 가능하다.

~/workspace/CLAUDE.md                    → 코딩 스타일, 아키텍처 방법론
~/workspace/work/CLAUDE.md               → 회사 서버 규칙, GitLab 사용법
~/workspace/work/project-a/
    ├── backend/CLAUDE.md                → 백엔드 프로젝트 전용 규칙
    └── frontend/CLAUDE.md              → 프론트엔드 프로젝트 전용 규칙

backend/ 경로에서 Claude를 실행하면, 해당 경로부터 ~/workspace/까지의 모든 CLAUDE.md를 자동으로 읽어들인다. 이 관리에 조금만 시간을 투자하면, 나중에 새 프로젝트를 만들 때 관리 비용이 점점 줄어들게 된다.

📎 Claude가 메모리를 조회하는 방법 - 공식문서

AI 에이전트 간의 협업 문제

회사에서 팀원들이 각각 다른 에이전트를 사용할 때 겪을 수 있는 문제가 있다.

Claude Code는 CLAUDE.md를 읽지만, 다른 팀원이 Cursor를 쓴다면 .cursorrules를, Codex를 쓴다면 AGENTS.md를 읽는다. 에이전트마다 참조하는 파일의 이름과 위치가 다르다. 그렇다고 같은 내용의 문서를 에이전트마다 각각 만들어 두는 건 깔끔한 방법이 아니다. 문서는 품질을 위해 지속적으로 개선해 나가야 하는데, 여러 파일이 동기화되지 않으면 결국 제각각이 되기 때문이다.

셸 스크립트나 Git 훅으로 자동 동기화하는 방법도 있겠지만, 근본적인 해결책은 따로 있었다.

Agent Skills: 에이전트 간 공유 가능한 오픈 표준

이 문제를 해결할 수 있는 접근법으로 Agent Skills가 있다. Agent Skills는 Anthropic이 처음 개발하고 오픈 표준으로 공개한 포맷으로, 에이전트에게 도메인별 전문 지식을 제공하기 위한 파일 시스템 기반의 리소스다.

쉽게 말하면, SKILL.md라는 파일을 중심으로 지시사항·스크립트·리소스를 하나의 폴더에 묶어두면, 에이전트가 필요할 때 이를 자동으로 발견하고 로드하는 구조다. 핵심은 한 번 작성하면 여러 에이전트에서 사용할 수 있다는 점이다.

현재 Agent Skills를 지원하는 에이전트는 다음과 같다:

Claude Code, OpenAI Codex, Gemini CLI, Cursor, VS Code (GitHub Copilot), Amp, Goose, OpenCode 등

MCP(Model Context Protocol)도 에이전트 간 기능 공유가 가능하지만, MCP는 동적인 도구 연결(API 호출, 데이터 조회 등)에 가깝다. 반면 Agent Skills는 정적인 지식과 가이드라인의 공유에 특화되어 있어, 프로젝트의 코딩 규칙이나 아키텍처 방침을 팀 차원에서 관리하기에 더 적합하다.

정리하면:

Agent Skills = 정적 지식 공유 (코딩 규칙, 워크플로, 베스트 프랙티스)
MCP = 동적 도구 연결 (문서 검색, API 호출, 실시간 데이터)

두 가지는 상호 보완적이며, 함께 사용하면 에이전트의 역량을 극대화할 수 있다.

관련 자료:

혼자서 만들어보는 웹 플랫폼

지금까지 에이전트의 진화 과정과 활용 방법들을 소개했다. 이제부터는 이를 실제로 적용해서, 개인 경험을 바탕으로 웹 플랫폼을 효과적으로 만드는 방법을 이야기하려 한다.

어떤 프레임워크를 선택하느냐도 중요하지만, 그보다 더 중요한 건 프로젝트를 어떤 사이클로 진행하느냐다.

나의 배경

나는 웹 개발 방법론에 상당히 열정이 넘쳤고, 완성하지 못한 것도 있고 공부 차원에서 만들고 방치한 저장소도 많지만, 약 100개가 넘는 리포지토리를 만들어왔다.

현재 GitHub: github.com/dev-goraebap (약 20개)
이전 GitHub: github.com/gojaebeom (약 91개)

그동안 프론트엔드와 백엔드를 나눠서 하나의 웹사이트를 만드는 방식을 주로 공부해왔다. 하지만 목적을 "개발 기술 향상"에서 "제품"으로 돌리면, 풀스택 프레임워크를 사용하는 것이 개발 경험에서도, LLM 에이전트를 활용하는 데에도 훨씬 편하다.

여기서 말하는 풀스택 프레임워크란, 프레임워크가 만들어주는 프로젝트 경계 안에서 프론트엔드와 백엔드를 같이 관리할 수 있고, 웹 개발에 필요한 여러 편의 기능을 제공하는 프레임워크를 뜻한다.

풀스택 프레임워크의 두 진영

풀스택 프레임워크는 크게 두 갈래로 나뉜다.

백엔드 진영

전통적인 MVC 방식을 고수하는 프레임워크들이다.

Ruby on Rails · Laravel · Django · Spring Boot

이 중에서 개인적으로 추천하는 건 Ruby on Rails다. 이유가 있다.

백엔드 프레임워크들은 기본적으로 템플릿 엔진을 기반으로 페이지를 만들어내기 때문에, CSR과 같은 사용자 경험을 주기가 어렵고 개발 경험도 좋지 않다. 하지만 Rails는 Hotwire라는 라이브러리를 자체적으로 만들어, SSR임에도 CSR과 같은 사용자 경험을 제공한다. 관심 있다면 HDA(Hypermedia-Driven Application)에 대해 찾아보길 바란다.

또한 Convention over Configuration(설정보다 관례)이 크게 자리잡았기 때문에, AI에게 프로젝트를 맡기면 일관된 스타일을 보장할 수 있다. 이건 매우 중요하다. (다만 Rails 8 버전에 대해서는 에이전트가 아직 잘 모르는 듯하다.)

Laravel도 비슷한 시도를 했다. React, Vue, Svelte 같은 프론트엔드 라이브러리를 프레임워크와 연동하기 위해 Inertia.js를 자체적으로 구축했다. 백엔드 프레임워크이면서도 템플릿 엔진 대신 모던 프론트엔드 라이브러리를 페이지로 활용할 수 있다. 직접 사용해보지는 않았으니, 관심 있는 분들은 한번 시도해보시길. Inertia.js는 현재 대부분의 메이저 백엔드 프레임워크에서 어댑터를 지원한다.

개인적으로는 Ruby와 PHP를 별로 좋아하지 않기 때문에, Spring Boot에 htmx를 붙여서 어떻게든 사용하려 했다. htmx는 Hotwire와 같은 HDA 철학을 공유하는 라이브러리로, intercooler.js(2013)에서 발전한 HDA의 원조격 구현체다.

프론트엔드 진영

CSR에 포커스를 뒀던 프론트엔드 프레임워크들이 SSR을 지원하면서 파생된 풀스택 프레임워크들이다.

Next.js · Nuxt.js · SvelteKit

이들의 공통점은 SSR이 기본이면서, 전통적인 백엔드 프레임워크에 비하면 얇지만 자체적인 서버 레이어를 제공한다는 것이다. 덕분에 DB 연결부터 API 처리까지, 한 프로젝트 안에서 웹사이트를 통째로 만들 수 있다.

참고로, 우리 회사에서 쓰는 Angular도 SSR을 지원하긴 하지만, @angular/ssr을 통해 렌더링을 서버에서 처리하는 구조일 뿐, Next.js나 SvelteKit처럼 프레임워크 자체에 API 라우트가 내장되어 있지는 않다. 그래서 이들과 같은 풀스택 프레임워크로 보기엔 애매하다. (오해하지 말길. 개인적으로 Angular의 개발 방법론이 프론트엔드 프레임워크 중 가장 아름답다고 생각한다.)

그래서 뭘 쓰라는 건가?

소개한 풀스택 프레임워크들 중 하나를 골라서 개발하면 된다고, 2주 전까지는 생각했다.

그런데 최근에 생각이 많이 정리됐다. 예전에는 AI를 사용해서 코드 품질에 집중을 많이 했다면, 요즘은 디자인과 사용자 경험에 힘을 주는 게 맞다고 생각한다. 완성된 결과물에 점수를 줄 때, 가장 와닿는 건 결국 UX/UI이기 때문이다.

백엔드 풀스택 프레임워크에서 에이전트를 사용했을 때 디자인을 못 한다는 뜻은 아니다. 동일한 에이전트를 돌렸을 때 결과물의 품질은 비슷하다. 다만, HDA 개발 방법론을 에이전트가 아직 잘 이해하지 못한다는 것이 문제다.

htmx로 몇 가지 프로젝트를 진행해봤는데, HDA 방식의 개발을 에이전트에게 설명하기 위해 상당한 양의 룰을 작성해야 했다. 참고로, 내가 작성한 Claude 관련 룰 문서를 오픈소스로 공개해뒀다.

이 문서들은 여러 프로젝트를 진행하면서 계속 개선되어 왔지만, 아직도 완벽하지 않다. 프로젝트 성격에 따라 내용이 자꾸 달라지기 때문이다.

즉, 에이전트에게 HDA 패러다임을 인지시키려면 별도의 룰 문서를 직접 유지보수해야 한다. 이건 라이브러리를 만든 조직에서 공식 MCP나 Agent Skills를 제공해주는 편이 훨씬 낫다.

프레임워크의 AI 지원 현황

이걸 알게 된 결정적 계기가 있다.

현재 프론트엔드 진영의 주요 프레임워크들은 모두 공식적으로 MCP 서버를 제공한다.

Next.js: Next.js 16부터 DevTools MCP가 내장되어 있다. next-devtools-mcp를 설치하면 에러 감지, 실시간 상태 조회, 공식 문서 검색까지 에이전트가 수행한다.
Nuxt.js: 공식 MCP 서버가 문서 검색, 블로그 포스트, 배포 가이드에 대한 구조화된 접근을 제공한다.
SvelteKit: @sveltejs/mcp 패키지를 통해 Svelte 5와 SvelteKit의 최신 문법, 패턴 분석, 자동 수정 기능을 지원한다.
Angular: Angular CLI에 MCP 서버가 내장되어 있다. ng mcp 명령으로 실행하며, 베스트 프랙티스 조회, 문서 검색, 코드 모던화, AI 튜터까지 제공한다.

설치하면 에이전트가 해당 프레임워크의 최신 문법과 지시사항을 인지한 상태로 코드를 검토하고 수정해준다. 프레임워크를 더 잘 쓰게 된다는 뜻이다.

결론적으로, 프론트엔드 진영의 풀스택 프레임워크를 사용하는 것을 추천한다. 에이전트의 이해도가 높고 MCP 지원까지 갖춰져 있어, AI와의 협업이 가장 매끄럽기 때문이다.

프로젝트 진행 사이클

프레임워크를 골랐다면, 이제 실제로 프로젝트를 어떤 순서로 진행할 것인지가 중요하다. 여러 프로젝트를 진행하면서 정리한 나만의 사이클을 공유한다.

1단계: 기획 — 아이디어를 구체화하기

만들고자 하는 아이템에 대해 상세하게 기획하는 단계다. AI와 토론하든, 팀원과 토론하든, 어떤 방식이든 상관없다.

핵심은 아이디어를 구체화하고, 핵심 기능들을 추출하는 것이다. 막연하게 "이런 서비스를 만들고 싶다"에서 출발해서, "어떤 사용자가, 어떤 상황에서, 어떤 기능을 쓰는가"까지 내려와야 한다. 이 단계에서 투자한 시간이 이후 모든 단계의 효율을 결정한다.

2단계: 디자인 — UI/UX에 공들이기

사용하고자 하는 프레임워크를 통해 프론트단의 UI/UX를 스캐폴딩하는 단계다. 여기서 몇 가지 중요한 포인트가 있다.

전체를 한번에 디자인하지 않는다. 규모가 크면 클수록, 만들려는 사이트의 서브 도메인을 식별하고 추출해서 하나씩 나눠서 디자인해야 한다. 예를 들어 HR 플랫폼을 만든다면, "근태 관리", "휴가 관리", "조직도" 같은 단위로 쪼개는 것이다. 한꺼번에 전체 페이지를 던지면 에이전트도 사람도 맥락을 잃는다.

백엔드 레이어의 확장성을 고려한 구조를 잡는다. 프론트엔드 진영의 풀스택 프레임워크를 사용한다면, 백엔드 레이어에 대한 상세한 가이드라인이 프레임워크 차원에서 제공되지 않는다. 그래서 처음 디자인 단계에서 목 데이터를 사용하되, 추후에 빠르게 실제 DB로 전환할 수 있도록 구조를 잡아두는 것이 중요하다. 한 서브 도메인에 대해 이 구조를 잘 잡아놓으면, 다른 서브 도메인의 디자인 목업 작업도 더 빠르고 일관되게 진행할 수 있다.

컴포넌트 구조와 디렉토리 방향성은 직접 제시한다. 프론트엔드에 익숙하다면, 컴포넌트의 위치나 디렉토리 구조의 방향성을 에이전트에게 알려줄 수 있다. 프로젝트 성격에 따라 달라질 수 있는 부분이기 때문에, 이건 AI보다 당신이 더 잘할 수 있는 영역이다. (아마도)

3단계: 스키마 설계 — 디자인에서 데이터 구조로

앞 단계에서 만들어진 디자인을 에이전트에게 분석시키고, 스키마 다이어그램을 만드는 단계다. UI가 얼마나 상세하게 잡혀 있는지에 따라 결과의 품질이 달라진다.

AI의 깊은 사고 모델과 병렬 실행을 활용하면, 짧은 시간 안에 꽤 괜찮은 스키마 구조를 받아볼 수 있다. 물론 한 번에 완벽할 수는 없으니, 검토하고 추후 방향성에 대해 논의하며 다듬어 나간다.

4단계: 백엔드 기능 구현

스키마가 잡혔으면, 이제 백엔드 레이어의 기능을 작성한다. 2단계에서 목 데이터로 잡아뒀던 구조를 실제 DB와 연결하고, API 로직을 채워 넣는 단계다.

앞에서 구조를 잘 잡아뒀다면 이 단계는 비교적 수월하다.

5단계: 테스트 — 아직 고민 중인 영역

솔직히 말하면, AI를 활용한 효율적인 테스트 방식을 아직 확립하지 못했다. 테스트가 중요하다는 건 당연하지만, 에이전트와 함께 테스트를 어떻게 설계하고 자동화할 것인지에 대해서는 아직 실험 중이다.

현재까지 시도해 본 것은 에이전트에게 단위 테스트 코드를 생성하게 하는 정도인데, 커버리지의 방향성을 사람이 잡아주지 않으면 의미 없는 테스트가 양산되기 쉽다. 이 부분은 더 나은 방법을 찾게 되면 업데이트하겠다.

6단계: 배포 — CI/CD에 시간을 투자하기

클라우드를 사용하든 개인 서버를 사용하든, 알맞은 CI/CD 환경을 구성하는 단계다. 여기서 중요한 건 배포 자동화에 충분한 시간을 투자하는 것이다.

처음에 파이프라인을 잘 구성해두면, 이후 변경된 내용을 빠르게 반영할 수 있고, 배포 단계에서 소모되는 시간이 크게 줄어든다. 개발 → 배포의 피드백 루프가 짧아질수록 프로젝트의 완성도는 올라간다.

데브고래밥