[AI소설] 모두가 바이브코딩을 하는 회사

그냥 뭐 문득 회사에 개발자가 없고 모두가 바이브 코딩을 한다면 어떻게 될까? 한 번 상상의 나래를 펼치면서 ChatGPT로 써달라고 했어요. 어차피 저는 아이디어만 제공하고 나머지는 그냥 ChatGPT가 다썻죠. 어파치 너무 극단적인 애기이고 저의 일방적인 생각이니 너무 진지하게 볼 필요는 없습니다.

[소설]

A기업에는 개발자가 없었다. 사장부터 말단 직원까지, 전 직원이 바이브코딩을 이용해 각자의 업무용 애플리케이션을 만들어 사용하고 있었다. 입사 첫날 신입사원이 배우는 것은 업무 매뉴얼이 아니라 프롬프트 작성법이었다. 문제를 정확히 설명하고, 원하는 결과를 구체적으로 말하는 법. 그것이 이 회사에서 일하는 방식이었다.

그 결과 회사 안에는 수십 개의 앱이 존재했다. 인사팀은 출퇴근을 기록하는 앱과 인사평가를 관리하는 앱을 따로 사용했고, 재무팀은 급여 계산 앱과 세금 처리 앱을 운용했다. 영업팀은 고객 관리 시스템을 두 번 갈아엎었고, 마케팅팀은 캠페인 분석 툴을 분기마다 새로 만들었다. 각자의 문제는 각자가 해결하는 것이 자율이었고, 남의 시스템을 건드리지 않는 것이 예의였다.

어느 날 인사팀 김대리는 매달 반복되는 작업을 하다 문득 생각했다. 출퇴근을 기록하는 앱과 인사평가를 하는 앱이 왜 따로 존재해야 할까. 애초에 하나로 만들면 되지 않을까. 그러나 출퇴근 앱은 오차장이 만들었고, 인사평가 시스템은 김과장의 작품이었다. 두 사람의 프롬프트 방식은 달랐고, 데이터 구조도 달랐다. 수정하려면 원래의 AI 대화 맥락을 알아야 했지만, 그 대화 기록은 이미 다른 업데이트로 덮여 있었다.

김대리는 엑셀로 데이터를 정리할 생각을 하지 않았다. 그런 방식은 이 회사의 문화와 맞지 않았다. 대신 그는 새로운 앱을 하나 만들었다. 두 시스템의 데이터를 자동으로 변환해주는 중간 변환기였다. 이름은 <DataBridge_Final>이었다. 출퇴근 앱의 emp_no를 인사평가 시스템의 employeeId로 매핑하고, 날짜 형식을 통일해주는 간단한 로직이었다.

문제는 그 다음이었다. 오차장이 “더 효율적인 구조”를 원한다며 출퇴근 앱을 리팩토링했다. AI는 테이블 구조를 바꾸고, 컬럼 이름을 개선했으며, 일부 필드를 병합했다. DataBridge_Final은 즉시 오류를 냈다. 김대리는 다시 AI에게 요청했다. “새 구조에 맞게 수정해줘.” 그렇게 <DataBridge_Final_v2>가 만들어졌다.

재무팀 송사원은 급여 계산을 하다 또 다른 문제를 발견했다. 출퇴근 기록과 인사평가 점수를 합산하는 과정에서 일부 직원의 식별 값이 일치하지 않았다. 그는 고민하다가 새로운 앱을 만들었다. 두 시스템의 결과를 비교해 차이를 검증하는 앱이었다. 이름은 <PayrollValidator_BETA>. 이 앱은 세 개의 시스템에서 데이터를 읽어와 불일치를 표시했다.

그러나 곧 문제가 발생했다. 인사팀이 점수 계산 방식을 “조금 더 공정하게” 바꾸면서 로직이 수정되었다. PayrollValidator_BETA는 이전 기준을 기반으로 검증하고 있었기에 오히려 정상 데이터를 오류로 표시했다. 송사원은 또다시 AI에게 수정 요청을 했다. <PayrollValidator_v2_REAL>이 만들어졌다.

이 과정은 반복되었다. 통합을 위해 만든 앱 위에 검증용 앱이 쌓였고, 그 검증용 앱을 감시하는 로그 분석 앱이 만들어졌다. 로그를 분석하는 앱이 신뢰되지 않자, 로그 분석 결과를 교차 검증하는 또 다른 앱이 등장했다. 문제를 해결하는 대신, 문제를 덮는 자동화가 계속 생성되었다.

사장은 이 상황을 보고 전사 통합 프로젝트를 선언했다. “이제 하나로 합치자.” 모두가 동의했다. 그러나 통합 앱은 각 부서의 요구사항을 반영하는 과정에서 점점 비대해졌다. 인증 방식은 세 가지가 되었고, 데이터베이스는 네 종류가 혼합되었다. 누군가는 보안을 강화하겠다고 토큰 구조를 바꾸었고, 누군가는 성능 개선을 이유로 데이터 타입을 수정했다. 그때마다 관련 앱들이 연쇄적으로 업데이트되었다.

급여일에 사고가 터졌다. 일부 직원의 급여가 두 배로 입금되었고, 일부는 지급되지 않았다. PayrollValidator는 정상이라고 표시했고, DataBridge는 오류를 감지하지 못했다. 로그 분석 앱은 “의심되는 패턴 없음”이라고 보고했다. 그제야 모두가 깨달았다. 자동화는 늘어났지만, 전체를 이해하는 사람은 아무도 없다는 사실을.

회의실에서 사장은 책임자를 찾았다. 그러나 이 시스템은 특정인의 작품이 아니었다. 모두가 만들었고, 누구도 설계하지 않았다. AI가 코드를 생성했지만, 구조를 설계한 사람은 없었다.

그날 이후 회사는 이상한 균형 상태에 들어갔다. 각 부서는 기존 시스템을 믿지 못해 검증용 앱을 하나씩 더 만들었다. 결과를 서로 비교하고, 비교 결과를 다시 분석하는 앱이 추가되었다. 앱의 수는 늘어났지만, 신뢰는 줄어들었다. 생산성 향상이라는 보고서와 달리 실제 업무 시간은 점점 길어졌다.

1년 뒤, A기업에는 공식 통합 시스템과 그를 보조하는 수십 개의 보조 앱, 그리고 그 보조 앱을 검증하는 또 다른 앱들이 존재했다. 새로 입사한 신입사원이 물었다. 왜 전담 개발자를 채용하지 않느냐고.

인사팀은 잠시 망설이다 대답했다. 이 회사에서는 모두가 개발자라고.

그러나 그 말 속에는 더 이상 자부심이 담겨 있지 않았다. 자율은 있었지만 연결은 없었고, 자동화는 있었지만 구조는 없었다. 코드 생성은 쉬워졌지만 설계는 사라졌다.

[소설]