[소프트웨어 장인] 7장 기술적 실행 관례

특정한 기술적 실행 관례가 실제 비즈니스에 가치가 있다면 어떤 부분이 그러할까?

올바른 일 vs 올바른 실행

애자일 방버론이 폭포수 모델이나 문서 기반의 다른 방법론보다 더 낫다고 생각한다. 애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 우리가 ‘올바른 일(Right Things)’을 실행하고 있는지 점검하도록 도와준다.

일을 올바르게 제대로 수행하고 있다는 것은 어떻게 알 수 있을까?
소프트웨어 장인정신은 기술적 실행 관례에 집중함으써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다. 기술적 실행 관례들은 우리가 일을 ‘올바르게’하고 있는지 알 수 있게 해준다.

상황 논리

왜 XP 실행 관례들을 이용하지 않는지 물으면 많은 개발자들이 제대로 대답하지 못한다. 몇 년 동안 가장 많이 들은 대답은

“당신은 우리 회사를 모릅니다. 같이 일하는 사람들이 어떤지 몰라서 그래요. 이런 것들은 우리 회사에서 제대로 될 수가 없어요. 이런 걸 하도록 상사가 어락하지도 않을 겁니다. 소프트웨어 장인정신의 개념들에 공감하지만 내가 일하고 있는 팀은 그렇지 않습니다. 내가 지금 무슨 말을 하고 있는지 우리 팀에 과서 직접 일을 해보면 이해가 될 겁니다.”

그 개발자들의 말이 맞다. 그 개발자가 처한 상황을 모두 알 수는 없기 때문에, 이론적으로 뭔가 결론을 낸다는 것이 무리다.
오랫동안 여러 프로젝트와 여러 회사들에서 일한 경험으로 볼 때, 그 회사에서 어떤 일이 일머나고 있을지 짐작해보는 것은 어렵지 않다. 공통으로 안고 있는 같은 문제들도 많다. 서로 업무 방식이 다르더라도, 소프트웨어 개발 역량 부족, 느린 대응 속도, 관려주의 등과 같은 비슷한 문제로 불안한 상태인 것은 예상 가능하다. 이러한 문제들을 풀기 위해, 기계적으로 따르기만 하면 문제가 해결되는 단순한 처방전 같은 해결책을 찾는 회사들이 많다.

애자일 방법론을 도입하여 일하는 방식을 바꾸기 전에 우리가 어떤 상황에 놓여 있는지 파악하는 것은 대단히 중요하다. 업무 절차가 바뀌면 역할과 책임 그리고 정보의 흐름에 영향을 줄 수 있기 때문에 현재 처한 상황에 대한 이해가 바탕이 되어야 한다.

익스트림 프로그래밍의 역사

많은 애자일 코치와 컨설팅 회사들은 애자일의 절차적인 관례가 XP 실행 관례보다 더 중요하다고 판단했다. 진실은 XP 실행 관례를 가르칠 만큼 충분한 역량이 있는 애자일 코치와 컨설팅 회사가 매우 드물다는 것이 문제다.

애자일 전환의 후유증과 실패 사례들을 볼 때 XP 실행 관례가 저절로 적용되기는 커녕 완전히 무시되었다.

실행 관례와 가치

XP 실행 관례들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공한다.

사람들은 우리가 원하는 대로 행동하도록 프록램할 수 있는 기계가 아니다. 단순히 실행 관례를 공표했다고 해서 기대하는 결과가 나오지 않는다. 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다.

XP 실행 관례로부터 성과를 얻으려면 진심으로 받아들이고 내재화 해야 한다. 실행 관례를 꾸준히 실행하지 않고 부분적으로 하다가 안 한다면 그것이 실제 효과가 있는지는 알 수가 없다.

실행 관례가 효율적이라면 반드시 모든 팀 구성원들에 의해서 그 가치가 납득되어야 한다.

어떤 가치를 중요시한다고 말하는 것만으로는 부족하다. 우리는 그 사람이 말하는 가치와 행동이 일치하는지 봐야 한다. XP 실행 관례가 실천되고 있는지는, 가치를 실현하고 있는지 알아볼 수 있는 척도다.

소프트웨어 장인정신 모임에서 “어떠헤 하면 팀에 TDD 나 페어 프로그래밍같은 것들을 도입하도록 설득할 수 있는가?”라는 질문을 자주 듣는다.

설득하려 하지말고, 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다. 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다.

실행 관례를 통한 가치 창출

