바이브코딩 과잉설계 피하는 법 2026 — 내가 만든 시스템에 압도당했던 이유

개인 기록을 정리하려고 시스템을 만들기 시작했는데, 만들수록 좋아 보이는 기능이 계속 늘었습니다. 자동 정리, 문서 연결, 화면 재생성처럼 하나씩 붙일 때마다 잘 되고 있다는 느낌은 들지만, 정작 안에 채워야 할 내용은 거의 늘지 않았습니다. 어느 날 문서 하나를 고치려다 손을 놓게 됐습니다. 어디를 고쳐야 하는지 알 수 없었고, 잘못 건드리면 다른 곳이 깨질 것 같았기 때문입니다. 만든 사람이 자기 물건 앞에서 이런 상태가 되면, 규모와 상관없이 이미 실패한 시스템입니다.

첫째, 기능을 만드는 재미가 원래 목적을 덮었습니다. 원래 목표는 기록을 편하게 보는 것이었는데 어느새 시스템을 잘 만드는 것 자체가 목표로 바뀌어 있었습니다. 둘째, 설명할 수 없는 것이 쌓였습니다. AI가 만들어준 부분은 그때그때 잘 돌아갔지만, 몇 주 뒤에는 그 구조를 스스로 설명할 수 없는 상태가 됐습니다. 설명할 수 없는 것은 고칠 수도 없습니다. 셋째, 내용이 아니라 그릇만 계속 다듬고 있었습니다. 정작 안에 채울 자료는 거의 손대지 않은 채 틀만 반복해서 손질하고 있었습니다.

Anthropic이 공개한 에이전트 설계 가이드는 같은 문제를 정면으로 다룹니다. 이 문서는 LLM을 활용한 성공이 가장 정교한 시스템을 만드는 데 있지 않고 필요에 맞는 시스템을 만드는 데 있다고 설명하며, 복잡도는 그것이 결과를 뚜렷하게 개선할 때만 추가하라고 안내합니다. 돌이켜보면 이 순서를 거꾸로 밟고 있었습니다. 결과를 개선하는지 확인하지 않은 채 기능부터 늘렸기 때문입니다.

이 가이드는 시작점 자체를 낮추라고도 권합니다. 여러 단계를 거치는 복잡한 구조보다 검색과 예시를 활용한 단순한 형태로 먼저 시도해 보고, 그것으로 부족할 때만 단계를 하나씩 늘리라는 것입니다. 제가 만들던 개인 지식 관리 시스템도 이 순서를 거꾸로 밟았습니다. 가장 단순한 형태로 먼저 써 보지 않고 처음부터 여러 기능을 갖춘 구조를 설계하려 했기 때문에, 나중에 무엇부터 줄여야 할지조차 알기 어려웠습니다.

새 기능을 멈추고, 좋아 보이는 아이디어는 목록에만 적어두고 손대지 않았습니다. 그릇을 더 다듬는 대신 실제 자료부터 채우기 시작했더니, 필요하다고 생각했던 기능의 절반이 사실은 필요 없었습니다. 매일 쓰는 부분은 이미 검증된 일반 도구에 맡기고, 직접 만든 부분은 그 도구가 못 하는 것만 남기자 시스템 자체가 처음보다 훨씬 작아졌습니다. 마지막으로 이 시스템을 다른 작업 공간에서 완전히 분리했습니다. 섞여 있을 때는 어느 쪽을 손대야 할지 매번 헷갈렸기 때문입니다.

많이 만들었다는 기록은 쉽게 남지만, 만들다가 감당이 안 됐다는 기록은 잘 남지 않습니다. 그런데 실제로 더 자주 일어나는 쪽은 후자입니다. 이 경험에서 배운 것은 기능을 더 만들 수 있느냐가 아니라 몇 주 뒤의 내가 그것을 고칠 수 있느냐를 먼저 묻는 습관입니다. 이해할 수 없는 구조를 늘리는 것은 지금 당장은 진행이 되는 것처럼 보이지만, 결국 그 구조를 다시 이해하는 데 드는 시간으로 되돌아옵니다. 그래서 새 기능을 붙이기 전에 그 구조를 한 문장으로 설명할 수 있는지부터 확인하는 것이 가장 싼 예방입니다. 설명이 막히는 순간이 바로 멈춰야 할 신호입니다.

이미 만든 걸 전부 버려야 하나요?

버리지 않아도 됩니다. 지우는 대신 옮기고 줄이는 방법이 있습니다. 지금 안 쓰는 것은 보관해두고 실제로 쓰는 것만 남기면 되고, 나중에 필요해지면 그때 다시 꺼내 쓰면 됩니다.

어느 정도가 너무 커진 상태인가요?

기준 하나만 두면 됩니다. 그 구조를 한 문장으로 설명할 수 있는가입니다. 설명이 막히면 이미 커진 것이고, 그 시점부터는 기능을 더 늘리기 전에 정리부터 해야 합니다.

개발 경험이 없어서 이런 일이 생기는 건가요?

경험이 있으면 조금 늦게 오겠지만, 만든 것이 이해 범위를 넘어서는 일은 누구에게나 일어납니다. 차이는 그 시점에 멈출 수 있느냐이고, 멈춘 뒤에 곧바로 새 기능이 아니라 내용부터 채우는 쪽으로 방향을 트는지가 회복 속도를 가릅니다.

만드는 재미는 진짜지만, 몇 주 뒤에도 쓸 수 있어야 그때 비로소 만든 것이 됩니다. 복잡도는 결과를 뚜렷하게 개선할 때만 늘리고, 그렇지 않으면 단순한 상태를 유지하는 편이 안전합니다. 가장 단순한 형태로 먼저 써 보고 부족한 부분만 하나씩 늘려가는 순서를 지키면, 시스템에 압도당하는 상황 자체를 애초에 줄일 수 있습니다. 자세한 원칙은 아래 공식 문서에서 확인할 수 있습니다.

• Anthropic — Building effective agents (https://www.anthropic.com/engineering/building-effective-agents, 확인일 2026-09-18)