단순함의 장점에도 불구하고 아쉽게도 복잡성이 더 잘 팔리는 현실 (2022)

• 단순한 방법이 논문 심사나 승진 평가에서 낮게 평가되는 배경에는 복잡성 편향이 있으며, 복잡한 산출물이 더 많은 노력·숙련·혁신을 담은 것처럼 보이기 때문임
• 선택지와 구성 요소가 많은 시스템은 유연해 보이지만, 실제 운영에서는 설명·테스트·문제 해결이 어려워지고 실수와 비효율이 늘어날 수 있음
• 단순한 아이디어와 시스템은 이해·사용·피드백·확장이 쉬우며, Instagram은 2012년 인수 당시 13명 팀으로 수천만 사용자를 서비스하면서 PostgreSQL과 Redis 같은 검증된 기술을 유지함
• 머신러닝에서도 복잡한 기법이 항상 우월하지는 않으며, 중간 규모 표 형식 데이터셋 45개에서는 트리 기반 모델이 심층 신경망보다 나았고 추천·검색에서는 내적(dot product)이 neural collaborative filtering보다 나은 사례가 있음
• 복잡성 자체를 보상하면 불필요한 복잡화와 not invented here 성향을 키우므로, 복잡한 문제일수록 단순한 해법이 가능한지와 복잡성의 비용이 정당한지 먼저 따져야 함

---

복잡성이 더 매력적으로 보이는 이유

• 복잡성은 노력의 신호로 받아들여지기 쉬움
  • 어려운 아이디어와 기술적 세부사항이 많은 논문은 많은 시간과 노력이 들어간 것처럼 보임
  • 구성 요소와 기능이 많은 시스템은 더 작은 시스템보다 더 공들여 만든 산출물로 평가되기 쉬움
  • 만들기 어렵다는 인상이 곧 가치와 품질의 신호처럼 작동함
• 숙련의 신호로도 해석됨
  • 움직이는 부분이 많은 시스템은 설계자가 각 부분을 이해하고 통합할 능력이 있다는 인상을 줌
  • 전문 용어와 증명이 많은 논문은 접근하기 어렵지만, 그만큼 주제 전문성을 보여주는 것처럼 보임
  • 실무에서 거의 쓰지 않는 알고리듬과 자료구조를 면접에서 묻는 관행도 이런 신호와 연결됨
• 혁신의 신호라는 인식도 있음
  • 완전히 새로운 모델 아키텍처를 만든 논문은 기존 네트워크를 수정한 논문보다 더 새롭게 평가되기 쉬움
  • 처음부터 만든 구성 요소가 많은 시스템은 기존 부품을 재사용한 시스템보다 더 독창적으로 보임
  • “한 가지만 바꾸고 나머지는 기존 연구와 같다”는 평가는 단순한 아이디어의 가치를 낮출 수 있음
• 기능이 많을수록 더 포괄적이라는 착시가 생김
  • SQL과 NoSQL 데이터 저장소를 모두 지원하거나, 배치와 스트리밍 파이프라인을 모두 가능하게 하는 시스템은 모든 경우를 다루는 것처럼 보임
  • 레고 블록이 많을수록 변화에 더 잘 대응할 수 있다고 여겨짐
  • 이런 판단이 단순한 아이디어와 시스템보다 복잡한 것을 과도하게 선호하는 complexity bias로 이어짐

단순함이 실제 장점이 되는 지점

• 단순한 아이디어와 기능은 이해하고 사용하기 쉬움
  • 채택 가능성과 실제 영향이 커짐
  • 전달하고 피드백받기도 쉬움
  • 복잡한 시스템은 설명과 관리가 어려워 사용자가 무엇을 어떻게 해야 하는지 파악하기 힘듦
  • 조정할 항목이 너무 많으면 실수가 늘고, 단계가 너무 많으면 비효율이 생김
• 단순한 시스템은 만들고 확장하기 쉬움
  • 구성 요소가 적으면 구현이 쉬워짐
  • 표준화된 기성 기술을 쓰면 구현·유지보수할 사람을 찾기 쉬움
  • 코드와 내부 상호작용이 줄어들어 이해와 테스트 부담도 낮아짐
  • 불필요하게 복잡한 시스템은 구축에 더 많은 시간과 자원을 쓰게 만들어 낭비를 낳음
