프로그래밍 심리학을 읽고 - 2

오늘은 지난번에 이어, 프로그래밍 심리학 2부 사회 활동으로 보는 프로그래밍을 요약하고 느낀 점을 이야기해보겠습니다.

2부에서는 총 3가지 프로그래밍 집단이 등장합니다. 장소 정도만을 공유하는 프로그래밍 그룹, 한 프로그램을 개발하기 위해 함께 일하는 프로그래밍 팀, 그리고 여러 개의 프로그램으로 구성된 하나의 통합된 시스템을 만드는 프로그래밍 프로젝트. 관계성의 강도로 나열하면 그룹이 가장 느슨하고, 팀이 가장 팽팽하며 그 사이에 프로젝트가 있다고 볼 수 있습니다.

프로그래밍 그룹

따라서 좋은 프로그램을 만들기 위해서는 확실한 반증이 있음에도 자신의 프로그램은 정확하다고 믿으려는 완전히 정상적인 사람의 성향에 대해 뭔가 조치를 취해야 한다. (122p)

느슨한 관계성을 가진 프로그래밍 그룹의 가장 큰 특징은 비공식적 구조를 가진다는 뜻입니다. 예를 들면 자리가 가까운 사람, 자판기 근처에서 담배를 피우거나 커피를 마시며 잡담을 하는 사람 등이 있습니다. (참고로 이 책에서는 책이 쓰인 시대를 증명하듯 천공기 기계 사용을 기다리는 사람들이 예시로 나옵니다.) 이는 일반적으로 조직도나 팀, 프로젝트와 같은 명시적인 “공식적 구조”와 차별성을 가집니다. 저자는 이 비공식적 구조의 중요성을 의외로 많은 사람이 간과한다고 이야기합니다. 저 역시 입사 초기에는 아침 10시 다른 팀의 팀원분들과 함께 커피를 마시며 개발에 관련된, 혹은 완전히 무관한 잡담을 하던 때가 있었습니다. 그런 잡담에서 도메인에 얽매이지 않고 다양한 종류의 좋은 인사이트를 얻었던 터라, 재택근무가 장기화되면서 가장 그리운 시간 중 하나입니다.

다만 프로그래머는 종종 홀로, 창조적인 업무를 하다 보니 자연스럽게 고립성을 갖게 되고, 따라서 이러한 그룹을 의식하지 못하는 경우가 있습니다. 고립성은 그 자체로 좋은 것도 나쁜 것도 아니지만, 정도가 과하면 문제가 발생합니다. 그중 하나가 프로그램에 애착을 가지는 일입니다. 자신의 작업물에 열정을 다하는 것을 넘어 객관적으로 프로그램을 바라보지 못하게 되는 것은 지양해야 합니다. 이때 저자는 같은 프로그램 그룹의 코드 리뷰를 받고, 자아와 프로그래밍을 분리해서 사고하는 이른바 비자아적 프로그래밍을 할 것을 권장합니다.

혼자 코딩을 하던 제가 회사에 처음 입사해서 낯설었던 문화 중 하나가 바로 코드 리뷰였습니다. 아마 저 역시 제가 작성한 코드를 제 것이라고 인식했기 때문이겠죠. 그러다 보니 다른 사람에게 피드백을 받는 것도, 피드백하는 것도 마음이 편하지만은 않았습니다. 하지만 이 글에서 언급한 것처럼 서서히 코드와 저를 분리하면서 더 나은 방향으로 나아가고 있고, 이제는 자연스럽게 코드 리뷰를 하고 있습니다. 여러모로 공감 가는 대목이 많은 파트였습니다.

프로그래밍 팀

한 사람이 감당할 수 없는 업무 요구사항을 만족시키려면 프로그래밍 팀을 조직해야 한다. (146p)

프로그램의 규모가 커지면 현실적으로 한 사람이 프로그램 전체를 구현하는 것은 불가능에 가깝습니다. 따라서 하나의 목표를 달성하기 위해 프로그래밍 팀이 꾸려지는 것은 어찌 보면 자연스러운 일입니다.

