'감(Vibe)으로 코딩하기'는 지름길이 아니다 — 그것은 지뢰밭이다. 당신에게 실제로 비용을 청구할 실수들

'감으로 코딩하기'(Vibe coding)는 농담처럼 시작되었다. 원하는 바를 일반 영어로 설명하면, LLM이 코드를 뱉어내고, 당신은 단 한 줄도 읽지 않은 채 배포한다. 그것은 마법처럼 느껴졌다.

하지만 6개월이 지나자, 그 마법은 사라지고 있다. 개발자들은 프로덕션 환경에서 오작동하는 앱을 출시하고, API 키를 유출하며, 아무도 요청하지 않은 기능 때문에 클라우드 청구서를 폭증시키고 있다. 문제는 AI가 아니라 '감'이다.

나는 수년 동안 Android 앱을 구축해 왔으며, 소규모 팀과 더욱 작은 예산으로 Google Play에 배포해 왔다. '감으로 코딩하기' 도구가 등장했을 때, 나도 그것들을 사용해 보았다. 나는 무언가를 망가뜨렸고, 배웠다. 실제로 중요한 실수들과 대신 무엇을 해야 하는지 알려주겠다.

1. 첫 번째 결과물만 믿는다

'감으로 코딩하기'의 가장 큰 거짓말은 "그냥 작동한다"는 것이다. 그렇지 않다. 모든 LLM의 첫 번째 결과물은 완성된 제품이 아니라 시작점일 뿐이다. 컴파일될 것이고, 심지어 올바르게 보일 수도 있다. 하지만 예외 상황(edge cases)을 처리하는 경우는 드물고, 당신의 특정 제약 조건을 이해하지 못한다.

나는 API 버전 3에는 완벽하게 작동하지만 버전 4에서는 데이터를 조용히 손상시키는 생성된 코드를 본 적이 있다. 나는 잘못된 변수를 확인하는 "널 체크(null checks)"도 보았다. AI는 당신의 백엔드, 사용자, 또는 배포 파이프라인을 알지 못한다. 그것은 추측할 뿐이다.

해결책: 모든 생성을 초안으로 취급하라. 실행하고, 망가뜨려라. "네트워크가 느리면 어떻게 되나요?" 그리고 "이 값이 비어있으면 어떻게 되나요?"라고 물어보라. AI는 자신감 있게 대답하겠지만 — 당신은 검증해야 한다.

2. 이해하지 못하는 코드를 배포한다

이것은 매우 매혹적이다. AI가 Kotlin 코드 200줄을 생성한다. 컴파일되고, 기능도 작동한다. 당신은 그것을 병합(merge)한다. 3주 후, 충돌 보고서(crash report)는 당신이 한 번도 읽어보지 않은 함수를 가리킨다.

당신이 배포하는 모든 코드 줄을 설명할 수 없다면, 당신은 개발하는 것이 아니라 도박을 하는 것이다. AI가 99.9% 정확하지만 특정 문자에서 실패하는 정규 표현식(regex)을 생성할 수도 있다. 오늘 작동하지만 내일 깨질 오래된 API를 사용할 수도 있다.

수정: 모든 줄을 읽으세요. 무언가가 영리하게 보인다면, 그것은 아마도 틀린 것일 가능성이 높습니다. 주니어 개발자에게 설명할 수 있을 때까지 다시 작성하세요. 만약 설명할 수 없다면, 배포해서는 안 됩니다.

3. AI가 아키텍처 결정을 내리도록 맡기는 경우

Vibe 코딩 도구들은 함수를 생성하는 데는 탁월합니다. 하지만 그 함수들이 어떻게 구성되어야 하는지 결정하는 데는 형편없습니다. LLM(대규모 언어 모델)에게 "확장 가능한 아키텍처(scalable architecture)"를 구축해 달라고 요청하면, 사방으로 화살표가 뻗어나가는 아름다운 다이어그램과 두 스프린트 만에 자체 무게로 무너져 내릴 코드베이스를 얻게 될 것입니다.

아키텍처 결정—의존성 방향(dependency direction), 모듈 경계(module boundaries), 데이터 흐름(data flow)—은 AI가 알지 못하는 맥락을 요구합니다. AI는 팀 규모, 릴리스 주기(release cadence), 또는 어떤 구성 요소가 가장 자주 변경되는지 알지 못합니다.

Pin Up Retro Manner의 개발자로서 저는 아키텍처 선택이 복리처럼 쌓인다는 것을 배웠습니다. 첫날의 잘못된 결정은 백일째에 고치려면 열 배 더 많은 비용이 듭니다. AI는 당신이 맡기면 기꺼이 그 잘못된 결정을 내릴 것입니다.