• Instagram 사례는 단순한 기술 선택의 장점을 보여줌
  • 2012년 인수 당시 Instagram은 13명 팀으로 수천만 사용자를 서비스함
  • 새로운 유행 기술 대신 검증된 기술을 유지해 엔지니어당 운영 부담을 낮춤
  • 다른 스타트업들이 유행하던 NoSQL 데이터 저장소를 도입하고 어려움을 겪을 때, Instagram은 이해하기 쉬운 PostgreSQL과 Redis를 사용함

운영 비용과 유지보수성

• 시스템 배포는 끝이 아니라 시작점임
  • 대부분의 노력은 프로덕션 투입 이후에 발생함
  • 운영은 원래 만든 팀이 아닌 다른 사람이 맡을 가능성이 큼
  • 단순한 시스템은 유지보수 비용을 낮추고 수명을 늘릴 수 있음
• 움직이는 부품이 적을수록 더 신뢰할 수 있고 고치기 쉬움
  • 고장 날 수 있는 부분이 줄어듦
  • 내부 상호작용이 적어 개별 구성 요소를 업그레이드하거나 교체하기 쉬움
  • 복잡한 시스템은 제한된 팀이 이해해야 할 구성 요소가 많아 유지보수 비용이 커짐
  • 상호의존적인 부분이 많으면 문제 해결도 더 어려워짐
• Thomas Paine은 『Common Sense』에서 “어떤 것이든 단순할수록 흐트러질 가능성이 적고, 흐트러졌을 때 더 쉽게 고칠 수 있다”고 말함

머신러닝에서도 단순한 기법이 밀리지 않는 사례

• 더 정교한 기법이 항상 더 좋은 성능을 내지는 않음
  • Tree-based models > deep neural networks: 중간 규모 표 형식 데이터셋 45개에서 트리 기반 모델이 심층 신경망보다 나음
  • Greedy algorithms > graph neural networks: 조합 그래프 문제에서 greedy 알고리듬이 graph neural network보다 나음
  • Simple averaging ≥ complex optimizers: 다중 작업 학습 문제에서 단순 평균이 복잡한 최적화기 이상임
  • Simple methods > complex methods: 32개 논문 전반의 예측 정확도에서 단순한 방법이 복잡한 방법보다 나음
  • Dot product > neural collaborative filtering: 아이템 추천과 검색에서 내적이 neural collaborative filtering보다 나음

복잡성을 보상할 때 생기는 문제

• 복잡성을 보상하면 사람들이 불필요하게 복잡한 것을 만들 유인이 생김
  • 단순한 방법이나 시스템은 쉬워 보인다는 이유로 덜 가치 있게 평가될 수 있음
  • 보상을 얻기 위해 시스템을 복잡하게 만들면 가장 단순한 해법이 더 이상 명확한 선택지가 아니게 됨
  • 복잡성은 더 많은 복잡성을 낳고, 결국 작업이 불가능한 수준으로 이어질 수 있음
• not invented here 성향도 강화됨
  • 기존 구성 요소를 재사용하면 시간과 노력을 아낄 수 있는데도 처음부터 만들려는 경향이 생김
  • 시간과 자원을 낭비하고 더 나쁜 결과로 이어질 수 있음
• 승진 절차와 머신러닝 논문 심사에서도 복잡성이 과도하게 강조될 수 있음
  • Bryan Liles는 단순한 해법이 복잡한 해법보다 구현과 확장이 쉽지만, 승진은 복잡한 해법을 만든 사람에게 주어지는 경우가 많다고 지적함
  • Micah Goldblum은 ML 리뷰에서 방법이 너무 단순하거나 기존 부품으로 구성됐다는 지적이 흔하지만, 단순함은 약점이 아니라 강점이라고 말함
  • Kalman Filters, PageRank, SVM, LSTM, Word2Vec, Dropout 같은 혁신도 거절된 적이 있음

복잡성을 다루는 더 나은 방식

