𝗩𝗶𝗯𝗲 𝗖𝗼𝗱𝗶𝗻𝗴 𝗜𝘀𝗻'𝘁 𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺. 𝗡𝗼𝘁 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗧𝗵𝗲 𝗦𝘁𝗮𝗰𝗸 𝗜𝘀.
한 AI 도구가 저에게 다음과 같은 설정 파일을 건네준 적이 있습니다:
DATABASE_URL = "postgresql://admin:SuperSecret123@db.internal:5432/app"
API_KEY = "sk-live-4f9a..."
작동은 합니다. 바로 그게 함정입니다. 데모는 돌아가고 검토자는 고개를 끄덕입니다. 하지만 그 비밀 정보는 이제 영원히 git 히스토리에 남게 됩니다. 저장소에 들어오는 사람이라면 누구나 이를 볼 수 있습니다.
저는 개발자가 아닙니다. 시스템 엔지니어링 분야에서 20년을 보냈습니다. 저는 애플리케이션이 실행되는 토대를 만듭니다. 호스트, 네트워크, 그리고 데이터베이스를 구축합니다.
제가 AI 도구를 사용할 때 다른 사람들처럼 실패하지 않는 이유는 다음과 같습니다.
안드레 카파시(Andrej Karpathy)는 일회성 프로젝트를 위한 "바이브 코딩(vibe coding)"에 대해 언급했습니다. 어떤 이들은 이를 너무 멀리까지 가져갔습니다. 그들은 코드를 보는 것을 멈췄습니다. 이제는 시스템을 보는 것조차 멈췄습니다. 코드는 무시할 수 있어도, 시스템은 무시할 수 없습니다. 실제로 실행되는 것은 바로 시스템이기 때문입니다.
저는 AI의 제안을 무시할 때가 많은데, 모델에 운영적 맥락(operational context)이 부족하기 때문입니다:
- Operating Systems: AI는 보안 앱에 Windows를 제안할 수도 있습니다. 이는 라이선스 비용을 간과한 것입니다. 무료 Ubuntu 서버가 더 저렴하게 동일한 작업을 수행할 수 있습니다.
- Databases: AI는 MySQL을 선택할 수도 있습니다. 하지만 1년 뒤 새벽 2시에 제가 어떤 엔진을 관리할 수 있을지는 알지 못합니다.
- Security: AI는 "로그인이 된다"는 수준에서 멈춥니다. 진정한 보안에는 조건부 액세스(conditional access)와 신뢰할 수 있는 장치가 필요합니다. 이는 단순히 '느낌(vibes)'만으로는 찾아낼 수 없습니다.
- Networking: AI는 종종 인터넷 전체에 포트를 개방하라고 제안합니다. 저는 특정 관리 네트워크로 액세스를 제한합니다.
AI는 네트워크를 다른 사람의 문제로 취급합니다. 하지만 그렇지 않습니다.
하드코딩된 비밀 정보를 해결하는 방법은 간단합니다. 환경 변수를 사용하세요:
import os
DATABASE_URL = os.environ["DATABASE_URL"]
사용자가 막지 않으면 모델은 파일 안에 비밀 정보를 직접 포함시켜 버릴 것입니다.
바이브 코더들이 실패하는 이유는 애플리케이션 코드가 시스템의 전부라고 생각하기 때문입니다. 그렇지 않습니다. 애플리케이션은 건물의 한 층에 불과합니다. 기초를 제대로 다지지 않았다면 건물은 무너질 것입니다.
저는 AI를 사용할 때 "X를 만들어줘"라고 시작하지 않습니다. 그런 방식은 운영 환경(production)에서 깨져버리는 데모를 만들 뿐입니다. 저는 먼저 제약 조건과 트레이드오프(tradeoffs)에 대해 30분 동안 대화하며 논의합니다. 그리고 그 논리에 기반하여 모델이 사양서(spec)를 작성하게 합니다. 이렇게 하면 나중에 몇 시간씩 걸리는 정리 작업을 방지할 수 있습니다.
문제는 도구가 아닙니다. 무엇을 건드리는지 확인하지 않은 채 변경을 가하는 것이 문제입니다. 기반을 이해하고 있다면, 바이브를 따라가는 것도 안전할 것입니다.
실력의 차이는 코드를 얼마나 많이 작성하느냐가 아닙니다. 자신의 코드가 기반하고 있는 것을 이해하고 있느냐의 문제입니다.
모델이 매번 틀려서 당신이 계속해서 직접 수정(override)해야 하는 부분은 무엇인가요?
출처: https://dev.to/kkierii/vibe-coding-isnt-the-problem-not-understanding-the-stack-is-4kif
참여 가능한 학습 커뮤니티: https://t.me/GyaanSetuAi