오래된 SW 엔지니어의 평생 공부

아래 글은 Agile Coach하시는 분의 웹페이지의 글[1]을 가져다가 번역한 건입니다. 

Agile Software Development의 여러 실천법을 살펴 보았고, Scrum이나 간헐적으로 실행해 보고, 또한 Kanban을 실행해 보았다. 하지만, 큰 조직 내에서 프로세스가 있어고 이에 맞추어 Agile Software Development를 적용하는 것은 쉽지 않다 또한, 처음은 가능하지만, 지속 가능하게 만드는 것은 어렵다. 그래서, 최근에 고민하고 있는 사항은 Agile에 숨어 있는 철학 혹은 핵심이 무엇인가 하는 의문이다. 아래 글은 이와 일맥상통하는 부분이 있어 번역해 본다.

=========

실천, 원리, 가치

나는 결코 애자일 실천법(Recipes)의 팬이 아닙니다. 내가 책을 읽고 적용해봐야하겠다고 생각이 든 것 또한 매우 낮습니다. 제가 수년 동안 발견 한 사실은, 그 책이 필자의 실재 상황과 유사한 상황을 설명하는 경우도 거의 드뭅니다. 그리고, 특정 솔루션은 책에 쓰여져 있는 원래 상황에서도 동일한 방식으로 적용되지 않을 수 있습니다.

이것이 내가 일반적으로 실질적인 조언보다는 보다 추상적인 지식을 찾고 영감을 주는 말로서의 맥락 의존적 조언(context dependent advice)을 다루는 이유입니다.

제가 보기에도 이것은 일반적인 태도는 아닙니다. 저는 애자일 컨퍼런스에서 얼마나 자주 실천법이 포함되지 않았기 때문에 세션이 충분히 실용적이지 못했다는 논쟁을 보아서 놀랍니다. 하지만, 이것은 현상에 지나지 않습니다.

그 근본 원인은 사람들의 일반적인 사고 방식과 접근 방식 때문 입니다. 우리가 온갖 종류의 변화 프로그램(Transformation and Change progmras)을 살펴 볼 때 반복해서 볼 수있는 것입니다.

"사람들은 가장 눈에 잘 띄고 분명하며 종종 제일 중요하지 않은 실천법을 따릅니다."
Jeffrey Pfeffer & Robert Sutton

실천법에 대한 우리의 편견은 이유가 없는 것이 아닙니다. 결국 우리는 성공 사례로만 듣기 때문입니다. Toyota가 자동차 산업에서 선두 자리를 차지하기 위해 무엇을했는지. 애자일 방법론을 채택한 기업의 초기 성공 사례. 이러한 사례에는 많은 실천법이 언급 되고 있었습니다. 결국 이것이 우리가 성공한 조직을 볼 때 처음 보게되는 것입니다.

빙산

까다로운 부분은 실천, 기법, 도구 및 방법이 빙산의 일각에 불과하다는 것입니다. 즉 바다를 볼 때 우리에게 눈으로 보이는 것과 정확히 같습니다. 다른 쪽에는 이 보다 10배 큰 부분이 물 아래 있습니다. 수중에 가려진 부분은 이미 거기에 있고 정확하게 물 위에 일부분만 보이는 것입니다.
다시 말해서 눈에 보이는 빙산의 부분을 때어 내어 물에 다시 넣으면 그 결과는 그리 인상적이지 않을 것입니다.
이 메타포는 조직 변화가 일어나는 방식과 매우 관련이 있습니다. 경험 보고(exprience report) 및 성공 사례(success stories)에서 계속 듣게 되는 것은 전체 상황의 일부에 지나지 않는다는 것입니다. 수면 아래에 무엇이 숨겨져 있는지 이해하지 못한다면 보이는 부분을 복사하는 것은 말이 되지 않습니다.

원칙

