바이브코딩에 대한 생각
오랜만에 글 쓰려고 하니까 어렵네요.
개요
바이브코딩
여러분들은 AI로 개발할 때 가장 중요하다고 보는 게 무엇인가요?
- 모델의 성능?
- 정교한 프롬프트?
- 컨텍스트 엔지니어링?
- 최신 기술이 포함된 하네스?
- 더 효과적인 LLM 평가 방법?
- 워크스페이스 및 세션 분리?
- AI 혹은 인간 개발자에 대한 자율성?
모두 중요한 것들이지만, 제 경험 상 단 하나의 가치에 의해 충분히 조율될 수 있는 것들이라고 생각되는 항목들입니다.
재현가능성
저희가 어떤 경험을 한 사람을 만나거나, 조언을 듣거나, 채용을 한다는 건, 그 사람이 과거에 경험한 것을 바탕으로 나 혹은 조직에게 충분한 도움을 줄 수 있을 거라 믿기 때문입니다. 그리고 이건 재현가능성, 즉 과거의 것을 반추하고 반복하는 것을 기대하고 있죠. 내 앞에서 과거에 해당 문제를 해결한 경험과 솔루션을 재현해줄 거라는 믿음입니다. 그것도 반성을 포함해서요.
저희가 경력직 개발자를 채용하는 이유고, 시니어 개발자에게 배우는 부분이기도 하죠. 단순히 코드를 작성함에 그치는 게 아니라, 어떻게 문제를 바라보고, 어떤식으로 문제를 정의하고, 어떤 디자인 패턴과 같은 철학을 도입해서, 어떻게 정의된 문제를 풀어내는지에 대한 전반적인 행동양식과 사고방식 또한 포함합니다.
그리고 AI의 도입으로 개발자들은 일종의 시즌 리셋을 맞이했습니다. 모두가 지금 당장 알고 있는 전문화된 지식은, 각 도메인별 특수한 경우를 제외하면 상당 부분 장벽이 허물어졌습니다. 이제 요청 몇 자와 엔터 한 번이면 많은 지식을 얻을 수 있게 되었습니다. 그렇다면 앞으로 개발자의 가치를 가르는 것은, 그 지식을 어떻게 활용하는가, 어떤 솔루션을 만들어보았는가, 그리고 다음에도 그것을 재현할 수 있는가의 문제가 될 것입니다.
본론
맹목적 바이브코딩
적지 않은 사람들이 바이브코딩을 극단적으로 하나의 요청 당 하나의 솔루션 쯤으로 받아들이는 것같습니다. 그 안에서 어떤 원리로 어떠한 로직이 작성되었거나 기술이 사용되었는지에 대해선 관심없이 그저 일단 결과가 나온 것에 의미를 두는 것입니다.
이에 대해선 물론 최근 LLM은 블랙박스라던가, 언론이 가끔 이유는 모르겠지만 더 효율적인 구조나 혁신적인 발견이라면서 전문가들이 AI를 극찬한 듯이 보도하면서 생긴 인지 차이도 분명 한몫했을 것입니다. 일론 머스크 조차 기계 지능이 가장 똑똑한 인간 한명의 지능을 능가할 때가 올 것이라 했으며, 이는 마치 우리에게 지능을 확보할 이유를 없애는 것처럼 보이기도 합니다.
실제로 LLM 자체는 여전히 많은 부분이 블랙박스고, 인간이 이해하기 어려운 방식으로 최적화나 발견을 해내는 것도 사실입니다. 하지만 저희가 평소 작성하는 애플리케이션 코드까지 그런 방식으로 취급해야 한다고 느껴지진 않습니다. 우리가 AI에게 맡기는 것은 보통 미지의 과학적 발견이 아니라, 요구사항을 코드로 옮기고, 버그를 줄이고, 구조를 정리하고, 기존 시스템 안에 변경을 통합하는 일입니다. 이 과정은 여전히 설명 가능해야 하고, 검증 가능해야 하며, 다시 시도했을 때 비슷한 경로로 도달할 수 있어야 합니다.
혹여 새로운 솔루션을 개발할 수도 있을 것입니다. 시장에 존재하지 않는 새로운 걸 개발해야할 수 있고, 이를 위해 LLM을 연구 목적으로 쓸 수도 있을 것입니다. 안드레 카파시의 LLM 카운슬이나 오토 리서치 등이 그 예입니다. 그리고 그 결과를 이용해서 성공적으로 솔루션 개발을 완료할 수도 있을 것입니다.
위 예시가 잘못되었다는 것은 아닙니다. 충분히 영리하고 빠른 선택이고, 산업적으로 올바른 접근이라 생각합니다.
재현가능한 바이브코딩
하지만 제가 중요하게 보는 지점은 그 다음입니다. 그렇게 만들어낸 결과가 한 번의 성공으로 끝나는지, 아니면 다음 문제를 풀기 위한 경험으로 남는지입니다. 결과물이 동작했다는 사실만 남고, 어떤 맥락에서 어떤 판단을 했는지 사라진다면, 우리는 같은 종류의 문제를 다시 만났을 때 다시 처음부터 운에 기대게 됩니다. 조금 과격하게 말하면, 우리는 다시 한 번 LLM의 주사위 놀이에 기대야 한다는 것입니다.
물론 시대에 따라 정답이 되는 논리와 근거는 달라지고, 이는 개발도 마찬가지입니다. 해시만 하더라도 과거엔 md5면 충분했다면, 지금은 sha256, blake2b는 되어야 안전하죠. 그걸 넘어 요구 사항에 따라 sha3, blake3를 바라기도 합니다.
그래서 무작정 그때 LLM이 연구 결과로 어떤 걸 선택했는지 외우라는 것이 아닙니다. 어떤 이유로 어떤 환경에서 이런 선택을 했는지 이해하는 것이 중요합니다. 암호화에 대해 이야기 해볼까요? 하드웨어 지원이 받쳐주거나, 표준을 선택했다는 사실이 유의미하게 무게감이 있는 곳이라면 AES-256 GCM이 자연스러운 선택지가 될 수 있습니다. 다만, 임베디드 장치나 불특정 다수의 웹, 구형 모바일 기기가 전체 고객의 다수라면 ChaCha20Poly1305가 더 나은 선택지가 될 수도 있습니다.
이러한 선택에 대해 연구 결과를 이해하고, 비슷한 솔루션을 개발할 때 이용할 수 있어야 합니다. 구조를 잡는 방식도 마찬가지입니다. AI가 어떤 계층을 나누고, 어떤 책임을 어디에 두고, 어떤 추상화를 만들었는지 이해하지 못하면 그 코드는 당장은 동작해도 다음 변경에서 쉽게 무너집니다.
물론 기술 선택에 대한 이야기만이 아닙니다. 요구사항을 쪼개는 방식, 테스트를 설계하는 방식, 장애를 추적하는 방식, 코드의 책임을 나누는 방식도 모두 재현가능성의 대상입니다. 결국 재현가능한 것은 결과물이 아니라, 결과에 도달하는 과정이어야 합니다.
개인 브랜딩 측면의 작업 방식
결국 이 과정의 확립은 제가 이전부터 얘기한 개인의 브랜딩과 방향성이 유사합니다. AI는 연구도 잘하고, 코딩도 잘 합니다. 다만, 어떤 식으로 프로젝트를 구성하고, 테스트를 구성할 것인지는 다른 이야기입니다. 각 모델은 각각 자기가 주로 학습한 내용으로 테스트를 구성하거나, 아예 말하기 전까지 작성하지 않기도 합니다.
그렇기에 인간 개발자가 필요합니다. AI는 인지된 범위와 학습된 범위 내에서 이상적으로 하려고 합니다. 이게 인간과의 차이입니다. 인지 범위 측면에서 인간 개발자는 AI가 대화 안에서 직접 보지 못하는 맥락을 알고 있습니다. 조직의 사정, 제품의 방향, 사용자의 습관, 코드베이스의 역사, 앞으로 감당해야 할 유지보수 비용 같은 것들입니다.
학습 범위에서는 AI보다 값싼 비용으로 새로운 정보를 받아들일 수 있습니다. 아니, 학습할 필요도 없습니다. 어떤 것이 새로 나왔고, 그걸 어떻게 적용할 수 있을지 같은 정보를 AI에게 제공할 수 있으면 됩니다.
이게 결과적으로 하네스와 에이전트의 설계와 구성에까지 영향을 주게 됩니다.
- 최소한의 지식과 지능을 가진 모델을 이용해서
- 최대한 잘 수행할 수 있도록 정교하게 작성된 프롬프트로
- 컨텍스트가 너무 장황해지지 않게 관리하며
- 하네스를 구성해서
- 효과적으로 평가하고 반복하는
에이전트를 구성하면 되니까요. 혹은 그 과정을 인간 개발자가 통제해가며 작업을 해도 좋습니다. 오히려 저는 후자를 더 선호하기도 합니다.
결론
결국 제가 생각하는 좋은 AI 개발자는 AI 없이도 모든 것을 할 수 있는 사람이 아닙니다. AI가 만든 결과를 자신의 맥락 안으로 가져오고, 그 과정을 다음에도 다시 사용할 수 있게 만드는 사람입니다. 그것이 인간에게 더 많은 자율성을 주든, AI에게 더 많은 자율성을 주든, 마이크로매니징을 하든 말이죠.
마지막으로 이런 질문은 어떤가요?
여러분들은 지금 하고 있거나, 이미 했던 프로젝트를 다른 모델이나 하네스로 충분히 다시 할 수 있나요? GPT나 Claude가 아니라 Gemini나 Grok으로도 충분히 가능한가요? Codex나 Claude Code, PI가 아니라 Antigravity나 Grok Build, Cursor로도 충분히 가능한가요?