팀을 구성하기 위해서는 고려해야 할 사항이 많이 있습니다. 저는 그중에서도 목표의 수립과 합의를 가장 인상적으로 읽었습니다. 같은 목표로 뭉친 프로그램 팀이지만, 목표를 어떻게 인식하는지는 구성원 간에 서로 다를 수도 있습니다. 저자는 구성원들이 목표를 직접 설정하도록 하는 것이 가장 좋은 방법이라고 말합니다. 이를 통해 구성원들은 목표를 한층 더 분명하게 이해할 수 있고, 이를 실현할 것을 공개적으로 약속한 것이 되므로 목표를 더 잘 인정하고 받아들이게 됩니다.

이 부분을 읽으면서 지금까지 제가 하고 있던 것이 협업이었는지, 분업이었는지에 대해 생각해보게 됐습니다. 기계적으로 일을 나누고, 각자 파트의 정해진 명세만 달성하는 분업은 명세를 달성할 때까지는 편하지만, 각 작업물을 통합할 때 어려움을 겪습니다. 하지만 구성원 간의 분명하고 뚜렷한 목표 공유와 합의를 거친 후 함께 작업하는 협업은 비록 처음에는 시행착오를 겪고, 들이는 수고도 분업보다 더 들지만, 같은 생각에서 비롯된 작업물은 훨씬 더 쉽게 조화를 이룰 것입니다.

프로그래밍 프로젝트

절대 없어서는 안 될 프로그래머가 있다면, 한시라도 빨리 그를 프로젝트에서 제거하라. (202p)

프로젝트는 어떻게 실패하지 않을 수 있을까요? 저자는 사람들이 프로젝트에 대해 오해하고 있는 것들이 많다고 이야기합니다. 대표적으로 변화를 통한 안정이 있습니다. 우리는 일반적으로 변화가 프로젝트의 붕괴를 가져온다고 생각합니다. 프로젝트는 마치 가옥과도 같아서 기둥과 같은 핵심 인력이 사라지면, 프로젝트가 무너진다고 생각하기도 하죠. 하지만 저자의 표현을 빌리자면, 프로젝트는 일종의 강에 가까운 형태를 가지고 있습니다. 팀원 간의 상호작용을 통해 팀의 목표와 성취를 주고받고 이는 기존 구성원이 떠나도 유지되기 때문입니다. 대표적인 예로 미국은 워싱턴이 떠나고 링컨이 떠났지만, 여전히 미국으로 남아있습니다. 개인은 조직보다 오래 살 수 없고, 따라서 정체성이 될 필요는 없습니다. 오히려 영속을 지향하는 프로젝트라면 핵심 인력이 한 명 없어진다고 붕괴하지 않아야 합니다.

저는 항상 지원서에 대체 불가능한 인력이 될 것이라는 자신감을 담으려고 노력해왔습니다. 하지만 프로젝트를 관리하는 입장에서 본다면, 대체 불가능한 인력은 양날의 검과 같을 것입니다. 그렇게 보면 개발자 입장에서도 어느 자리든 대체할 수 있는 개발자를 지향하는 편이 좋겠네요. 어쩐지 이전에 읽었던 유지보수하기 어렵게 코딩하는 방법이라는 책이 떠오르기도 합니다.

마치며

이 글을 읽는 내내 이건희 회장의 “한 명의 천재가 10만 명을 먹여 살린다”라는 말이 머릿속을 맴돌았습니다. 저는 ‘천재 개발자’와 어울리는 말이 아닌가 싶습니다. 이건희 회장이 그 말을 할 당시에 예를 들었던 것도 빌 게이츠였고, 한 때는 스티브 잡스, 최근에는 일론 머스크, 마크 저커버그 등 오늘날 유명한 혁신가들은 모두 IT 업계에 몸을 담고 있습니다. 여전히 이 말은 어느 정도 유효하다고 생각합니다.

하지만 앞서 말했던 것처럼, 프로그램의 규모가 커지면 한 사람이 프로그램 전체를 구현할 수 없습니다. 프로그램을 만들고, 혁신을 이루기 위해서는 함께하는 10만 명의 개발자도 필요합니다. 집단보다 수명이 짧다는 점도 개인이 가진 한계입니다. 한 명의 천재가 10만 명을 먹여 살리지만, 10만 명이 있기 때문에 한 명이 빛날 수 있다고 덧붙이고 싶습니다.