어떤 실천이든 그것을 넘어서는 것이 원칙입니다. 우리가 시각화(Visualization: Kanban에서 현재 업무 프로세스를 눈에 보이게 만드는 실천법입니다.)에 대해 이야기하고 있다면 우리는 투명성(Transparency)을 제공하고 이를 통해 작업에 대한 이해를 향상시키는 것을 암묵적으로 이야기하고 있는 것입니다. 투명성을 제공하는 것은 실천법이 아닙니다. 그것은 많은 실행에 의해 체화(embodied)될 수있는 원칙인 것입니다.
흥미로운 부분은 원칙은 실천 뒤에 숨어 있지만, 조직에 의해 체화 되어 있는 원칙도 있다는 것입니다. 이 두 가지가 정렬되지 않으면 특정 실천법을 적용해도 동작하지 않습니다.
이야기로 설명해 드리겠습니다. 여러 팀으로 사이에 칸반(Kanban)이 적용되어 있는 회사 안에 소프트웨어 아키텍트 팀이 있었습니다. 그 팀에는 초기 단계였음에도 불구하고 거대한 저항이 있었습니다. 그 이유는 단순히 작업을 시각화하는 것입니다.
복면 뒤에서 일어난 일은 시각화가 제공하는 투명성이 팀에서 일하는 사람들에게 위협이된다는 것입니다. 일의 대부분이 회의, 토론 등에 시간을 할애 할 것이어서 성취를 눈으로 보여주기가 어려운 것들이었습니다. 투명성은 안전 감각에 대한 위협이어서, 저항을 발생시켰습니다.
더 깊은 맥락을 이해하지 못 하면, 도대체 무슨 일이 벌어지고 있는지와 왜 다른 환경에서와 같은 결과가 나오지 않는지 이해할 수 없는 것입니다.

가치

보다 더 깊이 들어가는 부분이 가치입니다. 가치에 관해 이야기 할 때, 일반적으로 바로 떠오르는 한 가지가 있습니다. 여러 종류의 비전과 사명 선언문입니다. 이것은 회사가 집중하는 가치를 찾을 수있는 곳입니다. 더 정확하게 말하자면, 조직이 집중한다고 주장하는 것입니다.

이것의 문제점은 통상 리더와 조직의 사람들의 보여주기식 행동과 실재 일상 행동 사이에 커다란 진정성 차이가 있다는 것입니다.
꽤나 보편적으로 언급되는 한 가지 가치는 품질입니다. 거의 모든 단일 조직은 높은 품질에 관심이 있습니까? 글쎄요, 많은 분들은 적어도 그렇게 말합니다.

이때, 우리가 해볼 수 있는 좋은 질문은 바로, "매일의 행동으로 표현되는 가치가 무엇인가?" 하는 것입니다. 개발자가 유닛 테스트를 작성할 시간이 없이 기능을 구현축해야한다고 이야기를 듣거나, 아무도 빌드가 초록색인지 빨간색인지를 신경 쓰지 않는다면 그 회사의 진정한 가치가 무엇인지 알 수 있을까요?
사실, 보여 주기식 행동은 거의 중요하지 않습니다. 그것은 메시지에 숨어 있는 허위를 간파하는 사람들에게 좌절감만 줄 뿐입니다. 중요한 것은 행동에 의해 설명되는 가치입니다. 많은 경우에, 효용 최적화(Utilization Optimization), 사람 무시(Disrespecting People), 투명성 부족(Lack of Transparency) 등이 이러한 예가 될 수 있습니다.
다시 말하지만, 이것은 우리가 실천법 뒤에 숨어 있는 가치를 찾을 수 있기 때문에 중요합니다. Kanban을 채택한다면, 예로 들자면 Mike Burrows의 "take on Kanban's values"를 채용할 수 있습니다. 흥미로운 질문은 이러한 가치가 조직에서 수용하는 가치와 어떻게 조화를 이루는가하는 것입니다.
도입할 때 영향이 없다면, 그 방법(Method)는 매우 제한적이거나 의미가 없거나 심지어 부정적일 것입니다.

사려깊음

우리가 실천법, 도구 그리고 방법론(Method)을 적용할 때, 가장 최소한으로 지켜야 하는 것은 사려깊게 접근하는 것입니다. 이것은 우리가 사용하고 자 하는 도구에 대한 초기의 심도 깊은 이해뿐 아니라 우라 자신의 조직을 이해하는 것도 포함한다는 의미입니다.
이것은 제가 종종 보아 오는 "그것을 만들기 전까지 꾸며라(fake it till you make it)"과는 상반되는 것입니다. 실재로, 특정 상황에서는 "만드는 것(making it)"이 실재로 불가능할 수도 있습니다. 빙하의 아래 부분에 무엇이 있는지 이해하지 못하면 무엇이 잘못되고 있는지 그리고 왜 우리의 노력이 실패하는지 알 수 없습니다.
원칙과 가치에 집중하는 것은 또한 학습을 가능하게 합니다. 이것 없이 우리는 기존에 알고 있는 도구를 단순히 모사해서 사용합니다. 어떠한 맥락에 어떻게 활용해아 하는지 관계 없이 말이죠. 이는 많은 애자일 코치들이 하고 있는 방법입니다.
사려 깊은 실천법의 적용은 학습으로 이끕니다. 사려 없는 실천법은 맹신(Cargo cult)로 이끕니다.