• 목표는 복잡한 문제를 가능한 한 단순한 해법으로 푸는 것임
  • 해법의 복잡성이 아니라 문제의 복잡성에 집중해야 함
  • 단순한 해법은 문제에 대한 깊은 통찰과 더 꼬이고 비용이 큰 해법을 피하는 능력을 보여줌
  • Albert Einstein의 “모든 것은 가능한 한 단순해야 하지만, 그보다 더 단순해서는 안 된다”는 말과 연결됨
• 모든 것을 포괄하는 복잡한 해법보다 여러 개의 초점 있는 해법을 고려할 수 있음
  • 만능(one-size-fits-all) 해법은 기대보다 덜 유연하고 덜 재사용 가능할 수 있음
  • 여러 사용 사례와 이해관계자를 동시에 지원하면 강하게 결합되고, 계획과 마이그레이션에 더 많은 조율이 필요함
  • 단일 목적 시스템은 운영하기 쉽고, 필요할 때 폐기하기도 쉬움
• 복잡성 편향을 줄이는 방법으로 Occam’s razor를 적용할 수 있음
  • 가장 단순한 해법이나 설명이 보통 맞다는 원칙임
  • 단순한 아이디어를 너무 빨리 배척하거나, 가치를 정당화하려고 불필요한 복잡성을 추가하지 않아야 함
  • 복잡성의 비용을 고려해 “그만한 가치가 있는가”를 물어야 함

익숙한 복잡성을 재사용하는 반대편 편향

• “not invented here”의 반대편에는 기존 구성 요소를 자동으로 선호하는 편향도 있음
  • 이미 알고 있어 개인 경험상 더 쉽고, 자신의 시간과 노력을 줄일 수 있기 때문임
  • 하지만 기존 구성 요소 자체가 매우 복잡하다면, 더 단순한 것을 새로 만드는 것보다 시간과 자원을 낭비하고 더 나쁜 결과를 낳을 수 있음
• 단순한 선택지가 없을 때는 새로 만드는 것이 필요할 수 있음
  • 새로 만든 것이 실제로 단순해지지 않고 기존 것만큼 복잡한 다른 물건이 되는 경우도 있음
  • 어떤 문제는 본질적으로 복잡하고, 실제로 제거할 수 없는 essential complexity를 가짐
• ORM은 나쁜 사례로 다뤄짐
  • ORM은 계속 새로 만들어지고 처음에는 단순하게 시작하지만 결국 복잡성이 폭발함
  • object/relational impedance mismatch는 잘 알려져 있으며, ORM이라는 아이디어 자체가 본질적으로 복잡함
  • 단순함을 유지한 것처럼 보이는 것은 ORM이 아니라 query builder나 data mapper일 가능성이 높음
• PSR 캐시 API는 제거 가능한 복잡성의 사례임
  • PSR-6 캐시 API 뒤에 더 단순한 PSR-16 캐시 API가 나옴
  • PSR-16은 복잡성과 개념 수를 줄여 API를 더 작고 덜 의견적인 형태로 만듦
  • PSR-16 구현용 PSR-6 어댑터와 반대 방향 어댑터를 만들 수 있다는 점은 PSR-16에서 제거된 복잡성이 본질적이지 않았음을 보여줌
• 일부 라이브러리와 프레임워크는 개발자 경험이라는 이름으로 본질적 복잡성을 넘어 커질 수 있음
  • 실제 단순함은 코드 줄 수, public method 수, 결합도 같은 지표로 측정 가능한 성격을 가짐
  • 라이브러리가 몇 년 사이 원래 크기의 10배로 커지고 6~12개월마다 큰 breaking change를 내는 경우가 있음
  • 성장이 없는 라이브러리를 “죽었다”고 여기고 더 “활발한” 패키지로 옮기려는 동기도 복잡성 편향의 증상일 수 있음
• 퍼져 나가는 복잡성을 피하려면 새로 만드는 선택이 필요할 때도 있음
  • 요구사항을 고정하고 범위가 퍼지는 성장을 피할 수 있다면 새 구현이 더 단순한 선택이 될 수 있음
  • 어느 한쪽 편향도 강화하지 않도록 주의해야 함

