Romantic Binaries

이게 이 Tumblr에서의 마지막 글이 될 것 같습니다. [블로그를 이전했기 때문입니다.][1] 새 블로그 URL은 다음과 같습니다.

blog.hongminhee.org

혹시 이 글을 RSS 구독을 통해서 읽게 되신 분이 계시다면, RSS 주소를 로 옮겨주세요.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

홍민희 블로그가 이전됐습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

오늘도 프로그래밍과 아무 관계 없는 얘기를 써본다.

Soylent로 점심을 때운지 두 달 남짓 됐다. Soylent는 이른바 식사를 대체하는 것을 목표로 한 제품으로, 그런 종류의 제품 중에서 가장 먼저 널리 알려진 것이다. (앞서 Premist 님이 썼던 리뷰 “Soylent 1주일 후기”도 읽어볼 것을 권한다.) 쉽게 얘기해서 그것만 먹고 살아도 영양 불균형으로 인해 병이 나거나 죽을 걱정을 하지 않아도 되는 식품을 목표로 한다고 보면 된다.

내가 먹어본 버전은 1.5와 2.0 두 개인데, 1.5는 Soylent 첫 버전부터 꾸준히 발전해온 분말 유형이고 봉투에 담겨서 온다. 2.0은 최근에 새로 나온 것인데 이미 음료 형태로 완성이 된 상태로 병에 담겨서 온다.

처음에는 2.0의 맛이 더 깔끔하고 군더더기가 없어서 선호했으나, 번갈아 먹다보니 몇일 지나지 않아 식사라는 느낌을 조금이나마 더 주는 1.5를 선호하게 됐다. 2.0에 비해 1.5는 호두 냄새 같은 게 더 나고, 살짝 건더기 느낌도 난다. 1.5는 “먹는” 느낌이 좀 나는데, 2.0는 “마시는” 느낌이다. 게다가 2.0은 정량이 정해져 있는데, 그 양이 내게는 좀 부족한 정도였다. 점심을 2.0으로 때우면 5시쯤에는 벌써 심하게 배가 고파진다. 1.5는 분말을 통에 담고 물을 직접 섞어서 먹어야 하므로, 양은 자신이 원하는대로 정할 수 있다.

물론 빠르고 편하게 먹자는 이유로 Soylent를 먹는 것도 있는데, 그런 관점에서 보면 1.5는 2.0에 비해 손색이 있다. 은근히 통에 정량대로 가루를 담고 물 넣어서 흔드는 것도 일이다. 별 것 아닌 설거지도 귀찮다.

그런 경험이 누적되어, 특별히 규칙을 정한 건 아니지만 대체로 1.5과 2.0 중 어떤 것을 먹을지 정하는 기준 같은 게 생기긴 했다. 지각했을 때, 지금 당장 회의 들어가야 하는데 식사 못 했을 때, 아침에 일어나서 입맛이 하나도 없는데 배가 비어 뭐라도 먹어야 할 때, 자정에 배가 고픈데 2시간 안에 잘 것 같을 때는 2.0을 마신다. 자정에 2.0을 뜯는 이유는 양이 적고 밤에 설거지하기 귀찮기 때문이다. 그 외에는 보통 1.5를 먹는다.

맛에 관해서는, 나는 어떤 음식이 맛있는 음식인지 잘 모르지만, 먹을만 했다. 앞서 얘기했듯 2.0이 더 깔끔해서 처음 먹을 때는 거부감이 들지 않는다. 1.5는 처음 먹으면 살짝 거부감이 드는데, 익숙해지면 오히려 거부감을 주었던 그 향이 더 식사 같은 느낌을 줘서 선호하게 되는 듯하다. 어쨌든 둘 다 똥맛은 아니다. 직장 동료는 1.5가 똥맛은 아니지만 흙맛이 난다는 얘기는 했던 것 같다.