수정: 아키텍처를 직접 설계하세요. 이미 설정한 경계(boundaries) 내에서 구현 세부 사항을 채우는 데 AI를 사용하십시오. "어떻게 이 프로젝트를 구조화해야 할까요?"라고 절대 묻지 마세요. 대신, "이 구조가 주어졌을 때, 이 모듈을 구현해 주세요"라고 물으십시오.

4. "AI가 제대로 했으니까" 테스트를 건너뛰는 경우

LLM은 그럴듯하게 보이는 코드(plausible-looking code)를 생성합니다. '그럴듯하다'는 '정확하다'와 다릅니다. 저는 10개의 항목에 대해서는 작동하지만, 100개 이상에서는 모든 것을 뒤섞어 버리는 생성된 정렬 알고리즘을 본 적이 있습니다. 개발 환경(development)에서는 올바른 결과를 반환하지만 실제 데이터 볼륨에서 프로덕션 환경(production)에서 치명적으로 시간 초과되는 데이터베이스 쿼리도 본 적이 있습니다.

테스트가 없다면, 당신은 사용자들이 자신보다 먼저 버그를 발견해 줄 것이라고 베팅하는 것입니다.

수정: 코드를 신뢰하기 전에 테스트를 작성하세요. 나중에가 아닙니다. 만약 AI가 구현을 생성할 수 있다면, 테스트도 생성할 수 있습니다—하지만 당신은 둘 다 검증해야 합니다. AI가 작성했고 통과한 테스트는 아무것도 증명하지 못합니다. 그 테스트를 읽으세요. 코드를 의도적으로 깨뜨려보고 테스트가 이를 잡아내는지 확인하십시오.

5. 컨텍스트 창을 소진하다 (Burn Your Context Window)

모든 LLM은 컨텍스트 윈도우(context window)를 가지고 있습니다. 기능을 '느낌대로 코딩(vibe-code)'하면, 주고받는 수정 사항, 재시도, 그리고 '아니, 제가 의도한 건...' 같은 말에 토큰을 소진하게 됩니다. 중요한 부분에 도달했을 때쯤이면 AI는 프로젝트 구조, 명명 규칙(naming conventions), 그리고 20 메시지 전에 언급했던 그 핵심 제약 조건까지 잊어버립니다.

그 결과: 나머지 코드베이스와 일치하지 않는 코드가 나옵니다. 일관성 없는 패턴. 중복된 로직. 컨텍스트 망각으로 인해 도입된 버그들입니다.

해결책: 개별 기능에 대해서는 새로운 대화를 시작하세요. 각 세션 시작 시 붙여넣을 프로젝트 컨텍스트 문서를 유지하세요. 첫 메시지에서 구체적으로 작성하는 것이 중요합니다. 프롬프트가 더 집중적일수록, 낭비되는 컨텍스트가 적습니다.

6. 프롬프트 기록은 버전 관리하지 않는다

당신의 코드는 git에 있습니다. 당신의 프롬프트는요? 아마도 다시 찾아볼 일도 없는 채팅 기록 속에 묻혀 있을 겁니다. 6개월 후에 버그가 발생하여 특정 구현 결정이 왜 내려졌는지 이해해야 할 때, 그것을 생성했던 프롬프트는 사라져 있습니다.

해결책: 코드 변경 사항과 함께 프롬프트를 저장하세요. 커밋 메시지에 한 줄 주석을 달거나, 리포지토리 내에 prompts/ 디렉토리를 만드세요. 10초밖에 걸리지 않지만 나중에 수많은 포렌식 디버깅 시간을 절약해 줍니다.

핵심 요약

느낌대로 코딩(Vibe coding)은 도구일 뿐, 엔지니어링 판단을 대체할 수는 없습니다. 지루한 부분—보일러플레이트 코드, 테스트 스텁, 문서 초안 작성—을 가속화하는 데 사용하세요. 하지만 아키텍처, 보안, 그리고 정확성이 문제가 될 때는 '느낌'이 멈춥니다. 당신이 결정을 내려야 합니다.

AI와 함께 번성할 개발자들은 가장 빠르게 프롬프트를 입력하는 사람들이 아닙니다. 그들은 언제 AI의 출력을 신뢰하고, 언제 그것을 분해하여 처음부터 다시 시작해야 하는지 아는 사람들입니다.

본 기사는 AI 도구와 모바일 개발 교차점을 탐구하는 독립 안드로이드 개발자 Artem Garazha가 작성했습니다. Pin Up Retro Manner on YouTube에서 여정을 팔로우하세요.