<div id="readability-page-1" class="page"><article>
        <p>최근 IT 기업에서 개발자들을 모시기 위한 경쟁이 치열해지고 있다. 개발자들이 회사를 선택할 때 보는 요소 중에 금전적인 부분도 중요한 요소 중의 하나일 수는 있겠지만 좋은 개발문화를 가지고 있는지도 개발자들에게 중요한 관심사 중의 하나이다. 좋은 개발 문화에서 일할 때 개발자로서의 높은 성장도 기대할 수 있다고 믿기 때문이다. 그렇기 때문에 회사들은 몸값 경쟁 이외에도 회사의 개발문화를 홍보하기 위한 노력도 많이 기울이고 있다.<br>근데 좋은 개발문화라는 것은 무엇일까? 애자일 프로세스를 적용하고 있다든지, 코드 리뷰를 한다든지, 회고를 한다든지와 같은 몇 가지 활동만을 보고 판단하기에는 참 모호한 부분이 많다. 내부에서 개발문화를 발전시키려고 하는 입장에서는 더욱 그렇다. 어떤 것을 시도하면 좋은 개발문화로 향하는 것인지 판단하기가 쉽지 않다.<br>그런 면에서 IT 업계에서도 <a target="_blank" rel="noopener" href="https://ko.wikipedia.org/wiki/%EB%8A%A5%EB%A0%A5_%EC%84%B1%EC%88%99%EB%8F%84_%ED%86%B5%ED%95%A9_%EB%AA%A8%EB%8D%B8">CMMi</a> 나 <a target="_blank" rel="noopener" href="https://ko.wikipedia.org/wiki/ISO/IEC_15504">SPICE</a> 같은 성숙도 모델을 만들고 해당 모델에 기반하여 수준을 높이려는 노력을 하기도 했다. 오늘은 이러한 모델 중 QSM1 에서 설명하는 6가지 문화 패턴을 소개하고 내 생각을 함께 적어보고자 한다.</p>
