몇달 전 개발 방법론과 관련한 모임이 있었다. 모임 중 여러 주제로 의견을 나눴는데, 그 중 프로세스에 대한 격렬한 논쟁이 있었다. 어떤 문제를 개선하기 위해 프로세스를 도입하자는 측과 도입하지 말자는 측의 의견대립이 있었던 것이다. 이런 모임에서 여러 의견을 듣다보면 프로세스에 대한 고민이 참 재밌게 느껴진다. 그래서 프로세스에 대한 경험이 많지 않음에도 개발자로 생활하며 자연스레 갖게 된 프로세스에 대한 여러 생각을 나눠볼까한다. 

1. 어떤 프로세스가 생기는 과정

어느 날 회사가 왜 프로세스를 만드는지에 대해 생각해봤다. 다양한 생각을 하다보니 내 나름의 결론에 이르게 되었다. 예를 들어 '쿼리 검수'라는 프로세스가 있다고 가정해보자. 왜 생겼을까? 내가 속한 회사의 사례를 들면 좋을 것 같다. 내가 처음 입사했을 당시 회사에는 프로세스가 많지 않았다. 많은 팀이 각자가 선호하는 방법을 활용하여 서비스를 운영했다. 때로 장애가 발생하기도 했다. 고객이 피해를 입었고, 일을 잘하는 팀은 장애 대책을 스스로 고안하여 대응하곤 했다. 장애 중 자주 발생했던 것 중 하나는 느린 쿼리 문제였다. 예로 개발자가 실수해 인덱스를 사용하지 않는 쿼리가 배포 되면 예외 없이 문제가 발생했었다.

여기부터는 나의 상상이 약간 들어간다. 어느 날 전사적 관점에서 문제를 바라보는 고위 관리자가 등장한다. 고위 관리자는 장애 기록을 보다 재밌는 사실을 알게된다. 그동안 쿼리 때문에 장애가 많이 발생했다는 점이다. 중간 관리자를 불러 물어본다.

고위 관리자 : '왜 이렇게 쿼리 관련 장애가 많죠?'
중간 관리자 : '가끔 개발자가 쿼리를 잘못 작성해서 그렇습니다.',
고위 관리자 : '이에 대한 대책을 마련해 주세요.'

(대책 마련 후)


중간 관리자 : '앞으로 모든 쿼리 변경은 쿼리 검수라는 절차를 통해 실행될 것입니다. 이는 기존처럼 개발자의 실수로 장애가 발생 할 확률을 줄이기 위함입니다.


내가 알기로 적지 않은 프로세스를 이런 계기로 만들었다. 쿼리 검수 프로세스는 가만히 생각해보면 쿼리 작성하는 데 있어 가장 실력 없는 개발자를 염두에 두는 것 같다. 다시 말해 말도 안 되는 수준의 쿼리가 작성되는 것을 막으려는 것이다. 좋다. 분명 필요한 것 같다. 그런데, 혹시 이로인해 잃어버린 것은 없나?

2. 프로세스 도입으로 잃어버린 것

프로세스가 도입된 후 개발자의 아우성이 커진다. 쿼리 검수를 받다가 힘들다고 느낀 어떤 개발자가 용기내어 묻는다.

개발자 : '쿼리를 자주 수정하는 데 이거 맨날 검수 받아야 하나요?',  
담당자 : '예, 받아야 합니다. 프로세스를 지키지 않으면 문제가 생길 시 문책을 받을 수 있습니다.'


결국 개발자는 울며 겨자먹기로 쿼리 검수를 받는다. 본인이 쿼리를 잘 작성하던 못 작성하던 예외가 없다. 잘하는 사람이라고 예외를 적용하기 시작하면 전체적으로 시행이 안될 수 있기 때문이다. 따라서 소명할 수 있는 특별한 사유가 없는 한 모든 개발자는 쿼리 검수를 받는다. 여기 흥미로운 점이 하나 있다. 시간이 지나며 자연스레 개발자는 쿼리작성이 본인의 주요업무는 아니라고 생각하게 된다는 것이다. 왜냐하면 주도권과 책임이 본인에게 온전히 있지 않기 때문이다. 따라서 쿼리에 많은 시간을 들여 공부하기 보다는 쿼리 작성에 필요한 최소한의 지식만을 유지하며 쿼리 검수에 의존하게 된다. 그래도 문제가 없다. 왜냐하면 잘못 된 부분이 있으면 쿼리 검수를 받아 조언을 받고 그에 맡게 고치면 되기 때문이다. 또한 문제가 생겨도 이제는 쿼리 검수자의 잘못이 크다. 그렇다. 개발자는 더 이상 쿼리전문가가 아니어도 되고, 더 이상 쿼리를 전적으로 책임지지 않아도 된다.

