2ebf827ebd823ef623bad7b0419c756c25b40df99cea59f4374a2ea2ea7e2001d5596495967057356f7e6631b7044f52ba44fd


조나단 블로우에 대한 소개)








008b8504dce61df25498e3e02fdb2f29a117e1913083722c1b600804ad339b67394c76dcc86c028267f111ecdd7c5f8a048affa520c648d198cf5a8348f765d0a07f7957ec6769ab5a39127fc06bc2227d1cd902d8fb29bd562420b02e4b1490edc8424f7db7e5f497c3a781e77fb2be168f7f9913f93a0a1b54dbeff8

(브레이드)


7ce98974b3836cf73dee82e7439c33346895df8eadac2283d2e8eececd7ba81ef818cf3cdbdb8d5677674c

(더 위트니스)


조나단 블로우는 인디 게임 베스트셀러 <브레이드>와 <더 위트니스>의 개발자


다큐멘터리 영화 <인디게임 더 무비>에도 개발자 3인방 중 한명으로 출연한 바 있음


그밖에 Jai라는 자체 제작 프로그래밍 언어를 만들기도 했음


---------------------
















0cbfc332f7d33bb267b0d8f53ad03d38984c988c96e4a53bc6d3d68db426fd68c73d4cfecca682440bda9b94f8bf718b57cdfc3f1975a7ee2196b6f15e05f5dc48d47b5079e9aba932035e4f2512b45055


인터뷰어)

내 개인적인 경험으로는, 대학교에서 배운 걸 다 잊어버려야 했어.

지금 내가 프로그래밍하는 방식은 대학 졸업 직후보다 10대 때 하던 방식이랑 더 비슷해.

그래서 우리가 문제를 괜히 더 어렵게 만들고 있는 건 아닐까 싶어.


내 생각엔, 그래.

우리가 문제를 더 어렵게 만들고 있어.









0cbfc332f7d33bb267b0d8f53ad03d38984c988c96e4a53bc6d3d68db426fd68c73d4cfecca682440bda9b94f8bf718b57cdfc3f1e74a7ee2196b6f15e05f5dc36e00003fece494b79362a2a4b318f368a



조나단 블로우)

적어도 프로그래밍 쪽에서는 확실히 그래.

사람들은 문제를 해결할 때 항상 추상화 계층을 쌓는 방식으로 배워.

근데 그 과정에서 잘 언급되지 않는 몇 가지 중요한 사실이 있어.


첫째, 추상화 계층은 절대 완벽하게 추상화되지 않아.

위와 아래 계층 간의 연결도 완벽할 수 없고, 항상 약간의 ‘슬롭’이 생겨.


그리고 둘째, 이 추상화 계층은 순수 수학처럼 이상적인 개념이 아니야.

현실에서 돌아가는 코드잖아.

무게가 있어.

복잡성을 더하고, 컴파일하는 데도 시간이 걸리고,

실행 속도도 느려지고, 전체 볼륨이 커지니까 사람들이 이해하기도 더 어려워져.









0cbfc332f7d33bb267b0d8f53ad03d38984c988c96e4a53bc6d3d68db426fd68c73d4cfecca682440bda9b94f8bf718b57cdfe3f1a73a7ee2196b6f15e05f5dccb5b8ae3e8bcd7c05bc9326a4816da18da


그래서 난 우리가 코드를 좀 더 재료공학적인 관점에서 봤으면 좋겠어.

예를 들어, 어떤 코드는 말랑말랑해서 무게를 잘 못 견디는 반죽 같은 느낌이고,

어떤 코드는 균열이 많아서 살짝 눌러도 깨질 것 같고,

또 어떤 코드는 진짜 튼튼해서 높은 건물을 지을 수 있을 만큼 강해.


근데 어떤 재료든 간에, 더 많이 쓰면 무게가 늘어나잖아.

로켓을 만들 때는 재료 하나하나가 엄청 중요해.

코드도 마찬가지야.


물론 로켓 방정식처럼 극단적인 수준은 아니더라도,

우리가 인정하는 것보다 훨씬 큰 비용이 있지

모든 코드에는 비용이 따르지.




인터뷰어)

이런 문제는 예측 가능한 방식으로 커지다가

어느 순간 갑자기 확 나빠지는 전환점이 생겨.

