# 좋은 소프트웨어는 멈출 때를 안다 > Clean Markdown view of GeekNews topic #27256. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27256](https://news.hada.io/topic?id=27256) - GeekNews Markdown: [https://news.hada.io/topic/27256.md](https://news.hada.io/topic/27256.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-06T17:33:09+09:00 - Updated: 2026-03-06T17:33:09+09:00 - Original source: [ogirardot.writizzy.com](https://ogirardot.writizzy.com/p/good-software-knows-when-to-stop) - Points: 12 - Comments: 1 ## Summary 좋은 소프트웨어는 자신이 해결해야 할 문제의 **경계와 목적**을 명확히 인식합니다. 모든 기능을 담으려는 욕망 대신, **불필요한 확장을 멈추고 핵심에 집중**할 때 비로소 안정성과 지속성을 얻습니다. 37Signals가 강조한 것처럼 제약은 약점이 아니라 **결정의 기준**이 되며, 새로운 유행보다 **명확한 문제 정의**가 더 큰 가치를 만듭니다. ## Topic Body - **소프트웨어의 본질적 역할**은 자신이 해결해야 할 문제를 명확히 알고, 그 한계를 인식하는 데 있음 - **좋은 소프트웨어는 모든 기능을 담으려 하지 않고**, 개선이 필요한 부분만 다루며, 목적을 벗어나지 않음 - `ls` 명령어가 AI 기능으로 대체되는 가상의 사례를 제시go, **기존 도구가 불필요하게 확장되는 현상**을 풍자 - 37Signals의 **‘Getting Real’** 과 **‘Rework’** 에서 제시된 원칙을 인용해, 제약을 장점으로 삼고 불필요한 기능 요청을 거부해야 함을 강조 - AI 열풍 속에서도 **기존 표준의 안정성과 명확한 문제 정의**가 새로운 유행보다 더 큰 가치를 지닌다는 점을 상기시킴 --- ### 소프트웨어의 역할과 한계 - 글은 리눅스 배포판을 업데이트한 후 `ls` 명령어가 **AI 기반 디렉터리 인텔리전스**로 바뀌는 상상의 장면으로 시작 - 새로운 `als` 명령어는 사용자의 의도를 예측하고 파일을 순위화하며, 기존 `ls`는 30일 후 지원이 중단된다는 메시지를 표시 - 이 장면은 **기능 과잉과 불필요한 혁신**을 풍자하는 예 - “다행히 이런 일은 실제로 일어나지 않는다”며, **좋은 소프트웨어는 자신이 언제 멈춰야 하는지 안다**고 강조 ### 좋은 소프트웨어의 핵심 원칙 - 좋은 소프트웨어는 자신이 **어떤 목적을 수행하는지** 알고, 모든 것을 하려 하지 않으며, 언제 멈출지와 무엇을 개선할지를 구분 - 인간의 **‘최대주의적 사고방식’** 은 모든 것을 더 크게, 더 복잡하게 만들려는 경향이 있음 - 그러나 소프트웨어는 자신이 속한 **역할과 위치를 명확히 정의**해야 하며, 새로운 아이디어가 기존 비전과 맞지 않는다면 **별도의 프로젝트로 분리**해야 함 ### 37Signals의 제품 철학 - Basecamp 창립자들이 쓴 **‘Rework’** 과 **‘Getting Real’** 은, 제품 설계에 중요한 교훈을 제공함 - **제약은 장점(Constraints are advantages)**: 작은 팀, 제한된 예산, 제한된 범위가 더 나은 의사결정을 유도 - **기능 요청 무시(Ignore feature requests)**: 사용자가 요청한 기능을 그대로 구현하기보다 **근본 문제를 이해하는 접근** 필요 - **빠른 출시와 반복(Ship early, ship often)**: 완벽하지만 출시되지 않은 제품보다 **불완전하지만 실제로 작동하는 제품**이 더 가치 - **핵심 중심 설계(Epicenter design)**: 네비게이션이나 주변 요소보다 **핵심 인터페이스와 상호작용부터 설계** - **기본적으로 ‘아니오’라고 말하기(Say no by default)**: 새로운 기능은 **복잡성, 유지보수 비용, 예외 처리 증가**라는 숨은 비용 존재 - **자신이 필요로 하는 것을 만들기(Scratch your own itch)**: **자신이 실제로 필요한 문제를 해결하는 제품**이 더 나은 의사결정 가능 ### 변화보다 지속의 가치 - 최근 여러 제품이 **AI를 중심으로 이름과 기능을 재구성하는 흐름**이 있음 - MinIO → **AIStor** - Oracle Database → **Oracle AI Database** - 모든 것이 극적으로 변할 필요는 없음 - 특정 문제 영역에서 **사실상 표준(de facto standard)** 으로 자리잡는 것이 **더 큰 가치**를 지님 ## Comments ### Comment 52522 - Author: neo - Created: 2026-03-06T17:33:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47261561) - “기능 요청을 무시하라”는 조언을 보며 **Blizzard와 World of Warcraft Classic** 사례가 떠올랐음 수년간 유저들이 클래식 버전을 요청했지만, 블리자드는 “그건 원하지 않을 거야”라며 거절했음 결국 클래식 WoW를 출시했고 **압도적인 성공**을 거둠 나중에 개발진이 “유저들이 정말로 자신이 원하는 걸 알고 있었다”고 인정했음 즉, 항상 기능 요청을 무시하기보다는, 때로는 유저가 정확히 옳을 수도 있음을 인정해야 함 - 유저 요청이 처음엔 말이 안 된다고 느껴져도, **정중한 유저**라면 왜 안 되는지 설명하다가 스스로 더 나은 해결책을 떠올리게 되는 경우가 있음 반대로 **무례하거나 자기중심적인 유저**는 대화 자체가 피곤해져서 대응하지 않게 됨 결국 교훈은, 요청할 땐 예의 있게 해야 한다는 것임 - “유저 요청을 무시하라”는 말은 겉보기엔 좋아 보이지만, 실제로는 “유저가 무엇을 말하고 있는지 이해하라”가 더 정확함 그 후에 그게 유효한 요청인지 판단하고, 구현 방법을 고민해야 함 - Blizzard 사례를 보면, 유저들이 단순히 “클래식 버전”을 원한 게 아니라 **현대 WoW의 복잡한 시스템**에 대한 반감이었음 근본적인 문제는 ‘원래의 감각을 잃은 게임’이었고, 이를 이해했다면 클래식이 아닌 다른 방식으로도 해결할 수 있었음 - 사실 유저도, 개발자나 PM도 **진짜로 원하는 것**을 명확히 모를 때가 많음 WoW 클래식은 ‘옛 감성’을 되찾고 싶다는 **얕은 욕구**의 표현이었지만, 그 밑에는 ‘신뢰할 수 없는 개발 방향’에 대한 불신이 있었음 이상적인 세상이라면 두 버전의 장점을 섞은 완벽한 형태가 가능하겠지만, 현실에서는 의견 충돌로 혼란만 커질 것임 - 반대 사례로는 **Ultima Online**이 있음 유저 요청에 따라 비(非)PVP 인스턴스를 추가했더니, 긴장감이 사라져 게임이 밋밋해졌음 이 경우엔 개발자가 유저보다 더 잘 알고 있었던 셈임 - **기능 추가를 멈춘 완성된 소프트웨어**가 더 많아져야 한다고 생각함 “이 정도면 충분하다”라고 말할 수 있는 용기가 필요함 Evernote나 Dropbox처럼 완벽했던 시절 이후 **기능 과잉**으로 혼란스러워진 사례가 많음 - 사실 예전엔 대부분의 소프트웨어가 그런 식으로 출시됐음 박스에 담겨 팔리고, 새 버전이 나오면 새 박스를 사는 구조였음 지금처럼 끊임없이 업데이트되는 웹앱 이전의 시대였음 - 대부분의 소프트웨어는 **완성되었다는 사실을 인정하지 않음** 오히려 업데이트할수록 나빠지는 경우가 많음 진짜로 개선되는 제품은 손에 꼽을 정도임 - [관련 댓글](https://news.ycombinator.com/item?id=47272024)을 읽고 나서야 왜 이런 현상이 생기는지 이해했음 - Dropbox는 원래의 단순한 목적을 잃고, 다시 복잡한 **네트워크 파일시스템**으로 돌아가 버림 결국 원래 해결하려던 문제를 다시 만들어버림 - 예전에 **Task Eater**라는 단순한 iOS 할 일 앱이 있었는데, 개발자가 “이제 완성됐다”고 선언하고 업데이트를 멈췄음 하지만 시간이 지나며 iOS 버전 호환이 안 돼 결국 사용할 수 없게 됨 완성의 아름다움과 기술 진화의 잔혹함을 동시에 느꼈음 - 2020년에 인프라 담당에서 **Java 개발자**로 전향했을 때, 주요 라이브러리들이 유지보수 모드라 “Java가 죽은 건가?”라고 생각했음 하지만 나중에 보니 그건 **기능 완성 상태**였음 수많은 엣지 케이스가 해결된 안정적인 상태였던 것임 문제는 사람들이 그런 안정성을 원하지 않고, 늘 새로운 걸 원한다는 점임 결국 같은 프레임워크를 언어만 바꿔가며 반복 제작함 - 많은 사람들이 유지보수 중인 라이브러리를 쓰면 **버그가 고쳐지지 않을까 두려워함** 그래서 계속 개발 중인 프로젝트를 선호함 또 어떤 기업은 **컴플라이언스 요건** 때문에 업데이트가 계속되는 소프트웨어만 쓸 수 있음 - 예전에 Java의 memcached 라이브러리가 유지보수 중이라 Redis로 갈아탔던 적이 있음 “그냥 완성된 거라 더 개선할 게 없다”고 농담했지만, 결국 바꿨음 - **Sublime Text**를 좋아하는 이유는 단순함과 속도 때문임 AI나 복잡한 기능을 넣지 않고, **한 가지 목적**에 집중함 - 그래서 나는 여전히 **vim**을 씀 - 좋은 소프트웨어가 꼭 돈을 버는 소프트웨어는 아님 하지만 돈을 벌려면 사람들이 실제로 쓰는 기능이 필요함 유저마다 **20%의 다른 기능**을 쓰기 때문에, 다양성을 고려해야 함 - **Notepad.exe**는 완성된 소프트웨어의 대표 사례라고 생각했는데, Windows 11에서 파일 연결을 바꾸려면 **해킹 수준의 조작**이 필요해서 놀랐음 - 하지만 어떤 사람은 Notepad를 **나쁜 예시**로 봄 [Windows Insider 블로그](https://blogs.windows.com/windows-insider/2026/01/21/notepad-and-paint-updates-begin-rolling-out-to-windows-insiders/)와 [보안 공지](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841)를 보면, 멈출 줄 모르는 업데이트가 문제라고 함 - **완성된 소프트웨어의 아름다움**을 인정하지만, 요즘은 대부분 “**영원한 베타**” 상태임 인터넷 연결이 전제되면서 “언제든 업데이트 가능”하다는 구조가 생겼고, 버그 수정과 원치 않는 기능 추가가 분리되지 않음 YouTube 같은 웹서비스는 버전 선택조차 불가능함 - 나는 Evernote에서 **Obsidian**으로 옮겼지만, Obsidian도 점점 기능이 과해지고 있음 특히 **Canvas 기능**이 추가되면서 본래의 단순한 철학이 흔들렸음 오픈소스였다면 그 시점에서 포크했을지도 모름 - **Signal**은 무료, 오픈소스, 프라이버시 중심이라 기능이 적음 하지만 그게 오히려 마음에 듦 - 그래도 **예약 전송 기능** 하나만큼은 WhatsApp보다 훨씬 유용함 WhatsApp은 쓸데없는 기능만 늘리고 있음 - 37signals의 책에서 말한 **‘항상 필요한 것(evergreen)’**, 특히 **속도**의 중요성을 예전엔 몰랐음 하지만 시간이 지나며 앱들이 점점 느려지는 걸 보니, 빠른 소프트웨어의 가치가 얼마나 큰지 깨달았음 - Neal Stephenson의 『REAMDE』에 나오는 “**작가들은 거주지를 좋아한다**”는 문장이 떠오름 작가들이 계속 일거리를 만들어 거주지를 유지하듯, 개발자도 **일거리를 만들기 위해 코드를 바꾸는 경향**이 있음 - “코드베이스를 X 아키텍처나 Y 언어로 전면 재작성해야 한다”는 말을 수없이 들었음 결국 우리도 **변화를 위한 변화**를 반복하고 있음