다만 모든 식사를 Soylent로 때우기에는 나도 아직 미래인이 될 준비가 되지 못했다. 처음 시도할 때는 연속으로 다섯 끼니 정도를 Soylent로 해결하기도 했지만, 나는 누구보다 짠맛과 MSG의 감칠맛를 사랑하기 때문에 그러한 자극적인 느낌이 그리워졌던 것이다. 그래서 주말에 집구석에 박혀서 식사는 대충 때우고 싶을 때, 점심은 Soylent로 때우고 저녁은 라면이나 스팸에 밥만 먹기도 한다.

이러한 식사 대체품으로는 Soylent 외의 여러 대안 제품들이 나오고 있다. 국내에도 벌서 여러 종류가 나와 있다. 회사에서 이러한 식사 대체품(회사 안에서는 “미래 식량”이라고 불리고 있고 Slack 채널이 따로 있다)에 대한 유행이 생겨서, 다들 이것 저것 서베이하고 도전해보았다. 나도 동료가 주문한 랩노쉬라는 국산 제품을 시도해 보았는데, 초콜렛 맛과 구운 오징어 냄새가 섞여있는 느낌을 참을 수 없어서 한 통을 다 비우지 못했다. 물론 이는 전적으로 개인적인 경험으로, 동료들 중에서는 오히려 Soylent보다 랩노쉬가 낫다면서 만족한 사람도 여럿 있다.

Soylent는 한국에서 가격적인 디메리트가 있다. 배송 대행을 거쳐야 하기 때문이다. 관세도 적지 않고, 특히 2.0은 무게가 나가기 때문에 배송비가 많이 나간다. 이런 점 때문에 국산을 찾는 동료가 많았다. 나 같은 경우 2.0은 가격이 부담되기 때문에 더이상 주문하지 않고 1.5만 주문하려고 한다.

홍민희 블로그가 이전됐습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

홍민희 블로그가 이전됐습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

홍민희 블로그가 이전됐습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

홍민희 블로그가 이전됐습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

회사 슬랙에서 김병환 님이 연속적 디자인과 NoPSD 운동에 대한 글을 링크해주셔서 읽게 되었다. 이미 연속적인 과정으로 개발하는 방식에 확신을 가진지 오래된 프로그래머로서 글의 많은 부분에 동의하는 바이나, 읽고나서 든 생각은 “그런데 정작 당사자들에게 공감을 얻을 수 있을까?”였다.

나는 저런 내용이 당사자들에게는 공감을 얻어내기 힘들다고 생각한다.

프로그래머들은 이미 현재 누리고 있는 개발 방식에 익숙해져 있기 때문에 쉽게 잊곤 하지만, Donald Knuth가 회상하듯 옛날 프로그래머들은 원래 “돌에 새기듯 프로그래밍하는 것을 배웠다.”

건축을 비롯해 처음부터 완벽하고 올바른 설계를 하는 것을 강조하는 많은 분야들에는 하나 같이 대동소이한 정당화가 존재한다. “한번 만들면 바꿀 수 없다.” 그러나 그러한 특성은 프로그래밍에도 존재하던 것이었다. 컴퓨터 프로그램은 모든 부분이 논리적으로 정확하게 맞물려 한치의 오차도 없이 맞아 떨어져야 한다. 그 와중에 일치하지 않는 것, 일관성이 깨지는 부분이 있다면 프로그램은 단지 보기에 나빠지는 것이 아니라, 오류가 나며 동작하지 않게 된다. 컴퓨터 프로그램은 작성하고 나면 방대하고 복잡해질 수밖에 없어서, 과장하면 거의 쓰기 전용(write-only)이었다. 프로그래밍은 본래 천성적으로 ‘처음부터 완성된 채로 만들어져야 하는’ 작업이었다. Paul Graham은 그의 유명한 에세이 해커와 화가에서 어렸을 적 자신이 처음부터 올바른 설계를 하는 식으로 프로그래밍하지 못하는 것에 대해 부끄럽게 여겼다는 고백을 한다. 소프트웨어 공학은 한동안 건축의 메타포를 버리지 못했다. (그리고 지금도 어느 정도는 여전하다.)