한편 팀은 순발력을 잃어버린다. 기존에는 쿼리 수정이 매우 자유로웠다. 따라서 서비스에 필요한 즉시 쿼리를 수정할 수 있었다. 하지만 이제는 쿼리에 문제가 있으면 그게 사소한 수정이든 중요한 수정이든 프로세스에 따라 검수를 받아야 한다. 따라서 속도가 자연스레 떨어진다. 어떤 소신 있는 개발자는 생각한다. '이 정도 간단한 수정은 굳이 검수 받을 필요가 없다. 이는 낭비다. 내가 책임지는 것으로 하고 그냥 검수 없이 쿼리를 수정해야겠다.' 그런데 몇일 후 옆 팀의 누군가가 검수 없이 쿼리를 수정하다 장애를 냈다. 프로세스 미준수에 대한 심각한 메일이 도는 것을 보니 심상치 않다. 프로세스를 잘 지키는 게 필요하다는 쪽으로 생각이 바뀐다.
 

어떤 프로세스든 도입의 취지를 이해하는 개발자는 프로세스의 필요성을 어느정도는 인정한다. 반면 어떤 개발자는 도무지 이해가 안 되고 인정도 하지 않는다. 이 때 후자의 개발자는 답답함을 느낀다. 본인이 생각하기에 도움이 안 된다고 생각하는 프로세스를 맨날 준수하자니 비관적인 생각도 든다. 결국 프로세스의 배경을 이해하고 걸맞게 수행하기 보다는 그냥 일단 달리 수가 없으니 시키는 대로 하자라는 심정으로 '형식적인 수행'을 하게 된다. 그럼 어떤 일이 발생할까? 아마 프로세스를 만들 당시의 기대와는 달리 프로세스가 '동작하지 않을 것'이다.

3. 동작하지 않는 프로세스

어떤 분은 프로세스의 준수를 아이가 손 닦는 것으로 비유한다. 좋은 비유라 생각하여 얘기거리로 사용해보려 한다. 어떤 어린아이가 있다. 이 아이는 맨날 밖에서 온갖 더러운 것을 만지며 놀다 저녁에 들어온다. 부모는 아이의 위생이 염려된다. 따라서 아이에게 한 가지 규칙을 강제하기로 한다. '너는 항상 밖에 나갔다 들어오면 예외 없이 손을 닦아야 한다. 화장실에 들어갔다 나오지 않으면 방에 들어갈 수 없어.' 아이는 할 수 없이 밖에 나갔다 오면 항상 화장실에 들어간다. 하지만 아이는 손 닦는 것이 너무 싫기 때문에 화장실에 들어가 물을 틀고 손에 물을 살짝 묻힌 후 바로 밖으로 나온다.

아이는 부모가 정한 규칙을 지켰다. 하지만 이게 정말 부모가 바랬던 것일까? 의학적으로 맞는지는 모르겠지만 아이가 손에 물만 살짝 묻힘으로 손에 있는 세균이 더 번성했다고 가정해보자. 만약 그렇다면 부모가 기대했던 손닦기 효과는 오히려 역효과를 낸 셈이다. 아이에게 강제하고, 화장실에 들어가는 시간을 낭비했으며, 물을 사용했지만 위생이 오히려 더 안 좋아진 것이다. 한 발자국 물러나 세균이 들어가기 전 그대로라고 가정해보자. 그렇다면 좋은 것인가? 역시 아니다. 이는 투자대비효과가 나오지 않는 것이다. 왜냐하면 화장실에 들어간 노력과 물이라는 자원을 사용했음에도 그 결과가 없기 때문이다. 실제로 부모는 최소한 손이 조금이나마 깨끗해지기를 바랬지만 이는 전혀 달성되지 않았다.

내 생각에는 아이의 행동을 통해 볼 수 있는 모습 회사에서도 보이는 것 같다. 어느 정도의 비효율성(밖에 나갔다 오면 손이 더렵냐에 관계없이 무조건 손을 닦아야 함)을 감수하고 프로세스를 도입했지만 프로세스 준수자(아이)는 프로세스를 형식적(
손 닦는 시늉만 함)으로 수행하여 별 이득(물만 살짝 묻혀 여전히 손이 더러움)이 없게 한 것이다.

4. 프로세스의 개선

그럼 어떻게 하자는 얘기인가? 긍적적으로 생각해보면 이런 상황은 뭔가 다른 방법을 시도해볼 좋은 기회라고 본다. 여러 방법이 있을 것 같다. 아이에게 왜 손을 닦아야만 하는지 차근 차근 설명할 수도 있고, 아이가 손을 정말 잘 닦는지 엄하게 감시할 수 있다. 어쩌면 아이가 스스로 필요성을 느낄 때까지 손 닦는 문제에 관한 자율권을 줄 지도 모른다. 어떤 방법이든 장단점이 있을 것이다. 중요한 것은 아이를 관찰하고 본래의 목적을 달성하지 못한다면 변화를 주어야 한다는 것이다.