[GN⁺]

Hacker News 의견들

• FAANG의 어떤 회사에서 복잡한 문제 해결을 승진 기준으로 삼던 시기에 일했는데, 더 복잡한 문제를 풀수록 레벨·보상·지위가 올라갔음
  자연스럽게 사람들은 풀 만한 복잡한 문제를 찾아다니게 됐고, 다른 회사들도 그 회사의 아이디어를 베끼면서 복잡한 해법이 필요 없는 작은 회사들까지 비슷한 기술 스택을 갖게 된 듯함

  • 승진 기준으로 반드시 좋은지는 모르겠지만, 복잡한 문제를 푸는 것과 복잡한 해법을 찾아내는 것은 다름
  • 복잡한 문제를 해결하는 건 승진할 만하지만, 복잡하다는 이유만으로 복잡한 해법을 전달하는 건 그렇지 않음
  • 소수만 들어본 수학 용어로 설명할 수 있으면 가산점까지 붙음
  • Google? 지금의 클라우드 네이티브 복잡성 함정을 만든 곳 말하는 건가
  • 표현은 바뀌었을지 몰라도 그 문화는 100% 남아 있고, 거기에 맞서 싸우는 게 기운 빠지게 함

• 요즘 자동차 UI, 특히 전기차의 복잡하고 다루기 힘든 UI를 보며 비슷한 생각을 했고, 이게 필요로 하는 차를 사지 못하게 할 정도임
  결론은 세련된 소비자와 동경형 소비자는 매우 다르고, 동경형 소비자가 훨씬 많다는 것임
  그래서 세련된 소비자를 희생해 동경형 소비자에게 맞추는 건 경제적으로 합리적임
  동경형 소비자는 결함과 눈속임을 소비 성취의 상징처럼 받아들이기 때문에 감수함
  거칠게 말하면 “럭셔리” 차를 모는 게 너무 좋아서 딸려온 쓰레기를 못 보고, 수십 년간 럭셔리 차를 사온 입장에서는 그냥 변속 레버가 알아보기 쉬웠으면 함

  • 예전 Tesla 차들은 조작계가 더 나았는데, 소프트웨어 업데이트로 더 나빠졌음
    터치 대상이 이유 없이 너무 작아졌고, 개발자들이 고정된 책상 위 디스플레이나 움직이지 않는 차에서 UI를 만들고 테스트한 것 같음
    움직이는 차 안에서는 모든 게 망가짐
    변속 레버, 방향지시등, 와이퍼, 조명 레버가 없는 최신 차들은 난장판임
    손을 올려둘 곳도 없는 화면에서 운전석에 앉아 작은 대상을 찔러 맞혀야 하니, 간접 조작·혼란·부정확성·주의 분산 때문에 모두 운전을 더 못하게 만듦
  • 솔직히 Tesla의 사용자 경험과 UI를 좋아함
    잠금·해제, 창문 닫기, 예열·예냉, 아침에는 회사로 저녁에는 집으로 자동 내비 설정, 어떤 휴대폰 키를 썼는지에 따른 좌석과 설정 조정 같은 귀찮은 일을 자동화해 줌
    무료 연결 덕분에 내비게이션도 제대로 동작하고, 예전에 써본 차내 GPS들은 전부 쓸모없었음
    음악 선택과 재생 화면도 좋고, 음성 명령도 음악 선택에는 꽤 잘 작동함
    완벽하진 않지만 지금까지 몰아본 모든 내연기관차보다 낫다고 봄
    아침에 회사로 출발하는 과정은 문 열기, 주행 모드 넣기 두 단계면 끝남
    겨울철 내연기관차에서는 키 찾기, 차 열기, 문 열기, 아내가 운전한 뒤 좌석 조정, 시동 버튼, 앞유리 성에 제거, 뒷유리 열선, 앞유리 얼음 긁기, GPS에서 회사 선택, 주차 브레이크 해제, 클러치, 기어 넣기까지 10단계 이상이었음
  • 내 기준으로는 1974 Celica가 자동차의 정점임
  • Tesla를 가진 입장에서 보면 좀 웃김
    직접 갖고 있지 않은 사람들이 온라인에서 터치스크린을 계속 한탄하지만, Tesla 소유자들은 터치스크린 여부와 상관없이 다른 차보다 훌륭해서 계속 그 브랜드에 남음
    Technology Connections가 최근 영상에서 와이퍼를 바꾸려고 못생긴 90년대식 레버를 4초 동안 잡고 있어야 했고, 그걸 알아내려고 설명서를 읽어야 했다고 했음
    따로따로 붙인 부품들로 만든 차에서는 이런 쓰레기 같은 동작이 아주 흔함
    반면 내 차는 실시간 감시 영상 알림을 휴대폰으로 보내고, 출근길 운전을 해주며, 변속은 보통 안전벨트를 매고 브레이크를 밟으면 차가 방향을 알아서 고르는 수준임
    중요한 기능은 50개 버튼이 아니라 핸들 휠로 문맥에 맞게 접근 가능함
    단순하면서 강력하고, 문제는 앞서 말한 럭셔리 차들의 실행이 형편없다는 데 있음

