2012/07/05
몇 달 전 개발 방법론과 관련한 모임이 있었다. 모임 중 여러 주제로 의견을 나눴는데, 그중 프로세스에 대한 격렬한 논쟁이 있었다. 어떤 문제를 개선하기 위해 프로세스를 도입하자는 측과 도입하지 말자는 측의 의견 대립이 있었던 것이다. 이런 모임에서 여러 의견을 듣다 보면 프로세스에 대한 고민이 참 재밌게 느껴진다. 그래서 프로세스에 대한 경험이 많지 않음에도 개발자로 생활하며 자연스레 갖게 된 프로세스에 대한 여러 생각을 나눠볼까 한다.
어느 날 회사가 왜 프로세스를 만드는지에 대해 생각해 봤다. 다양한 생각을 하다 보니 내 나름의 결론에 이르게 되었다. 예를 들어 '쿼리 검수'라는 프로세스가 있다고 가정해 보자. 왜 생겼을까? 내가 속한 회사의 사례를 들면 좋을 것 같다.
내가 처음 입사했을 당시 회사에는 프로세스가 많지 않았다. 많은 팀이 각자가 선호하는 방법을 활용하여 서비스를 운영했다. 때로 장애가 발생하기도 했다. 고객이 피해를 입었고, 일을 잘하는 팀은 장애 대책을 스스로 고안하여 대응하곤 했다. 장애 중 자주 발생했던 것 중 하나는 느린 쿼리 문제였다. 예로 개발자가 실수해 인덱스를 사용하지 않는 쿼리가 배포되면 예외 없이 문제가 발생했었다.
여기부터는 나의 상상이 약간 들어간다. 어느 날 전사적 관점에서 문제를 바라보는 고위 관리자가 등장한다. 고위 관리자는 장애 기록을 보다 재밌는 사실을 알게 된다. 그동안 쿼리 때문에 장애가 많이 발생했다는 점이다. 중간 관리자를 불러 물어본다.
고위 관리자 : "왜 이렇게 쿼리 관련 장애가 많죠?" 중간 관리자 : "가끔 개발자가 쿼리를 잘못 작성해서 그렇습니다." 고위 관리자 : "이에 대한 대책을 마련해 주세요."
(대책 마련 후)
중간 관리자 : "앞으로 모든 쿼리 변경은 쿼리 검수라는 절차를 통해 실행될 것입니다. 이는 기존처럼 개발자의 실수로 장애가 발생할 확률을 줄이기 위함입니다."
내가 알기로 적지 않은 프로세스를 이런 계기로 만들었다. 쿼리 검수 프로세스는 가만히 생각해 보면 쿼리 작성에 있어 가장 실력 없는 개발자를 염두에 두는 것 같다. 다시 말해 말도 안 되는 수준의 쿼리가 작성되는 것을 막으려는 것이다. 좋다. 분명 필요한 것 같다. 그런데 혹시 이로 인해 잃어버린 것은 없을까?
프로세스가 도입된 후 개발자의 아우성이 커진다. 쿼리 검수를 받다가 힘들다고 느낀 어떤 개발자가 용기 내어 묻는다.
개발자 : "쿼리를 자주 수정하는데 이거 맨날 검수받아야 하나요?" 담당자 : "예, 받아야 합니다. 프로세스를 지키지 않으면 문제가 생길 시 문책을 받을 수 있습니다."
결국 개발자는 울며 겨자 먹기로 쿼리 검수를 받는다. 본인이 쿼리를 잘 작성하든 못 작성하든 예외가 없다. 잘하는 사람이라고 예외를 적용하기 시작하면 전체적으로 시행이 안 될 수 있기 때문이다. 따라서 소명할 수 있는 특별한 사유가 없는 한 모든 개발자는 쿼리 검수를 받는다.
여기 흥미로운 점이 하나 있다. 시간이 지나며 자연스레 개발자는 쿼리 작성이 본인의 주요 업무는 아니라고 생각하게 된다는 것이다. 왜냐하면 주도권과 책임이 본인에게 온전히 있지 않기 때문이다. 따라서 쿼리에 많은 시간을 들여 공부하기보다는 쿼리 작성에 필요한 최소한의 지식만을 유지하며 쿼리 검수에 의존하게 된다. 그래도 문제가 없다. 왜냐하면 잘못된 부분이 있으면 쿼리 검수를 받아 조언을 받고 그에 맞게 고치면 되기 때문이다. 또한 문제가 생겨도 이제는 쿼리 검수자의 잘못이 크다. 그렇다. 개발자는 더 이상 쿼리 전문가가 아니어도 되고, 더 이상 쿼리를 전적으로 책임지지 않아도 된다.
한편 팀은 순발력을 잃어버린다. 기존에는 쿼리 수정이 매우 자유로웠다. 따라서 서비스에 필요한 즉시 쿼리를 수정할 수 있었다. 하지만 이제는 쿼리에 문제가 있으면, 그게 사소한 수정이든 중요한 수정이든 프로세스에 따라 검수를 받아야 한다. 따라서 속도가 자연스레 떨어진다.
어떤 소신 있는 개발자는 생각한다. "이 정도 간단한 수정은 굳이 검수받을 필요가 없다. 이는 낭비다. 내가 책임지는 것으로 하고 그냥 검수 없이 쿼리를 수정해야겠다." 그런데 며칠 후 옆 팀의 누군가가 검수 없이 쿼리를 수정하다 장애를 냈다. 프로세스 미준수에 대한 심각한 메일이 도는 것을 보니 심상치 않다. 프로세스를 잘 지키는 게 필요하다는 쪽으로 생각이 바뀐다.
어떤 프로세스든 도입의 취지를 이해하는 개발자는 프로세스의 필요성을 어느 정도는 인정한다. 반면 어떤 개발자는 도무지 이해가 안 되고 인정도 하지 않는다. 이때 후자의 개발자는 답답함을 느낀다. 본인이 생각하기에 도움이 안 된다고 생각하는 프로세스를 맨날 준수하자니 비관적인 생각도 든다. 결국 프로세스의 배경을 이해하고 걸맞게 수행하기보다는 그냥 달리 수가 없으니 시키는 대로 하자는 심정으로 '형식적인 수행'을 하게 된다. 그럼 어떤 일이 발생할까? 아마 프로세스를 만들 당시의 기대와는 달리 프로세스가 '동작하지 않을 것'이다.
어떤 분은 프로세스 준수를 아이가 손 닦는 것으로 비유한다. 좋은 비유라 생각하여 얘기거리로 사용해 보려 한다.
어떤 어린아이가 있다. 이 아이는 맨날 밖에서 온갖 더러운 것을 만지며 놀다 저녁에 들어온다. 부모는 아이의 위생이 염려된다. 따라서 아이에게 한 가지 규칙을 강제하기로 한다. "너는 항상 밖에 나갔다 들어오면 예외 없이 손을 닦아야 한다. 화장실에 들어갔다 나오지 않으면 방에 들어갈 수 없어."