어떤 변화를 줄지 결정할 때 중요한 것은 투자대비효율에 근거한 판단이라고 생각한다. 아이에게 설명해주는 것이 유리할지, 아니면 얘기해봤자 소용없으니 아이에게 자율성을 부여하고 인내하며 물과 시간을 아낄지 등에 대해서다. 그런데 이런 부분을 판단하기 전에 반드시 아이와 진지한 대화가 필요하다고 생각한다. 아이의 현재 상황과 심정을 물어봐야 하는 것이다. 그냥 아이가 보여주는 단편적인 모습만 보고 일방적으로 무엇인가를 하면 잘못된 결정을 할 확률이 높다고 생각한다.

5. 상황(Context)에 따른 프로세스의 적용

쿼리검수의 예에서 볼 수 있듯이 프로세스는 최저의 수준을 보장하는 데 초점을 맞출 때가 많다. 이로 인해 비효율이 발생한다. 쿼리 작성 수준이 높은 개발자도 쿼리 검수를 받아야 하고 결국 순발력에 부정적 영향을 받기 때문이다. 하지만 이런 손해가 있어도 우리가 유지보수하는 서비스가 크다면 이는 합리적이라 할 수 있다. 왜냐하면 각 부분별로 촘촘히 정의 된 쿼리 검수 같은 프로세스가 서비스가 신중한 발걸음을 내딛으며 적정 품질을 유지하는 데 도움이 되기 때문이다. 하지만 만약 다양한 상황이 존재한다면 얘기가 달라진다. 예로 회사 내 다른 어떤 서비스는 시장상황에 기민하게 대응하는 것이 필요하다고 가정해보자. 이런 서비스는 어떻게 해야하는가? 이미 잘 뿌리내린 모든 프로세스를 도입해야 하는가? 

방금 전의 의문은 축구의 포매이션의 비유를 통해 얘기해보면 좋을 것 같다. 축구에는 다양한 포매이션이 있다. 4-4-2, 3-4-3 등. 아마 축구에 관심이 있다면 누구나 한번쯤은 들어보았을 것이다. 보통 4-4-2는 사람들이 매우 공격적인 전술이라 얘기한다. 공격 시 수비수 2명을 제외한 모든 선수가 공격을 할 때가 잦기 때문이다. 반면 3-4-3은 4-4-2에 비해 비교적 수비적인 전술이다. 공격 시에도 수비 3명은 항상 자리를 지킨다. 재밌는 점은 대부분 감독이 하나의 포매이션만을 고집하지 않는다는 점이다. 강팀을 만나면 수비수를 늘려 수비적인 전술로 싸우다가도, 약팀을 만나면 공격수를 늘리며 공격적인 전술로 싸운다. 약팀이라 생각해 공격적으로 나서다가도 거세게 공격당하면 수비적으로 금새 변하기도 한다.

나는 회사의 프로세스도 축구의 포매이션을 닮으면 어떨까 생각을 해본다. 즉, 서비스의 상황에 따라 프로세스를 유연하게 조정할 수 있었으면 좋겠다는 얘기다. 예를 들어 무엇보다 순발력이 절실히 필요한 서비스에는 쿼리 검수 프로세스를 제거하고 쿼리에 관한 모든 것을 개발자에게 전적으로 맡길 수 있을 것이다.

6. 유연한 프로세스 적용의 어려움

그렇지만 유연함은 갑자기 생기진 않는 것 같다. 평소에 스트레칭을 안 하던 사람이 유연하기로 마음 먹었다고 해도 관절이 말을 듣지 않는 것처럼, 회사에서도 이런 일이 생길 것이라 생각한다. 예를 들어 무거운 프로세스 하에서만  5년 이상 일한 팀이 있다고 가정해보자. 갑작스런 시장상황의 변화로 신규 서비스를 최대한 빠르게 출시하는 것이 필요하다. 회사에서는 힘을 실어주기 위해 이미 정의 된 프로세스는 신경쓰지 말고 마음껏 해보라고 한다. 이 때 해당팀이 정말 기민하게 반응할 수 있을까?

사실 난 이런 문제에 관한 충분한 실례를 알지 못한다. 하지만 축구를 보면서 이런 일을 예측해본다. 히딩크가 2002년 한국에 왔을 때 공격적인 전술인 4-4-2 포매이션을 정착시키려 했다. 하지만 우리나라 선수 대부분은 4-4-2에는 익숙하지 않았고, 4-4-2 포매이션으로 경기할 때 히딩크가 원하는 만큼의 경기력을 보이지 못했다. 월드컵 전 결국 히딩크는 4-4-2 포매이션을 완전히 포기했다. 반면 유럽의 어떤 팀들은 만나는 상대팀에 따라 포매이션을 변경한다. 그 팀은 어떤 포매이션을 사용해도 일정수준 이상의 경기력을 보인다.

