메뉴
HN
Hacker News • 3일 전

비개발자에게 소프트웨어 개발이 여전히 어려운 이유를 설명하는 법

IMP
6/10
핵심 요약

노코드 AI 도구인 Lovable로 해커톤에서 1일차에 90%를 완성했지만, 2일차에 끝없는 버그로 제대로 된 데모조차 위태로워진 경험을 소개한다. 저자는 '집 짓기' 비유를 통해 소프트웨어의 근본 원인 수정과 인프라 작업이 왜 필요한지 비개발자에게 설명하는 방법을 제시한다. AI 코딩 시대에도 소프트웨어 엔지니어링의 본질적 어려움은 그대로 남아 있다는 점이 핵심이다.

번역된 본문

해커톤 마지막 날 오후 1시, 남은 시간은 5시간이다. 지난 2시간 동안 우리는 아무런 진전을 만들지 못했다. 나는 Lovable이 태어난 날을 저주하고 있다. 문제 하나를 고치면 또 다른 문제가 나타나고, 우리 앱은 겨우 쓸 만한 수준이다. 시작은 아주 유망했다. 나는 엔지니어 친구 2명과 리크루터 3명과 함께 'HoneyCrew'라는 스마트 추천 시스템(매주 모든 직원에게 자신의 인맥 중 채용 중인 포지션에 적합한 후보자를 정리해 보내주는 시스템이 목표였다. 오픈소스 버전은 여기 있다)을 만들기로 했다. 리크루팅 팀이 나중에 직접 유지보수할 수 있도록 Lovable을 사용하기로 했다. 첫날 우리는 그야말로 날아다녔다. 프로젝트의 90%를 완성했다. 스크래핑, 스코어링, Slack 연동, 관리자 기능까지 거의 다 준비된 것처럼 보였다. 둘째 날(마지막 날)에는 사소한 개선을 하던 중 모든 것이 완전히 망가졌다. 끝없는 버그, 느려짐, 모두가 극도로 스트레스받았다. 팀의 리크루터들은 무엇이 잘못됐는지 이해할 수 없었다. 멋진 제품을 향해 가고 있었는데, 이제는 데모할 것조차 없을 위기에 처한 것이다. 어째서일까?

'인프라 작업' 알레르기 예전에 함께 일했던 임원 한 명은 '리팩터링'과 '인프라 작업'이라는 단어에 알레르기가 있다고 말하기 좋아했다. 그는 왜 처음부터 제대로 만들 수 없는지, 왜 항상 그렇게 느린지 이해하지 못했다. LLM이 등장한 후에는 상황이 더 악화됐다. 그는 끊임없이 물었다. "그냥 이 작업을 ChatGPT에 맡기면 안 되나? 뭐가 문제야?" 공정하게 말하자면, 그나마 우리 얼굴을 보고 말한 편이었다. 엔지니어들이 항상 과장하고 너무 느리게 일한다고 생각하는 비기술적 리더들이 많이 있다는 것을 안다. 지난주에 이야기했던 오래된 소프트웨어 엔지니어링 전쟁의 또 다른 형태다. 동료(그리고 좋은 친구) 한 명은 이렇게 표현했다. "당신들은 코드를 쓰잖아. 그건 내가 이해하지 못하는 언어로 된 단어들일 뿐이잖아. 의미는 정해져 있고, 따라야 할 스펙도 있어서 뭘 말해야 할지 알잖아. 그런데 왜 항상 더 복잡해지는 거야?"

흠. 나는 이걸 설명하는 데 애를 먹다가, 집을 거의 사게 되면서 깨달았다.

소프트웨어가 집이라고 상상해보라 지난 10월, 처가 부근에 매물로 나온 집을 봤다. 좋은 위치, 좋은 이웃, 원하던 정원, 그리고 아주 저렴한 가격으로 훌륭한 조건처럼 보였다. 작고 30년 된 집이었지만 낮은 가격 덕분에 개조할 여유 예산이 남았다. 그래서 시공사에게 물었다. "리모델링하고 방 2개를 추가로 짓는 데 비용이 얼마나 드나요?" 그의 대답에 나는 웃음을 참을 수 없었다. "추천하지 않겠습니다. 너무 오래됐어요. 헐고 새로 짓는 게 훨씬 간단하고 저렴할 겁니다." 그는 훌륭한 소프트웨어 엔지니어가 될 수 있었을 것이다… 우리는 그 집을 포기했지만, 그 이후로 소프트웨어 이야기를 할 때 '집 비유'를 자주 사용한다. 집 짓는 과정은 수천 년 동안 알려져 왔지만, 여전히 모든 새 집은 저마다 다른 문제를 갖는다. 그리고 모두가 집에서 살기 때문에 공감하기 쉽다. 예를 들어:

