비즈니스 담당자에게 소프트웨어 개발이 여전히 어려운 이유를 설명하는 법 — Lovable 해커톤 참전기와 '집 짓기' 비유

본문

엔지니어링 매니저 대상 뉴스레터 manager.dev에 실린 글로, 저자는 해커톤 마지막 날 오후 1시, 데모까지 5시간이 남은 상황에서 2시간째 진전이 전혀 없다는 고백으로 이야기를 시작합니다. 'Lovable이 태어난 날을 저주한다'는 문장이 이 글의 원제입니다.

첫날 90% 완성, 둘째 날 붕괴

저자는 엔지니어 2명, 리크루터 3명과 팀을 이뤄 'HoneyCrew'라는 스마트 레퍼럴 시스템을 만들었습니다. 직원들의 네트워크에서 공석에 맞는 잠재 후보자를 찾아 매주 요약을 보내주는 도구로, 오픈소스 버전도 공개되어 있습니다. 리크루팅 팀이 나중에 직접 유지보수할 수 있도록 바이브 코딩 플랫폼 Lovable을 선택했습니다. 첫날에는 스크래핑, 스코어링, Slack 연동, 관리자 기능까지 '날아다니는' 속도로 90%를 완성했습니다. 그런데 둘째 날 사소한 개선 작업을 하던 중 모든 것이 무너졌습니다. 끝없이 나타나는 버그, 느려지는 속도, 극도의 스트레스 속에 팀의 리크루터들은 무엇이 잘못됐는지 이해하지 못했습니다.

'인프라 작업' 알레르기

저자는 과거 함께 일한 시니어 리더가 '리팩터'와 '인프라 작업'이라는 단어에 알레르기가 있다고 말하던 일화를 소개합니다. 그 리더는 왜 처음부터 제대로 만들지 못하고 왜 항상 느린지 이해하지 못했고, LLM 등장 이후에는 '이 일을 그냥 ChatGPT에 시키면 안 되나? 뭐가 문제인가?'라고 물었다고 합니다. 한 동료는 이렇게 표현했습니다. '코드는 내가 모르는 언어로 된 단어들이고 고정된 의미가 있으며, 따라야 할 스펙도 있는데, 왜 항상 더 복잡해지는가?' 저자는 이 질문에 답하기 어려워하다가 집을 살 뻔한 경험에서 비유를 얻었습니다.

소프트웨어가 집이라면

장모님 근처에 30년 된 작은 집이 저렴하게 나왔을 때, 시공사에 '2개 방을 증축하는 리노베이션 비용'을 물었더니 '너무 낡아서 부수고 새로 짓는 게 훨씬 간단하고 저렴하다'는 답이 돌아왔다고 합니다. 집 짓기는 수천 년 된 프로세스지만 매번 새로운 문제가 생기고, 모두가 집에 살기 때문에 공감하기 쉽다는 점에서 좋은 비유라고 설명합니다. 대표적인 예시 두 가지를 듭니다. 첫째, '왜 이슈를 빨리 고치지 못하고 항상 커지는가'에는 지붕 누수로 답합니다. 바닥에 양동이를 놓는 임시방편과 근본 원인을 찾는 것 사이의 선택인데, 양동이는 며칠은 버티지만 계속 비워야 하고 진짜 문제가 악화될 위험이 있습니다. 둘째, '그냥 이 유스케이스만 인프라 없이 해결하면 안 되나'에는 2층 증축으로 답합니다. 예산상 1층만 지을 수 있어도 몇 년 뒤 2층을 원할 큰 가족이라면, 2층을 지탱할 인프라를 지금 넣는 것이 나중에 추가하는 것보다 훨씬 저렴합니다.

끝나지 않는 집

해커톤 마지막 날, 팀은 선택지가 없었습니다. 바이브 코딩 광풍을 멈추고 한 영역씩 차근차근 '이해, 계획, 구현' 순서로 작업해 데모 가능한 플로우를 완성했습니다. 첫날 속도보다 훨씬 느렸지만 이것이야말로 좋은 소프트웨어가 만들어지는 방식이며, 앞만 보고 달리다 보면 쉽게 잊힌다고 지적합니다. 집과 달리 소프트웨어는 결코 완성되지 않기 때문에, 이미 사람이 살고 있는 동안 설비를 계속 업데이트해야 한다는 것이 결론입니다. 글 말미에는 이번 주 추천 글과 함께 Lenny's Newsletter 설문이 인용됩니다. 매우 효과적인 매니저와 일하는 직원은 직무 만족도가 약 65% 높고 번아웃이 현저히 낮지만, 자신의 매니저를 매우 효과적이라 평가한 테크 노동자는 25.5%에 불과하고 36.5%는 비효과적이라 답했습니다.

Reddit 반응

• @phaedra_solutions — 집 비유가 정말 와닿습니다. LLM이 몇 시간 만에 프론트엔드나 기본 CRUD 앱을 만들 수 있다면 '어려운 엔지니어링'은 기본적으로 해결됐다는 큰 오해가 있습니다. 코드 작성은 애초에 병목이 아니었습니다. 그 밑에 있는 모든 것, 즉 상태 관리, 기술 부채, 인프라, 실제 사용자가 몰렸을 때의 스케일링 등이 문제입니다. 그리고 비기술 사람들에게 그 차이를 이해시키는 것 자체가 큰 도전입니다.
• @Nutrimiky — 저도 집 비유를 자주 씁니다. 사실 우리 직업 용어 자체가 아키텍처부터 파이프라인, 데코레이팅까지 집 관련 용어 투성이니까요. 다만 현대의 상호 연결된 시스템에는 '집'보다 '마을을 짓는다'는 표현이 더 적합하다고 생각합니다.
• @web-dev-kev — 글은 잘 쓰였지만 저는 다른 관점입니다. 소프트웨어가 어려운 이유를 설명할 때 진짜 어려운 점은 소프트웨어가 하드웨어와 정반대라는 것입니다. 소프트웨어는 절대 완성되지 않고, 유연하고 변경 가능하며, 진화하는 요구사항을 상대로 짓기 때문에 여전히 어렵습니다. 애자일이나 스크럼 관점이 아니라, 유지보수, 새 브라우저 지원, 새로운 인터랙션 유형 대응이 필요하다는 뜻입니다. 우리는 이를 완화하기 위해 프레임워크와 방법론을 계속 만들어내고 있지만요.
• @learning-to-programm — 좋은 글이고 집 비유도 마음에 듭니다. 다만 제 경험상 Lovable은 '바이브 코딩' 플랫폼 중에서도 최악 수준입니다. 이런 노코드 계열 플랫폼들은 다 그랬습니다. Claude Code나 다른 실제 에이전트/하니스를 썼다면 결과가 매우 달랐을 겁니다. 에이전트는 실제 코드를 만들고, 실제 스펙을 구현하고, 테스트를 작성하고, E2E로 검증하고, 스크린샷으로 페이지가 괜찮은지 확인할 수 있습니다. git도 있고요.
• @SwiftySanders — 비즈니스 사람들은 자신들이 하는 금융 조작 외의 모든 일을 그다지 가치 있게 여기지 않습니다. 금융화가 아닌 것은 생각하고 고려할 가치가 없다고 보는 거죠.

원문: Manager.dev / 번역·요약: Trawling