Reference

[1] Practices, Principles, Values, http://brodzinski.com/2014/08/practices-principles-values.html

발표자[1]는 김창준님으로 거의 초창기 국내 XP를 소개하고 Agile Consulting을 하는 분이다. 

중요한 것은 미신이기 때문에 틀리다는 것이다.

아래는 발표의 요약이다. 

1. 프로그래밍을 잘하는 것과 협업을 잘하는 것은 별개이다.
   (Sonnentag 연구, Frey, Osborne 연구): 사회적 요소의 중요성, 사회적 지능, 협상, 설득, 타인을 돕고 돌보는 것.

2. 팀의 퍼포먼스는 협업이 아니라 가장 뛰어난 사람이 결정한다.
   (Woolley, Chabris, Pentland 연구): 팀내의 문화의 중요성. MIT Wooley 연구. CQ(집단 지능) 결정항목 3가지 중 2가지가 공감력과 말을 골고루 하는 것. Google 아리스토텔레스 프로젝트. 심리적 안정감의 중요성.

3. 전문가들을 모아두면 협력을 잘 할 것이다.
   (Woolley, Gerbasi, Charbis 연구): 의식적인 협력의 중요성. 일을 시작하기 전에 어떻게 협력할 것인가, 일하는 방식에 대한 논의 하는 것이 중요함.

4. 협업을 잘하는 것은 서로 좋은 관계를 유지하는 것이다.
    (Stephens, Carmeli 연구): 갈등에 대한 처리. 신혼 때 적게 싸운 부부들이 이혼할 확률이 높다. 갈등을 잘 처리하지 못한다.

5. 분업을 잘하는 것이 협업을 잘하는 것이다.
   (Salas 연구, Hackman 연구): 팀 vs 워크 그룹. Peer Review.

선문답 같지만,, 이 내용에 대해서 내가 무의식적으로 그냥 믿고 있지는 않은지 생각해 봐아겠다.

[1] 협업에 대한 5가지 미신, http://agile.egloos.com/5904102

왜 여기까지 왔는가?

궁금증이 있었다. 우선 회사에서 가르치는 아키텍트(Architect) 관련 과정이 무엇을 가르치는 것일까? 그리고, 거기서 말하는 소프트웨어 아키텍트(Software Architecture)라는 것은 어떤 것일까? 그 과정을 들었떤 지인들에게 이야기 들었던 것들은 나에게 속시원한 답을 주지는 않았다. 그래서, 우선은 과정에 참여하였고, 일단락을 맺었다. 하지만, 이제 시작이라는 느낌이다. 그래서, 이글을 시작으로 또 공부하게되는 내용들을 정리하려고 한다.

교육 과정을 통해서 알게 된 소프트웨어 아키텍처 설계(Software Architecture Design)은 소프트웨어 공학(Software Engineering) 관점에서 최적 설계에 대한 것이었다. 단계별로 보면, 요구사항 분석(Requirement Analysis)에서 시작하여 시스템의 범위를 정하고, 기능적 요구 사항(Functional Requirement)를 도출한다. 그리고, 이를 분석하여 품질 시나리오(Quality Scenario)를 도출한다. 여기서, 비기능적 요구 사항(Non-Functional Requirement)와 품질 속성(Quality Attribute)를 선정한다. 이 때, 비지니스 동인(Business Driver)를 고려하여 우선순위 선정이 필요하다. 그리고, 이를 기반으로 시스템 범위 내에 중요한 내용을 기반으로 하는 후보 구조(Candidate Architecture)들을 도출하고 이를 비교 분석하며 아키텍처 디시젼(Architectural Decision)을 해가면서 최종적 아키텍처를 완성해 간다. 이 내용들은 시스템의 이해관계자(Stakeholder)과 공유 되어야 하면서 장점과 단점이 지속적으로 언급이 되면서, 의사결정이 되는 과정인 것이다.

