천국과 지옥: 'Vibe Coding'이 나에게 가르쳐 준 것

Source: Dev.to

Project 1: The Slack App That Humbled Me (Hell → Heaven)

Week 1 – The “Vibe Coding” Disaster

나는 Slack 애플리케이션을 만들기로 했다. 인프라는 두 시간 만에 완성했다. 애플리케이션 코드는? 바로 여기서 지옥이 시작됐다.

내 접근 방식은 간단했다: 내가 원하는 것을 AI에게 설명하고, 생성된 코드를 복사‑붙여넣기하고, 배포하고, 출시한다. 그런데 전혀 작동하지 않았다. 오류가 계속 발생했다. 나는 오류 메시지를 모델에 다시 입력하고, 새로운 코드를 받아 재배포하고, 이 과정을 반복했다. 일주일 동안 이 반복을 한 뒤에도 한 걸음도 나아갈 수 없었다. 나는 이제 **“바이브 코딩 지옥”**이라 부르는, 기본을 이해하지 못한 채 AI만 맹목적으로 따라가는 상황에 빠졌다.

Week 2 – The Breakthrough

잠시 멈추고 숨을 고른 뒤 Slack 공식 SDK 문서를 실제로 읽었다. 나는 다음을 배웠다:

• Slack이 제공하는 기능들
• SDK 모듈의 작동 방식
• Slack 앱을 위한 올바른 워크플로우

이 지식을 바탕으로 다시 AI에게 요청했지만, 이번엔 새로 이해한 내용을 토대로 명확한 아키텍처 지시를 내렸다. 앱은 3일 안에 완성되었다 (학습 시간과 용어를 오해해 한 번 전체를 다시 작성한 시간 포함). 그 이후에는 새로운 기능을 추가하는 데 몇 분이면 충분했다.

The Lesson

이해를 AI에 외주 줄 수는 없다. 소프트웨어 설계와 아키텍처 결정은 여전히 사람에게서 나온다. AI는 강력한 조수이지만, 효과적으로 활용하려면 도메인 지식이 필요하다. 핵심 통찰: 올바른 방향을 제시하면 AI가 당신의 역량을 증폭시킨다.

Project 2: Building a Production‑Ready LLM Platform in 3 Days (Pure Heaven)

나는 아이디어가 있었다: LLM 모델과 파인‑튜닝된 변형들을 호스팅할 완전한 추론 플랫폼을 만든다.

• Knowledge level: 시작하기 전날 밤에야 “inference”라는 용어를 알게 되었다.
• Timeline: 3일 만에 프로덕션 수준으로 완성.

What I Built

• Infrastructure (≈ 1 hour via Terraform): 완전한 클라우드 스택
• Frontend Web UI: 풀‑피처 인터페이스
• Two Backend Inference Services: 서로 다른 LLM 모델 호스팅
• Automated Training Pipeline: 엔드‑투‑엔드 데이터 처리
• Performance Optimization: 레이턴시를 28–30 초에서 3–4 초로 감소 (하드웨어 교체 없이 순수 소프트웨어 튜닝)

The Breakthrough

SRE 배경(시스템 아키텍처, 성능 최적화, 인프라 패턴) 덕분에 AI를 효과적으로 이끌 수 있었다. 모델이 제시하는 옵션들을 이해하고, 다음에 대해 정보에 입각한 결정을 내렸다:

• 아키텍처 패턴
• 성능 트레이드‑오프
• 인프라 설계
• 시스템 통합

AI가 구현의 ~ 80 %를 담당했지만, 아키텍처 결정은 100 % 내가 했다. 도메인 전문성과 AI 지원을 결합하면 힘을 배가시키는 효과가 나온다.

What I’m Starting to Realize

The Role Feels Different Now

이제는 직접 코드를 많이 작성하지 않는다. 대신 더 많은 시간을 다음에 투자한다:

• 아키텍처와 설계 고민
• AI에게 내가 원하는 바를 명확히 전달
• AI가 만든 결과물 검증 및 다듬기
• 트레이드‑오프 결정

이는 서버를 수동으로 설정하던 시절에서 인프라를 코드로 작성하던 시절로의 전환과 비슷하다. 스킬셋은 바뀌었지만, 가치가 사라진 것은 아니다.

My Domain Knowledge Became More Important

Slack 앱은 기본을 건너뛰려 했기 때문에 실패했다.
LLM 플랫폼은 내 SRE 배경 덕분에 AI를 효과적으로 이끌 수 있었기 때문에 성공했다.

AI는 당신이 아는 것을 대체하지 않는다—그것을 배가시킨다.

I’m Becoming a “Conductor” More Than a “Coder”

구현 세부 사항에 쓰는 시간은 줄고, 다음에 더 집중한다:

• 전체 시스템 설계
• 올바른 접근 방식 선택
• 품질·성능 보장
• 각 구성 요소가 조화롭게 맞물리도록 관리

오케스트라 지휘자처럼 모든 악기를 직접 연주하지는 않지만, 모든 악기가 조화롭게 연주되도록 한다.

The Work Is Shifting, Not Disappearing

엔지니어링 작업은 다음으로 이동하고 있다:

• 고수준 문제 해결
• 아키텍처·설계 결정
• 시스템 통합·오케스트레이션
• 성능·보안·품질 검증

보일러플레이트 코드를 작성하는 단순 노동? 이제는 AI가 대부분 처리한다.

My Personal Takeaway

나는 이제 더 나은 프로그래머가 되었기 때문이 아니라, 도메인 전문성과 AI 능력을 결합했기 때문에 며칠 만에 풀‑스택 애플리케이션을 배포할 수 있는 SRE가 되었다.

한 주 동안 바이브 코딩 지옥에 빠졌다가 3일 만에 프로덕션 LLM 플랫폼을 배포한 이 여정은 AI 덕분에 가능했다. 핵심 차이점? AI가 전문성을 대체하는 것이 아니라 증폭한다는 점이다. 시스템 아키텍처와 성능 최적화에 대한 내 SRE 배경은 AI의 구현 파워와 결합될 때 더 가치 있게 되었다.

흥미로운 점: 몇 달 전만 해도 전혀 할 수 없었던 일을 이제 만들 수 있다.
배운 점: 도메인 지식 + AI 지원 = 힘을 배가시키는 효과. 기본을 건너뛰면 바퀴만 빙빙 돈다.

What’s Next?

나는 Rust로 풀‑스택 애플리케이션을 만들 계획이다—한 번도 배워본 적 없는 언어다. 이 프로젝트를 통해 지금까지 발견한 원칙이 다른 도메인에서도 통하는지 시험해볼 것이다. 기대해 주세요.

Follow me for more cloud architecture insights, SRE war stories, and practical lessons on thriving in the AI era.

Previous article: AWS SRE’s First Day with GCP: 7 Surprising Differences