상황 논리가 항상 의미가 있을까? 프로젝트가 성공할 확률을 높이기 위해 우리가 할 수 있는 일은 없을까? 어떤 실행 관례들이 빠르고 짧은 피드백 루프를 제공해 줄 수 있을까?

자동화된 테스트

자동화된 테스트는 클릭 한번으로 전체 시스템을 단 몇 분만에 검증할 수 있게 해준다. 자동화된 테스트가 있으면 코드를 수정한지 몇 분만에 안심하고 상용 릴리즈에 반영할 수 있다. 코드가 올바른지 알려주는 피드백 루프가 몇 주에서 몇 분으로 줄어 들면 실수를 거의 즉시 고칠 수 있다.

QA를 통한 정규적인 전체 시스템 테스트는 수동으로 수행되기 때문에 시스템이 커질수록 테스트 단계가 더 질어진다. 양산에 적용될 코드를 작성하기 전에 테스트 코드를 먼저 작성하면 시스템이 커지더라도 빠른 작업 속도를 유지할 수 있다. 새로운 기능을 추가할 때 다른 부분들이 망가질 두려움을 덜 수 있기 때문이다.

자동화된 테스트는 실제 측정 가능한 비즈니스적 가치를 가져다 준다.

테스트 먼저

테스트 코드를 먼저 작성하면 여러 가지 장점이 있다. 아이디어를 생각해내는 데도 도움이 되고 한번에 하나씩만 집중할 수 있다. 모듈, 클래스, 함수를 구체적으로 정의하도록 강제하여 일을 점진적으로 진행할 수 있다. 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것이라고 강하게 확신할 수 있다.

테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩하도록 유도하여 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다. 이러한 것들이 바로 비즈니스적인 가치다.

테스트 주도 개발

테스트 주도 개발(TDD)은 테스트 코드를 먼저 작성한다는 것의 진화된 버전이다. 가장 흔한 오해가 TDD 를 단위 테스트와 동일하게 생각하는 것이다. TDD 는 테스트 단위가 어느 정도로 작아야 하는지 강제하지 않는다.

TDD 의 이름 자체에 ‘테스트’가 들어 있기는 있지만 사실 TDD 는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.

그 첫 번째 이유는 정확히 요구사항만큼만 만족시키는, 즉 테스트로 규정된 부분만 작성하게 되기 때문이다. 첫 설계 단계에서는 요구사항을 확대 해석하고 미래에 있을지 모를 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는(BDUF:Big Design Up Front) 경향이 있다. TDD 는 그렇게 되지 않도록 막아 준다.

두 번째는 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다. 테스트 대상 코드가 잘못된 설계와 과도한 복잡도를 가지고 있으면 새로운 테스트 코드를 작성하기가 점점 어려워진다. 이렇게 테스트 자체가 어려우면 설계를 재검토하고 코드를 더 단순하게 리펙로링하는 긍정적인 원인이 된다.

TDD 에 의해서 주어지는 피드백은 정규적인 설계 리뷰 미팅보다 훨씬 빠르고 객관적이다. 새로운 기능이나 수정 방향이 테스트로 드라이빙되면 기존 코드의 유지보수 용이성에 대해 거의 즉시 피드백을 받게 된다. 설계 리뷰는 물론 좋은 것이지만 TDD 와 비교하면 두 가지 면에서 단점이 있다.

첫 번째는 설계 리뷰가 너무 잦으면 무엇이라도 기여하고픈 참여자의 욕구로 인해 객관성을 잃고 오버 엔지니어링이 되기 쉽다. 설계 리뷰 미팅을 자주하는 것은 바람직하지 않다. 변경 사항이 너무 크다면 더 작은 단위, 점진적인 단계로 나누어서 다루어야 한다.

반면에 TDD 는 코드 한 줄마다 문제가 발생하는 즉시 피드백을 준다. TDD 는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다. 또한 코드에 대한 살아 움직이는 문서 역할을 한다. 이러한 것들이 TDD 가 주는 비즈니스적인 가치다.

지속가능한 통합

아무리 작은 팀이라도 서너명으로 구성된다. 어떻게 하면 서로의 발을 밟지 않고 일을 할 수 있을까

한 가지는 전담 QA 팀을 통해서 시스템이 여전히 제대로 동작하는 변경점마다, 통합 때마다 테스트하는 것이다. 테스터는 수동으로 사전에 정해진 테스트 시나리오를 구동하고 결과를 리포트한다. 이것이 피드백 루프가 된다.