• Theo Browne라는 YouTuber를 가끔 보는데, 주로 프런트엔드 개발자임
  그가 해법을 설명하는 걸 보면 야구방망이로 머리를 맞은 느낌이고, 데모에 들어가는 요소 수가 눈물 날 정도로 많음
  한 영상에서 언급하는 React 관련 난해한 용어 수에도 놀람
  특정인을 콕 집어 비난하려는 건 아니지만, 그 복잡성이 인기를 유지하게 하는 건 아닌지 걱정됨
  반면 Pieter Levels는 Suspense, 서버 측 렌더링, Hydration 같은 얘기 없이 생 PHP를 바로 프로덕션에 밀어 넣음
  둘 다 결국 같은 목표에 도달하지만, Pieter Levels가 돈은 훨씬 더 많이 벌 것 같고 복잡성의 격차는 큼
  실제로 Nomad List 같은 건 Theo에게서 보는 것보다 기능도 훨씬 풍부하다고 봄

  • Theo를 한 번 만난 적이 있는데, 누군지 몰랐지만 몇 문장 안에 자신이 인기 스트리머/YouTuber라고 꼭 알려줬음
    이후 다른 사람이 알아보고, Theo가 채널에서 강하게 말한 주제로 친근한 고성 토론을 벌이는 걸 봤음
    그의 성격은 불필요한 복잡성을 통해 미디어 참여를 극대화하는 데 완벽히 맞아 보였음
    복잡할수록 논쟁거리가 많아지고, 난해한 선택지에 익숙하지 않은 사람들에게 더 똑똑해 보일 수 있음
  • YouTube 인플루언서식 소프트웨어 개발은 현실의 소프트웨어 개발과 완전히 동떨어져 있다고 점점 더 느낀다
    장난감 같은 예제에 쓰이는 라이브러리와 코드의 양이 프로덕션에서 보는 것보다 훨씬 크고, 나도 꽤 괴물 같은 시스템들을 본 적이 있음
    이게 얼마나 오래 갈지는 모르겠음
  • 프레임워크나 추상화 계층을 하나 더할 때마다 실제로는 복잡도가 올라가는 경향이 있음
    쓰지 않을 잡다한 것들이 잔뜩 포함되고, 정작 쓸 부분을 방해함
    문제가 생기면 이제 프로그래밍 언어와 자기 코드뿐 아니라 프레임워크 안에서 자신이 지나가는 경로의 코드까지 이해해야 함
    그 경로는 쉽게 10~20개 함수 깊이까지 내려가고, 다양한 경계 사례에서 무슨 일이 일어나는지 충분히 구체적으로 문서화된 경우는 극히 드묾
  • 편향된 생각일 수 있지만 이건 프런트엔드/JavaScript 생태계의 모습임
    비교적 단순한 것을 만들려고 쓰는 도구의 양이 엄청나고, DevOps에서도 비슷한 일이 벌어지는 느낌임
  • 오랫동안 동형 JavaScript가 PHP를 대체하길 바랐지만, 안타깝게도 이런 복잡성 구루들이 10년 넘게 산소를 빨아먹고 있음
    이 문제는 기업의 “프런트엔드 개발자”들이 만든 것 같음
    풀스택이나 백엔드 개발자가 하는 “진짜 엔지니어링”에 대한 열등감 비슷한 것이 프런트엔드에도 “진짜 엔지니어링” 문제를 만들고 싶게 한 듯함

