그림출처: //forintus.com/tag/agile-manifesto/

애자일 선언서는 동 시대를 살아가는 가장 유명한 애자일 멘토들이 개발자들에게 외치는 “복무신조”, “우리의 다짐” 같은 것이다(맞나요? 제대한 지 20년도 넘어서). 선언서에서 오른쪽의 것들이 중요하지 않다는 것이 아니라, 소프트웨어 개발자로서 왼쪽의 것을 추구하라고 말씀하신다.

개인마다 해석이나 이 선언서가 주는 임팩트는 다를 수 있다. 필자가 나름대로 이해한 내용을 썰로 풀어 본다.

INDIVIDUALS AND INTERACTIONS over PROCESSES AND TOOLS

프로세스나 도구를 모든 팀에 획일적으로 적용해서는 안되며, 팀의 성격에 맞게 써야 한다. 가령 애자일 도구로 유명한 스크럼이나 칸반이 모든 팀이 따라야 하는 매직 프로세스는 아니라는 의미다. 프로세스나 도구에 매몰되어, 실제로 산출해야 할 결과물인 작동하는 소프트웨어를 등한시 하는 어리석음을 범하지 말아야 한다. 대기업이란 문맥에서는, 개발자의 생산성이 덜 나올 수 밖에 없다, 지켜야 할 프로세스가 많기 때문에…

팀에서 위키, 지라, 슬랙, 이메일을 사용한다고 하자. 가장 위험한 상황은

• “아 그거 이틀 전에 위키에 답변 드렸는데…“라고 말하거나,
• 슬랙으로 업무 요청하고 결과를 마냥 기다린다거나,
• 지라 티켓 등록하고 담당자 할당 후 팔로우 업을 하지 않는

상황들이다.

우리개발자 스스로에게 반문해보라. 작업에 몰두하고 있을 때, 이런 메시지를 확인하기 위해 주기적으로 자기 자신에게 인터럽트를 거는지? 필자의 경우, 담배 필 때나 화장실 갈 때 몰아서 보는 편이다.

답은 의외로 간단하다. 자리에 가서, “스펙 수정 요청 보냈어요. 자세한 내용은 위키에 썼으니 확인해주세요”라고 한번 더 말하는 것이다, 상대방이 멀리 있다면 30초 짜리 전화 한통이면 된다. 아래 링크에서 한 숨만 나오는 CEO를 만나보라.

Follow Up 이란?

팀을 들여다 보라~ 적합한 프로세스와 도구로 인터랙션하고 있는가? “남들이 하니까 무조건 따라한다”라는 위험한 선택을 하고 있지 않는가? “남들이 하니까”는 판단을 위한 참고자료일 뿐이다.

WORKING SOFTWARE over COMPREHENSIVE DOCUMENTATION

너무나도 당연한 얘기다. 최종 산출물Deliverable이 무엇인지 잘 생각해 보라. “작동하는 서비스=우리가 준비한 런타임 환경 + 우리가 개발한 소프트웨어“다. UI 목업이나 초벌 구현 소프트웨어를 보면서 고객과 대화해 본 적이 있다면 그 강력함에 동의하며, “무릎을 탁~” 칠 것이다.

문서가 중요하지 않다는 것이 아니다. 작동하는 소프트웨어 만큼이나 문서도 중요하다. 일을 시작하기 위해 문서가 필요하고, 일을 끝내기 위해서 문서가 필요하다. 상위 요구사항이 구체화되어야 일을 시작할 수 있고, 프로젝트 진행 중에 구체화된 하위 스펙을 전부 구현해야 일을 끝낼 수 있다는 점을 상기시켜보라¹.

예를 들어, 완벽한 시스템을 상위 설계하고 문서화 했다고 하자. 그런데, 그것은 그냥 문서일 뿐이다. 작동하는 소프트웨어가 없는 문서가 무슨 의미가 있는가?

개발자로 경력을 전환하기 위해 10개월의 준비 기간을 가지는 동안, 꽤 여러 명의 청년 창업가들을 만났다. 말하는 목표 시스템은 전부 애플/잡스 급이다. 그런데, 공허한 말로만 존재할 뿐, 심지어 문서도 없고, 작동하는 최소한의 서비스는 당연히 없었다. 창투사들이 MVPMinimum Viable Product를 요구하는 이유다². 해결하고자하는 비즈니스 문제를 정확히 이해하고, 현실적인 해결책을 가지고 있는 창업가들은 조금씩이라도 힘 닿는데로 도와줬다.

CUSTOMER COLLABORATION over CONTRACT NEGOTIATION

필자는 2002년부터 10년 동안 非 개발자로서, 투자를 받거나, 차입을 하거나, 기술을 도입하거나, 인력 파견 요청을 하거나, 회사를 파는 등 크고 작은 계약을 경험했다. 그런데, 생각해 보니 누군가의 요청을 받아 용역SI을 제공하는 계약을 다루어 본 적 없는 甲이었다. 해서 이 원칙을 이해하는데 있어서 전문성이 떨어질 수 밖에 없다. 그런데, 고객이란 꼭 외부의 고객만을 의미하지 않는다. 개발자의 직접 고객인 팀 동료, 매니저, 기획과 QA, 간접 고객인 사업 부서도 넒은 의미의 고객이라 생각할 수 있다.

필자는 이 원칙을 “상호 이득Mutual Benefit“을 추구하기 위해 계약=약속 또는 스펙보다는 고객과 지속적 협업을 이끌어 내야한다는 취지로 이해했다.