지속적인 통합은 TDD 와 함께 수행되어 이러한 피드백 루프를 단 몇 분으로 줄일 수 있다. 시스템이 항상 배포 가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다는 장점이 있다.

지속적인 통합과 TDD 를 함께 할 경우 QA 팀의 부담이 크게 줄어들거나 아예 팀 자체가 필요 없어질 수 있다. 가장 훌륭한 테스터는 자동화된 테스트를 개발하여 개발자를 돕고 비즈니스 분석가와 제품 오너가 사용자 시나리오에 따른 제품의 적합 기준을 정의하는데 도움을 주는사람이다.

훌륭한 테스터는 자동화하기 어려운 임의의 사용자 시나리오에 집중하여 개발자를 돕는다.

페어 프로그래밍

코드 리뷰를 아예 하지않는 팀은 버그를 가득 안은 코드가 문제를 일으킨 몇 달 뒤에나, 손을 쓸 수도 없는 상태에서 피드백을 받을 것이다.

페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다.

같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다. 더불어 코딩 표준을 정의하고 유지하는 데도 도움이 된다. 이러한 것들이 바로 가치다. 즉각적인 피드백 루프가 만들어진다.

리펙토링

개발자들은 이해하기 어려운 코드를 만났을 때 그것을 개선해보려 하기 보다는 그대로 내버려둔다. 괜히 수정했다가 코드를 망가뜨릴 수 있기 때문이다. 그래서 작은 워크 어라운드들과 늘어나는 속도도 빨라진다. 지저분하고 엉망인 애플이케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다.

레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 실용적인 관념 없이 리펙토링하는 것은 의미가 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다. 이것이 리펙토링의 비즈니스적인 가치다.

책임감

이와 같이 각 실행 관례들의 가치를 설명함에도 불구하고 여전히 많은 사람들이 받아들이기를 거부한다.
‘실행 관례들 없이도 좋은 소프트웨어를 쉽게 개발할 수 있다’ 라는 말들이 여전히 반복해서 들린다.

구글에서 실해한 소프트웨어 프로젝트 비율을 검색해보면 얼마나 많은 프로젝트들이 이런 저런 형태로 실해팼는지 여러 자료와 통계를 찾아볼 수 있다.

개발자든 프로젝트 매니저이든, 비즈니스 담당이든, 이러한 실행 관례를 원하지 않는다고 하면 귀담아 들어야 한다. 기분 나쁘게 생각하거나 그런 사람의 지식 부족을 의심할 이유는 전혀 없다. 우리는 그런 사람들과의 대화에서 배워야 한다. 앞선 섹션에서 설명된 가치들을 이야기 한 후 “이러한 실행 관례보다 더 나은 방법이 있습니까”라고 되물어야 한다.

우리의 의사 결정에 책임감을 가져야 한다. 여기에는 실행 관례를 도입하지 않는 결정도 포함된다. 우리는 이러한 결정들을 기록하고 문제가 있을 때 에스컬레이션 해야 한다.

실용주의

기술, 방법론, 실행 관례들은 계속 개발되고 진화 중이다. 어떤 일이든 항상 더 좋은 수행 방법이 있다. 그것들이 유일한 실행 관례들이거나 모든 상황에 적합한 것은 아니다.

실용주의는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다. 누군가가 이야기했기 때문에, 또는 그 실행 관례 도입을 위한 도입을 해서는 안된다.

무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.

어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해 보는것이다.

특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다. 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.

요약

많은 개발자들이 그들의 관리자나 동료 개발자들에게 새로운 기술적 실행 관례를 수용하도록 설득하는 데 어려움을 겪고 있다. 그 이유는 그 실행 관례의 도입이 프로젝트에 어떤 가치가 있는지 설명하는 데 실패하기 때문이다. 기술적 실행 관례를 따르는 것은 노력과 비용이 수반된다. 새로운 실행 관례에 팀이 익숙해지는 데는 학습 곡선이 필요하다

실행 관례에 대한 도입을 이야기하기 전에, 먼저 우리가 이루려는 것이 무엇인지 논의해야 한다. 소프트웨어 개발/납품 절차 중에서 어떤 부분을 얼마만큼 개선하길 원하는가? 이러한 것이 정의되고 나면 그것을 달성하기 위해 어떤 실행 관례를 도입할지 말할 수 있다.

참조

• 소프트웨어 장인