• 수십 년 동안 레거시 시스템 개발을 하면서, 때로는 우리 회사 설계로, 때로는 고객 계약 작업으로 복잡하고 버그 많은 소프트웨어를 특정 고객들이 선호한다고 믿게 만드는 일을 많이 봤음
  이유는 그 뒤에 숨을 수 있기 때문임
  “소프트웨어에 버그가 있어서 제때 못 끝냈다”, “소프트웨어가 Y를 지원하지 않아서 X를 못 했다”, “개가 숙제를 먹었다” 같은 식임
  많은 경우 단순하고 쉽고 버그가 훨씬 적은 해법을 설계할 수 있었지만, 그러면 사용자들이 특정 실패가 소프트웨어 문제가 아니라 자기 무능 때문일 수 있다는 걸 더는 숨기기 어려워짐
  그래서 특히 위에서 내려오는 압박이 큰 회사에서는 관리자들이 완전히 이해하지 못하고, 버그와 문제가 있는 것으로 알려진 소프트웨어로 일하는 걸 실제로 선호함

  • 경력 대부분과 인생 대부분을 꽤 순진하게 살았던 것 같음
    27살에 5년 다닌 첫 직장을 옮길 때, 초복잡 GUI 프로그램을 두 개 CLI 프로그램을 감싼 작은 GUI로 대체했음
    그건 잘못된 입력이 들어와도 매번 동작했고, 드물게 실패해도 유익한 오류 메시지를 줬음
    그걸 쓰던 여성 세 명은 나를 정말 싫어했음
    회사를 떠난 뒤 1년쯤 지나서야 이유를 이해했고, 그때는 내가 별로 똑똑하지 않았음
    시간이 지나며 사람들은 Microsoft Teams 같은 걸 원한다고 생각하게 됐는데, 필요할 때 그걸로 자기 뒤처리를 할 수 있기 때문임

• 물리적 UI에서 우리 그룹은 이걸 전자레인지 문제라고 부름
  전자레인지에 달린 20개의 추가 버튼은 아무도 안 쓰고 대부분 한두 개 버튼만 쓰지만, 버튼이 적은 전자레인지는 아무도 사지 않음

  • 나는 그 “아무도”가 아닌가 봄
    10년째 Samsung ME82V를 좋아하고 있고, 다이얼 두 개면 끝임
  • 그 20개 버튼 중 어느 것도 삐 소리를 끄지 못함
    그래서 새벽 2시 몰래 간식 먹기는 1999년처럼 전자레인지를 지켜보는 일이 됨
  • 고급 블렌더도 마찬가지임
    원하는 건 속도 다이얼, 순간 작동 스위치, 전원 스위치뿐이고 모두가 그걸 원하지만, 어째서인지 세대가 바뀔 때마다 아무도 쓰지 않는 기능들이 잔뜩 붙음
  • 선택지에는 가치가 있음
    꼭 항상 같은 두 버튼만 쓰는 것은 아니니, 다른 버튼을 쓸 수 있다는 선택권을 좋아함
    그리고 버튼이 많으면 더 나은 사양이 함께 오는 경우도 꽤 많음
  • Apple은 예전에 선별된 UI를 가진 제품을 팔았음
    조작도 적고 기능도 적지만 사용자 경험은 훌륭했음
    기능이 과하게 많고 복잡한 경쟁 제품들과 비교해 iPod의 깔끔함이 기억남

