바이브코딩의 시대에 소프트웨어 엔지니어가 여전히 필요한 이유

* 아래의 글은 보안컨설턴트를 준비하는 대학생이 작성한 글로 주관적인 해석 및 부정확한 정보를 포함할 수 있습니다. 또한 이 글은 소프트웨어 공학 수업 시간의 강의를 바탕으로 재구성한 글임을 밝힙니다.

 

결론부터 적자면, 바이브코딩이 우세해 보이는 지금 상황에서도 컴퓨터공학 전공자로서 커리어를 쌓는 것은 분명 의미가 있다.

 

1. 요구사항 정의와 프로그램 구현은 한 번에 완성되지 않는다. 하지만 바이브코딩에서는 제대로 되지 않은 설계와 구현으로 이루어진 사이클이 무수히 반복되는 것을 발견할 수 있다. 따라서 비용적으로 곤란해질 수 있다.

 

2. John Ousterhout의 복잡성 정의에서 '스스로 쉽게 고칠 수 없는 시스템'은 복잡하다고 정의한다. 그런데 바이브 코딩을 들여다보면 소위 '인간 컴파일러'가 아닌 사람들이 코딩 에이전트가 순식간에 써내려간 코드를 부분부분 수정하는 등 직접 건드릴 수 없어서 곤란한 순간들이 많이 보인다. 복잡한 시스템은 일관성을 쉽게 잃고, 유지보수가 어려워지며 결국 논리적인 오류가 생길 것이다. 전에 정리했던 'KISS(Keep It Simple, Stupid) 원칙'도 같은 맥락에서 언급될 수 있다.

 

3. 바이브 코딩을 하다보면 분명 토큰을 전부 소진한 순간이 오게 될텐데, 바이브 코더는 에이전트가 없으면 한 줄도 써내려가기 어렵기 때문에 토큰에 의존한다고 볼 수 있다. 다시 말해 개발 흐름이 토큰에 달려있는 상황인건데, 이는 소프트웨어의 운명을 개발자 스스로 통제하지 못하는 상황을 야기한다.

 

4. 3번에 이어, 역량이 부족한 주니어 여러 명에게 토큰을 분산하는 것보다, 전체 맥락을 짚을 줄 아는 중견 개발자에게 토큰을 몰아주는 것이 훨씬 효율적이라는 것을 생각하면 여전히 바이브 코더보다 코딩과 시스템의 구조를 잘 설계할 줄 아는 능력이 중요함을 생각할 수 있다. (Harness 개념)

 

5. 코딩 자체가 바이브 코딩으로 쉬워진 것은 맞지만 히려 '품질 좋은 코드베이스'의 상대적 가치는 더 높아졌다. 정돈된 아키텍처가 돋보이는 것이다.

 

6. 아마존(Amazon)의 경우 AI 붐으로 인해 사내에 중복된 도구와 데이터가 넘쳐나고 있다고 한다. 비용적 측면이나, 구조적 안정성 측면 모두를 위협하고 있다. 일반 코더가 아닌 그들도 이런 문제를 일으키는데.. 코드 짜는 수준이 이들 이하인 바이브 코더가 만드는 시스템들은 어떤 문제를 일으킬까?

 

... 무엇보다 바이브 코딩은 공격 표면을 넓힌다.

 

대략 아래와 같은 이유들을 정리해볼 수 있다.

 

1) AI나 바이브 코딩으로 라이브러리를 가져다 쓰면, 내가 실제로 쓰는 기능은 뿐만 아니라 나머지 불필요한 코드도 함께 프로젝트에 포함된다. 공격자는 내가 쓰지도 않는 그 코드들에 숨겨진 취약점을 이용해 시스템에 침투할 수 있다.

2) 바이브 코딩을 무작정 돌리면 라이브러리가 또 다른 라이브러리를 불러오는 '의존성의 지옥'이 펼쳐진다. 관리되지 않는 외부 라이브러리가 많아질수록 보안적으로 신경써야할 것이 많아진다.

3) 코드를 직접 짜지 않고 AI가 추천한 라이브러리를 무비판적으로 수용하면, 검증이 부재해 해당 라이브러리에 백도어가 있는지 혹은 보안 업데이트가 중단되었는지 확인하기 어렵다.