Error rendering WebPanel: No renderer found for resource type: velocity Template contents: <meta name="ajs-keyboardshortcut-hash" content="$keyboardShortcutManager.shortcutsHash">
메타 데이터의 끝으로 건너뛰기
메타 데이터의 시작으로 이동

동작하지 않는 프로세스 글을 읽고 든 첫번째 생각은 참 우리 민창이 많이 성장했구나였다. 경험을 통해 생각의 깊이가 묻어 나는 것을 느낀다. 또한 자신이 가지고 있는 생각을 글로 정리해 다른 사람을 설득하는 능력 또한 뛰어나다고 생각한다. 난 민창과 1년 이상 일해보지는 못했지만 다른 형태로 많은 이야기를 나눈 관계로 어떤 생각을 가지고 이 글을 썼는지, 이 글을 쓸 때의 목적은 무엇이었는지 대략적으로 짐작할 수 있다. 개인적으로 그 사람을 알고 있을 때 그 사람이 전하고자 하는 바가 무엇인지를 알 수 있다는 것은 더 없이 좋은 듯하다.

난 민창처럼 차분하게 정리해서 글을 쓰기 보다는 민창의 글을 읽으면서 느낀 점을 짧막하게(질문) 남겨 본다.

이 글의 마지막 문장을 보면 다음과 같이 마무리하고 있다.

이 의견에 나 또한 동의한다. 하지만 프로세스를 좋아하지 않는다는 의견에 지금까지 내 경험을 덧붙여 보고 싶다. 나 또한 내가 한 팀의 팀장이 되고, 프로젝트를 리딩하기 전까지 프로세스를 좋아하지 않았다. 프로세스를 적용한다면 일단 배격하는 자세를 취하는 것이 다반사였다. 하지만 지금은 그 때와는 다른 생각을 하고 있어 공유해보고 싶다. 프로세스를 그렇게 거부할 필요는 없다는 것이 지금의 생각이다. 이렇게 이야기하면 "개발자의 자유로운 영혼을 구속하려고 하는 것을 보니 너도 이제 관리자가 다 됐구나."라고 비꼬는 사람들이 반드시 있다. 한 때 나도 그랬으니까. 비꼬더라도 상관없다. 나는 그 때와 다른 생각을 하고 있기 때문에 내 이야기를 공유할 뿐이니까. 다르다고 생각하면 이 글에 대한 반론으로 제시해 주면 좋겠다.

나는 이와 관련해 프로세스라는 용어에 대해서 각자가 가지고 있는 생각이 다르기 때문에 발생한다고 본다. 프로세스라는 용어가 남용되는 것 또한 사실이다. 프로세스라는 서로의 경험이 다른 상태에서 논의를 하게 되면 결국에는 감정 싸움으로 번지게 된다. 나는 프로세스를 실무를 담당하는 담당자들에 자발적으로 만들어지는 프로세스(자의적 프로세스)와 다른 사람, 다른 조직에 의해 전사적으로 적용되는 프로세스(타의적 프로세스)로 나누어 판단해야 한다고 생각한다.

사람이 모여 일을 하려면 서로 간의 약속이 필요하다. 그렇지 않으면 반복적인 작업이 발생하고, 반복적인 이슈와 버그가 발생하는 것이 일반적이다. 우리가 무슨 방법론이나 프로세스를 적용하기 전이더라도 서로 간의 약속을 통해 업무를 진행할 수 밖에 없다. 나는 서로가 지켜야할 이 약속, 원칙들이 프로세스라 생각한다. 그리고 단순, 반복적인 작업을 반복하다보면 조직 자체적으로 원칙을 만든다. 이와 같이 조직의 요구에 의해서 자발적으로 만들어지는 원칙들은 반드시 있어야 하며, 이 원칙들을 지킬 때 업무를 좀 더 효율적으로 진행할 수 있다고 생각한다.

경험이 적었을 때는 내가 진행하는 방식과 업무에 조금이라도 다른 형태의 제안을 하면 무조건 거부 반응을 일으켰다. 그런데 경험이 쌓이면 쌓일 수록 서로 간에 지켜야 할 원칙을 만들어야 한다는 생각이다. 프로젝트를 효율적으로 진행하기 위해 이 같은 원칙을 지킬 때 나에게 더 많은 시간이 생겼으며, 내가 정말 하고 싶은 일에 더 많은 시간을 투자할 수 있다는 것을 느끼고 있다. 원칙이 없는 상태에서 프로젝트를 하다 보면 중요하지 않은 부분에 많은 시간을 할애하는 경험을 종종 하게 된다. 예를 들어 버전 관리 시스템을 사용하고, 버전 관리 시스템에 소스 코드를 커밋할 때는 커밋 로그를 반드시 적는다는 원칙들 말이다. 나는 이 같은 원칙들이 프로세스라 생각한다.

문제의 본질은 이 프로세스가 조직의 필요에 의해서 자의적으로 만들어지고 개선되어 가느냐, 그렇지 않고 다른 목적 때문에 전사적으로 만들어지고 표준화된 후에 타의적으로 적용되느냐의 문제라고 생각한다. 항상 문제는 타의에 의해서 강제적으로 지켜야 하는 원칙들에서 발생한다. 물론 최초에는 잘 맞았을 수도 있으나 각 조직에 적용하면서 상황에 따라 변화 발전해야 하는데 국내의 많은 소프트웨어 조직에서는 일단 적용한 후에 원칙은 바뀌지 않는다. 즉, 각 조직의 다양성을 인정하지 않는다는 것에서 발생하는 것은 아닐까라는 생각을 한다.

시간이 지날 수록 프로젝트의 복잡도는 증가하고 협업 비용도 많이 발생하고 있다. 이런 상황에서 각 조직마다 지켜야할 기본적인 원칙은 반드시 있어야 한다. 원칙들은 시간이 지나면서 하나씩 추가되고 발전되어가는 것을 느꼈다. 하지만 이 같은 발전은 각각의 조직이 자발적으로 개선해 나갈 때 성공할 수 있다. 다른 사람에 의해서 강제적으로 적용해야 하는 타의적 프로세스는 성공하기 힘들다. 따라서 너무 전사적으로 표준을 만들어 적용하는데 초점을 맞추지 말고 각 조직의 다양성을 인정해 주면서 자신들에게 맞는 원칙들을 하나씩 만들어가는 것이 가장 바람직한 모습이라고 생각한다. 이 같은 원칙들이 모이면 그 자체가 하나의 프로세스가 될 것이다. 동작하지 않는 프로세스 글에서 이야기하고자 하는 핵심은 프로세스를 거부하는 것이 아니라 타의적 프로세스에 의해 최초 의도했던 효과를 보지 못함에 대한 문제제기라 생각한다.

나는 강력하게 추천하고 싶다. 자신들만의 원칙들을 만드는 노력을 지금부터 시작하라고.. 서로가 지켜야할 원칙들을 조직원의 동의하게 만들어 간다면 지금까지 생각하지 못했던 형태로 일할 수 있다는 것을 느낄 때가 올 것이라고 이야기하고 싶다. 그런 상태가 되었을 때 진정 즐겁게 일할 수 있지 않을까라고 조심스럽게 제안해 본다.