기본 콘텐츠로 건너뛰기

생산성 혁신의 순서로 보는 테스팅 조직의 성숙도

프랙탈이라는 것이 있습니다.

부분 부분의 모습이 자기 복제를 통해 전체 역시 동일한 형태를 가지는 기하학적인 도형을 일컫는 말입니다.

즉, 전체와 부분이 유사한 형태를 지닌다는 말입니다.

테스팅 조직의 성숙도와 발전 역시 회사의 성숙도와 발전과 유사한 모습을 지닙니다.

생산성 혁신의 순서는 제조업의 발전과 맞물려 있지만 그 발전 순서는 작은 조직 또는 개인의 발전에도 충분히 적용하여 생각해 볼 수 있습니다.

아무리 작은 조직과 개인이라도 자신의 생산성을 더 낫게 만들기 위해서 노력합니다. 더 나아진 상태로 나가기 위해 항상 노력하는 것은 어쩌면 우리의 본능일지도 모릅니다.

그런데 우리 자신과 우리의 조직이 항상 생산성 혁신을 성공하는 것은 아닙니다. 많은 경우는 실패로 끝나는 경우도 많습니다.

왜 그런것일까요?

가장 큰 원인은 자신의 성숙성과 관계가 있습니다. 자신의 조직이 현재 어떤 단계에 있고 그 단계에 어떤 접근법을 취해야 할것인지에 대한 고민도 없이 최신의 방법론을 도입하기 위해 서두르기 때문입니다.

어떻게 하면 우리는 성공할 수 있는 것일까요? 그것은 지금 자신의 상태와 환경에 적합한 방법론을 선정해서 합리적인 절차에 따라 수행하는 것이라고 생각합니다.

그러한 합리적 절차는 5S 3I로 요약할 수 있습니다.

5S와 3I란 경영 혁신 절차 8단계의 머리 글자를 딴것입니다.

각 경영 혁신 절차는 그 시대적 환경에서 기업이 부딪친 경영 환경에 맞게 개발된 시대적 산물로 우리 조직 역시 아무리 노력한다고 해도 그 기간을 단축할 뿐이지 각 단계를 뛰어넘을 수는 없습니다.

그것은 개구리 알이 올챙이가 되고 앞다리가 나오고 뒷다리가 나오고 꼬리가 사라져야 개구리가 될 수 있지 중간의 어떤 단계도 건너뛸 수 없는 것과 마찬가지입니다.

만약 여러분이 테스팅 조직 성숙도 모델인 TMMi나 TPI 또는 ISO/IEC 29119과 같은 표준, Agile Testing와 같은 방법론을 도입하려고 노력해도 성공하지 못한다면 여러분의 조직은 아직 이러한 단계를 도입할 준비가 되지 않은 것입니다. 여러분이 알아차리지 못했던 어떤 단계에 대한 더 나은 성숙도에 도달해야만 그 다음 단계를 성공할 수 잇씁니다.

즉, 먼저 그 길을 달려갔던 조직과 회사가 성장하면서 거쳤던 생산성 혁신의 순서를 우리도 짧게나마 밟지 않으면 안되는 것입니다.

생산성 혁신을 생각할 때 가장 먼저 생각할 것이 전문화입니다.

크게는 개발팀과 테스팅을 구분하여 전문화 하는 것을 생각해 볼 수 있고 테스팅 안에서도 테스트 설계, 성능 테스팅, 보안 테스팅, 사용성 테스팅 등 각각의 영역에서 전문성을 취하고 분업화를 하는 단계라고 볼 수 있습니다.

전문화 다음으로 생각할 수 있는 것이 표준화입니다.

업무 수행의 표준화, 보고서의 표준화, 코딩작성 방법에 대한 표준화 등 생각해 볼 수 있는 표준화는 무척 많습니다. 표준화란 약속이며 질서를 만드는 단계라고 볼 수 있습니다.

전문화와 표준화가 이루어지면 그 다음으로 찾아오는 것이 단순화입니다.

단순화는 전문화와 표준화를 거치면서 복잡해졌던 많은 단계를 단순화 하는 단계입니다.