<ol start="0">
<li>Oblivious: “우리는 프로세스를 수행하고 있다는 사실조차 모른다.”</li>
<li>Variable: “우리는 그 순간에 좋다고 느끼는 것을 수행한다.”</li>
<li>Routine: “우리는 루틴을 따른다(패닉에 빠질 때를 제외하고).”</li>
<li>Steering: “우리는 결과에 따라 우리의 루틴들 중 하나를 선택한다.”</li>
<li>Anticipating: “우리는 과거에 경험한 루틴에 기반하여 루틴들을 수립한다.” </li>
<li>Congruent: “모든 사람은 항상 모든 것을 개선하는데 참여한다.”</li>
</ol>
<p>6가지의 종류라고는 했지만, 현실적으로 보여지는 패턴은 3까지라고 한다. </p>
<h2 id="패턴0-Oblivious"><a href="#패턴0-Oblivious" title="패턴0: Oblivious"></a>패턴0: Oblivious</h2><p>패턴 0 은 기업 안에 별도의 소프트웨어 개발 조직이 존재하지 않으며, 본인이 “소프트웨어 개발”을 하고 있다는 사실조차 인지 못한 채 소프트웨어 개발을 하고 있는 상황이다. 예를 들어 엑셀에 능숙한 어떤 직원은 lookup 테이블이나 VBA를 활용하여 고객을 관리하고 시각화하는 일을 처리하고 있지만 이러한 업무가 소프트웨어 개발과 관련성이 있다고 인지하지 못한다.</p>
<h2 id="패턴1-Variable"><a href="#패턴1-Variable" title="패턴1: Variable"></a>패턴1: Variable</h2><p>이 패턴에서의 이미지는 “슈퍼 개발자”이다. “슈퍼 개발자”가 모든 문제를 해결해줄 것이라고 믿고 있으며 나머지 개발자들은 “슈퍼 개발자”를 서포트하기 위해 존재한다. 초기 스타트업에서 자주 보이는 패턴으로 창업 때부터 기여한 “슈퍼 개발자”가 존재하며 조직이 커져 새로운 문제가 발생되더라도 새로운 “슈퍼 개발자”가 나타나 문제를 해결해주기를 기대한다. 패턴1 에서의 성과는 전적으로 개인의 노력에 의존하기 때문에 일정과 비용의 변동성은 개인의 변동성에 달려있으며 특히 “슈퍼 개발자”의 일정에 대한 의존도가 크다. 개인을 대상으로 한 연구에서 일정, 비용, 오류 등에 대한 변동 수준은 지속적으로 20배 이상의 변동을 보여왔기 때문에 그와 같은 리스크를 지니고 있다고 볼 수 있다. </p>
<p>개인적으로 이 조직이 변화하기 어려운 이유 중에 하나는 조직 내 높은 영향력을 가지고 있는 “슈퍼 개발자”가 변화를 원치 않는 경우가 많기 때문 인 것 같다. 사실 개발자라면 누구나 한번쯤은 빠르고 멋지게 기능을 만들어서 인정받고 싶은 욕구가 있을 것이다. 그러나 인정받고 싶은 욕구로 인해 한 행동들이 조직 차원에서 안좋은 결과를 가지고 온다는 것을 인지하는 경우는 드물다.</p>
<p>이 패턴에서의 다른 특징은 서로가 무슨 일을 하고 있는지 잘 모르며, 팀의 표준환경이나 개발도구도 없이 제각각 사용하게 된다. 이 패턴에서 사람들이 요구하는 것들은 일반적으로 다음과 같다. </p>
<ul>
<li>“무엇을 원하는지 명확하게 말해달라(그리고 나중에 바꾸지 말아달라)”</li>
<li>“우리가 필요로 하는 자원을 제공해달라(그리고 우리가 요청할 때마다 계속 지원해달라)”</li>
<li>“우리를 귀찮게 하지 말아달라(모든 불확실성을 제거해달라)”</li>
</ul>
<h2 id="패턴2-Routine-but-Unstable"><a href="#패턴2-Routine-but-Unstable" title="패턴2: Routine(but Unstable)"></a>패턴2: Routine(but Unstable)</h2><p>이 패턴에서의 이미지는 “슈퍼 관리자”이다. 패턴 1에서 조직이 커지기 시작하면서 개발자들 개개인을 관리할 필요성이 있다고 느껴질 때 발생한다. 이 패턴 의 관리자는 패턴 1의 “슈퍼 개발자”가 자연스럽게 맡는 경우가 많은 것 같다. 다만 개발을 잘 하는 것과 관리를 잘하는 것은 다른 영역이기 때문에 많은 문제가 생기게 된다. 일반적으로 본인의 경험을 기준으로 지나친 일반화를 하는 경우가 많으며, 거기에서 발생되는 예외를 무시하고 정해진 루틴을 그대로 수행하려고 하는 경우가 많다. 그러다 문제가 크게 터지면 다시 패턴1 로 회귀하게 되는 경우도 발생된다. </p>
<p>패턴2에서 잘못된 확신성을 가지게 되는 이유 중 하나는 핵심 사고 패턴이 선형적이기 때문이다. 어떠한 결과는 하나의 원인에서 기인한다는 생각을 가지고 있는데 이러한 오해에서 나온 해결책은 단기적으로는 문제가 해소된 것처럼 보이나 장기적으로 더 큰 문제를 가져오는 경우가 많다.</p>
<h2 id="패턴3-Steering"><a href="#패턴3-Steering" title="패턴3: Steering"></a>패턴3: Steering</h2><p>패턴3의 관리자는 패턴2의 관리자에 비해 좀 더 전문성을 가지고 있다. 패턴2의 관리자는 “말로 하는 관리” 이외에 별다른 기술을 가지고 있지 않은 경우가 많다. 패턴3의 관리자는 다양한 기술을 기반으로 상황에 맞는 대처를 할 수 있다. 불확실성이 적은 상황에서는 패턴2의 관리자와 큰 차이가 없이 느껴질 수 있기 때문에 종종 패턴2에서 일이 잘 풀리면 패턴3로 착각하기 쉽다고 한다. 둘 다 계획된 절차를 사용하지만 패턴3 에서만이 계획에서 벗어난 상황에서 효과적으로 대응하는 방법을 알고 있다고 한다. </p>
<h2 id="패턴4-Anticipating"><a href="#패턴4-Anticipating" title="패턴4: Anticipating"></a>패턴4: Anticipating</h2><p>패턴4의 관리자는 패턴3와 비슷하지만 품질관리에 대해 더 높은 수준의 이해를 가졌다고 한다. </p>
<h2 id="패턴5-Congruent"><a href="#패턴5-Congruent" title="패턴5: Congruent"></a>패턴5: Congruent</h2><p>패턴5는 최고 수준의 품질 관리를 유지한다고 하며 품질 관리를 회사 시스템의 필수 부분으로 간주한다고 한다. 패턴5의 조직은 구성원들이 프로세스의 지속적인 개선과 최적화에 기여할 수 있는 기반을 제공하며 구성원들은 항상 모든 것에 개선하는데 기여한다고 한다.</p>
<p>위의 6가지 패턴 중 내가 속한 조직의 문화 패턴은 어디에 속해있다고 생각하는가? 일반적인 IT 기업이라면 1-3의 패턴을 가지고 있을 것이다. 얼핏 보기에 아래로 갈 수록 더 좋은 문화라고 볼 수 있을 것 같지만 사실 어느 한쪽이 꼭 우월하다고 볼 수는 없다. 조직의 규모나 상황에 따라 적절한 패턴이 존재하는데 이러한 패턴을 인지하고 조직의 변화에 따라 적절하게 변화를 할 수 있는지가 중요할 것 같다. 3-4명으로 시작한 스타트업에서는 패턴1이 충분할 수 있지만 스타트업이 성공해서 100명 이상의 규모로 성장했음에도 불구하고 여전히 패턴1을 벗어나지 못하는 경우도 많이 보아왔다. 이들은 과거에 성공한 경험을 가지고 있기 때문에 변화의 필요성을 받아들이기 어렵게 되고 그렇게 정체되거나 도태되는 상황을 겪기도 한다. </p>
<p>다음에는 패턴을 변화하기 위해 필요한 것이 무엇인지 다뤄보도록 하겠다.</p>

    </article></div>