물론 이는 오래된 이야기이다. 현대의 소프트웨어 개발은 점진적이며, duct tape programmer라는 말도 생겼을 만큼 ‘얼기설기’ 만들어서 ‘조금씩 고쳐나가는’ 것이 가능해졌을 뿐만 아니라, 그러한 것을 오히려 바람직한 개발 방식으로 본다. 이렇게 프로그래머 공동체의 관점이 크게 바뀐 것에는 애자일 선언이나 스타트업 열기도 중요한 역할을 했겠으나, 나는 이 글에서 흔히 고려되지 않는 또 다른 요인도 꺼내볼까 한다.

소프트웨어 개발이 점진적일 수 있게 된 이유는, 점진적으로 소프트웨어 개발을 빠르고 쉽게 할 수 있는 충분한 도구가 아주 많이 주어졌기 때문이다. 그리고 그러한 도구가 아주 많이 생겨날 수 있었던 이유는, 프로그래밍이라는 작업의 특수성에 기인한다.

소프트웨어 개발이 발전함에 따라 프로그래머 사회는 아주 특이한 양상을 띄게 되었다. “장인은 도구 탓을 하지 않는다”라는 기존 다른 분야의 격언에 역행하는 방향으로 가게 된 것이다.

많은 프로그래머들은 “우리가 도구를 어떻게 써야 하는지”보다 “우리가 쓰는 도구가 어땠어야 하는지”에 점차 집중하기 시작했다. “장인은 도구 탓을 하지 않는다” 내지는 “도구는 도구일 뿐”과 같은 격언은 대부분의 분야에서 아주 중요한 가르침을 준다. 자신이 직접 통제할 수 없는 요소에는 헛된 노력을 투입하지 말고, 통제할 수 있는 영역에만 노력을 집중하라는 것이다. 여기서 중요한 부분은, 자신이 통제할 수 있는 영역이라면, 노력을 들일 이유가 생긴다는 것이다.

악기 연주자는 본인의 악기에 불평할 수는 있어도, 만족할만한 더 좋은 악기를 만들어내지는 않는다. 연주자가 악기에 대한 불평을 해봤자 대체로 비생산적인 일이다. 그래봤자 악기를 좋게 만들 수 없기 때문이다. “도구 탓을 하지 말라”는 이야기는 그런 맥락으로 이해해야 한다.

반면, 프로그래머들은 아주 운이 좋게도 스스로의 도구를 고치거나 만들어낼 수 있었다.

머릿속에 한번에 담을 수 없는 많은 수의 상태를 머릿속으로 추적하며 디버깅하기 어려웠기 때문에, (순간 기억력을 늘리려는 노력을 하기보다) 디버거를 만들었다.

기계어로 사소한 곳까지 긴 코드를 써가며 코딩하는 것이 어려웠기 때문에, (폰 노이만처럼 기계어에 능숙해지는 대신) 기계보다는 수학이나 인간 언어에 가까운 높은 추상화 수준의 언어를 만들고, 그 언어를 기계어로 번역해주는 컴파일러도 만들었다.

소스 코드가 길고 복잡해지면 한눈에 파악하는 것이 어려워졌기 때문에, (소스 코드 읽는 수련을 하는 대신) 구문 강조와 통합 개발 도구(IDE)를 만들었다.

처음에 세웠던 가정들이 중간에 깨질 때마다, 그 가정에 기대어 만들었던 방대한 코드를 모두 찾아가며 고치는 것이 어렵고 버그가 생기기 쉬웠기 때문에, 리팩토링 도구를 만들었다.

코드를 약간만 고쳐도 소프트웨어의 모든 부분이 여전히 잘 동작한다는 것을 보장하려면, 수정할 때마다 사람이 많은 시간을 들여 전체 기능 체크 리스트를 들고 전수 검사를 해야했는데, 이걸 자동화할 테스트 자동화 기술을 만들었다.

다양한 소프트웨어를 만들면서도 비슷한 기능을 매번 새로 만드는 것이 불편하고 시간이 낭비되었기 때문에, 의존성을 나열하고 명령어 하나만 치면 필요한 라이브러리가 알아서 받아서 설치되고 빌드까지 되게 하는 패키지 시스템을 만들었다.

