▲

좋은 소프트웨어는 멈출 때를 안다

 (ogirardot.writizzy.com)
7P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 소프트웨어의 본질적 역할은 자신이 해결해야 할 문제를 명확히 알고, 그 한계를 인식하는 데 있음
  • 좋은 소프트웨어는 모든 기능을 담으려 하지 않고, 개선이 필요한 부분만 다루며, 목적을 벗어나지 않음
  • 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) 으로 자리잡는 것이 더 큰 가치를 지님
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • “기능 요청을 무시하라”는 조언을 보며 Blizzard와 World of Warcraft Classic 사례가 떠올랐음
    수년간 유저들이 클래식 버전을 요청했지만, 블리자드는 “그건 원하지 않을 거야”라며 거절했음
    결국 클래식 WoW를 출시했고 압도적인 성공을 거둠
    나중에 개발진이 “유저들이 정말로 자신이 원하는 걸 알고 있었다”고 인정했음
    즉, 항상 기능 요청을 무시하기보다는, 때로는 유저가 정확히 옳을 수도 있음을 인정해야 함

    • 유저 요청이 처음엔 말이 안 된다고 느껴져도, 정중한 유저라면 왜 안 되는지 설명하다가 스스로 더 나은 해결책을 떠올리게 되는 경우가 있음
      반대로 무례하거나 자기중심적인 유저는 대화 자체가 피곤해져서 대응하지 않게 됨
      결국 교훈은, 요청할 땐 예의 있게 해야 한다는 것임
    • “유저 요청을 무시하라”는 말은 겉보기엔 좋아 보이지만, 실제로는 “유저가 무엇을 말하고 있는지 이해하라”가 더 정확함
      그 후에 그게 유효한 요청인지 판단하고, 구현 방법을 고민해야 함
    • Blizzard 사례를 보면, 유저들이 단순히 “클래식 버전”을 원한 게 아니라 현대 WoW의 복잡한 시스템에 대한 반감이었음
      근본적인 문제는 ‘원래의 감각을 잃은 게임’이었고, 이를 이해했다면 클래식이 아닌 다른 방식으로도 해결할 수 있었음
    • 사실 유저도, 개발자나 PM도 진짜로 원하는 것을 명확히 모를 때가 많음
      WoW 클래식은 ‘옛 감성’을 되찾고 싶다는 얕은 욕구의 표현이었지만, 그 밑에는 ‘신뢰할 수 없는 개발 방향’에 대한 불신이 있었음
      이상적인 세상이라면 두 버전의 장점을 섞은 완벽한 형태가 가능하겠지만, 현실에서는 의견 충돌로 혼란만 커질 것임
    • 반대 사례로는 Ultima Online이 있음
      유저 요청에 따라 비(非)PVP 인스턴스를 추가했더니, 긴장감이 사라져 게임이 밋밋해졌음
      이 경우엔 개발자가 유저보다 더 잘 알고 있었던 셈임

  • 기능 추가를 멈춘 완성된 소프트웨어가 더 많아져야 한다고 생각함
    “이 정도면 충분하다”라고 말할 수 있는 용기가 필요함
    Evernote나 Dropbox처럼 완벽했던 시절 이후 기능 과잉으로 혼란스러워진 사례가 많음

    • 사실 예전엔 대부분의 소프트웨어가 그런 식으로 출시됐음
      박스에 담겨 팔리고, 새 버전이 나오면 새 박스를 사는 구조였음
      지금처럼 끊임없이 업데이트되는 웹앱 이전의 시대였음
    • 대부분의 소프트웨어는 완성되었다는 사실을 인정하지 않음
      오히려 업데이트할수록 나빠지는 경우가 많음
      진짜로 개선되는 제품은 손에 꼽을 정도임
    • 관련 댓글을 읽고 나서야 왜 이런 현상이 생기는지 이해했음
    • Dropbox는 원래의 단순한 목적을 잃고, 다시 복잡한 네트워크 파일시스템으로 돌아가 버림
      결국 원래 해결하려던 문제를 다시 만들어버림
    • 예전에 Task Eater라는 단순한 iOS 할 일 앱이 있었는데, 개발자가 “이제 완성됐다”고 선언하고 업데이트를 멈췄음
      하지만 시간이 지나며 iOS 버전 호환이 안 돼 결국 사용할 수 없게 됨
      완성의 아름다움과 기술 진화의 잔혹함을 동시에 느꼈음

  • 2020년에 인프라 담당에서 Java 개발자로 전향했을 때, 주요 라이브러리들이 유지보수 모드라 “Java가 죽은 건가?”라고 생각했음
    하지만 나중에 보니 그건 기능 완성 상태였음
    수많은 엣지 케이스가 해결된 안정적인 상태였던 것임
    문제는 사람들이 그런 안정성을 원하지 않고, 늘 새로운 걸 원한다는 점임
    결국 같은 프레임워크를 언어만 바꿔가며 반복 제작함

    • 많은 사람들이 유지보수 중인 라이브러리를 쓰면 버그가 고쳐지지 않을까 두려워함
      그래서 계속 개발 중인 프로젝트를 선호함
      또 어떤 기업은 컴플라이언스 요건 때문에 업데이트가 계속되는 소프트웨어만 쓸 수 있음
    • 예전에 Java의 memcached 라이브러리가 유지보수 중이라 Redis로 갈아탔던 적이 있음
      “그냥 완성된 거라 더 개선할 게 없다”고 농담했지만, 결국 바꿨음

  • Sublime Text를 좋아하는 이유는 단순함과 속도 때문임
    AI나 복잡한 기능을 넣지 않고, 한 가지 목적에 집중함

    • 그래서 나는 여전히 vim을 씀

  • 좋은 소프트웨어가 꼭 돈을 버는 소프트웨어는 아님
    하지만 돈을 벌려면 사람들이 실제로 쓰는 기능이 필요함
    유저마다 20%의 다른 기능을 쓰기 때문에, 다양성을 고려해야 함

  • Notepad.exe는 완성된 소프트웨어의 대표 사례라고 생각했는데,
    Windows 11에서 파일 연결을 바꾸려면 해킹 수준의 조작이 필요해서 놀랐음

  • 완성된 소프트웨어의 아름다움을 인정하지만, 요즘은 대부분 “영원한 베타” 상태임
    인터넷 연결이 전제되면서 “언제든 업데이트 가능”하다는 구조가 생겼고,
    버그 수정과 원치 않는 기능 추가가 분리되지 않음
    YouTube 같은 웹서비스는 버전 선택조차 불가능함

    • 나는 Evernote에서 Obsidian으로 옮겼지만, Obsidian도 점점 기능이 과해지고 있음
      특히 Canvas 기능이 추가되면서 본래의 단순한 철학이 흔들렸음
      오픈소스였다면 그 시점에서 포크했을지도 모름

  • Signal은 무료, 오픈소스, 프라이버시 중심이라 기능이 적음
    하지만 그게 오히려 마음에 듦

    • 그래도 예약 전송 기능 하나만큼은 WhatsApp보다 훨씬 유용함
      WhatsApp은 쓸데없는 기능만 늘리고 있음

  • 37signals의 책에서 말한 ‘항상 필요한 것(evergreen)’, 특히 속도의 중요성을 예전엔 몰랐음
    하지만 시간이 지나며 앱들이 점점 느려지는 걸 보니, 빠른 소프트웨어의 가치가 얼마나 큰지 깨달았음

  • Neal Stephenson의 『REAMDE』에 나오는 “작가들은 거주지를 좋아한다”는 문장이 떠오름
    작가들이 계속 일거리를 만들어 거주지를 유지하듯, 개발자도 일거리를 만들기 위해 코드를 바꾸는 경향이 있음

    • “코드베이스를 X 아키텍처나 Y 언어로 전면 재작성해야 한다”는 말을 수없이 들었음
      결국 우리도 변화를 위한 변화를 반복하고 있음
답변달기