그렇다면 4-4-2를 잘 소화화지 못했던 2002년의 한국팀과 다양한 포매이션을 자유롭게 변경하는 유럽팀과의 차이점이 뭘까? 난 축구 전문가는 아니지만 팀 구성원의 경험도 가장 크게 작용했으리라 생각한다. 여러 포매이션에서 성공적인 경기를 치뤄본 선수는 이후에도 해당 포매이션에 관한 경험과 이해를 바탕으로 여러 포매이션에서 본인의 능력을 십분 발휘할 수 있으리라 생각한다. 반면 여러 포매이션에 관한 경험과 이해가 부족한 선수는 새로운 포매이션에서 경기하게 되면 온전한 능력을 발휘하지 못할 것이다. 그래서 난 앞서 시장상황에 빠르게 대응하고 싶었던 그 팀 역시 무거운 프로세스에서만 5년 이상 일했던 경험으로 인해 기민함을 확보하는 데 어려움울 겪지 않을까 생각해본다.

7. 결론 및 요약

프로세스는 잘 활용하면 체계적으로 일하기 위한 좋은 도구가 될 수 있다고 생각한다. 하지만 도입배경에 대한 이해 없이 무조건 프로세스를 준수하는 상황이 보이면 신중히 원인을 조사해 해결방법을 모색해야 한다고 본다. 또한 단 하나의 프로세스 체계를 고집하기 보다는 유연한 프로세스 체계가 있으면 어떨까 생각해본다. 예를 들어 순발력이 중요할 때를 위한 프로세스와, 신중한 운영이 중요할 때를 위한 프로세스와 같이 말이다. 하지만, 이런 유연한 프로세스의 적용을 위해서는 구성원이 충분히 훈련되어 있어야 한다고 본다. 

지극히 개발자로써 개인적인 의견을 솔직히 밝히자면 난 프로세스를 별로 좋아하지 않는다. 일을 할 때 항상 프로세스가 걸리적 거리고 답답할 때가 많다. 난 예전 서버든 보안이든 DB든 개발자가 모두 책임지고 관리하던 시절이 그립다. 그 때는 내가 원하는 만큼 속도를 낼 수 있었고, 개발자로써 배우는 것도 훨씬 많았다.


* 관련 글 

자의적 프로세스와 타의적 프로세스 

 



WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

트랙백  0 , 댓글  3개가 달렸습니다.
  1. 좋은 글 잘 보았어요.
    프로세스는 배움에 수동적인 개발자들을 위한 것이 아닐까 생각해 봅니다. ^^
  2. 좀 뜬금없는 이야기이긴 하지만...

    쿼리 장애에 대한 대책으로 생각하는 것이 일반적으로 쿼리 검수가 될텐데...
    그런 프로세스 보다 자동화를 도입하는 것은 어떨까?
    소스 저장소를 폴링 하고 있다가 쿼리들이 수정된 사항이 발생하면 덤프 DB에서 한번씩 돌려보고 특정 수행시간을 확인해볼 수 있을 것 같아.

    일반적으로 무언가 조심해야 할 것들이 있다면 항상 대책 시간이 제일 적게 들어가는 방법인 프로세스를 선택하게 되는 것 같아.
    "당장 내일 부터 이런 장애 없도록 해!" 라고 고위 관리자가 요구한다면
    중간 관리자는 당연히 프로세스 도입이요~

    좋은 글에 엉망인 댓글을 남기고 간다
  3. 저도 프로세스를 좋아하지 않습니다. 정확히는 맹목적인 프로세스를 좋아하지 않습니다. 저는 프로세스를 능동적 협업이라는 프로세스를 좋아 합니다. 프로세스는 어찌보면 딱딱한 사람의 관계 속에서 협업을 하는 것입니다. 쿼리 검수라는 프로세스를 보면 dba님 이렇게 쿼리 작성했어요 검토해서 주세요. 개발자님 이렇게 변경 했어요. 이렇게 쓰세요. 사람 간의 액티비티가 있지만 시너지가 없는 활동 입니다. 사람 간의 액티비티가 있다면 그 액티비티에서 지식도 전달되고 아이디어도 개선도 논의도 나와야 합니다.

    그렇기에 프로세스라는 용어에 집중하지 말고 협업자 간에 긴밀한 유대관계 - 놀고 하는 것이 아닌 업무적 유대관계 - 를 쌓도록 하고 그것을 기반으로 속도를 낼 수 있도록 하는 것이 서비스 개발이 아닐까 합니다. 그리고 그것이 우리가 원하는 프로세스가 아닐까 합니다.
secret