제 경험상 많은 업체들은 아직까지는 표준화 진행 단계로 생각됩니다. 많은 조직에서 ISO 인증이나 표준의 도입들에 열심을 낼 뿐, 그 표준에 있어서 어떻게 자신의 조직에 맞게 적절하게 단순화 시킬 것인지에 대한 고민은 그다지 많지 않은 것 같습니다.

이렇게 전문화, 표준화 , 단순화를 생산성 혁신의 3S라고 합니다.

이 3S에 정확한 측정과 그에 걸맞는 보상 체계를 맞추는 과학화가 더해져 4S가 됩니다. 이러한 합리적 보상체계는 조직 구성원에 대해 동기를 부여하는 요인이 됩니다.

그리고 이러한 보상 체계는 직간접적으로 조직의 구성원의 활동에 영향을 미치게 됩니다.

가장 흔하게 얘기되는 예가 테스팅 조직의 보상 체계로 테스터를 결함의 갯수로만 평가하게 된다면 테스터는 발견하기 쉬운 결함에만 집착하게 됩니다.

이렇게 되면 테스팅의 완성도와 조직 전체에 좋지 않은 영향을 끼치게 되는 것은 자명한 일입니다.

과학화란 테스팅의 완성도를 높이기 위해서 반드시 의미있는 매트릭을 개발해야 된다는 것입니다.

이상과 같은 4S는 순차적으로 진행될 수도 있지만 사실 순차적이라기 보다는 병렬적으로 그리고 개별적으로 진행되는 개선으로 4S가 조화를 이뤄 효과를 내기 위해서는 이를 체계화할 필요성이 있습니다.

이것을 우리는 프로세스라고도 부르고 어떤 경우는 모델 또는 방법론이라고도 부르는 것입니다.

이는 다섯번째의 S로 시스템화입니다.

어떤 제품을 이루는 부품들이 흩어지면 아무런 힘이 되지 않지만 정해진 역할에 따라 모인다면 목표로 하는 효과가 나타나는 것처럼 효과가 극대화되기 위해서는 전문화, 표준화, 단순화, 과학화의 4S가 이루어지고 난 다음에는 이를 시스템으로로 구축해야할 필요가 있습니다.

이렇게 시스템이 구축되면 그 다음이 1I, 집적화 입니다.

집적화란 고객의 요구사항에 대한 신속한 대응을 말합니다. 즉, Agile 개발 방법론 등이 목표로 하는 바가 이 집적화 단계입니다.

다른 말로 한다면 조직 자체가 5S 단계를 거쳐서 이루지 못했다면 Agile 개발 방법론을 아무리 도입하려고 해도 그 효과가 빠르고 직접적으로 나타나지 못한다는 것과 같습니다.

그 다음은 2I, 지능화입니다.

지능화는 무인 자동화를 말합니다. 지능화 단계는 선진국에서도 실험적인 응용이 시도중인 단계입니다. 하지만 우리 나라에서는 많은 경우 이전 단계들을 무시하고 자동화만을 추구하는 우를 범하는 경우도 많습니다.

마지막 3I 는 비상식화의 단계입니다.

기존의 상식적인 개선으로 한계에 다다랐을 때 생각해 볼 수 있는 것이 이 단계이고 이것을 혁신이라고 합니다.

즉, 혁신이라는 것을 이루기 위해서는 상식의 기초가 갖추어져야 한다는 것입니다.

정리해 본다면 생산성 혁신은 아래와 같은 순서로 진행됩니다.
생산성 혁신의
여러분과 여러분의 조직은 지금 어느 단계에 도달했나요? 어떤 단계가 부족한가요?

발전하고 발전해서 더 나은 단계에 도달하고 싶으시다면 꼭 한번 여러분의 조직이 현재 어떤 환경에서 어떤 단계에 도달해 있는지 꼭 한번 고민해 보시기 바랍니다.

만약 객관적인 시각이 필요하시다면 믿을만한 컨설팅 회사를 찾아보시기 바랍니다. 만약 여러분의 조직이 가지고 있는 제약과, 강점과 약점, 환경을 고려하지 않고 단순히 자동화, 표준화 만을 강조한다면 그 컨설턴트는 가짜일겁니다.

