여기서 실제로 일어나고 있는 일

10년 전만 해도 코딩은 세미콜론(;)을 어디에 찍어야 하는지, 메모리가 어떻게 할당되는지를 아는 것이 핵심이었습니다. 하지만 이제 우리는 'vibecoding'이라는 시대에 진입하고 있습니다. 이것은 게으름을 피우는 문제가 아닙니다. 이는 코드 라인을 작성하는 것에서 의도(intent)를 관리하는 것으로 정신적 모델 자체가 변화하는 것입니다.

제가 LLM(대규모 언어 모델)을 무거운 작업을 위해 사용하기 시작했을 때, 저는 그것들을 빠르고 유능한 주니어 개발자처럼 대하려고 했습니다. 작고 개별적인 작업들만 부여했죠. 하지만 이것은 이 도구들을 사용하는 잘못된 방법입니다. 진정한 힘은 구문(syntax)에 대해 걱정하는 것을 멈추고 시스템 아키텍처와 구현의 '느낌'(vibe)에 대해 고민하기 시작할 때 나옵니다.

플로우 상태의 위험성

이 새로운 워크플로우에는 특정한 함정이 있습니다. 기능을 프롬프트로 요청하면, AI가 작동하는 코드 100줄을 생성하고 사용자가 '적용' 버튼을 누릅니다. 작동합니다. 마치 신이라도 된 기분이 들죠. 그리고 이것을 열 번 더 반복합니다.

갑자기, 작동하는 코드베이스를 갖게 되었지만, 사실 그것이 어떻게 작동하는지 사용자 자신은 알지 못하게 됩니다. 사용자는 애플리케이션의 정신적 지도를 확률 엔진에 아웃소싱한 것입니다. 바로 여기서 문제가 발생합니다. 수동으로 설계하지 않은 시스템에서 버그가 나타나면, 생성하는 데 3초밖에 걸리지 않은 코드를 디버깅하느라 3시간을 허비하게 됩니다.

통제력을 유지하는 방법

vibecoding을 하면서도 제정신을 유지하려면, 사용자의 역할을 작성자(writer)에서 편집자(editor)로 바꿔야 합니다.

첫째, 검토 없이 대량의 코드를 받아들이는 것을 멈추세요. 만약 AI가 200줄짜리 함수를 제공한다면, 그것을 작고 테스트 가능한 모듈들로 분해해 달라고 요청하세요. 이는 AI가 더 나은 디자인 패턴을 따르도록 강제하고, 사용자 자신이 논리적 오류를 발견하기 쉽게 만듭니다.

둘째, 타입(type)에 중점을 두세요. TypeScript나 Rust 같은 언어를 사용한다면, 타입 시스템을 적극적으로 활용해야 합니다. 타입은 AI가 환각(hallucinating)하는 것을 막아주는 가드레일입니다. 타입이 엄격할수록 AI는 더 정확해지도록 강제됩니다. 모든 것을 'any'로 남겨두면, 그것은 그저 추측하고 최상의 결과를 바라는 것과 같습니다.

세 번째로, 테스트를 먼저 작성하세요. 이것이 '바이브(vibe)'가 현실과 일치하는지 확인할 수 있는 유일한 방법입니다. 만약 테스트 스위트(suite of tests)가 있다면, 프롬프트에 대해 빠르게 반복할 수 있습니다. 테스트가 통과하면, AI가 루프를 어떻게 작성했는지와 관계없이 구현이 올바르다는 것을 의미합니다.

새로운 기술 세트

우리는 가장 가치 있는 기술이 특정 라이브러리의 API를 아는 것이 아니라, 복잡한 시스템을 명확하게 설명하는 방법을 아는 방향으로 나아가고 있습니다.

언어에서의 정밀함은 이제 구문(syntax)의 정밀함을 대체하고 있습니다. 들여쓰기(indentation)에 대해 걱정하기보다는 모호성(ambiguity)에 대해 걱정해야 합니다. AI에게