• 이런 한탄은 뻔한 격언으로 가득해서 짜증남
  Einstein과 Dijkstra를 인용하면 똑똑해 보이기 쉽고, 사후 판단의 이점과 실제 요구사항에 대한 무지를 가진 채 복잡한 해법을 일반화하고 손가락질하기도 쉬움
  “가능한 한 단순하게, 하지만 더 단순하지 않게”는 언제나 맞는 말임
  지저분한 해법이면 더 단순하게 만들었어야 하고, 원시적인 해법이 문제를 일으키면 너무 단순하게 만들면 안 됐던 것임
  왜 그냥 완벽하게 만들 생각을 못 했냐는 식임
  현실에서는 해법에 여러 절충이 있을 때 무엇이 단순한지 합의하는 것조차 매우 어려움
  복잡한 데이터베이스 하나를 유지하는 게 “단순한” 데이터베이스 세 개를 두고 관리 작업을 세 배로 하다가 결국 동기화나 분산 트랜잭션을 구현하는 것보다 쉬울 수도 있음
  지금 구현하기 쉬운 것이 나중에 복잡한 문제를 만들 수도 있고, 문제를 완전히 해결하지 못하는 기성 해법은 지원하지 않는 경우를 위한 복잡한 우회책을 낳다가 결국 적절한 것으로 이전하는 복잡성까지 추가함
  “그냥 단순하게 하라”는 조언은 그런 해법이 만병통치약이 아니며, 복잡함 대 단순함의 명확한 선택지가 드문 현실을 모르는 경우가 많음
  프로젝트에는 기존의 지저분한 시스템, 일관성 없는 법적 요구, 변하는 사업 요구 같은 제약이 있고, 출시 속도나 채용 가능한 역량을 우선할 수도 있음
  경제성도 냉혹해서 연례 보고서 내보내기가 루브 골드버그 기계 같더라도 1년에 한 번만 쓰이고, 다시 써도 50년 안에 비용을 회수하지 못할 수 있음
  복잡성 논의는 프로젝트와 요구사항이 성장한다는 사실을 거의 인정하지 않음
  지금은 완벽히 단순한 것이 나중에는 무능이나 악의가 아니라 완전히 합리적인 방식으로 복잡해질 수 있음
  처음에는 일반 텍스트 파일에 데이터를 저장하는 게 아름답게 단순하지만, 나중에는 형편없는 NIH 데이터베이스가 될 수 있음
  그렇다고 데이터 3줄을 위해 처음부터 데이터베이스를 쓰는 것도 과잉 설계임
  리팩터링에는 비용이 있으니, 항상 이상적인 해법을 쓰는 것 역시 그렇게 단순하지 않음

  • 우리 둘에게는 그런 격언이 뻔해 보이겠지만, 그런 말을 들은 사람들이 오랫동안 정말 단순한 걸 이해하지 못했다가 처음 깨닫는 표정을 짓는 자리에 여러 번 있어 봤음
    생각보다 훨씬 적은 것만이 실제로 뻔함
    “가능한 한 단순하게, 하지만 더 단순하지 않게”가 완벽을 요구한다는 식의 해석은 논리적으로 이어지지 않음
    실무에서는 반복이 계획을 이긴다는 걸 알고 있음
    무엇이 단순한지 합의하기 어렵다면 허락을 구하지 말고 용서를 구하면 됨
    이 업계, 어쩌면 다른 많은 업계에서도 통하는 법칙임
  • 어떤 복잡성은 문제 자체에 내재하지만, 대부분은 배포 현실의 비기능 요구, 설정의 기능 요구, 그리고 사용자라는 혼돈 원숭이 때문에 우발적으로 들어오는 듯함
    몽상가와 프런트엔드 개발자에게서 보이는 특정한 우발적 복잡성의 유형이 확실히 있음
    복잡성은 복잡함
  • 진짜 요구사항은 왜 숨겨져 있는가

• 더 복잡한 시스템은 튜토리얼, 영상 같은 주변 자료를 많이 만들어내는 2차 효과도 있음
  또한 그걸 배운 사람들에게는 회사에서 필요한 기술과 책임을 가진 존재가 되므로, 그냥 잘 동작해서 그런 사람이 필요 없는 것보다 고용 안정성을 줌

  • https://en.wikipedia.org/wiki/Full-employment_theorem
    소프트웨어가 단순하면서도 그냥 동작하도록 만들어졌다면 존재하지 않았을 일자리가 IT에는 너무 많음
  • SQL Server DBA로서 무슨 뜻인지 전혀 이해할 수 없겠음
    단순한 경우에는 “그냥 동작”하지만, 내부를 들여다보거나 사소하지 않은 일을 하려 하지 않으면 괜찮음
  • 가끔 AWS와 Azure가 이런 식으로 느껴짐
  • 맞음. 복잡성은 공급업체 종속을 부르는 캣닙임
  • 이렇게 말하니 Scientology 같은 것으로 들림
    비유가 꽤 맞을지도 모름