아주 오래전에 소프트웨어 공학(Software Engineering) 교수님께서 설명하신 객체 지향 패러다임(Object Oriented Paradigm)관련한 강의에서 들은 내용이 있다. 소프트웨어 공학(Software Engineering)이 무엇인지에 대한 것인데, 이는 소프트웨어 개발자가 가져야 하는 상식(Common Knowledge)이다라는 것이 있다. 나도 소프트웨어를 개발하는 사람이 가져야 하는 기본적 소양이라는 관점에 지금까지도 동의 하는 부분이다. 하지만, 많은 소프트웨어 공학 책에서 강조하는 정식 프로세스(Formal Process) 관점에 대해서는 나는 수긍하지 못하고 있다. 많은 회사들이 이를 채용하고 있다고는 하지만, 직간접적으로 경헌한 나의 경우는 아직 보지 못했기 때문이다. 물론 많은 회사들이 제품을 만들기 때문에 프로세스가 있을 것이다. 

가장 큰 이유 중에 하나는 사람이다. 프로세스 중에 사람이 없다. 내 경험으로 여기에 가장 가까운 것은 애자일 소프트웨어 개발(Agile Software Development)이다. 나는 이것도 결국은 소프트웨어 공학의 한 분야로 이해하고 있다. 사람이 하는 일은 사람을 떠나서 생각하면 공허해 진다.

문서화에 대한 거부감

내가 SW 개발 실무를 처음 시작할 때에는 통신 프로토콜 스택의 설계 및 구현에 참여 하였다. 요구 사항(Requirement)이 사양서(Specification)이었다. 나의 상사는 소프트웨어 공학을 했던 분으로 내가 받았던 업무 지시는 요구 사항 분석을 통해서 상세 설계를 하는 것이었다. 코딩은 중요하지 않다(Trivial하다는 의미로 이해된다)고 이야기를 계속 들었다. 이러한 작업은 내가 구현해야 하는 분야의 도메인 지식(Domain Knowledge)을 높여 주는데는 성공했지만, 최종적으로 코딩을 하는데는 실패하게 되었다. 이유는 나의 기술적인 미숙, 하드웨어 제약에 대한 이해 부족, 목표한 테스트의 실패, 충분하지 못한 일정 그리고는 지속적은 목표 변경 등 여러 가지가 복합적이었다.

이후 내가 경험했던 여러 성공한 프로젝트들은 문서화보다는 실질적으로 동작하는 제품에 맞춰졌다. 내부 혹은 외부의 고객이 원하는 제품 혹은 우리가 만들 수 있는 제품을 고객에게 보여주면서 정제(Refine)해가는 절차를 통해서였다. 즉, 동작하는 솔루션을 만들어 놓고, 그를 바탕으로 확장해 나아가는 방식이다. 여기에서의 우리가 하는 문서화는 점점 줄어 들었다. 이는 읽지 않는 문서는 만들지 않는다는 중요한 원칙이 있었던 것이다.

성공적이라 할 수 있는 프로젝트는 많았지만, 늘 지적 받던 것은 소프트웨어의 품질이었다. 과제가 끝났지만, 여전히 소프트웨어에는 문제점(Defect)이 많고, 변경이 용이하지 않으며, 성능이 좋지 않은 경우가 많았다. 여러 가지 개선 방법들을 논의 하였지만, 우선적으로 소개되며 고민되었던 방법은 프러덕트 기반의 애자일 개발 접근 방법이었다. 여기서도 문서는 그렇게 중요한 것은 아니었다. 그 보다는 진행 사항을 가시화(Visualize)하고 제품을 점진적으로 개발하여 실재 제품에 적용가능한지를 평가하면서 진행하는 방식으로 프로젝트가 변경되었다.

이렇듯, 소프트웨어 공학에서 이야기 하는 설계서와 같은 문서화에 대해서는 여러 거부감이 있다. 하지만, 아이젠하워의 말대로 "계획대로 승리한 전투는 없지만, 계획없이 승리한 전투도 없다. No battle was ever won according to plan, but no battle was ever won without one" 인 것이다. 결국은 읽힐 문서, 다이어그램(Diagram)을 만들어야 하는 것이다.

소프트웨어 공학에 대한 비판

많은 아키텍처 책이나 글 그리고 프로세스는 소프트웨어 공학을 가정한 내용이다. 아래 글은 Wikipedia의 소프트웨어 공학(Software Engineering)[1]에 있는 내용이다. 여러가지 관점에서 살펴 보기 위해서 이러한 의견도 고려해 보려 한다.

