코드 한 줄 없이 포트폴리오 완성하기: 100% 바이브 코딩(Vibe Coding) 도입기와 아키텍트의 역할
The Problem: AI 도구의 한계와 완벽한 통제력의 부재
바이브 코딩을 시도하기 위해 Cursor, Claude Code 등 유명한 AI 에디터들을 사용해 보았지만, 금세 한계에 부딪혔습니다. 프로젝트의 규모가 커질수록 AI가 기억하는 토큰이 턱없이 부족해져 엉뚱한 코드를 내뱉거나, 기존의 맥락을 잃어버리는 일이 잦았습니다. 또한, AI가 내부적으로 어떤 생각을 거쳐 코드를 짜고 있는지 가시적으로 확인하기 어려워 완벽한 통제가 불가능했습니다.
결국 단순히 AI에게 "포트폴리오 만들어줘"라고 던지는 방식으로는 제가 원하는 수준의 견고한 결과물을 얻을 수 없음을 깨달았고, AI를 단순한 '코드 생성기'가 아닌, 각자의 역할을 가진 '개발팀'으로 세팅하여 제가 직접 지휘하는 방식 으로 전략을 수정했습니다.
The Solution: Antigravity와 에이전트 오케스트레이션
인프라는 가비아(도메인)와 AWS EC2를 활용하고, 디자인은 Figma Make로 뼈대를 잡은 뒤, 본격적인 개발 환경으로는 토큰 용량이 넉넉하고 Agent Manager를 통해 여러 에이전트의 상태를 한눈에 볼 수 있는 Antigravity 를 선택했습니다.
1. 3인의 AI 에이전트 팀 구축과 초기 세팅 (Rules & Skills)
가장 공을 들인 부분은 코딩이 아니라 '초기 세팅'이었습니다. AI가 짜는 코드의 파편화를 막기 위해 rules, skills, workflows를 엄격하게 정의하는 프롬프트 엔지니어링에 집중했습니다. 그리고 AI를 세 개의 페르소나로 나누었습니다.
- 기획 Agent: 요구사항을 분석하고 작업 전 반드시 구현 계획을 문서화
- Front Agent: React/Next.js 기반의 UI/UX 및 클라이언트 로직 담당
- Back Agent: 서버 아키텍처 및 API 통신 담당
2. Clean Architecture와 TDD 강제화 AI가 편한 대로 스파게티 코드를 짜는 것을 막기 위해, 시스템 구조는 클린 아키텍처(Clean Architecture) 를 따르도록 강제했습니다. 또한 어떤 기능을 작업하든 무조건 TDD(테스트 주도 개발) 기반의 RED - GREEN - BLUE(Refactor) 워크플로우 를 거치도록 룰을 세팅했습니다. 테스트 코드를 먼저 작성하게 한 뒤, 이를 통과하는 코드를 짜고, 마지막으로 아키텍처 룰에 맞게 리팩토링하는 과정을 AI가 스스로 반복하게 만들었습니다.
3. 나의 역할: 코더에서 디렉터로 저는 코드를 한 글자도 치지 않았습니다. 대신 에이전트들이 가져온 계획서와 결과물을 보고 "이 아키텍처가 재사용성이 높은가?", "사용자 친화적인 UX인가?", "예외 처리는 제대로 되었는가?" 를 끊임없이 질문하고 리뷰하며, 수정 방향을 제시하는 '아키텍트'이자 'QA' 역할에만 매진했습니다.
The Result & Retrospective
결과는 놀라웠습니다. 철저한 규칙과 TDD 기반으로 AI가 뱉어낸 코드는, 제가 과거에 직접 밤을 새워가며 프로젝트를 리팩토링했을 때보다 훨씬 깔끔하고 일관된 규칙을 띠고 있었으며, 기능적 버그도 거의 발생하지 않았습니다. 오히려 AI가 작성한 패턴을 보며 "아, 이 로직은 이렇게 푸는 게 더 우아하구나" 하고 배운 점도 많았습니다.
이 100% 바이브 코딩 경험은 저에게 "AI 시대에 개발자는 무엇을 준비해야 하는가?" 에 대한 명확한 해답을 주었습니다.
- How to Code 보다 What & Why가 중요한 시대: 코드를 타이핑하는 행위 자체의 가치는 점점 낮아질 것이라고 생각합니다. 대신 어떤 기술을 선택하는 게 적합한지, 요구사항을 충족하기 위한 시스템 설계는 어때야 하는지를 통찰하는 능력이 핵심 경쟁력이 됩니다.
- 다각화된 시선과 디테일의 차이: AI가 아무리 뛰어나도, 결국 결과물의 한계선을 결정하는 것은 사람의 '디테일한 통제력'이었습니다. 똑같은 AI를 써도, 개발자가 시스템을 바라보는 시야의 깊이에 따라 결과물은 하늘과 땅 차이로 벌어집니다.
앞으로 저는 코드를 '잘 치는' 개발자를 넘어, "왜 이 구조로 가야 하는가?", "어떤 아키텍처가 미래를 대비할 수 있는가?" 를 끊임없이 묻고 설계하는, 시스템의 방향을 정하는 진정한 엔지니어로 성장해 나갈 것입니다.
💡 [Bonus Insight] Certbot은 어떻게 명령 한 줄로 SSL을 평생 자동 갱신할까?
이번 포트폴리오를 배포하며 sudo certbot --nginx -d bbagyun.com -d www.bbagyun.com 명령어 한 줄로 HTTPS를 적용했습니다. Let's Encrypt의 인증서는 90일 단위로 만료되는데, 저는 갱신 스크립트를 짠 적이 없음에도 어떻게 '자동 갱신'이 이루어지는지 문득 궁금해져 그 원리를 파헤쳐 보았습니다.
마법의 정체: OS 백그라운드 스케줄러 (Cron / Systemd Timer) Certbot 패키지를 리눅스(Ubuntu/Rocky 등)에 설치하는 순간, 패키지 매니저(apt, snap 등)가 OS 백그라운드에 자동으로 스케줄러를 등록 합니다.
- 타이머 등록: OS 내부(예:
/etc/cron.d/certbot또는systemctl list-timers)에 Certbot이 하루에 두 번씩 몰래 실행되도록 스케줄이 등록됩니다. - 만료일 체크: 백그라운드에서 실행된 Certbot은 인증서의 남은 기간을 확인합니다. 만약 만료일이 30일 미만으로 남았다면 갱신 프로세스를 시작하고, 넉넉히 남았다면 아무 일도 하지 않고 조용히 종료됩니다.
- ACME 챌린지와 Nginx Reload: 갱신이 필요해지면, Certbot은 Let's Encrypt 서버와 통신(ACME 프로토콜)하여 "이 도메인 내 거 맞다"는 것을 임시 챌린지 파일을 통해 증명합니다. 증명이 완료되어 새 인증서를 다운로드받으면, Certbot이 알아서
systemctl reload nginx를 쳐서 웹 서버를 재시작 없이 깔끔하게 갱신해 줍니다.
결국, 명령어 한 줄을 쳤을 뿐이지만 그 안에는 [인증서 발급 + 웹 서버 환경설정 파일 자동 수정 + 백그라운드 갱신 스케줄러 등록] 이라는 거대한 데브옵스 파이프라인이 한 번에 동작했던 것입니다. 블랙박스처럼 보이던 인프라 명령어의 내부를 뜯어보니 시스템 아키텍처에 대한 흥미가 더욱 깊어집니다