• 논문 심사 이야기라면, 심사자로서 논문에서 찾는 것은 단순성도 복잡성도 아니고 “새로움”도 아님
  내가 찾는 것은 문제에 대한 철저하고 생각을 자극하는 실증 분석임
  제출물 중에는 1) 기존 아이디어 십여 개를 꿰맨 프랑켄슈타인 같은 시스템을 제안하며, 각 부분의 실패 양상을 깊이 분석하지 않고 손에 잡히는 최신 장난감을 최대한 동원해 “굵은 숫자”를 얻는 데 성공한 것, 2) 기존 방법을 단순히 조금 바꿨더니 우연히 성능이 좋아졌지만 왜 도움이 되는지에 대한 적절한 실증적·이론적 정당화가 없는 것이 많음
  두 번째 유형은 커뮤니티나 독자에게 아주 조금의 가치는 있을 수 있지만, 대부분 쓸모없다고 봄
  독자에게 가치 있는 것은 박사과정 학생이 문제를 오래 들여다본 끝에 자신의 직관을 정량적이고 검증 가능한 확인으로 연결하고, 예측력을 가진 재현 가능한 관찰을 얻은 경우임
  예컨대 “이 논문에서 설명한 Z 메커니즘을 통해 X가 Y에 영향을 준다는 것을 모든 경우에서 실험적으로 검증했고, 그래서 A 지표를 B% 개선했으며 이는 Z와 일치한다” 같은 것임
  복잡성과 무관하게 “X를 했더니 A가 B% 올랐다”는 식은 부족함
  안타깝게도 모든 심사자가 동의하진 않음

• 고등학교 역사 선생님이 제2차 세계대전으로 이어진 사건들에 대한 에세이를 쓰라는 과제를 냈음
  첫 질문은 분량이 얼마나 되어야 하느냐였고, 선생님은 이 복잡한 주제를 A4 한 장으로 다룰 수 있다면 만점을 주겠지만, 그렇게 짧은 글로 다룰 수 있을지는 진심으로 의심한다고 답했음
  모두가 그 논리에 충격을 받았음
  선생님이 그런 말을 하는 걸 아무도 들어본 적이 없었고, 어릴 때부터 더 많은 것이 항상 더 좋다고 배운다는 걸 보여줌

  • 좋은 일화지만 경계 조건이 조금 더 필요함
    설명은 언제나 추상화 수준을 골라 길게도 짧게도 만들 수 있고, 사람들은 보통 맥락과 사회적 관례에 따라 그 수준을 고름
    예를 들어 “키 입력이 어떻게 화면 글자로 이어지는가”는 한 문장으로도 설명할 수 있고, 펌웨어·소프트웨어 스택·전자공학·재료과학·제조 공정까지 들어가면 긴 책 여러 권으로도 설명할 수 있음
    제2차 세계대전도 Hitler가 Poland와 France를 침공하면서 시작됐다고 할 수 있고, Versailles 조약으로 들어갈 수도 있으며, 지구 생명의 진화까지 말할 수도 있음
    마지막은 현학적이지만, 기술적으로는 제2차 세계대전으로 이어진 사건이 맞음

• Rich Hickey의 Simple Made Easy 강연을 강력 추천함
  복잡성은 전혀 잘 팔리지 않지만, 쉬운 것은 잘 팔림
  회사가 ‘foo’를 쓸 줄 아는 사람들을 많이 채용할 수 있고 업계가 계속 ‘foo’를 이야기한다면, foo가 완전한 난장판이어도 선택할 것임
  람다 아키텍처, 대부분의 Apache 프로젝트, 컨테이너 등을 보면 됨

  • https://www.youtube.com/watch?v=SxdOUGdseq4