블로그로 돌아가기

바이브코딩 시대에 오히려 기능을 줄여야 하는 이유 3가지

AI에게 코드를 맡기는 바이브코딩으로 만드는 일은 빨라졌지만, 만든 뒤에 남는 운영 부담은 그대로입니다. 문서함과 알림 센터 사례를 따라가며 기능을 덜어내야 하는 이유를 세 가지로 정리했습니다.

에그코드
2026년 9월 23일
9 min read
#바이브코딩#AI에이전트#AI코딩#기술부채#클로드#인공지능#스타트업#코딩#SaaS#개발자#앱개발#유지보수#웹개발#서비스기획#에그코드
바이브코딩으로 기능은 빠르게 늘어나지만 운영 비용은 매년 남는다는 구조를 요약한 표지
만드는 일은 1회, 남는 일은 매년

올해 무엇을 만들었느냐고 물으면 목록이 길게 나옵니다.

그런데 무엇을 없앴느냐고 물으면 대답이 잘 나오지 않습니다.

소비자용 금융 앱을 만들어 온 프로덕트 디렉터 리암 뉴젠트가 최근 글에서 던진 질문입니다.

그는 이 일을 하면서 끝까지 막아낸 기능이 두 가지 있다고 밝혔습니다.

하나는 문서함이었고, 다른 하나는 알림 센터였습니다.

에그코드는 자체 서비스를 운영하면서 웹과 앱 외주 개발도 맡고 있습니다.

그래서 기능 추가 요청을 양쪽에서 받습니다.

AI에게 코드를 맡기는 바이브코딩이 퍼진 뒤로 그 요청은 눈에 띄게 늘었습니다.

다만 쉬워진 영역은 만드는 일에 한정되어 있습니다.

그래서 기능을 덜어내야 하는 이유를 세 가지로 정리했습니다.


1. "파일 목록 하나"는 결국 구글 드라이브가 됩니다

문서함은 아주 단순한 요청에서 출발합니다.

고객에게 보낸 안내문과 명세서를 앱에서도 보게 해 달라는 요청입니다.

단순한 파일 목록 요청이 태그·보관·인쇄·공유·권한 기능으로 늘어나는 과정
STEP 1에서 시작해 플랫폼으로 끝나는 흐름

문제는 회의에 들어온 사람마다 한 가지씩 덧붙인다는 데 있습니다.

태그와 보관함이 붙고, 인쇄와 공유와 권한 처리가 차례로 따라옵니다.

권한 처리란 각 문서를 볼 자격이 있는 사람에게만 보이도록 막는 작업을 말합니다.

이쯤 되면 구글 드라이브를 처음부터 다시 만드는 일과 크게 다르지 않습니다.

알림 센터도 같은 길을 걷습니다.

종 모양 아이콘에 빨간 점 하나만 찍어 달라는 요청에서 시작합니다.

몇 달 뒤에는 메일함을 닮은 화면을 만들고 있습니다.

에그코드도 외주 문의에서 이 두 기능을 자주 만납니다.

단순해 보이는 기능일수록 요청이 더 잘 달라붙습니다.


2. 견적서에 적히지 않는 비용이 매년 발생합니다

기능의 가격은 대부분 구축비로만 제시됩니다.

실제로 돈이 나가는 자리는 그다음입니다.

구축비 1회와 3년간 반복되는 운영·점검 비용을 비교한 도표
0년차는 한 번, 1~3년차는 매년 반복

iOS와 안드로이드는 해마다 새 버전을 내놓습니다.

기존 동작이 바뀌거나 사라지면 그 기능은 다시 손봐야 합니다.

3년이면 이 점검이 최소 세 번 돌아옵니다.

이렇게 쌓여서 나중에 갚아야 하는 부담을 기술부채라고 부릅니다.

뉴젠트는 이해관계자를 설득한 방법으로 운영비를 펼쳐 보이는 방식을 꼽았습니다.

만드는 값이 아니라 몇 년에 걸친 유지보수 비용을 계산해서 보여 주는 것입니다.

구분구축비운영비
발생 주기1회매년 반복
견적서 표기명시됨대부분 빠짐
대표 작업기획·개발·테스트OS 대응·보안 점검·장애 대응
기능이 늘면한 번 더 지출매년 점검 대상이 늘어남

구축 견적보다 3년치 운영비가 결정을 바꿉니다.


3. 바이브코딩이 싸게 만들어 준 것은 만드는 일뿐입니다

바이브코딩은 초안을 뽑는 속도를 확실히 끌어올렸습니다.

DHH는 모든 아이디어를 곧바로 실행해 볼 수 있게 된 지금을 반겼습니다.

이 이야기는 더 많이 만들라는 말로 읽히기 쉽습니다.

AI 에이전트를 기능 생산에 쓰는 경우와 정리·유지보수에 쓰는 경우의 차이 비교
같은 도구를 어디에 붙이느냐의 차이

뉴젠트는 여기에 다른 쓰임을 제안합니다.

AI 에이전트를 새 기능이 아니라 정리 작업에 붙이는 편이 낫다는 관점입니다.

쓰이지 않는 화면을 찾아내고 낡은 코드를 걷어내는 일이 여기에 해당합니다.

만드는 속도가 아니라 정리하는 속도가 서비스의 수명을 정합니다.


결론: 추가는 까다롭게, 제거는 단호하게

모든 기능을 빼라는 뜻은 아닙니다.

문서를 보여 줄 의무와 알림을 남길 의무는 그대로 남습니다.

다만 그 의무를 플랫폼 하나로 해결해야 하는지는 다시 살펴야 합니다.

기능 추가 전에 확인할 네 가지 질문을 정리한 체크리스트
화면부터 그리기 전에 확인할 네 가지

무엇을 언제 전달해야 하는지부터 정리하고, 이미 있는 수단으로 가능한지 확인합니다.

이메일과 문자, 푸시 알림만으로 충분한 경우가 생각보다 많습니다.

바이브코딩이 벌어 준 시간을 기능을 늘리는 데만 쓸 이유는 없습니다.

뉴젠트의 결론은 분명합니다.

무엇을 넣을지는 극도로 까다롭게 고르고, 빼는 일에는 단호해야 합니다.

에그코드도 기능 하나를 추가할 때마다 이 질문을 먼저 던집니다.

참고 자료: Liam Nugent, "The most important product decision is what you don't build"

함께 읽어보세요 — MVP 뜻부터 제작까지, 개발비 아끼는 현실적인 순서 · 외주개발 유지보수에서 반드시 확인할 3가지 · 바이브코딩 현실과 AI 코딩의 3가지 함정 · 에그코드 MVP 개발 서비스

문의하기

MVP 개발, 어디서부터 시작해야 할지 모르겠다면?

무료 MVP 견적 받기
카카오톡 문의