여러분이 지금 추진중인 6시그마, TQC, Agile, Lean 등의 방법론이 정착되지 못하고 힘들고 어렵고 실패한 경험이 있다면 방법론이 잘못된 것이 아니라 여러분의 성숙도가 문제인 것입니다.

여러분을 돌아보시기 바랍니다.

개인적으로는 우리 나라의 IT와 SW 업계를 포함해서 테스팅 조직에서 가장 필요한 단계는 단순화 그리고 시스템화와 함께 TQC 적인 사고와 정책의 도입이 아닌가 생각됩니다.

댓글

이 블로그의 인기 게시물

20년 차 테스터가 고른 최근 IT 소식: 기술의 속도, 그리고 사람의 자리

20년 넘게 IT 업계에서 테스팅하고 강의하고 공부하고 여러 일을 해왔지만... 정말이지 단 하루도 편하게 쉴 틈을 주지 않는 세상입니다. 특히 최근 4~5년 동안 가속화된 AI의 물결은 기술의 스펙트럼뿐만 아니라 우리가 일하고, 협업하고, 조직을 이끄는 방식 전체를 뒤흔들고 있습니다. 이번 주에도 수많은 뉴스레터와 아티클을 훑어보았습니다. 그중에서도 기술의 화려함 뒤에 숨겨진 ‘사람, 조직, 그리고 커리어의 본질’을 찌르는 글 몇 개가 눈에 띄어 메모해 둡니다. 제 평소 생각과 맞닿아 있는 6가지 이야기입니다. --- 1. 인지부채(Cognitive Debt): 바이브 코딩 시대에 우리가 지게 되는 진짜 빚 (출처: ROBOCO - 인지부채: 바이브 코딩 시대의 새로운 부채 관리법 / 정도현 수석 컨설턴트 ) 요즘 커서(Cursor)나 클로드 코드(Claude Code) 같은 에이전트를 붙여 "이거 만들어줘" 하고 승인(Approve) 버튼만 누르면 눈 깜짝할 사이에 코드베이스가 완성되는 '바이브 코딩(Vibe Coding)'이 유행입니다. 그런데 속도는 엄청나게 빠른데, 정작 서비스에 장애가 나면 "AI가 짜서 잘 모르겠는데요?"라는 답이 나오는 이상한 현상이 벌어집니다. 정도현 컨설턴트는 이를 '인지부채(Cognitive Debt)'라고 정의합니다. 코드는 쌓이는데, 정작 인간의 시스템 이해도는 쌓이지 않는 격차죠. * Human-in-the-loop의 환상: AI가 초당 수백 줄을 뽑아내는데 사람이 일일이 검토한다? 결국 검토자는 병목이 되고, 시간 압박에 쫓겨 영혼 없이 승인 버튼만 누르게 됩니다. 40년 전 자동화 연구(Bainbridge, 1983)가 지적했듯, 자동화될수록 사람은 감시만 하다가 정작 개입해야 할 결정적 순간에 숙련도를 잃어버립니다. * 부채는 0으로 만드는 게 아니라 '관리'하는 것: AI가 만든 모든 코드를 사람이 외울 수는 없습니다. 핵심은 ...

우리는 AI로 '더 빠른 말'을 키우고 있는걸까요? 아니면 '자동차'를 만들고 있는걸까요?