왜 문제를 빨리 고칠 수 없나? 왜 항상 일이 커지나? 지붕이 샌다. 바닥에 양동이를 놓을 수도 있고, 근본 원인을 찾을 수도 있다. 자신의 집이라면 어떻게 하겠는가? 맞다, 양동이는 며칠은 괜찮을 수 있다. 하지만 계속 비워야 하고, 진짜 문제가 악화될 위험이 있다.

왜 그 특정 사용 사례만 해결하면 안 되나? 그 '인프라'는 다 뭔가? 가족을 위한 새 집을 짓는다고 하자. 1층만 지을 예산이 있지만, 가족이 크고 몇 년 안에 2층을 원할 것을 안다. 2층을 지탱할 기반 구조를 지금 넣어두는 것이, 실제로 2층이 필요해졌을 때 넣는 것보다 훨씬 저렴하다.

결코 끝나지 않는 집 그래서 해커톤 마지막 날 오후 1시, 모든 것이 망가진 것처럼 느껴진다. 다른 선택지는 없었다. 우리는 바이브 코딩에 빠져있던 광란을 멈추고, 데모가 가능한 간단한 흐름이 동작할 때까지 한 영역씩 차근차근 점검했다. 이해하고, 계획하고, 구현하는 것이다. 첫날의 속도보다 훨씬 느렸지만, 적어도 데모 가능한 작동하는 흐름을 만들어낼 수는 있었다.

원문 보기
원문 보기 (영어)
It’s 1 pm on the final day of the Hackathon, 5 hours left. For the last 2 hours, we made ZERO progress. I’m cursing the day Lovable was born. As soon as I fix one problem, another one appears, and our app is barely usable. The start was very promising. I joined 2 engineering friends and 3 recruiters to build ‘HoneyCrew’, a smart referral system (the goal was to send a weekly summary to every employee with potential candidates from their network for our open roles. Here’s an open source version ). We decided to go with Lovable so the recruiting team can maintain it themselves later. On the first day, we just FLEW, completing 90% of the project. Scraping, scoring, Slack integration, admin - things looked almost ready. On the 2nd (and final) day, we worked on some minor improvements, and things just… Completely broke. Endless bugs everywhere, slowness, everyone super stressed. The recruiters on our team couldn’t understand what went wrong. We were on the path for an amazing product, and now we were in danger of not having anything ready for the demo. How come? An allergy to ‘infra work’ I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?” To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly. It’s a flavor of the same old software engineering war I talked about last week. A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?” Huh. I’ve been struggling to explain this, until I almost bought a house: Imagine if your software was a house Last October, we saw a house for sale near my parents-in-law. It looked like a great deal - good location, nice neighbors, a garden like we wanted, and very affordable. It was small and 30 years old, but the low price left us extra to spend on it. So we asked a contractor: “How much would it cost to renovate it and expand by 2 additional rooms?” I couldn’t stop laughing at his response: “I wouldn’t recommend it. It’s too old. It’d be much simpler and cheaper to destroy it and build from scratch”. He could have been a great software engineer… We passed on it, but since then I’ve been using the house analogy quite a lot when talking about software. The house-building process has been known for thousands of years, and still every new one has different problems. And everyone lives in one, so it feels relatable. For example: Why can’t you just fix the issue fast? Why does it always get bigger? Your roof leaks. You can either put a bucket on the floor, or find the root cause. If it’s your own home, what would you do? Yeah, a bucket might be ok for a couple of days, but you need to constantly empty it, and you risk the real issue becoming worse. Why can’t you just solve this specific use case, without all that “infra”? Let’s say you build a new house for your family. You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years. Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor. The house you never finish So it’s 1 pm on the final hackathon day, and everything feels broken. We didn’t really have any other choice. We stopped our vibe coding frenzy and carefully went over one area at a time until we had a simple demo-able flow working. Understand, plan, implement. Much slower than our day-1 pace, but we at least ended up with a working demo-able flow. This process is how good software is built, but it gets so easily forgotten, just rushing forward. And unlike a house, you never really finish building it, so you constantly need to update the facilities while people already live inside. My favorite reads of the week Stop being the code review bottleneck . A very interesting and practical take on handling code review fatigue differently (hint: not doing them faster, and not delegating everything to agents). What being "inspiring" actually means . You are not Viggo Mortensen rallying men to fight Sauron. You are an Engineering Manager in tech. Here's what it means to inspire in this context. How tech workers are feeling in 2026: a workforce splitting in two . A very interesting survey in Lenny’s newsletter. Takeaway #9 is especially relevant for us: Workers with an extremely effective manager report roughly 65% higher job enjoyment and dramatically lower burnout than those with an ineffective one. Yet only 25.5% of tech workers rate their manager as highly effective , while 36.5% rate theirs as ineffective Know a manager who’d get something out of this? Share Get the next one in your inbox One email a week for engineering managers. No spam, unsubscribe anytime. Email address Subscribe Recommended for you The "Negative split" software engineering effect Software engineering calories: what would cal.ai say about your product? Stop forcing AI tools on your engineers