소프트웨어는 사람을 미치게 만든다

오늘 HN 첫 페이지에 올라온 최신 "우리는 tech/architecture X에서 Y로 이동한다" 글에 이 생각을 올리려던 참이었는데, 지금은 여기가 더 어울린다고 느낀다.

최근에 친구와 우리가 예전에 얼마나 적은 개발자로 훨씬 많은 일을 했는지에 대해 이야기했다. 20년 전에는 미션 크리티컬한 실시간 소프트웨어(트레이딩 시스템)를 C++로 개발했는데, 팀은 20여 명 정도였다. 핵심 트레이딩 커널 팀은 네 명이었다. 사내 분산 프로세스 오케스트레이션 도구(프런트엔드와 백엔드 모두 C++로 작성)는 두 명이 만들었다. 나 자신도 한때 선물 계약을 위한 포스트 트레이드 리스크 관리 시스템 전체를 혼자서 몇 달 만에 만들어냈다. 오늘날에는 웹과 모바일 애플리케이션에 60~80명 팀이 붙어 있는데, 대부분의 작업이 CRUD이고, 극히 일부에 트랜잭션/큐 복잡성이 있을 뿐이다.

차이는 기술의 격변이라고 생각한다. 그때는 런타임 라이브러리든 개발 도구든 우리가 가진 의존성이 거의 없었고, 그것들은 안정적이었다. 표준 라이브러리, 컴파일러, 유닉스 명령어와 bash 스크립트, 그리고 일부 내부 라이브러리 정도였다. 우리의 시간과 집중력 대부분은 올바른 알고리즘과 데이터 구조를 찾는 데 들어갔고, 코딩은 그 다음이었다. 기술 스택과 도구를 선택하고, 설정하고, 업데이트하고, 재설계하거나 교체하는 데는 거의 시간을 쓰지 않았다.

글쓴이는 소프트웨어를 통해 에고의 효과를 사실상 관찰했지만, 그것을 수치화할 능력까지는 아직 도달하지 못했다.

다시 읽으면서 주어진 모든 예시를 그 렌즈로 적용해 보라.

우리가 인간 본성의 이 부분을 유난히 잘 드러내는 업종에 있는 것일 수도 있지만, 다른 일화로 나타날 뿐 어디에나 존재한다고 확신한다. 직업적 창의성에 환원주의적 선불교 관점을 적용하면 이 모든 것이 사라진다.

Bob은 자신이 영웅이 되기 위해 하위 시스템을 리팩터링하려 하고, 경영진에게 잘 포장만 하면 기술적 가치와 실제 성공 수준은 무관해진다. Alice는 명백한 우려를 제기한 뒤 뒤로 물러나 상황을 지켜보기로 한다. Jane은 스탠드업에서 손을 들고 모두에게 하늘이 무너질 거라고 감정적으로 설득하려 한다. Alice처럼 행동하고 정신 건강을 지켜라.

내 관찰은 단순히, 기술 리더들이 어떤 도메인의 한 측면을 추상적으로 표현한 것을 정복함으로써 시장에서 받는 보상을 그 도메인 자체를 정복한 것으로 오해한다는 것이다. 그러다 자기애에 빠진다.

당신은 미래의 업무와 사회를 열어젖힌 상업용 부동산을 정복한 것인가, 아니면 편리한 일정 관리 앱을 만든 것인가?

온라인 커뮤니티에 대한 멋진 아이디어가 있었던 것인가, 아니면 인간 관계를 혁신한 것인가?

2014년 글 "Programming Sucks"[0]가 떠오른다. 항상 "마땅히" 더 나아야 하는데도 현실과 단절되는 비슷한 문제를 다룬다.

> 모든 프로그래밍 팀은 미친 사람들에 의해, 미친 사람들로 구성된다 [...]

> 뇌에 미치는 파괴적 영향은 사람들이 작성하는 프로그래밍 언어로 드러난다. [...]

> 모든 프로그래머는 뇌가 결코 하도록 설계되지 않은 일을, 결코 나아질 수 없는 상황에서, 하루 10~15시간, 주 5~7일 강제로 시키고 있으며, 그들 모두는 서서히 미쳐가고 있다.

[0] https://www.stilldrinking.org/programming-sucks

소프트웨어가 이런 영향을 미치는 것인가, 아니면 소프트웨어 제품에 대한 관리가 그런 것인가? 학술적이거나 취미로 하는 소프트웨어 프로젝트가 변덕스럽게 중요한 것을 계속 바꾸는 경우는 별로 보지 못했다. 하지만 소프트웨어 업계에서는 항상 볼 수 있다.

소프트웨어가 아니다. 대부분의 관리자/행정가가 소프트웨어 개발자가 아니라는 사실이 문제다(비록 어느 정도 프로그래밍 능력은 있을지라도). 그래서 그들은 개발팀과의 관계에서 마치 물리적 제품의 기능에 대해 제조사에 불평하는 고객과 같은 위치에 서서, '이것도 저것도 되어야 한다, 바꾸는 건 쉬운 일'이라고 말한다(구현하는 지루함을 건너뛰면 갖는 것을 상상하기 쉽기 때문이다).

물론 때로는 요구가 정당하고 원래 사양의 결함(야심 부족이든, 잔디깎이 엔진에 화물 컨테이너를 연결한 과도한 야심이든)을 해결하기도 한다. 하지만 글에서 묘사된 갈등의 대부분은 변화의 이점을 상상하면서 구현은 버튼 몇 개만 더 누르면 되는 일이라는 무언의 가정이 결합된 데서 비롯된다.

이 프레이밍이 정말 좋다. 왜 그런지에 대한 생각이 많지만, 내가 생각해낸 가장 그럴듯한 설명은:

1. 소프트웨어 구축의 상당 부분은 일종의 수학이다. 수학에서는 X가 참인 이유를 설명하는 증명을 쓴다. 소프트웨어에서는 X가 참이 되도록 보장하는 코드를 쓴다(예: "백엔드는 사용자 ID가 항상 존재한다고 가정했는데, 이제 서비스 계정이 생겼으니 합리적인 뷰가 여전히 반환되도록 접근 제어 코드를 바꿔야 한다").

2. 수학은 어렵고, 대부분의 작업은 보이지 않는 사고다. 수학자에게 리만 가설이 언제 증명될지 추정해 달라고 하면 비웃을 것이다. 우리 문제는 일반적으로 더 쉽지만 여전히 어려울 수 있다. 그리고 수학에서처럼 때로는 예상보다 훨씬 어렵다(예: 페르마의 마지막 정리. "왜 그렇게 어려웠어? 페르마와 이야기했어? 그가 떠났다고? 하지만 쉬울 거라고 했잖아!").