코드는 읽는 것보다 실행되는 경우가 더 많다

 (olano.dev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • “코드는 쓰는 것보다 읽는 경우가 많다”는 원칙은 작성자보다 유지보수자를 우선하라는 말에서 출발해, 사용자·운영·비즈니스까지 고려하는 의사결정 모델로 확장됨
  • 코드의 가치는 정교함 자체가 아니라 사용자 목적을 충족하는지에 달려 있으며, 일찍 자주 사용자에게 보여주고 피드백을 반영하는 과정이 중요함
  • 프로덕션에서 코드를 “실행”한다는 것은 배포, 업그레이드, 관찰, 감사, 모니터링, 수정, 폐기까지 포함하며, 장기 운영 비용은 개발 중 불편보다 훨씬 커질 수 있음
  • KISS는 코드 단순화에 그치지 않고, 움직이는 부품을 줄이고 실패 모드를 이해해 실패하더라도 동작하게 만드는 운영 원칙으로 확장됨
  • 예산, 마케팅, 마감, 이해관계자, 투자자, 정치적 이해관계가 의사결정에 개입하므로, 사용자를 기쁘게 하는 일과 매출을 만드는 일이 항상 일치하지 않음을 인정해야 함

우선순위 모델의 확장

  • “코드는 쓰는 것보다 읽는 경우가 많다”는 말은 처음 코드를 작성하는 사람이 미래에 읽고 수정할 사람의 비용을 무시하지 말아야 한다는 뜻임
  • 이 원칙은 단순함, 테스트, 문서화처럼 유지보수성에 투자하는 근거가 됨
  • 압축하면 maintainer > author라는 모델로 볼 수 있음

사용자는 개발자보다 앞에 있음

  • 코드는 목적을 위한 수단이며, 소프트웨어는 어떤 사용자에게 서비스를 제공해야 함
  • 아무리 잘 작성된 코드나 정교한 기술도 목적을 충족하고 좋은 사용자 경험을 제공하지 못하면 가치가 줄어듦
  • 우선순위는 user > maintainer > author로 확장되고, 개발자 역할을 구분하지 않으면 user > dev가 됨
  • 사용자가 무엇을 원하는지 추측하거나 묻기만 하기보다, 프로그램을 일찍 자주 사용자 앞에 놓고 피드백에서 배운 내용을 반영하는 편이 좋음

실행은 프로덕션 운영까지 포함함

  • “실행”은 단순히 프로그램을 켜는 행위가 아니라, 프로덕션에서 운영하는 전체 과정을 포함함
    • 배포
    • 업그레이드
    • 관찰
    • 감사
    • 모니터링
    • 수정
    • 폐기
  • Dan McKinley의 Choose Boring Technology는 시스템을 안정적으로 계속 동작하게 유지하는 장기 비용이 만드는 동안의 불편보다 거의 항상 훨씬 크다고 봄
  • 이 관점을 넣으면 모델은 user > ops > dev가 됨
  • 많은 소프트웨어는 의미 있는 규모의 프로덕션에 도달하지 못하고, 검증되지 않은 가정 위에서 만들어짐
  • 프로덕션에서 코드를 운영하면 KISS는 코드 차원을 넘어 움직이는 부품을 줄이고 실패 모드를 이해하는 문제가 됨
  • 중요한 일은 무언가를 배포하고, 실패할 때에도 동작하도록 보장하는 것임

비즈니스는 별도의 축임

  • 사용자를 생각하며 개발하면 멀리 갈 수 있지만, “사용자에게 가치 있는 소프트웨어가 조직에도 가치 있다”는 가정은 단순화된 추상화임
  • 개발자 입장에서는 좋은 소프트웨어를 만들고 비즈니스가 이를 돈으로 바꾼다고 나누기 쉽지만, 결국 작업 과정에 비즈니스 관점을 포함해야 할 때가 생김
  • 이 구분은 소비자 소프트웨어와 엔터프라이즈 소프트웨어에서 대체로 작동함
  • 모델은 biz > user > ops > dev로 확장됨
  • 예산은 가장 명확한 예이며, 사용자 요구를 만족시키기 위한 자원이 무한하지 않기 때문에 비용과 이익을 측정해야 함
  • 마케팅, 마감, 이해관계자, 투자자, 개인적 이해관계, 정치도 의사결정에 영향을 줌
  • 소프트웨어, 팀, 사용자만 놓고 보면 맞는 결정도 조직 전체를 고려하면 맞지 않을 수 있음
  • 때로는 사용자를 기쁘게 하는 일보다 매출을 만드는 일을 해야 함

모델로 보는 개발 조직의 냄새

  • 유지보수 불가능한 코드: author > maintainer

    • 영리하지만 게으른 코드가 스파게티와 “유령 숲”이 됨
    • 성급한 최적화, 특정 사람만 만질 수 있는 모듈 같은 문제가 포함됨

  • 사용 불가능한 소프트웨어: dev > user

    • 사용자에게서 배우지 않는 팀이나 기술을 우선하는 팀에서 나옴
    • 과도하게 설계된 프로그램, 사용자 경험을 악화시키는 “현대화”, 브라우저 기능을 깨는 웹 앱이 예시임

  • “내 컴퓨터에서는 되는데”: dev > ops

    • 운영을 염두에 두고 설계되지 않은 소프트웨어임
    • 작은 데이터 부하에 화려한 데이터베이스를 쓰거나, 작은 팀 하나가 마이크로서비스 생태계를 운영하는 식의 과도한 복잡성이 포함됨
    • 장애가 나면 한밤중에 깨워지는 사람과 설계한 사람이 다른 소프트웨어도 여기에 해당함

  • “올바른 것”: dev > biz

    • 코드를 그 자체가 목적인 것처럼 다루는 경우임
    • 허세 있는 장인, 타이타닉의 음악가, Lisp Hackers가 예시임

  • 이력서 주도 개발: dev > *

    • 걸린 것이 없고 개발자가 원하는 대로 할 수 있을 때 만들어지는 소프트웨어임

  • 상상 속 소프트웨어: biz > user > ops > dev

    • 만들어졌지만 거의 또는 전혀 프로덕션에 가지 않는 소프트웨어임
    • Charity Majors는 이를 living a lie라고 부름
    • 사용자가 없는 소프트웨어도 상상 속 소프트웨어에 해당하며, 문제를 풀지 않거나 잘못된 문제, 혹은 아무도 가진 적 없는 문제를 푸는 경우임
    • 과장된 기술을 들고 모든 것을 두드리다가 흐릿한 사용 사례처럼 보이는 것이 나오는 경우도 포함됨

  • “후기 자본주의”

    • 벤처 투자 기반 소프트웨어가 비즈니스 모델이 없거나, 독점까지 성장한 뒤 사용자를 착취하는 비즈니스 모델을 갖는 경우임

사용자와 비즈니스의 긴장

  • biz > user는 받아들이기 어려운 파급효과를 가짐
  • 소프트웨어를 배우던 방식은 최종 사용자의 문제를 푸는 일이었고, The Pragmatic Programmer의 마지막 팁 중 하나는 단순히 코드를 전달하는 것이 아니라 사용자를 기쁘게 하라는 목표로 요약됨
  • 소프트웨어가 보편화되면서 이 가정을 유지하기가 점점 어려워짐
  • 많은 소프트웨어가 사용자를 신경 쓰지 않거나, 조작하거나, 사용자를 제품으로 만듦
  • 이 문제는 소셜 미디어에만 국한되지 않음
    • 방 예약, 음식 주문, Windows 시작 버튼 클릭에서도 사용자의 주의를 끌려는 팝업이 나타남
    • Google 검색에서는 쓰레기 더미 같은 결과를 받는다고 표현됨
  • 좋은 일을 한다고 믿었던 것과 업계의 상당 부분이 수익성 있다고 여기는 것 사이의 불일치가 많은 소프트웨어 전문가의 불편함을 설명함
  • 경제적 현실을 무시하던 과거로 돌아갈 수는 없지만, 사용자에게 해를 끼치지 않기 위한 더 강한 윤리적 태도가 필요함
  • 사용자가 항상 비즈니스보다 앞설 수는 없지만, 비즈니스도 무조건 먼저 와서는 안 됨
    • user > ops > dev
    • biz > ops > dev
    • biz ≹ user

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 어떤 사용자는 시스템을 좋아해서 쓰는 게 아니라 회사에서 구매했기 때문에 쓰는 경우가 있음
    이런 상황에서는 정의상 비즈니스가 사용자보다 우선이고, 개발자는 실제 사용자보다 고객사 중간관리자의 요구에 맞추게 됨. 그렇게 하지 않으면 계약을 따지 못하기 때문임. 결국 사용자는 개발팀이 중간관리자가 좋아할 새 기능을 만들느라 바쁜 사이, 대충 제공된 기능에 묶이게 됨
    약간 냉소적이긴 하지만, 엔지니어로서 자신이 근본적으로 그런 종류의 회사에 있는지 아는 건 도움이 됨. 예를 들어 온라인 소매업체는 사용자에 매우 민감해서, 독일인은 X를 좋아하고 미국인은 Y를 좋아한다는 이유로 국가별 웹사이트 버전을 다르게 두기도 함. 작은 변화가 매출에 큰 차이를 만들기 때문임
    반면 어떤 회사들은 제품을 사는 사람이 실제 사용자가 아니어서 사용성에 거의 민감하지 않음

    • 대기업에 SaaS를 파는 회사에서 일한 적이 있음
      계약을 따려면 고객사의 체크리스트를 맞춰야 했지만, 사용자 경험도 신경 썼음. 좋은 사용자 경험은 고객의 엄격한 요구사항인 경우가 거의 없었음
      경쟁사 소프트웨어는 쓰기 매우 고통스러웠기 때문에 그 부분에서 차별화하고 싶었고, 그 덕분에 교육이 쉬워지고 사용자들이 더 만족했으며, 가능한 경우 자기 관리자에게 우리 제품을 더 사라고 추천하기도 했음
      결국 80%는 “우리 소프트웨어는 형편없지 않다”는 자부심과 공감에서 나온 일이었지만, 장기적으로는 브랜드가 쌓인다는 점에서 우리 이익이기도 했음
    • 비슷한 구매 구조를 가진 시장의 회사에서 일했는데, 우리는 사용자에게만 집중했음
      제품 주도 성장 전략을 택해서 영업사원이 없었고, 제품팀은 전적으로 사용자 경험에 집중했음. 문제는 우리가 사용자에게 파는 게 아니었다는 점임. 소프트웨어를 구매하는 사람들은 사용자 조직 안의 다른 사람들이었고, 실제 제품을 직접 써본 경험도 없었음
      실패할 수밖에 없는 접근이었음. 구매자의 머릿속을 이해하고, 그들에게 이점을 설명하고, 사용자들이 조직 내부의 다른 사람들에게 이점을 설명하도록 코칭할 영업사원이 필요했음. 사용자와 구매자 사이의 간극을 메워야 했음
    • 보통 중간관리자도 사용자이긴 하지만, 사용자 기반에서는 소수이고 사용하는 기능도 보고서처럼 다름
      그래서 어떤 사용자를 우선할지의 문제가 되고, 나머지 사용자에게 영향력을 가진 소수의 경험을 우선하는 것과, 나머지 사용자들이 관리층에 유의미한 데이터를 제공할 만큼 제품을 쓸 수 있게 유지하는 것 사이에서 균형을 찾아야 함
    • 시정부에 소프트웨어를 파는 회사에서 이런 일을 겪었음
      중요한 건 시장, 타운 매니저, 시의회 의견뿐이었음. 보고서가 좋아 보이고 가격이 맞으면 갱신했음
      현장 회의에서 매일 쓰는 사람들이 우리 면전에서 얼마나 끔찍한지 말하던 장면이 기억남. 그래도 예외 없이, 몇몇 특정 버그를 고치겠다는 약속과 최소한의 가격 인상으로 그 고객은 갱신했음
    • 개발자가 실제 사용자가 아니라 고객사 중간관리자의 요구에 맞추게 되는 게 엔터프라이즈 소프트웨어가 전부 별로인 이유임

  • 오늘 ≹ 라는 기호를 알게 됨. “비교되는 두 대상 중 어느 쪽도 다른 쪽보다 크거나 작지 않지만, 반드시 같다고 할 수도 없는 관계를 나타낸다. 엄격히 수치적이지 않은 비교 방식이 있는 영역에서 중요한 미묘한 구분”이라고 함 (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

    • 복소수 z_1, z_2에 대해 z_1 ≹ z_2라고 드는 예시는 이상함
      차라리 |z_1| = |z_2|, 즉 두 복소수가 같은 절댓값을 가진다고 쓰는 게 더 명확해 보임
      “결론적으로 ≹ 기호는 전통적인 관계 연산자 사이의 중간 지대를 제공하는 데 중요한 역할을 한다”고 되어 있는데, 수학 박사과정생으로서 한 번도 본 적이 없음. 중요한 역할을 한다고는 믿기 어려움
    • 이 글리프는 사과 이모지와 오렌지 이모지를 합친 결과여야 할 것 같음
    • 조합 게임 이론의 게임 개념이 떠오름
      게임은 초현실수의 상위 집합이고, 초현실수는 실수의 상위 집합인데, 초현실수의 정의를 느슨하게 해서 전순서 성질을 잃게 만든 것임
      그래서 다른 수와 “혼동될 수 있는” 또는 “퍼지한” 이상한 수들이 생김. 가장 단순한 예시는 * (star)로, 0보다 크지도 작지도 않아 0과 혼동됨. 0 주변의 퍼지한 구름 같은 것이고 0║*로 표기함
      더 복잡한 게임인 스위치는 더 큰 수 구간과 혼동될 수 있고 “뜨겁다”고 여겨짐. 스위치로 수를 만들면 더 흥미로운 뜨거운 게임을 만들 수 있음
    • 이 개념은 분산 시스템의 인과적 순서를 이해하는 데 중요하다고 봄. 예를 들어 CRDT 맥락에서 그렇다
      단일 장치에서 생성된 이벤트는 항상 완전한 순서가 있음. 하지만 오프라인 상태의 두 장치에서 이벤트를 생성하면 어느 것이 먼저인지 말할 수 없고, 두 이벤트 사이에 ≹ 관계가 생김. 달리 말하면 이벤트가 동시적이라고 보는 것임
      그래서 “d > b > a”와 “d > c > a”라는 순서가 생길 수 있지만 “c ≹ b”가 됨
      이런 경우의 동률 처리를 결정적으로 수행하는 방식을 정의하는 것이 CRDT가 해결하는 문제의 큰 부분임
    • 링크의 “예시 1: 수치 맥락”에는 두 실수 a와 b를 두고, a가 b보다 크지도 작지도 않지만 명시적으로 같지도 않다면 관계가 ≹라고 되어 있음
      이게 어떻게 가능함?

  • 우리 중 상당수에게는 코드를 10억 번 실행하는 비용이 개발자 몇 분의 시간보다 쌀 수 있음
    AWS에서 한 달 서버 비용으로 200달러를 쓰면 내 웹 API 코드 상당수를 1000억 번도 실행할 수 있음
    그래서 인간 독자를 위한 최적화가 항상 낫고, 경제적으로 감당하기 어려울 정도로 느리다는 게 입증되는 경우에만 다른 최적화를 하면 됨

    • 글쓴이도 같은 생각인데 제목을 혼란스럽게 고른 것 같음
      글은 다음 식으로 끝남:
      user > ops > dev
      biz > ops > dev
      biz ≹ user
      결론은 코드가 최종 사용자와 비즈니스를 위해 존재한다는 것에 가까워 보임. 마지막 식인 ≹는 최종 사용자와 비즈니스의 요구가 같지는 않지만, 코드의 존재에는 둘 다 똑같이 중요하다는 점을 깔끔하게 표현함
    • “개발자 시간보다 비용이 적다”는 계산의 문제는 보통 그 비용을 내는 사람이 자신이 아니라는 데 있음
      사용자가 더 높은 전기요금, 줄어든 수명[0], 잃어버린 기회, 더 큰 좌절, 더 잦은 하드웨어 업그레이드 같은 덜 명백한 방식으로 비용을 냄
      게다가 대부분의 사용자는 개발자 연봉이나 삶의 질을 갖고 있지 않으므로 피해가 몇 배 더 크게 다가옴
      [0] 남의 시간을 낭비하는 건 QALY를 줄이는 일임
    • 글에서는 “실행”을 단순히 프로그램을 실행한다는 뜻으로 쓰지 않았음
      프로덕션에서 운영하는 것, 즉 배포, 업그레이드, 관찰, 감사, 모니터링, 수정, 폐기 등을 모두 포함한다고 함
    • 내 경험상 지연 시간은 신경 써야 함. 사용자 경험에 영향을 주기 때문임. 더 나은 지연 시간을 돈으로 사기는 꽤 어려움
    • 읽을 줄 알았던 반응은 이쪽이었음. 하지만 이 글은 다른 글임. 한번 읽어볼 만함

  • 제목의 귀결을 글쓴이에게 되돌려 말하자면 “코드는 쓰이는 것보다 더 많이 읽힌다”가 아니라 읽을 수 없는 코드는 오래 실행되지 못한다에 가까움
    단, 나는 개발로 옆길 이동하려는 숙련된 시스템 관리자이고, 그런 의미에서 완전 초보임

    • 사람들이 이해하지 못해서 건드리길 두려워하지만, 비즈니스는 그 위에 걸려 있는 굳어진 코드가 아주 많음
    • 소스가 없는 독점 소프트웨어, 예컨대 서드파티 라이브러리나 거의 모든 블랙박스 시스템은 그 귀결의 반례임
    • 금융 산업 전체가 동의하지 않을 듯함. 그리고 은퇴에서 잠깐 돌아와서 다른 개발자들에게 당신의 COBOL 코드를 설명해줄 생각은 없음?
    • 올바른 인프라만 있으면 계속 실행될 수는 있다고 봄
      더 정확히는 “읽을 수 없는 코드는 오래 수정 가능하지 못하다”에 가까움
    • 나쁜 포인트는 아니지만 별개의 주제에 가까움
      의도적 난독화를 다루는 게 아니라면, 대부분의 코드는 노력할 마음이 있는 사람이 읽을 수 있고 필요하면 코드 포매터도 있음

  • 여기에 덧붙일 귀결이 있음. 다음 각 단계 사이에는 사용 횟수가 지수적으로 증가함

    1. 언어 설계자와 표준 라이브러리 개발자
    2. 공유 모듈 또는 라이브러리 개발자
    3. 일반 개발자
    4. 최종 사용자
      많은 언어에서 각 단계의 비율은 대략 1000배 수준이라, 언어 설계자 1명당 모듈을 설계하고 배포하는 사람이 1000명, 개발자가 100만 명, 사용자가 10억 명일 수 있음. 구체적 상황에 따라 숫자는 크게 달라지지만, 정성적 논의에는 대략적인 규모가 맞음
      핵심은 첫 번째나 두 번째 단계에서의 아주 작은 게으름이 하류에서 극적으로 곱해진다는 것임. 1단계에서 “자기 편의”를 위해 1분 아끼려고 만든 더러운 해킹이, 다른 사람들의 소중한 삶에서 말 그대로 수백만 시간을 낭비하게 할 수 있음. 느린 소프트웨어를 기다리게 하거나, 충돌로 좌절하게 하거나, 2·3단계에서 기능 개발이 늦어져 기다리게 만들기 때문임
      첫 두 단계에서 필요한 품질 수준을 유지하려면 엄청난 자기 규율과 개인 윤리가 필요함. 반대로 핵심 언어나 표준 라이브러리 설계와 관련해 정당화할 수 없는 입장을 방어하는 얘기를 들을 때마다 깊이 슬퍼짐
      “이 날카로운 부분이 생긴 전체 역사를 알기만 하면 괜찮다! 영원히 경계하면 문제가 아니다. 잘못 쓰지만 않으면 안전하지 않거나, 보안상 위험하거나, 느리거나, 문제적이지 않다” 같은 말을 자주 듣는데, 그런 것들이 앞으로 수십 년 동안 개발자들을 넘어뜨리고 수백만·수십억 명의 소프트웨어를 느리게 만들 걸 알기 때문임

  • 글쓴이가 꽤 괜찮은 경험칙을 가져다가 만물 이론을 만들려는 듯함
    깔끔하고 현명해 보이지만, 억지스러운 표현을 빼면 널리 알려진 뻔한 말을 다시 씹는 것에 가깝다

    • theory > /dev/null
    • “억지스러운 표현”이라고 했지만, 이 업계에는 영어 원어민도 아니고 영어권 국가에 살지도 않으면서 영어로 글을 쓰려 노력하는 사람이 많다는 점을 자주 떠올릴 필요가 있음
      그래서 표현이 어색해질 수 있음
      그리고 “널리 알려진 뻔한 말”이라 해도, 이 글은 그것들을 특히 일관된 방식으로 잘 엮어서 유용한 참고자료가 됨
    • 경험칙을 변주하고, 그 변주를 통해 이미 안다고 생각한 것들을 다시 보고 맥락화하는 데도 가치가 있다고 봄
      누군가에게는 모든 것이 새롭고, 내 편견을 확인해준 것에 불과하더라도 흥미로운 관점이었음
    • 더 정확히 말하면 소프트웨어 개발에서 잘못될 수 있는 모든 것에 대한 만물 이론임. 그래도 흥미롭게 읽었음
    • 끝까지 읽어봤음? 나머지는 전부 배경 이야기임

  • 글쓴이의 프레이밍은 너무 여러 방식으로 오해될 수 있어서 유용한 축약 표현이 되기 어려움. 이 토큰들 사이에 절대적인 순위는 있을 수 없음
    우선 여기서 “dev”는 한 사람이 아니라, 여러 조직의 제품, 엔지니어링, 디자인 조직에 걸친 다양한 전문성과 연차를 가진 사람들의 집합임
    “ops”도 하나가 아니고 엔지니어링 운영만 뜻하지 않음. 비즈니스 운영, 고객 지원 등도 포함될 수 있음
    “biz” 역시 하나가 아님. 브랜딩, 마케팅, 영업, 법무와 경영진, 이사회, 규제기관, 대출기관, 투자자 등이 있음
    이 모든 사람이 어떤 코드가 작성되고, 어떻게 작성되며, 언제 어떻게 사용자에게 배포되는지에 영향을 줌. 모두가 같은 문제를 풀어야 함
    조직 안의 많은 사람들은 모두가 같은 문제를 이해하고 보며 같은 목표를 향해 일하게 하려고 존재하는 경우가 많음
    하지만 그 이해는 계속 진화하고, 조직 전체로 전파되는 데 지연이 있음. 그래서 목표 자체가 변하는 와중에 모두가 같은 목표를 향해 일하는 데도 지연이 생김
    마지막으로 “user”도 하나가 아니고, 어떤 사용자 집단도 정적이지 않음. 다양한 사용자 집단이 있으며, 이들의 행동은 장기적으로 안정적이지 않을 수 있음
    그러니 주변의 모든 변수가 어떻게 변하는지 이해하고 인정한 뒤, 그 맥락에서 불완전하고 망가진 세계를 해석하는 게 도움이 됨. 그렇지 않으면 다른 모두가 형편없고 모든 것이 망가졌으니 전부 처음부터 다시 만들고 싶다는 식으로 빠지기 쉬움

  • 윤리에 가까운 내용이 논의되는 걸 봐서 반가움
    글의 “우리가 좋은 일을 한다고 생각했던 것과 업계의 상당 부분이 수익성 있다고 여기는 것 사이에 불일치가 있고, 이것이 많은 소프트웨어 전문가의 불편함이 커지는 이유라고 생각한다”는 대목에서 불편함은 꽤나 약한 표현임. 많은 것이 말해지지 않은 채 남아 있음
    몇 가지 질문을 덧붙이고 싶음. 사용자가 고객, 즉 돈을 내는 사람이 아닐 때는 어떻게 되는가? 비즈니스는 돈을 내지 않는 사용자를 포함해 모든 사용자에게 윤리적 의무가 있는가? 유료 고객이 사용자에게 부정적 하류 효과를 만드는 방식으로 당신의 비즈니스를 쓰려 하면 어떻게 되는가?
    예를 들어 플랫폼이 기존 대안보다 사기를 쉽게 만들거나, 허위정보를 퍼뜨리기 쉽게 만들거나, 사용자의 의견을 장기적으로 파괴적이지만 매력적이고 습관 형성적인 방식으로 shaping하기 쉽게 만든다면 어떨까? 이 모든 것은 일정 기간 동안 성공적인 비즈니스 모델로 입증된 바 있음
    이런 역학이 현실이라면, 비즈니스는 그런 착취적 모델을 추구해야 하는가? 추구한다면 더 책임 있게 할 수 있는가? 더 윤리적인 버전의 비즈니스가 경쟁자의 최악의 경향을 완화할 수 있는가, 아니면 결국 문제의 일부가 되는가?
    핵심 결론은 분명함. 어떤 종류의 문제들은 비즈니스 모델보다 크고 중요함. “기업들이 어느 정도의 상식 범위 안에서 작동하게 하려면 어떤 규범과 규칙이 필요한가”로 구성될 수 있는 문제들이 있음
    마지막으로 명확히 하고 싶음. 비즈니스는 본질적으로 일련의 가치를 전달하며, 이는 피할 수 없음. “인기가 이긴다”는 입장만 취하더라도 그 자체가 가치에 깊은 함의를 가진 선택임. 정치학자와 역사학자는 다수의 폭정이라는 문제를 오래전부터 알고 있었음. 정치 철학이 무엇이든 생각해볼 거리임
    “최선”의 윤리 체계가 무엇인지는 모르지만, 어떤 윤리가 다른 윤리보다 낫다는 건 알고 있음. 그리고 우리가 윤리를 검토하지 않은 채 두기보다 계속 다듬어가길 바람

    • 이건 글이 말하는 문제와는 다른 문제라고 봄
      어떤 문제와 영역이 자신의 윤리에 맞는지는 선택할 수 있음. 이 글은 시스템을 어떻게 만들고 작업 우선순위를 어떻게 정하느냐에 관한 이야기임

  • 비즈니스는 실제로 존재하지 않고, 자원을 조직해서 함께 일하기 위해 우리가 만들어낸 상상적 구성물임
    비즈니스가 무엇보다 중요하지는 않음. 사용자는 여러 명이고 때로 이해관계가 충돌함. 어디에나 있을 수 없고 모든 것이 될 수 없으니 우선순위를 정해야 함. 더 수익성 높은 사용자나 장기 전략에 맞는 사용자를 추구하는 것이 “비즈니스에 좋다”고 보일 수 있지만, 사실 목표는 사용자를 섬기는 것임. 다만 몇 단계를 더 거칠 뿐임
    내부 정치가 꼬여서 사용자 행복으로 어떻게 이어지는지 따지지 않고 비즈니스의 이익만을 위해 의사결정하는 지경이 되면, 조직은 독성이 생긴 것임. 더는 존재해서는 안 됨. 한동안 좀비 상태로 비틀거리며 갈 수는 있지만 하락세에 있고, 좋은 사람들은 모두 떠날 것임

    • 비즈니스가 실제로 존재하지 않는다는 건 감정이 존재하지 않는다고 말하는 것과 비슷함
      감정도 상황에 대한 반응을 설명하려고 만든 구성물일 뿐이라고 할 수는 있겠지만, 원자로 만들어져 있지 않다고 해서 “실재”하지 않는 건 아님
      비즈니스는 대부분의 사람들 삶을 결정하는 주된 요인인 만큼 존재함. 도시, 미디어, 법, 정치, 외교정책을 형성하고 거의 모든 중요한 것에 큰 영향을 줌. 실재하든 아니든 우리 주변에 실질적 영향을 미침
      오픈소스 바깥에서는 돈을 내는 주체가 만들어지는 방식을 결정한다는 점이 꽤 분명함. 그 결정이 그 주체에게 나쁘고, 사용자에게 나쁘고, 대중 일반이나 환경에 나쁘더라도 말임. 물론 산업과 정부 규제가 있지만 대체로 회사가 결정권을 가짐
    • 이건 사실이 아님. 비즈니스는 법적 구성물로 존재하고, 비즈니스에는 좋지만 거의 모두에게 나쁜 일도 많음. 또한 비즈니스는 사용자를 섬기기 위해 존재하지 않음
      비즈니스는 불행히도 소유자를 섬기기 위해 존재함. 대부분의 경우, 특히 5명 미만의 초소형 사업이 아닌 큰 회사에서는 소유자가 돈을 원하므로 회사의 모든 사람은 소유자에게 더 많은 돈을 벌어주기 위해 존재함. 다른 사람의 행복, 사용자의 행복조차 매출과 상관관계가 있을 때를 제외하면 전적으로 무관함
      회사 안의 또 다른 보편적 유인은 자기보존임. 따라서 의사결정자들은 돈을 버는 일 외에도 자기 일자리의 안전성을 고려함
      직원들은 떠나지 않음. 회사가 충분히 만족하게 만들기 때문임. 돈을 잘 주고 “공동체”의 일부처럼 느끼게 하는 식으로, 악하거나 얼굴 없는 조직에서 사람을 계속 일하게 만드는 건 놀라울 정도로 쉬움. FAANG 사무실을 보면 이런 인사 트릭의 자세한 목록을 볼 수 있음
      이런 회사가 독성이 있고 존재해서는 안 된다는 데는 동의하지만, 실제로 회사는 이렇게 작동함. 이는 쇠퇴의 신호가 아니라 수십 년간 지속될 수 있는 성숙하고 건강한 비즈니스의 모습임. 임원도 제품도 소유자도 바뀌지만 비즈니스는 남음
    • 처음엔 나도 같은 반응이었음. 돈 > 사람으로 요약될 수 있는 글을 보면 틀려 보임
      하지만 중요성은 주관적임. 자기 즐거움을 위한 개인 코드라면 비즈니스는 중요하지 않음. 그것을 주 수입원으로 바꾸고 싶다면 비즈니스가 가장 중요함. 소프트웨어가 아무도 섬기지 못하면 아무리 사용자가 좋아해도 실제 매출로 바뀌지 않기 때문임
    • 여기서 “비즈니스”를 “유지보수, 지원, 미래 개발을 뒷받침할 수 있는 지속 가능한 자금 모델”로 너그럽게 해석해보자
      비즈니스 모델이 없으면 사용자가 좋아하고 배포 가능하며 유지보수 가능한 훌륭한 소프트웨어도 사그라질 수 있음

  • 처음엔 회의적이었지만, 이 사고 모델이 마음에 듦
    물론 맹목적으로 따르지는 말아야 함. dev > biz인 예외도 있고, OpenAI 사태가 그렇고, dev > ops인 예외도 있음. 초기 스타트업에서는 빠르게 움직여야 하므로 특히 비즈니스 때문에 dev > ops가 될 수 있음

답변달기