Egoless Programming이란 개념은 얼마전에 한국어로도 번역된 Gerald Weinberg의 The Psychology of Computer Programming에서 등장한 개념이다.
간단하게 얘기하면, 프로그래머라면 누구나 자신의 프로그램에 대한 애착을 가지고 있는데, 이 때문에 프로그램에 대한 비판을 받아들이지 못하는 것은 피해야한다는 것이다. 사실 프로그램 뿐만 아니라 지식 노동자의 모든 지적 작업의 결과물에는 이러한 경향이 있을 것이라고 생각한다.
팀 환경에서 프로그램에 대한 애착은 나쁜 영향을 미치게 된다. 코드가 아닌 사람을 향하는 비판 때문에 감정을 상하게 되고, 감정이 상할 까봐 비판을 하지 않게 되는 현상이 일어난다. 다른 사람의 잘못을 지적하기가 또는 받기가 두려워서 서로 협력하는 것에 미온적이거나 미루게 된다. 아예 협력하지 않기 위해서 했던 일을 새로 하기도 한다. 코드 리뷰나 회고 같은 활동도 정상적으로 할 수 없다.
이러한 문제는 Ego가 강한 한 개인의 문제라기보다는, 팀 문화의 문제라고 생각한다. 어떤 잘못이 있을 때 원인과 해결 방법에 집중해서 논의가 일어나기 보다는 그 사람의 성격 탓으로 돌리는 행위나 감정을 자극하는 언행들이 팀원 하나하나로부터 조금씩 보이면서 팀의 문화로 형성되는 경향이 있는 듯하다.
이를 방지하기 위해서는 팀 형성 초기 단계부터 세심하게 신경을 쓸 필요가 있다. 의식적으로 팀원의 언행을 살피고 Egoless Programming에 반하는 언행이 보일 경우, 그것을 바람직한 방향으로 수정해주는 것이 필요하다. 누군가가 잘못을 했을 때, 우리는 그에게 잘못을 추궁하는 것이 아니라 더 좋은 방법을 찾고 있다고 얘기해주어야 한다. 애초에 굳이 필요하지않다면 누구의 잘못인가를 공개적으로 찾아보는 행위도 나쁘다. 문제의 내용이 제대로 밝혀졌다면 누구의 실수 였는지는 고의적으로 모호하게 하는 방법도 생각해 볼 만하다. Egoless Programming에 익숙해질 수 있는 코드 리뷰나 회고 같은 활동도 유익한 것 같다. 실제로 코드 리뷰를 해보기 전엔 모두들 그것이 서로에게 감정적인 상처를 줄 것이라고 생각하지만, 적절하게 진행하기만 하다면, 그것이 자연스러울 수 있고 팀원들간의 신뢰를 높여줄 수 있는 방법임을 깨달을 수 있다.
신입 개발자일수록 팀이 어떻게 동작하는 것인지를 잘 이해하지 못하고 있으며 Ego도 강한 편이다. 이러한 점을 말로 지적하는 것도 필요하긴 하겠지만, 경험이 부족한 상태에서 주어진 규칙이란 것은 교장 선생님의 훈화 같은 것이나 다름없다. 오히려 권위가 있는 직책의 개발자나 경험이 많은 개발자가 모범을 보여주는 것이 좋은 것 같다. 그러한 것이 바로 잘 형성된 Egoless한 팀 문화다.
Ten Commandments of Egoless Programming이란 글은 Egoless Programming을 위한 좋은 가이드라인이니 읽어보기 바란다.