바이브 코딩 회고
TL;DR
나는 바이브 코딩이 개발자를 근시일내에 대체할 것이라는 말엔 동감하지 않음
현재의 AI Tool 은 단순히 개인 역량을 더 증폭시켜주는 도구라고 생각함
AI 코딩 에이전트의 성능을 작업 시간으로 재는 것이 유효한가?
LLM 은 일종의 OS 의 철학적 역할과 비슷하게 구현 상세를 추상화시키는 도구가 될것이라고 생각
들어가며
요새 vibe coding 이라는 말이 되게 평범해졌고, 이제 누구나 노력한다면 간단한 프로토타입은 AI 로 개발할 수 있는 시대가 도래했다. 이런 기술력은 표면적으로는 AI 로 사람을 근시일내에 쉽게 대체할수 있어 보이지만 나는 사실 이러한 AI 신봉자들에 의견에는 크게 동의하지 않는다. 그래서 이런 부분때문에 뭐 공부를 하지 않아야된다 라고 조언하는 사람들 또한 좋아하지 않는다. 이 이야기를 하기 위해서는 내가 AI 를 사용했던 경험들에 대해 이야기 해야 한다.
2022년 인가 2023년 쯤 인가 언젠지는 잘 기억안나지만 Github Copilot 이 나오고 그때 신청해서 엄청나게 썼던 기억이 난다. 개인적으로 계속 쓰다가, 회사 코드에서도 사용을 권장해서 신청하여 회사코드에서도 적용할 방법들을 계속해서 고민했었다. 그래서 배민 내부에서도 Github Copilot 을 잘 쓰는 방법에 대해 3번 정도 사내에서 작거나 크게 공유하는 자리를 가졌었다.
그 당시 코파일럿을 보면서 느꼈던 점은 참 구조화된 일은 잘한다는 것이였다. 예를 들면, given-when-then 으로 테스트 코드를 구조화 시켰을때 Copilot 이 새롭게 테스트 코드를 작성해도 이 given-when-then 을 맞춰서 잘 작성해준다는 것이였다. 즉, 파일 내에서의 일정한 패턴을 인식하고, 이 패턴에 맞게 코드를 작성해주는 것처럼 보였다.
그래서 이 당시에는 코파일럿에게 위와 같이 패턴이 파일내에서 한눈에 보이는 작업들을 많이 시켰다. 이러한 작업은 내가 작성하나 코파일럿이 작성하나 실상 큰 차이가 나지 않았기 때문이다. 이때도 일부 내가 패턴이 보이되 쉽게 반복해서 해야 하는 작업들은 코파일럿에게 넘기는 방법을 많이 연구했었다.
Agent 시대의 도래
그러다가 LLM 기술이 발전하고 컨텍스트 사이즈가 늘어나고 점차 Agent 향으로 발달하면서 확연하게 code assistance 들의 성능이 좋아진게 느껴졌다. 특히 Antropic 의 Claude Code 가 나오고 바로 써봤을때 정말 놀라운 수준의 지능을 가졌다고 느껴지기도 했다.
이정도면 사람들이 많이 쓰겠지? 라는 생각을 가지고 주변 개발자들과 만나는 시간을 가질때 이야기를 자주 했었지만 쓰는 사람이 생각보다 많지 않았다. (쓰는 사람이 나밖에 없을때가 더 많았던거 같다)
그 당시 집에서 혼자 웹 Trading 게임을 바이브코딩만으로 완성시켜보겠다고 클로드 코드랑 놀았던 기억이 있다. 여하튼, 이 당시 사용하지 않는 개발자들과 많이 이야기 해보며 느꼈던 점은 보통 아래와 같았다.
AI 기술에 대해 너무 큰 기대를 가지고 있음.
Copilot 시절의
auto-completion기능때문에 Context 를 헤쳤던 안좋은 기억이 많음그냥 필요가 있다고 느껴지지 않아 안써봄.
AI 로 근시일내 사람이 대체 불가하다고 믿는 이유
AI 기술에 대해 너무 큰 기대를 가지고 있는 그룹에 대해 이야기해보자. 이 경우는 프롬프트를 입력하면 Coding agent 가 뚝딱하고 완벽한 결과를 내놓기를 원한다. 하지만 그건 거의 불가능하다. 이건 나는 지금도 불가능하다고 생각하는데 이 이유는 아래와 같다.
예를 들어, 10억에서 100억건 사이의 문서를 크롤링 해야한다고 해보자. 이걸 AI Agent 에게 시킬때 단순히 아래와 같이 프롬프팅 했다고 해보자.
"내가 특정 페이지들에서 문서를 하루동안 크롤링 할건데, 최대한 이 시간동안에는 중복처리가 안되게 해줘."
그렇다면 중복처리는 어떻게 해야할까? AI agent 가 UUID 를 Unique 키로 이용해 Redis 를 통해 분산 시스템에서도 보장되는 중복처리를 하겠다고 플랜을 작성했다.
{"uuid" : "1"}
위와 같이 하면 충분히 중복처리가 가능할거 같고, 사용자 또한 크게 생각하지 않고 accept 를 누른다. 몇 번의 바이브 코드로 수정하고 동작하자 운영에 배포한다. 운영에 나가면 어떻게 될까? 높은 확률로 Redis 가 정상적으로 동작하지 않게 된다. 일단 저 구조로 10억개가 올라가면 어림잡아 계산 때려도 메모리가 몇십에서 몇백GB 이상이 필요하게 된다. 점점 쌓이다가 결국 죽고 말것이다.
여기서 문제가 이제 발생한다. Vibe coding 으로 저 코드를 accept 한 유저가 이 문제를 발견할 수 있을까? 내 생각에는 높은 확률로 발견하지 못한다. 왜냐면 이걸 accept 한 사람의 코드를 작성하는 판단에는 Memory 에 대한 경험 또는 학습이 부족하기 때문이다.
그리고 어찌어찌 알아내서 개선을 한다해도 이 이후에 개선은 Chat-GPT 또는 또다른 LLM 에 맞겨 진행한다. 이게 정말 Production 에 배포되도 되는 코드인가? 상황에 따라 다르겠지만 대부분의 상황에서 개인적으로는 아니라고 생각한다.
이 이야기를 들으면 반대로 모든 걸 다 디테일하게 챙겨주면 가능하지 않냐는 말을 하는 사람도 있다. 나도 이 부분에는 동의한다. 다만 여기서의 모순은 이 모든걸 다 챙길 사람이라는 리소스가 필요하다는 것이다. 즉, 이 말이 능력이 좋은 한 사람이 여러 Agent 를 활용해 생산성을 높일 수는 있지만, 그 사람을 대체하는 것은 아직은 불가능하다는 뜻이기도 하다.
그러므로 나는 현재의 AI 도구들은 증폭기라고 생각한다. 즉, 결국 LLM 이라는 것도 내가 입력한 토큰 기반으로 답변을 생성해내는 것이기 때문에, Garbage-in Garbage-out 이라는 말과 같이 쓰레기를 넣으면 쓰레기가 나올수 밖에 없다.
AI Agent 를 활용하는 방법
위와 같이 AI Agent 는 LLM 모델의 성능 그리고 내가 입력한 토큰들에 의해 결과가 좌지우지된다. 즉, 비결정적이다. 그래서 AI 와 TDD 를 함께 섞어 테스트로 결정적인 함수[^1]를 만들어서 이 비결정적인 Output 을 테스트하여 최대한 비결정성을 줄이려는 시도들을 하는 것 같다.
이러한 구조적인 방향성에는 크게 동의하며 나 또한 AI 에게 TDD 는 아니지만 Test 는 대부분 수행시키며, 코드 규칙을 따르게 하기 위한 lint 도 시킨다. 어떠한 더 좋은 방향성이 나올지는 모르지만, 사람의 개입으로 비결정적인 방향을 결정성을 지닌 함수에 넣어 빠르게 피드백을 받고 고치게 하는 이러한 방향으로 구조화 되어야 한다고 본다.
구조화 하는 방향과 함께 나의 작업 방향성과 AI 의 방향성이 틀어질 확률 또한 낮춰야 한다고 생각한다. 나 또한 최대한 Planning 과정에서 AI Agent 와 이야기를 많이 하여 대부분의 Planning 과정에서 구현 방향 또한 공유하고, 그걸 토대로 구현을 AI 에게 맡긴다.
이러한 방향에서 계속해서 인간이 개입해야 한다고 보며 개인의 능력에 따라서 AI 가 동일한 토큰을 입력했을때 원하는 답변을 얻을 확률을 줄이는 것이 개인의 역량이라고 본다.
OS 의 철학적 역할을 하게될 AI
위와 같이 AI 가 기초적인 구현을 잘 하게 되다보면 OS 의 철학적 역할과 비슷해질것이라고 본다. 우리는 하드웨어가 어떻게 동작하는지 기초적인 구현체는 잘 모르지만, 아래단계에서 추상화를 통해 구현의 복잡함을 숨겨주기 때문에 우리가 프로그래밍을 할때는 논리에만 집중하여 프로그래밍을 할 수 있게 된다.
나는 AI 들이 발전하면 점차 구체적인 구현작업들은 AI 들이 대부분 해주고, 사람은 오히려 더 추상적인 일들을 많이 하게 될것이라고 믿고 있다. 다만 현재에도 하드웨어를 만들고 더 효율 좋은 좋은 아키텍쳐로 발전하려고 힘쓰는 사람들이 있듯이 이 시간대에도 더 효율성이 좋은 미래의 보편적인 추상화 아래의 부분에서 힘쓰는 사람들이 있을거라고 생각한다.
코딩에이전트를 시간으로 효율을 측정하는게 정말 유효한가?
이렇게 하다보면 특정 작업에서는 내가 코드를 작성할때보다 AI 가 작성할때 시간이 더 걸리는 경우가 있다. 그래서 가끔 AI 코딩 에이전트의 시간 효율성이 인간 작업자에 비해 별로다 라고 이야기하는 리포트들이 나오는데, 나는 시간으로 측정하는게 맞나 싶다.
애초에 이 일을 맡겨 놓으면 나는 이 일에 뇌를 소비하지 않고, 또 다른 작업을 플래닝하는데 뇌를 쓸수 있는 가용시간이 생기는 것이기 때문에, 하나의 Task 를 같이 했을때 시간으로 측정하는건 크게 의미가 없다고 본다. 오히려 AI 도구를 쓰는 사람들이 위와 같이 작업을 하려는 노력을 해야한다고 본다.
마치며
나는 AI 가 앞으로 세상을 많이 바꿀거라고 생각한다. 지금은 극 초기라고 생각하고 앞으로 더 빠르게 바뀔것 같다. 이러한 시기에 내가 장점이라고 생각하는 부분은 기존에는 좋은 기관에 가야만 배울수 있던 부분들을 AI 를 통해 학습하고 실제로 구현해서 실험까지 해보는 것들이다.
실제로 AI 와 대화하면서 많이 생각하고, 실제로 몰랐던 부분들을 직접 구현해보고 테스트해보면서 다른 문제들을 해결할 방법들에 대한 실마리를 얻곤 한다. 평상시 잘 몰랐던 부분들을 AI 와 함께 학습하면서 최근에 실력이 더 빠르게 늘고 있다고 생각한다.
다만, 이러한 과정속에서도 대부분의 구현을 AI 에 맡기기 보다 자신이 원하는 케이스를 반환하도록 AI 를 함수처럼 이용해보거나 반대로 AI 에게 추상적인 부분을 맡기고 자신이 최대한 구현해 보며 구현력을 높이는 방향도 좋다.
아니라면 알고리즘을 풀어보는 연습을 하는 것도 좋다. 알고리즘 문제 풀이가 자신의 논리를 코드로 정확하게 옮기는 힘을 기른다고 생각하기에 이런 부분에서 큰 도움이 된다고 생각한다. 여하튼 AI 세상이 와도 뭐 노동은 가치가 없어진다는 등 나는 이러한 시대가 온다고 말하기에는 현재의 기술수준은 그정도는 아니라고 생각한다. 각자 자기가 할수있는 방향에서 AI 를 쓸수 있다면 써보도 개인의 능력을 키우는데 많이 써보는게 좋다고 생각한다.
그리고 과도한 AI hype 은 경계해야 한다. 그렇게 실제로 일자리를 없앨 기술이라면 이미 개발자는 아예 없어졌어야 한다. 재미있던 부분을 빠르게 공부해보고 잘 가르쳐주는 똑똑한 친구를 얻었다고 생각하면 좋을 것 같다.
[^1]: 테스트는 입력과 기대 출력이 고정되어 있으므로 결정적(deterministic)인 함수처럼 다룬다. 즉, F(Input) = Output 형태로 동일한 입력에 대해 동일한 출력이 나오는지를 검증하는 과정이다.