20년 넘게 IT 현장에서 뒹굴거렸는데... 요즘처럼 "우리가 지금까지 당연하게 여겨온 일하는 방식의 본질"에 대해 근본적인 질문을 던지게 만드는 때가 없었던 것 같습니다. 최근 읽은 UX 관련 글 하나가 가슴을 쿵 치고 지나갔습니다. UX 및 디지털 트렌드를 다루는 블로그 ux4dotcom에 올라온 "Beyond Faster Horses — Why AI Challenges One of UX's Oldest Assumptions"라는 글입니다. (출처: ux4dotcom - Beyond Faster Horses — Why AI Challenges One of UX's Oldest Assumptions ) 혁신을 말할 때 늘 인용되는 헨리 포드의 유명한 말이 있습니다. "사람들에게 무엇을 원하느냐고 물었다면, 그들은 '더 빠른 말'이라고 답했을 것이다." 사람들은 자신이 경험해 본 범위 안에서만 미래를 상상합니다. 말만 탈 줄 아는 사람에게 자동차는 상상 밖의 범주(Mental Model)니까요. 저자는 그동안 UX(사용자 경험)라는 학문과 필드 자체가 '더 빠른 말을 만드는 일(기존 과업의 효율화)'에 집중해 왔다고 지적합니다. 사용자의 행동을 관찰하고, 마찰(Friction)을 줄이고, 화면을 간소화하고, 기존 워크플로우를 최적화해 주는 작업 말입니다. 실제로 주변을 봐도 우리가 AI를 쓰는 방식도 대부분 이 범주를 벗어나지 못하고 있습니다. 더 빠르게 이메일을 작성하고, 문서 요약을 3초 만에 끝내고, 프레젠테이션 장표나 일정표를 순식간에 만들어내는 일. 분명 유용하고 저 역시 매일 요기하게 쓰고 있지만, 이건 어디까지나 '기존에 인간이 하던 일의 프로세스를 흉내 내어 속도만 올린 것(Faster Horse)'에 불과합니다. 정작 "이 워크플로우 자체가 과연 계속 존재해야 하는가?"라는 근본적인 질문은 던지지 못하고 있는 것이죠....

에이전틱 AI 시대의 소프트웨어 테스팅: 왜 '아키텍트' 역량이 필요한가?

최근 "프로그래밍이란 무엇인가?"라는 근본적인 질문에서 출발해, 하드웨어의 가장 밑바닥인 CPU 명령어 디코더의 원리부터 최근 화두인 에이전틱 AI(Agentic AI)와 바이브 코딩(Vibe Coding)에 이르기까지 AI와 함께 이런 저런 대화를 나누어 보았다.. 사실 내가 처음 컴퓨터를 공부할 때부터 컴퓨터가 내 명령을 어떻게 이해하고 처리해서 이런 결과가 출력되는지는 정말 이해하기 어려운 마법 같은 것이었다.  그래서인지.. 나이가 들어도 프로그래밍은 여전히 어렵다. 하지만 요즘은 AI와 함께 무언가를 만드는 재미를 만끽하고 있다.  어쨌든 AI와의 즐거운 대화의 끝에서 필연적으로 마주한 질문이 있다. "코드를 AI가 스스로 짜고 조립하는 시대에, 소프트웨어 테스팅은 무엇이며 우리는 어떤 역량을 키워야 하는가?" 지금까지의 고민을 바탕으로, 다가오는 AI 시대에 테스트 엔지니어가 나아가야 할 방향과 '아키텍트(Architect)' 역량의 중요성에 대해 정리해 본다. 현대의 소프트웨어 개발은 무(無)에서 유(有)를 창조하는 것이 아니다. 전 세계의 천재적인 엔지니어들이 만들어둔 수많은 라이브러리와 프레임워크라는 '레고 블록'을 조합해 원하는 서비스를 구축하는 과정이다. 내가 젋어서 이걸 잘 이해만 했었어도.. 테스터라는 직업의 세계에 발을 들이지는 않았을 텐데.. 어린 나이에 너무 생각이 많았었다. 그런데 에이전틱 AI가 등장하면서 거대한 변화가 일어났다. 이제는 인간이 직접 레고를 조립할 필요조차 없어지고 있다. "이런 기능을 만들어줘"라는 의도(Intent)만 던지면, AI가 기존에 학습한 방대한 오픈소스와 코드를 바탕으로 알아서 뼈대를 세우고 코드를 완성해 낸다. 개발자는 직접 코드를 타이핑하는 노동자에서, AI 에이전트를 부리는 총괄 기획자로 역할이 변하고 있는 것이다. 하지만 AI가 만들어내는 코드는 필연적인 한계를 지닌다. AI는 과거 인류가 작성한 코드를 학습하...