Continuous Design and the NoPSD Movement

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

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

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

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

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

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

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

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

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

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

• 머릿속에 한번에 담을 수 없는 많은 수의 상태를 머릿속으로 추적하며 디버깅하기 어려웠기 때문에, (순간 기억력을 늘리려는 노력을 하기보다) 디버거를 만들었다.
• 기계어로 사소한 곳까지 긴 코드를 써가며 코딩하는 것이 어려웠기 때문에, (폰 노이만처럼 기계어에 능숙해지는 대신) 기계보다는 수학이나 인간 언어에 가까운 높은 추상화 수준의 언어를 만들고, 그 언어를 기계어로 번역해주는 컴파일러도 만들었다.
• 소스 코드가 길고 복잡해지면 한눈에 파악하는 것이 어려워졌기 때문에, (소스 코드 읽는 수련을 하는 대신) 구문 강조와 통합 개발 도구(IDE)를 만들었다.
• 처음에 세웠던 가정들이 중간에 깨질 때마다, 그 가정에 기대어 만들었던 방대한 코드를 모두 찾아가며 고치는 것이 어렵고 버그가 생기기 쉬웠기 때문에, 리팩토링 도구를 만들었다.
• 코드를 약간만 고쳐도 소프트웨어의 모든 부분이 여전히 잘 동작한다는 것을 보장하려면, 수정할 때마다 사람이 많은 시간을 들여 전체 기능 체크 리스트를 들고 전수 검사를 해야했는데, 이걸 자동화할 테스트 자동화 기술을 만들었다.
• 다양한 소프트웨어를 만들면서도 비슷한 기능을 매번 새로 만드는 것이 불편하고 시간이 낭비되었기 때문에, 의존성을 나열하고 명령어 하나만 치면 필요한 라이브러리가 알아서 받아서 설치되고 빌드까지 되게 하는 패키지 시스템을 만들었다.
• 여러 사람이 거대한 시스템의 부분을 고치다보면 동시에 여러 사람이 한 군데를 건드리는 경우가 생기곤 했는데, 그러한 수정 사항들을 안전하게 합치기 위해 Git과 같은 버전 관리 시스템을 만들었다.
• 사소한 기능 수정을 할 때마다 프로그래머의 작업용 컴퓨터에서 전체 테스트를 돌리고 새로운 빌드를 만들어서 사용자들에게 전달하는 것이 귀찮았기 때문에, 프로그램을 수정할 때마다 자동으로 그 모든 것을 해주는 CI를 만들었다.

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

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

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

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

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

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