역시 경력전환기 동안 생계를 위해 용역을 기웃대던 시절 이야기다. 일을 주겠다는 사람을 만나보면, 그들이 하고 싶은 것이 무엇인지 정확인 기술하지 못하는 경우가 많았다. 그들의 잘못이 아니다. 해보지 않았기 때문에, 고객도 용역을 제공하는 쪽도 알 수 없는 것이다. 일의 시작이 계약이라고 한다면, 요구사항이 명확하지 않으니 밀땅을 하며 계속 시간을 지체하고 계약을 하지 말라는 것인가? 그것은 서로간에 에너지 낭비다. 현실적으로 계약서에 완벽한 요구사항과 계약 완료 조건을 담을 수는 없다. 개발자는 이 시기에 구현 가능성을 검토하고, 필요한 도구를 조사하면 된다.

훌륭한 고객은 구체적인 작업 목록을 제시하진 못해도, 해결하고자 하는 비즈니스 문제와 최종 결과물의 목표 이미지를 명확히 인지하고 있다. 또, 훌륭한 용역 제공자는 자신이 뭘 하고 싶은 지 설명하지 못하는 고객일지라도, 그들이 해결하고자 하는 문제를 구체화할 수 있도록 이끌어 주고, 최종 결과물의 목표 이미지와 기대 효과를 가늠할 수 있도록 해준다.

일단 일을 시작하게 되면 고객과 계속 협업해야 한다. 계약을 수행하는 중에 스펙은 계속 변한다, 그것이 고객에 의해서든, 개발팀의 한계에 의해서든. 고객이 제시한 요구사항을 구현하다보면 더 좋은 설계를 역으로 제안하는 경우도 있다. 가끔은 팀의 현재 기술 수준, 시간, 또는 자원의 한계로 구현이 불가한 경우도 있다. 개발자는 매일 매일 선택의 순간을 만나게 되고(e.g. > or >=), 스스로 선택할 수 없는 문제라면, 고객에게 빠르게 결정을 요청해야 한다. 스펙 변경에 의해 개발자의 일 량이 늘거나 줄기도 하며, 기간을 늘리거나, 개발자를 더 투입해야 하는 순간도 있는데, 프로젝트/팀 매니저의 역할이다오버타임하거나 태업하는 개발자를 관리하는 것은 매니저의 책임.

계약을 하지 말라는 얘기가 아니다. 계약은 무조건해야 한다. 다만, “상호 이득”을 위해 서로가 긴밀하게 협업해야 한다³.

RESPONDING TO CHANGE over FOLLOWING A PLAN

필자는 반도체 설계 전문 회사FABLESS라 부름에서 꽤 오래 근무했다. 제품성, 수익성, 사업성을 판단해서 콤포넌트 레벨의 상위 설계를 하는 제품 기획자 역할이었다. 목표 미세 공정 수준에 따라 다르긴 하지만, 32bit 범용 Applications Processor는 3개월 제품 기획 -> 1.5년 설계 -> 3년동안 생산/판매의 수명을 가진다. 설계가 끝나면 양산을 위해 마스킹 및 양산 셋팅 과정을 거치는데, 오류가 발견되면 마스크를 다시 떠야 한다. 당시 회사는 90~45nm 제품들을 설계했었는데, 45nm 기준 2년 개발 기간 동안 대략 100억원의 개발비를 쓰는데, 수정의 양에 따라 1억원 ~ 풀 리비전을 하게 되면 20억원의 비용이 더 써야한다. 개발은 끝났지만, 시장 환경이 변해서 제품성, 수익성, 사업성 측면에서 쓸모 없는 제품이면 매몰 비용으로 빨리 잊어버리고 다음 제품 개발에 몰두해야 한다.

이 이야기로 시작한 이유는 반도체는 “하드웨어”이고 우리는 “소프트웨어”를 다룬다는 점을 부각시키기 위해서다. 애자일 멘토들이 말하는 “변경을 받아 들이라”는 가치는, 한국의 소프트웨어 개발자에게는 과하게 이상적이란 생각이 든다.

그럼에도 불구하고, 소프트웨어는 원래 변경이 발생하는 것이 속성이며, 소프트웨어 개발자의 존재 이유는 그 변경을 처리하는 것이라 생각한다. 프로젝트에 관여하고 있는 등장 인물들의 역할을 잠깐 생각해 보자.

• 고객은앞 절에서 말한 광의의 고객 도메인 전문가 들이다.
• 우리들의 역할은 소프트웨어 설계라는 고도의 전문적인 기술을 가지고, 도메인 전문가들이 풀고자 하는 문제를 풀 수 있도록 도와주는 것이다.

우리의 설계를 담은 최종 서비스를 사용하는 것은 우리 자신이 아니라 고객이다. 우리는 도메인을 잘 모르고, 그들이 처한 상황을 잘 모른다. 변경이 발생하는 원인도 생각나는대로 나열해보자.

• 계획이 틀렸을 수 있다.
• 고객의 시장 또는 경쟁 환경이 변했을 수 있다.
• 고객이 더 효율적으로 일하는 방법을 찾았거나, 일하는 프로세스가 바뀌었을 수 있다.
• 설계가 틀렸을 수 있다=bug.

우리보다 더 제품에 대해 더 많은 지식을 가진, 그들이 항상 옳고 그들의 변경 요구사항을 처리해 주는 것이 우리의 존재 이유다.

처음부터 완벽한 계획도 없고, 처음부터 완벽한 시스템도 없다.

---