▲

Fast - 빠른 소프트웨어의 힘

 (catherinejue.com)
12P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 소프트웨어 개발에서 빠름(fast)을 요구하는 일은 드물지만, 빠른 소프트웨어는 사용자 행동에 변화를 만들어냄
  • 빠른 배포와 실시간 스트리밍 같은 기술은 업무 효율과 원격 근무를 혁신적으로 향상시킴
  • 느린 소프트웨어는 인지적 마찰을 유발하고, 실제로 사용자의 생산성을 크게 저하시키는 요인임
  • 빠른 소프트웨어는 복잡성을 감추지 않으며, 단순성과 집중력을 보여줌
  • 앞으로 개발 산업에서는 성능과 경험 최적화를 중시하는 흐름이 강해질 전망임

빠름을 요구하지 않는 소프트웨어 업계

  • 소프트웨어 업계에서는 주로 기능, 가격, 데이터 통합 등을 요구하지만, ‘빠름’을 직접적으로 요구하는 일은 드물음
  • 그러나 빠른 소프트웨어는 사용자 행동 자체를 바꾸는 힘을 가짐
  • 코드를 배포하는 데 초 단위로 줄어들면 개발자의 배포 빈도도 늘어남
  • 인공지능 기반의 코드 자동 완성 기능은 익숙하지 않은 언어 프로토타이핑을 쉽게 만듦
  • 실시간 스트리밍 기술은 원격 근무의 가능성을 열어줌

느린 소프트웨어의 한계

  • 느린 소프트웨어는 우리가 생각하는 것 이상으로 제약을 줌
  • 예로 비행기 WiFi를 사용할 때 큰 성과를 내기 어려운 경험을 할 수 있음
    • Slack 메시지 전송이나 이메일 답변 정도만 가능하고,
    • Google Docs는 제대로 작동하지 않는 경우가 많음
    • 결국은 포기하는 사용 경험이 됨
  • 반면 Instagram 같은 서비스는 일관되게 빠른 경험을 제공함

빠른 소프트웨어의 효과

  • 빠름은 마법적이라는 느낌을 줌
  • 빠른 소프트웨어는 인지적 마찰을 제거하고, Raycast나 Superhuman처럼 예상보다 한발 앞선 반응을 보여줌
  • Superhuman의 100ms 이하 반응 속도와 뛰어난 단축키 지원은 이메일 사용 경험을 혁신함
  • Mercury의 즉시 이체 기능도 느린 은행 거래에 익숙해진 사용자들에게 놀라움을 줌
  • 이러한 도구들의 속도는 명시적으로 칭찬받지 않지만, 사용자들이 마치 마법처럼 느끼는 요인임

빠름과 단순성, 집중력

  • 빠름은 곧 단순함을 의미하며, 현대 소프트웨어 환경에서 점점 더 희귀한 가치임
  • 소프트웨어가 빨라지려면 불필요한 기능을 제거하는 노력이 필요함
  • Linear와 같은 간결한 프로젝트 관리 도구는 Workday, Oracle 등과 같은 엔터프라이즈 앱에 비해 월등히 빠른 사용 경험을 제공함
  • 빠름은 사용자에 대한 존중으로, 불필요한 요소를 철저하게 걸러냈음을 보여줌

빠르게 만들기 위한 숨겨진 노력

  • 빠른 소프트웨어를 만들기 위해서는 복잡한 백엔드 최적화가 필요함
  • Cash App에서는 사용자 여정에 꼭 필요한 단계만 추가하려 노력하여, 복잡함은 내부적으로 처리함
  • Instagram은 사진 업로드 시 캡션 입력과 동시에 업로드를 시작하여 사용자가 즉시 업로드됐다고 느끼게 만들었음
  • 빠름은 단순한 기술적 성취가 아닌, 우선순위와 집중력의 결과임

빠름은 재미와 동기부여

  • 빠른 소프트웨어는 그 자체로 재미와 만족감을 줌
  • 타자 속도(WPM) 측정, 단축키 세팅과 같은 작은 부분에서도 사용자들은 빨라지는 경험을 즐김