wonderland

최근 IT 기업에서 개발자들을 모시기 위한 경쟁이 치열해지고 있다. 개발자들이 회사를 선택할 때 보는 요소 중에 금전적인 부분도 중요한 요소 중의 하나일 수는 있겠지만 좋은 개발문화를 가지고 있는지도 개발자들에게 중요한 관심사 중의 하나이다. 좋은 개발 문화에서 일할 때 개발자로서의 높은 성장도 기대할 수 있다고 믿기 때문이다. 그렇기 때문에 회사들은 몸값 경쟁 이외에도 회사의 개발문화를 홍보하기 위한 노력도 많이 기울이고 있다.
근데 좋은 개발문화라는 것은 무엇일까? 애자일 프로세스를 적용하고 있다든지, 코드 리뷰를 한다든지, 회고를 한다든지와 같은 몇 가지 활동만을 보고 판단하기에는 참 모호한 부분이 많다. 내부에서 개발문화를 발전시키려고 하는 입장에서는 더욱 그렇다. 어떤 것을 시도하면 좋은 개발문화로 향하는 것인지 판단하기가 쉽지 않다.
그런 면에서 IT 업계에서도 CMMi 나 SPICE 같은 성숙도 모델을 만들고 해당 모델에 기반하여 수준을 높이려는 노력을 하기도 했다. 오늘은 이러한 모델 중 QSM1 에서 설명하는 6가지 문화 패턴을 소개하고 내 생각을 함께 적어보고자 한다.
Oblivious: “우리는 프로세스를 수행하고 있다는 사실조차 모른다.”
Variable: “우리는 그 순간에 좋다고 느끼는 것을 수행한다.”
Routine: “우리는 루틴을 따른다(패닉에 빠질 때를 제외하고).”
Steering: “우리는 결과에 따라 우리의 루틴들 중 하나를 선택한다.”
Anticipating: “우리는 과거에 경험한 루틴에 기반하여 루틴들을 수립한다.” 
Congruent: “모든 사람은 항상 모든 것을 개선하는데 참여한다.”
6가지의 종류라고는 했지만, 현실적으로 보여지는 패턴은 3까지라고 한다. 
패턴0: Oblivious
패턴 0 은 기업 안에 별도의 소프트웨어 개발 조직이 존재하지 않으며, 본인이 “소프트웨어 개발”을 하고 있다는 사실조차 인지 못한 채 소프트웨어 개발을 하고 있는 상황이다. 예를 들어 엑셀에 능숙한 어떤 직원은 lookup 테이블이나 VBA를 활용하여 고객을 관리하고 시각화하는 일을 처리하고 있지만 이러한 업무가 소프트웨어 개발과 관련성이 있다고 인지하지 못한다.
패턴1: Variable
이 패턴에서의 이미지는 “슈퍼 개발자”이다. “슈퍼 개발자”가 모든 문제를 해결해줄 것이라고 믿고 있으며 나머지 개발자들은 “슈퍼 개발자”를 서포트하기 위해 존재한다. 초기 스타트업에서 자주 보이는 패턴으로 창업 때부터 기여한 “슈퍼 개발자”가 존재하며 조직이 커져 새로운 문제가 발생되더라도 새로운 “슈퍼 개발자”가 나타나 문제를 해결해주기를 기대한다. 패턴1 에서의 성과는 전적으로 개인의 노력에 의존하기 때문에 일정과 비용의 변동성은 개인의 변동성에 달려있으며 특히 “슈퍼 개발자”의 일정에 대한 의존도가 크다. 개인을 대상으로 한 연구에서 일정, 비용, 오류 등에 대한 변동 수준은 지속적으로 20배 이상의 변동을 보여왔기 때문에 그와 같은 리스크를 지니고 있다고 볼 수 있다. 
개인적으로 이 조직이 변화하기 어려운 이유 중에 하나는 조직 내 높은 영향력을 가지고 있는 “슈퍼 개발자”가 변화를 원치 않는 경우가 많기 때문 인 것 같다. 사실 개발자라면 누구나 한번쯤은 빠르고 멋지게 기능을 만들어서 인정받고 싶은 욕구가 있을 것이다. 그러나 인정받고 싶은 욕구로 인해 한 행동들이 조직 차원에서 안좋은 결과를 가지고 온다는 것을 인지하는 경우는 드물다.
이 패턴에서의 다른 특징은 서로가 무슨 일을 하고 있는지 잘 모르며, 팀의 표준환경이나 개발도구도 없이 제각각 사용하게 된다. 이 패턴에서 사람들이 요구하는 것들은 일반적으로 다음과 같다. 
“무엇을 원하는지 명확하게 말해달라(그리고 나중에 바꾸지 말아달라)”
“우리가 필요로 하는 자원을 제공해달라(그리고 우리가 요청할 때마다 계속 지원해달라)”
“우리를 귀찮게 하지 말아달라(모든 불확실성을 제거해달라)”
패턴2: Routine(but Unstable)
이 패턴에서의 이미지는 “슈퍼 관리자”이다. 패턴 1에서 조직이 커지기 시작하면서 개발자들 개개인을 관리할 필요성이 있다고 느껴질 때 발생한다. 이 패턴 의 관리자는 패턴 1의 “슈퍼 개발자”가 자연스럽게 맡는 경우가 많은 것 같다. 다만 개발을 잘 하는 것과 관리를 잘하는 것은 다른 영역이기 때문에 많은 문제가 생기게 된다. 일반적으로 본인의 경험을 기준으로 지나친 일반화를 하는 경우가 많으며, 거기에서 발생되는 예외를 무시하고 정해진 루틴을 그대로 수행하려고 하는 경우가 많다. 그러다 문제가 크게 터지면 다시 패턴1 로 회귀하게 되는 경우도 발생된다. 
패턴2에서 잘못된 확신성을 가지게 되는 이유 중 하나는 핵심 사고 패턴이 선형적이기 때문이다. 어떠한 결과는 하나의 원인에서 기인한다는 생각을 가지고 있는데 이러한 오해에서 나온 해결책은 단기적으로는 문제가 해소된 것처럼 보이나 장기적으로 더 큰 문제를 가져오는 경우가 많다.
패턴3: Steering
패턴3의 관리자는 패턴2의 관리자에 비해 좀 더 전문성을 가지고 있다. 패턴2의 관리자는 “말로 하는 관리” 이외에 별다른 기술을 가지고 있지 않은 경우가 많다. 패턴3의 관리자는 다양한 기술을 기반으로 상황에 맞는 대처를 할 수 있다. 불확실성이 적은 상황에서는 패턴2의 관리자와 큰 차이가 없이 느껴질 수 있기 때문에 종종 패턴2에서 일이 잘 풀리면 패턴3로 착각하기 쉽다고 한다. 둘 다 계획된 절차를 사용하지만 패턴3 에서만이 계획에서 벗어난 상황에서 효과적으로 대응하는 방법을 알고 있다고 한다. 
패턴4: Anticipating
패턴4의 관리자는 패턴3와 비슷하지만 품질관리에 대해 더 높은 수준의 이해를 가졌다고 한다. 
패턴5: Congruent
패턴5는 최고 수준의 품질 관리를 유지한다고 하며 품질 관리를 회사 시스템의 필수 부분으로 간주한다고 한다. 패턴5의 조직은 구성원들이 프로세스의 지속적인 개선과 최적화에 기여할 수 있는 기반을 제공하며 구성원들은 항상 모든 것에 개선하는데 기여한다고 한다.
위의 6가지 패턴 중 내가 속한 조직의 문화 패턴은 어디에 속해있다고 생각하는가? 일반적인 IT 기업이라면 1-3의 패턴을 가지고 있을 것이다. 얼핏 보기에 아래로 갈 수록 더 좋은 문화라고 볼 수 있을 것 같지만 사실 어느 한쪽이 꼭 우월하다고 볼 수는 없다. 조직의 규모나 상황에 따라 적절한 패턴이 존재하는데 이러한 패턴을 인지하고 조직의 변화에 따라 적절하게 변화를 할 수 있는지가 중요할 것 같다. 3-4명으로 시작한 스타트업에서는 패턴1이 충분할 수 있지만 스타트업이 성공해서 100명 이상의 규모로 성장했음에도 불구하고 여전히 패턴1을 벗어나지 못하는 경우도 많이 보아왔다. 이들은 과거에 성공한 경험을 가지고 있기 때문에 변화의 필요성을 받아들이기 어렵게 되고 그렇게 정체되거나 도태되는 상황을 겪기도 한다. 
다음에는 패턴을 변화하기 위해 필요한 것이 무엇인지 다뤄보도록 하겠다.

IT기업의 6가지 문화패턴

댓글