“기능 요청을 무시하라”는 조언을 보며 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에서 파일 연결을 바꾸려면 해킹 수준의 조작이 필요해서 놀랐음
Hacker News 의견들
“기능 요청을 무시하라”는 조언을 보며 Blizzard와 World of Warcraft Classic 사례가 떠올랐음
수년간 유저들이 클래식 버전을 요청했지만, 블리자드는 “그건 원하지 않을 거야”라며 거절했음
결국 클래식 WoW를 출시했고 압도적인 성공을 거둠
나중에 개발진이 “유저들이 정말로 자신이 원하는 걸 알고 있었다”고 인정했음
즉, 항상 기능 요청을 무시하기보다는, 때로는 유저가 정확히 옳을 수도 있음을 인정해야 함
반대로 무례하거나 자기중심적인 유저는 대화 자체가 피곤해져서 대응하지 않게 됨
결국 교훈은, 요청할 땐 예의 있게 해야 한다는 것임
그 후에 그게 유효한 요청인지 판단하고, 구현 방법을 고민해야 함
근본적인 문제는 ‘원래의 감각을 잃은 게임’이었고, 이를 이해했다면 클래식이 아닌 다른 방식으로도 해결할 수 있었음
WoW 클래식은 ‘옛 감성’을 되찾고 싶다는 얕은 욕구의 표현이었지만, 그 밑에는 ‘신뢰할 수 없는 개발 방향’에 대한 불신이 있었음
이상적인 세상이라면 두 버전의 장점을 섞은 완벽한 형태가 가능하겠지만, 현실에서는 의견 충돌로 혼란만 커질 것임
유저 요청에 따라 비(非)PVP 인스턴스를 추가했더니, 긴장감이 사라져 게임이 밋밋해졌음
이 경우엔 개발자가 유저보다 더 잘 알고 있었던 셈임
기능 추가를 멈춘 완성된 소프트웨어가 더 많아져야 한다고 생각함
“이 정도면 충분하다”라고 말할 수 있는 용기가 필요함
Evernote나 Dropbox처럼 완벽했던 시절 이후 기능 과잉으로 혼란스러워진 사례가 많음
박스에 담겨 팔리고, 새 버전이 나오면 새 박스를 사는 구조였음
지금처럼 끊임없이 업데이트되는 웹앱 이전의 시대였음
오히려 업데이트할수록 나빠지는 경우가 많음
진짜로 개선되는 제품은 손에 꼽을 정도임
결국 원래 해결하려던 문제를 다시 만들어버림
하지만 시간이 지나며 iOS 버전 호환이 안 돼 결국 사용할 수 없게 됨
완성의 아름다움과 기술 진화의 잔혹함을 동시에 느꼈음
2020년에 인프라 담당에서 Java 개발자로 전향했을 때, 주요 라이브러리들이 유지보수 모드라 “Java가 죽은 건가?”라고 생각했음
하지만 나중에 보니 그건 기능 완성 상태였음
수많은 엣지 케이스가 해결된 안정적인 상태였던 것임
문제는 사람들이 그런 안정성을 원하지 않고, 늘 새로운 걸 원한다는 점임
결국 같은 프레임워크를 언어만 바꿔가며 반복 제작함
그래서 계속 개발 중인 프로젝트를 선호함
또 어떤 기업은 컴플라이언스 요건 때문에 업데이트가 계속되는 소프트웨어만 쓸 수 있음
“그냥 완성된 거라 더 개선할 게 없다”고 농담했지만, 결국 바꿨음
Sublime Text를 좋아하는 이유는 단순함과 속도 때문임
AI나 복잡한 기능을 넣지 않고, 한 가지 목적에 집중함
좋은 소프트웨어가 꼭 돈을 버는 소프트웨어는 아님
하지만 돈을 벌려면 사람들이 실제로 쓰는 기능이 필요함
유저마다 20%의 다른 기능을 쓰기 때문에, 다양성을 고려해야 함
Notepad.exe는 완성된 소프트웨어의 대표 사례라고 생각했는데,
Windows 11에서 파일 연결을 바꾸려면 해킹 수준의 조작이 필요해서 놀랐음
Windows Insider 블로그와
보안 공지를 보면,
멈출 줄 모르는 업데이트가 문제라고 함
완성된 소프트웨어의 아름다움을 인정하지만, 요즘은 대부분 “영원한 베타” 상태임
인터넷 연결이 전제되면서 “언제든 업데이트 가능”하다는 구조가 생겼고,
버그 수정과 원치 않는 기능 추가가 분리되지 않음
YouTube 같은 웹서비스는 버전 선택조차 불가능함
특히 Canvas 기능이 추가되면서 본래의 단순한 철학이 흔들렸음
오픈소스였다면 그 시점에서 포크했을지도 모름
Signal은 무료, 오픈소스, 프라이버시 중심이라 기능이 적음
하지만 그게 오히려 마음에 듦
WhatsApp은 쓸데없는 기능만 늘리고 있음
37signals의 책에서 말한 ‘항상 필요한 것(evergreen)’, 특히 속도의 중요성을 예전엔 몰랐음
하지만 시간이 지나며 앱들이 점점 느려지는 걸 보니, 빠른 소프트웨어의 가치가 얼마나 큰지 깨달았음
Neal Stephenson의 『REAMDE』에 나오는 “작가들은 거주지를 좋아한다”는 문장이 떠오름
작가들이 계속 일거리를 만들어 거주지를 유지하듯, 개발자도 일거리를 만들기 위해 코드를 바꾸는 경향이 있음
결국 우리도 변화를 위한 변화를 반복하고 있음