난 가끔 생각해. 혹시 소프트웨어도 그런 전환점이 있는 게 아닐까?


그러니까 시스템의 복잡성이 어느 정도까지는

한 사람이 전부 이해할 수 있는 범위 안에 있을 땐 괜찮아.

근데 그걸 넘어서서, 이제는 문제를 쪼개서 여러 사람이 따로 관리해야만 할 때가 오면,

그 순간부터는 그냥 시스템이 망가지는 거야.


왜냐면 더 이상 한 사람이 문제의 양쪽 원인을 동시에 볼 수 없으니까.

예전 90년대 중반쯤엔 누군가가 MS 워드 전체 구조를 다 이해하고 있었을 수도 있어.

하지만 지금 버전은 그게 불가능하겠지.

너무 복잡해졌어.





24b0d768f5dc3f8650bbd58b368273696315



이건 단순한 선형 증가나 지수 증가 문제가 아니라,

아예 차원이 다른 문제야.

그냥 완전히 고장난 거지.













0cbfc332f7d33bb267b0d8f53ad03d38984c988c96e4a53bc6d3d68db426fd68c73d4cfecca682440bda9b94f8bf718b57cdf83f1a73a7ee2196b6f15e05f5dca40f251e802eae806b2fe506b5b1350c07



조나단 블로우)

내말이 그말이야

그러니까 한 사람에서 두 사람으로 늘어나는 순간, 퀄리티는 떨어지기 시작해.

이건 다들 알고 있잖아?

아니, 적어도 맨먼스 미신(Mythical Man-Month)* 같은 건 많이들 들어봤을 거야.

팀 규모가 커질수록 스케줄링이 엉망이 된다는 얘기.


(*진척이 되지 않는 프로젝트에 무작정 사람을 더 투입하는 행위는 해당 프로젝트를 오히려 더 망친다는 속설)


예를 들어, 두 사람이 있다고 해서 한 사람보다 두 배로 빨리 개발하지는 못해.

왜냐면 그 사이에 인터페이스 비용이 생기거든.

물론 거의 두 배 가까이 될 수는 있어.

근데 일곱 명이 모인다고 해서 한 명보다 일곱 배 빠르냐?


절대 아니지. 왜냐면 그만큼 조율하고 맞춰야 할 게 많아지니까.

그리고 그 비용은 단순히 시간만 낭비되는 게 아니야.

이해도도 떨어지고, 결과물의 질도 떨어져.













0cbfc332f7d33bb267b0d8f53ad03d38984c988c96e4a53bc6d3d68db426fd68c73d4cfecca682440bda9b94f8bf718b57cdf83f1f7da7ee2196b6f15e05f5dc322e70dbf8e6a3b48defd66fc5e50ac982


프로그래밍 좀 해본 사람이라면 다 공감할 거야.

예를 들어, 네가 어떤 시스템을 짜면서,

미래에 이런 방향으로 확장할 걸 생각해서 구조를 잘 짜놨어.

예를 들면 나중에 뭔가를 30도만 회전시키면 쉽게 기능을 추가할 수 있게 말이야.


근데 나중에 누군가 와서

심지어 같은 팀 안에 있는 사람이어도,

그걸 전혀 이해 못 한 채 이상한 식으로 구현해버리는 경우가 있어.


너라면 10분이면 될 걸, 그 사람은 쓸데없는 삽질을 몇 시간씩 해.

이런 일 진짜 흔하지.


그래서 이걸 해결하려고 ‘커뮤니케이션을 잘하자’고 하지.

근데 그게 말처럼 쉽지 않아.

결국 사람들은 회의에 시간 다 쓰고,

사기는 바닥나고,

생산성은 줄어들고...

그러면 또 사람을 더 뽑게 돼.


근데 문제는, 회의에 시간 반 쓰면 개발 시간도 반이니까 사람을 두 배로 뽑아야겠지?

근데 두 배 뽑는다고 두 배 빨라지는 것도 아니야.

오히려 더 복잡해지니까.

그렇게 되면 일은 점점 꼬이고, 상황은 악화되지.

정말 금방 악순환이 시작돼는거야...


---------------





7cea8471b6806eff3ce898bf06d6040335601985f5440341eb

팀단위 개발하는 사람들 입장에서는 


맨먼스 미신이라는게 좀 와닿을수도 ㅋㅋ