소프트웨어 공학에서는 개발자를 전문가(Practitioner)로 본다. 즉, 문제 해결에 대해 잘 정의된 엔지니어링 방식을 따르는 개인, 즉 전문가로 본다. 이는 마치 의사, 변호사와 마찬가지로 보는 것이다. 이러한 접근법은 다양한 소프트웨어 공학 서적 및 연구 논문에 명시되어 있으며 항상 예측 가능성, 정확성, 리스크의 완화 및 전문성을 함축한다. 이러한 관점은 엔지니어링 지식을 전파하고 현장을 성숙시키는 메커니즘으로서 라이센스, 인증 및 체계화 된 지식 체계를 요구하게 되었다.

하지만, 소프트웨어 공학에 대한 핵심 쟁점 중 하나는 일반적으로 실제 접근 방식의 검증이 없거나 매우 제한적이어서 접근 방식이 충분히 경험적이지 않다는 것이다. 그래서, 소프트웨어 엔지니어링이 종종 "이론적 환경"에서만 가능한 것으로 오인된다.  

에츠허르 데이크스트라(Edsger Dijkstra)는 오늘날 소프트웨어 개발에서 사용 된 여러 개념을 만든 사람으로서 2002 년 사망 할 때까지 소프트웨어 엔지니어링에 대해 컴퓨터 과학의 "급진적 참신성(Radical Novelty)"라고 반박했다.[2]

"이러한 현상은 소프트웨어 공학이라는 이름으로 포장되었다. 경제학이 비참한 과학(The Miserable Science)으로 알려짐에 따라 소프트웨어 공학은 종말에 이른 체계(Doomed Discipline)으로 알려 져야한다. 목표가 자기 모순적이어서 목표에 다가 갈 수 없기 때문이다. 물론 소프트웨어 공학은 또 다른 가치있는 이유를 제시하지만, 눈속임이다. 글을 주의 깊게 읽고 그것이 실제로 무엇을 하려고 헌신하는지 분석하면 프로그래밍을 할줄 모르면 어떻게 하는가(How to program if you can not)가 소프트웨어 공학의 진정한 근본 원리(Charter)로 받아 들여 졌음을 알게 될 것이다."

그럼에도 불고하고, 소프트웨어 공학은 이러한 비판에 대해서 닫혀 있지 않았다. 여러 경험적이고 공통적으로 받아 지는 것들을 쌓아 왔다. 특히, 애자일 소프트웨어 개발(Agile Software Development)의 성공적인 부분을 받아 들였따. 특히, 반복적 접근 방법(Iteratvive Development)를 받아 들이고 있다.

정리해 보면...

받아 들이기 어려운 극단적인 비판적 입장일 필요도 없다. 간단하고 명료하게, 우리는 실용적(Practical)일 필요가 있다. 즉, 결과를 낼 수 있고, 논리적으로 명백하다면 받아 들이기는 더욱 쉬울 것이다. 단지, 늘 비판에 대해서 열려 있어야 한다. 하지만, 목표는 분명하고 단단해야 할 것이다. 즉, 소프트웨어는 완성되어야 한다. 그리고, 소프트웨어 개발이 어려 사람들과 함께 만들어 내야 하는 것일 것이다.

이러한 실용적이라는 관점에서는 목표를 이야기 하고 싶다. 우리는 최상의 결과물을 만들어 내야 한다. 그런 입장에서 결과물을 처음 부터 그려 가는 것이 필요하다. 처음에 그렸던 최종 결과물이 마지막에도 꼭 그런 모습을 가지지 않을 수 있다. 아이젠하워의 말처럼 "Plan is nothing, but planning is indispensable"이 생각난다. 결국, 전쟁에서는 승리가 최종 목표 이듯이, 설계서에 함몰하지 말고 최종 결과물을 목표로 하는 설계에 집중해야 한다고 생각한다.

그래서, 나는 소프트웨어 공학 관점에서의 아키텍처에 관해서 고민을 시작하여 여러 관점에서의 실용적인 소프트웨어 아키텍처의 설계에 대해서 살펴 보고자 한다.

참고 문서

[1] Software Engineering, https://en.wikipedia.org/wiki/Software_engineering 

[2] On the cruelty of really teaching computing science, https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html