빠름의 상대성

  • AI 및 LLM 기반 워크플로우는 전통 방식에 비해 월등히 빠른 경험을 제공함
  • 예를 들어, 6분 만에 LLM에게 리서치를 맡기는 것이 예전과 비교해 10,000배 이상 빠른 생산성을 만들어냄
  • 하지만 아직 AI 앱 개발, 빌드, 배포 과정에서는 이전 소프트웨어 시대에 비해 부족한 점이 많음
  • 현 시점에서는 성능과 경험보다는 새로운 기능에 더욱 집중하고 있음
  • 미래에는 저지연, 인터페이스 디자인, 연결성, 신뢰성 등 최적화를 우선시하는 흐름이 올 것임
  • 그렇게 되면 더 많은 새로운 가능성과 사용자 경험의 진화가 열릴 것임

참고 자료

▲
GN⁺ 3일전  [-]
Hacker News 의견
  • YCom에서 HN 인터페이스를 빠르게 잘 유지해줘서 정말 감사한 마음임. Slashdot이 "모던 UI"라고 해서 인터페이스를 완전히 바꾼 후 엄청난 공백과 스캔하기 힘든 구조로 변해서 바로 떠났던 경험이 있음. 예전엔 매일 읽던 사이트였음
    • 정보 밀도와 원하는 정보를 빠르게 찾는 것이 "engagement"와는 완전 반대인 개념임. 보통 사이트 머무는 시간 수치 올리려고 일부러 복잡하게 만들어 광고주에게 어필하려는 경우가 많음. 페이지가 일부러 느리게 로드되어 잘못 클릭하게 만들고 "전환"을 유도함. 실제로 사용자 중심보다는 남을 속이는 쪽이 돈이 되는 현실임
    • HN은 인터넷 연결이 되는지 확인하려고 켜는 사이트임. 온갖 웹 블로트 가운데 정말 빛나는 존재임
    • HN UI도 특히 모바일에서 개선이 필요함. 명암비가 낮고, 버튼 크기가 너무 작아 조작이 불편함, 다크 모드 없음 등 아쉬움 있음. 내가 생각하는 이상적인 UI를 Elm으로, 완전 클라이언트사이드로, HN firebase API로 만든 버전 있음 https://seville.protostome.com/
    • Slashdot이 망한 게 UI 때문은 아니라고 생각함. 진짜 가치는 아주 초기의 수준 높은 SME들이 남겼던 댓글에 있었음. 사이트가 매각되고 나서 수준 낮은 유저들과 안 좋은 운영, 이탈 등으로 내리막길이 시작된 듯함. 아직 사이트가 살아있는 게 신기함
    • orange site(HN)은 여전히 마크다운 링크 태그를 지원하지 않음
  • LLM을 도입한 워크플로우가 실제로는 느린 경우가 많다고 느낌. IDE의 "리팩터" 기능은 1초 만에 끝나지만, AI 도우미에 맡기면 30초, "에이전트" 방식은 15분이 걸림. 예를 들어 에이전트에게 HTTP 엔드포인트 코드를 맡겼더니 "하루치 작업을 10분 만에 끝냈다"고 처음엔 생각했으나, 다시 보니 논리가 꼬여 있고, 에러 처리도 어설펐음. 결국 직접 5시간 정도 다시 짜서 테스트도 내 기준보다 더 잘되고 에러 처리도 스스로 하는 것보다 괜찮은 수준까지 완성함. 관련 연구도 있음 https://reddit.com/r/programming/…
    • 이미 이 주제로 몇 번 글을 썼던 경험이 있음. LLM이 벤치마크 점수 쫓는 건 프로그래밍 도구 입장에서는 결 방향이라고 생각함. 내 경험상 꽤 높은 확률로 틀리므로 항상 결과를 점검해야 해서, LLM과 주고받는 시간이 길어지고, 답변이 느려서 차라리 내가 직접 손으로 더 빨리 만들 수 있겠다는 느낌이 자주 듦. 내가 바라는 건 벤치마크 60% 수준이더라도 1초 이내로 바로 응답하는 에이전트임
    • LLM이 내 작업을 진짜로 빠르게 해준 건 코드의 고급 find/replace 개념에 한정됨. 예를 들면 코드 내 여러 곳의 "XXX 관련 로직"을 뭔가로 바꿔달라는 식의 프롬프트에 꽤 괜찮게 답함. 직접 찾아서 일일이 바꾸는 수고를 많이 덜어줌. 단, 엄청 큰 코드에서는 시도해본 적 없음
    • 상황에 따라 다른 것 같음. 리팩터는 IDE나 랭귀지 서버가 지원하면 훨씬 빠른데, 그 외에는 LLM도 도움이 됨. 예를 들어 어제 URL 정규화 로직을 MVP로 만들었는데, 고객 데이터에서 다양한 형태의 URL이 섞여 있어서 검증 케이스가 많았음. 가장 많이 쓰는 고객 사례를 Claude에 넣어서 "최소 스패닝 테스트 케이스"를 만들어달라고 하니 5~10초만에 결과가 나왔고, 이를 기반으로 Zed의 Opus 에이전트 기능으로 테스트 파일을 만들고, 케이스를 검토 후 불필요한 부분은 정리, 논리도 좀 더 개선함. 이 방법이 혼자 다 만드는 것보다 훨씬 빨랐음
    • 시니어 작업에서 40~60%는 속도가 빨라진다는 이야기를 온라인/오프라인으로 많이 듣는 중임. 그래도 아직 AI 에이전트만 믿고 만사 태업할 수준은 아닌 느낌임
  • 신입 시절 소프트웨어 엔지니어로서 속도를 높이는 일로 명성을 얻었던 에피소드임. 그때는 알고리즘 지식과 컴파일러 출력을 보는 능력 모두 중요했던 시기였고, Carmak, Abrash가 스타가 되어가던 시대였음. 22살에 큰 다국적 기업 고객 미팅에 처음 참여하게 되었는데, 우리의 제품 속도가 문제라는 지적을 받음. 그 회사 VP가 "1초 빨라진 것이 우리 연간 이익에 100만 달러를 더하는 셈"이라고 직접 말하는 걸 듣고 완전 충격을 받았음. 속도에 돈을 이렇게 대입하는 걸 처음 접했던 결정적 순간이었음. 20년이 지난 지금도 경력에서 손꼽히는 하이라이트임. 그리고 또 다른 엔지니어가 VP에게 "혹시 0초까지 줄이면 무한히 돈을 벌 수 있냐"고 농담을 했고, 그 방에서는 웃음이 없었지만 나는 꽤 재밌었다고 생각함
    • 1초에서 0초로, 2초에서 1초로 줄여도 그때마다 100만 달러씩 느는 식 아님? 굳이 무한한 돈이 쌓인다는 논리가 특이함
    • 결국 더 빨라졌는지 궁금함
  • 블로그 글 첫 문장에 공감해서 써보는 반응임. 사용자가 개발자한테 "빠르게 만들어달라"는 요청을 직접 하진 않지만, 실제로 안 빠르면 믿어주지도 않음. Rust가 Ruby보다 느렸다면 아무도 관심 갖지 않았을 것임. Rust가 "C++보다 빠르다"라고 해야 주목을 받음. HN에서도 "빠르다"는 점만 있으면 다들 홀린 듯 열광함. 조금이라도 더 빠르다 하면 바로 주목을 받음
    • HN에 글 쓰는 소수 프로그래머 계층에나 통하는 얘기임. 대부분의 개발자나 일반 유저는 느린 것도 별로 신경 안 쓰고, 그냥 UI가 편하면 됨. 프로 데이터 사이언티스트도 엄청 빠른 커맨드 대신 깔끔한 Github Desktop을 많이 씀
    • 결론이 잘못된 듯함. "빠름"은 같은 기능 세트를 빠르게 제공할 때 강력한 구분점이 되는 거임. 사람들이 "X보다 빠른 X"라 하면 몰려가지만, 더 많은 기능이나 더 좋은 UX, 더 싸거나 더 좋은 걸로 옮길 수도 있고, 느리더라도 선택할 여지는 있음
    • 언어나 런타임에서는 빠름이 중요하지만, 프레임워크 쓸 때는 특징, 호환성 등 다른 요소들이 더 중요함. Electron처럼 느려도 사람들이 많이 씀
    • 실제로 (특히 웹) 앱의 상당수가 엄청나게 느린 세상에 살고 있음. 사용자가 뭔가 조작하면 반응이 오기까지 몇 초가 걸리는 일이 비일비재함. "빠른 게 최고"라 해도 현실은 반대임
    • HN 유저들이 '빠름'을 좋아하는 이유는, 우리가 현재 접하는 대부분의 테크가 너무 느리다고 (그리고 본질적으로 더 빠르게 만들 수 있다는 걸) 알고 있기 때문임
  • 반대로, 뭔가가 "너무" 빠르면 진짜로 동작한 게 맞는지 의심하는 현상도 있음. TurboTax 사례에서 실제 분석은 1초도 안 걸리는데, 일부러 가짜 로딩 스크린을 만들어 줬더니 사람들이 더 신뢰하고 좋아함. 덕분에 실제 처리 시간은 훨씬 짧아도 '정말 검토했나'라는 신뢰를 위해 느려 보이게 만들었던 일화임
  • 빠름은 비용 측면에서도 중요함. 클라우드에서 초 단위로 돈을 내는 구조에서는, 모든 과정을 최적화하지 않으면 저렴한 전사 서비스 제공이 불가능함. 예를 들어, 내가 만든 이미지가 오픈 소스 다음으로 2.5배나 더 작아졌는데, 그 덕분에 더 빠른 콜드 부팅, 더 낮은 비용, 더 좋은 서비스로 이어짐 https://speechischeap.com
    • S3가 느릴까 빠를까? 실제로는 둘 다임. 단일 리퀘스트로 보면 느리지만, 병렬로 여러 리퀘스트를 쏘면 빠르게 느껴지게 됨. 결국 '빠름'은 때로는 생존에 중요하고, 때로는 하나의 미학임
    • 나는 반대로, 컨슈머 하드웨어에서 서비스를 돌려서 클라우드보다 훨씬 저렴하게 운영함. 이미지 사이즈 걱정이 필요 없음 (베어메탈이 더 빠름). 분당 2만 분짜리 전사도 무료로 제공 중임 (요청 5초 제한 기준). 관련 오픈 소스 및 크로스플랫폼 대안도 개발 중임 https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer 전사 서비스 혁신에 관심 있으면 연락 환영임
    • PAPER 같은 도구를 (최소한 리눅스 기준) 전체 설치 사이즈 2MB 이내(캐시까지 포함해도)로 맞추길 기대함. pip이 10~15MB, pipx는 그보다 크고, uv는 35MB임. 이보다 작게 가려고 노력 중임
    • 빠르다고 해서 모두 가볍고 효율적임을 의미하지 않음. 종종 비용 많이 드는 하드웨어를 대거 투입해서 빠르게 만드는 경우도 있음
  • 미국 은행 송금에 대한 불만 기사가 보이면 항상 스스로 상기시켜야 함. 영국이나 스위스 등에선 은행 송금이 거의 즉시 끝남. 왜 미국은 이렇게 느린지 궁금함
    • 미국 지역 은행은 자체 프로그래머가 거의 없고, "코어 프로세서"에 의존함. 그래서 시스템 업그레이드가 매우 느린 편임. Faster ACH 도입도 수 년이 걸렸고, 지역 은행 로비가 자신들에 불리하다는 이유로 도입 연기를 주장함. 자세한 설명이 잘 정리된 블로그 추천함 https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
    • ACH는 일정 맞추기와 일괄 처리(batch)가 느린 원인임. 송금 자체는 바로 끝나도, 보통 자정에 합산해서 처리함. 이 덕분에 미국에선 Venmo나 Zelle이 인기가 있음. 스위스에서도 IBAN 이체는 느리고, 실시간 결제는 TWINT가 대세임 (QR코드 찍는 방식). 영국 BACS도 같은 이유로 느린 편임
    • 미국에는 실제로 실시간 송금 시스템이 두 개 있음: RTP와 FedNow임. 참여하는 은행이 점점 늘어나고 있음 https://real-timepayments.com/Banks-Real-Time-Payments.html 과거에는 소액 수수료를 내고 크레딧카드 네트워크를 통해 즉시 송금할 수 있었음. 단, 신용카드는 보장과 환불 규칙이 다르고, 사기 발생 시 은행 손해가 더 큼
    • 이게 오히려 소비자에 좋은 점도 있음. 예를 들면, 자동이체로 잔고 없는 계좌에서 돈이 빠져나갈 때 은행에서 여러 번 이메일로 알려줌. 그 덕에 실시간 일어나면 바로 문제인데, 현재는 통지 받고 직접 조치할 시간이 있어서 연체료나 수수료를 피할 수도 있음. 즉시 송금이 아니다 보니 은행이 알리고 내가 대처할 기회를 얻음
    • patio11이 관련 내용을 자세하게 쓴 글 있음 https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
  • 글이 흥미로워 생각할 거리를 많이 던져줬음. 속도가 진짜 체감될 때는 실제 처리량보다는 "느껴지는 빠름", 즉 UI 반응성이나 입력 딜레이처럼 편하게 느껴지는 속도가 중요함. 그래서 Go를 Rust보다 더 선호하게 됨. Go는 컴파일 속도가 충분히 빨라서 마치 측정할 필요도 없는 느낌임. 반대로, 느린 것은 아무리 실제 처리량이 빨라봤자 그냥 싫어짐 (Java 스타트업처럼)
    • Go와 Rust 비교해도 컴파일 속도 진짜 중요하게 느껴짐. Rust 빌드는 여러 가지 잡다한 dependency가 많아 프로젝트 구조가 자바스크립트와 비슷해짐. Go는 comparative로 dep가 훨씬 적어서 그 점이 좋음
    • 개발자들이 이런 논쟁을 하는 건 좋은데, 실제로 중요한 건 "사용자에게 어떤 언어가 더 빠른가"임
  • "소프트웨어에서 '빠르게 해주세요'는 거의 듣지 않는다"는 얘기와 달리, 내가 일했던 거의 모든 회사에서 페이지 반응 속도와 지연이 최상위 우선순위였음. 스타트업이든 대기업이든, 속도와 레이턴시가 중요한 목표였고, 보통 제품이 얼마나 빠른지, 페이지가 얼마나 빨리 뜨는지, 이상한 지연이 없는지가 항상 중요하게 고려됨
    • 내가 직접 경험한 대부분(8곳 중 6곳) 회사는, 성능 최적화를 위한 시간을 거의 주지 않아 늘 몰래 처리했음. 심지어 레이턴시 측정하며 중요하다고 주장하는 곳도, 막상 기능 추가에 밀려 실제로는 뒷순위로 밀렸음
    • 검색 결과 속도를 집착하듯 개선하면서도, 페이지 렌더링이나 사용자에게 내려보내는 데이터 크기는 크게 신경 안 쓰는 경우가 많았음
  • 여러 직장에서 반복적으로 경험한 사실인데, 대부분 속도의 진짜 가치를 과소평가함. 단순히 "같은 워크플로우를 더 빨리" 한다고만 가정해서임. 예를 들어, 밤새 돌리는 대규모 실험을 더 빠르게 만드는 건 큰 도움이 안 된다고 생각하지만, 만약 속도를 획기적으로 올리면 낮에도 수차례 실험을 돌릴 수 있고 이로 인해 완전히 다른 차원의 생산성이 나옴
    • 컨텍스트 스위칭 비용을 사람들이 엄청 과소평가함. 어떤 명령을 30초가 3초로 줄여봐야 하루 10번이면 겨우 5분 줄이기라고 여기지만, 실제로는 전환비용이 훨씬 더 큼
    • CI 파이프라인이 여러 시간 걸릴 때마다, 만약 20분 안에 끝났다면 자잘한 lint 경고들까지도 그때마다 다 수정했을 거라는 생각이 듦
답변달기