[CHAPTER 7] 기술적 실행 관례

지금까지 읽은 내용으로 기술적 실행 관례가 얼마나 중요한지 알 것이다.

그렇지만 관리자 입장은 비지니스로 체감을 못하는 경우가 많다.

 

이번 챕터에서는 기술적 실행 관례를 도입할 때 동료나 관리자를 설득하는데 도움이 될 내용으로 구성되어있다.

 

올바르 일 vs 올바른 실행

애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 우리가 올바른일을 실행하고 있는지 점검하도록 도와준다...
이러한 실행 관례들이 애플리케이션의 품질 사애가 어떠한지는 알려주지는 않기 때문에 이 부분에서 문제가 된다.
품질 상태가 비즈니스의 발목을 잡을 정도로 나쁘다는 사실을 깨달았을 때는 이미 많이 늦었을 가능성이 높다.

코드가 망가지고 있는지를 비즈니스 담당이 눈치채기는 대단히 어렵다, 반면에 개발자가 그것을 숨기는 것은 너무나 쉽다. 

사용자는 내부코드를 이해하지 못하니, 개발자가 사용자를 속이기 매우 쉽다.

더군다나 겉으로는 소프트웨어가 정상적으로 작동하기 때문에 알기가 더 어렵다.

그런 사용자가 품질 상태를 깨달았을 때에는 개발자가 겉으로 숨기지 못할 정도로 최악이란 뜻이다.

 

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

 

 

상황 논리

익스트림 프로그래밍(XP)의 실행 관례들을 여러모로 활용한다.
테스트 주도 개발(TDD), 페어 프로그래밍, 리팩토링, 단순한 디자인, 지속적인 통합 등이 있다.

실행 관례는 흔하게 접할 수 있는 개발 방법론이라 정보를 찾아보기 매우 쉽다.

 

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

애자일 방법론 도입에 한정하지 않아도 많은 곳에서 활용할 수 있는 좋은 내용이다.

비즈니스 관점이든 기술적 관점이든 분야에 상관없이 문제가 무엇이고, 이를 해결할 방안이 있는지 찾으려면 현재의 상황을 이해해야 한다.

그래야 대안이 나왔을 때 대안에 따른 영향을 미리 살펴볼 수 있다.

 

 

실행 관례와 가치

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

안타깝게도 상급 관리자들에게...(생략) 페어 프로그래밍이나 TDD의 가치를 이해시키기는 어렵다.
"그런 것들이 비즈니스적으로 어떤 가치가 있나?"
"그런 기술적 관례가 우리에게 주는 가치를 어떻게 측정할 수 있나?" 라고 되묻는다.

기술적인 요소보다 영업적인 요소를 추구하는 상급 관리자를 설득하는건 매우 어려운 과제이다.

개발자 입장에서 이런 상급 관리자를 설득하려면 어떻게 해야할까?

 

저자는 실행 관례들의 비즈니스 가치를 다음과 같이 말한다.

자동화된 테스트 : 자동화된 테스트는 클릭 한번으로 전체 시스템을 단 몇분만에 검증할 수 있게 해준다. QA를 통한 정규적인 전체 시스템 테스트는 수동으로 수행되기 때문에 시스템이 커질 수록 테스트 단계가 더 길어진다.

테스트 먼저 : 테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 필요한 만큼 코딩하도록 유도하여 오버엔지니어링을 줄여준다.

테스트 주도 개발 : 테스트 코드를 먼저 작성한다는 것의 진화된 버전이다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다. 첫번째 이유는 정확히 요구사항만큼만 만족시키는 부분만 작성하게 된다. 두번째는 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다. 

페어 프로그래밍 : 페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다. 단, 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 페어를 바꾸는 것이 좋다. 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다.

리펙토링 : 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 벅가 만들어질 가능성을 낮춘다. 몇 년동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.

 

 

실용주의

실용주의는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다...

우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다...

무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다...

특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야한다...

개방적인 사고 방식을 가져야 한다.

말그대로 실용주의다.

현재보다 더 효율적이고 효과적인 방법이 생긴다면 변화를 수용해야한다.

 

---

후기 

나는 이전 회사에서 직접 수동으로 테스트를 진행했다. 자동화 테스트가 있는지도 몰랐던 경험 때문에 기술적 실행 관례에 대한 이야기가 많이 와닿았다. 넥스트스탭의 TDD Clean Code With Java 교육과 패스트캠퍼스, 이규원의 현실세상의 TDD로 자동화 테스트의 가치를 직접 느꼈다.

 

이런 생각을 해본다.

이전 경험으로 다시 되돌아간다면 지금 배운 개념과 기술적 실행 관례를 도입할 수 있을까?

플랫폼 확장과 유지보수에 시간이 부족해서 제대로 도입하지 못하지 않을까?

개인적으로 희생을해서 매일 야근하고 주말 출근하면서까지 도입하면 어땠을까?

 

아쉬움이 남지만 이 잘못된 경험들을 바탕으로 부족했던 부분을 학습하고 나아갈 수 있지 않을까 위안을 삼아본다.