여러 사람이 거대한 시스템의 부분을 고치다보면 동시에 여러 사람이 한 군데를 건드리는 경우가 생기곤 했는데, 그러한 수정 사항들을 안전하게 합치기 위해 Git과 같은 버전 관리 시스템을 만들었다.

사소한 기능 수정을 할 때마다 프로그래머의 작업용 컴퓨터에서 전체 테스트를 돌리고 새로운 빌드를 만들어서 사용자들에게 전달하는 것이 귀찮았기 때문에, 프로그램을 수정할 때마다 자동으로 그 모든 것을 해주는 CI를 만들었다.

나열하자면 끝이 없다. 위에서 언급한 것들은 굵직한 발명들만 모은 것이다. 어떤 프로젝트든 어느 정도 시간이 지나면 개발의 편의를 위해 만들어내는 내부 발명품들이 쌓여간다. 이를 아예 일반화하고 오픈 소스로 공개하는 경우도 아주 많다. 위에서 말한 도구들은 정확히는 도구의 분류에 가까워서, 가령 프로그래밍 언어는 하나가 아닐 뿐 아니라 지난 몇십년간 여러 언어들 사이에 끝없는 전쟁이 이어져 왔다. 재능 있는 프로그래머 지망생은 누구나 자신에게 꼭 맞는 운영체제나 프로그래밍 언어를 구현해볼 마음을 품는다. 그리고 상당히 많이들, 실제로 만들어낸다.

이는 디자이너로 치면 “재능 있는 디자이너라면 누구나 자신에게 꼭 맞는 포토샵 대체품을 만들어볼 마음을 품는다” 같은 얘기가 되며, 악기 연주자로 치면 “누구나 자신에게 꼭 맞는 악기를 만들어볼 마음을 품는다” 같은 얘기가 된다. 분야가 달라지니 상당히 다르게 받아들여진다.

그러나 프로그래머들이 명심해야 할 점은, 그러한 분야의 발전이 더딘 것이 아니라, 프로그래머 사회가 매우 이상한 특성을 가진 것이라는 사실이다. 프로그래머 공동체의 이러한 경향은 다른 직업 공동체에서는 쉽게 공감을 얻기 힘든 생소한 태도이다.

프로그래머 공동체는 앞으로도 더 많은 도구를 만들어내고, 더 자주 개선할 것이다. 그러한 개선된 도구를 가지고, 또 도구 그 자체를 빠르게 만들어내는 데에 활용할 것이다. 프로그래머들은 점점 큰 걸음을 손짓 하나로 할 수 있게 되면서, 프로그램은 아무때건 얼마든지 고칠 수 있다는 아이디어에 자신감을 얻을 것이다.1

그렇다면 소프트웨어 분야의 다른 직군들은 어떻게 ‘점진적으로 만들어가는’ 아이디어에 확신을 얻을 수 있게 될까? 글을 열심히 읽어준 분들께는 허탈하게 해서 죄송하지만, 나로서는 계속 고민하고 있을 뿐 아직 답을 못 찾았다. 현재로서는 개개인의 탁월함에 기대는 것이 한계이다. 훌륭한 작업을 빠른 시간 안에 해내는 능숙한 동료가 있다면, 빠르고 점진적으로 제품을 만들어나가는 방식에 발을 기꺼이 맞춰줄 것이다. 하지만 이것이 대부분의 평범한 동료들에게도 요구할 수 있는 덕목인지는 여전히 확신이 들지 않는다. 그러니까, 나는 ‘애자일한 제품 개발’이라는 것이 과연 프로그래밍 이외의 영역에도 쉽게 전이될 수 있는 방식인지에 대해 의문이 생긴다.

덧. 최근 회사 동료들과 얘기를 하면서 이러한 의문을 품기 시작했습니다. 스포카는 좋은 동료들과 일할 수 있는 좋은 회사입니다. 스포카는 웹 프론트엔드/안드로이드/iOS 개발자를 구하고 있습니다. 기승전구인

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.

내용은 위치만 다음 URL로 이동했을 뿐, 여전히 보존되어 있습니다.