洪民憙 (홍민희) 블로그

Continuous Design and the NoPSD Movement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  1. 이런 주장은 반면 프로그래머에게 덜 공감될 여지도 있을텐데, 프로그래머끼리는 함께 생산성이 높아지기 때문에 분야 자체의 개발 속도가 빨라진다는 느낌을 잘 받지 못하기 때문이다. 하지만 ‘5명으로 5주동안 만들 수 있는 것’이 15년 전에서 지금까지 어떤 식으로 바뀌었는지 생각해보면 많은 발전을 느낄 수 있다.