[소프트웨어 장인] 15장 실용주의 장인정신

안타깝게도 대부분 저급 품질의 싸고 빨리 만들 수 있는 코드를 선택하는 상황이 현실이다. 이 장에서는 ‘고품질은 고비용’이라는 것이 편견임을 설명한다.

품질은 선택사항이 아니다

비용이나 시장 타이밍과 같은 트레이드오프 문제만 없다면 누구든 품질이 높은 쪽을 원한다. 일부러 낮은 품질을 원하는 사람은 없다. 그 어떤 관리자나 고객도 나쁜 품질의 소프트웨어를 바라지 않는다.

가장 근본적인 문제는 싸고 그저 그런 코드로도 충분하다는 매우 잘못된 가정을 할 때가 많다는 것이다. 단기적으로는 그럴 수도 있다. 하지만 중장기적으로는 절대 그렇지 않다. 쓰레기 더미가 굴러 점점 커지면 싼 것이 더 이상 싸지 않게 된다.

고객이 어떤 결정을 하든지 간에, 심지어 저품질을 선택해야 하는 경우에서도 항상 품질이 좋기를 희망한다. 그 어떤 경우에도 비용을 지불한 서비스의 결과물에 문제가 발생하는 일은 좋아하지 않는다.

좋은 품질은 비싸고 시간이 오래 걸릴까

기능 구현을 완료했다는 의미는 그 기능이 상용 시스템이나 상용시스템과 비슷한 내부 검증 환경에 전개되었다는 의미다. 소프트웨어 장인은 지속적인 통합과 프로젝트 초기부터의 제품 딜리버리를 목표로 하기 때문에 소프트웨어 품질로 인해 상용 릴리즈가 지연되는 일은 가정에 없는 사항이다.

어떤 실행 관례를 배우고 마스터하는 데는 시간이 필요하다. 배우는데 시간이 든다고 해서 그 실행 관례가 나쁘다고 할 수 없다. 실행 관례를 무시하는 대신 경험 많은 소프트웨어 장인을 더 많이 확보하여 팀 구성원들의 학습 곡선을 멘토링하는 데 관심을 기울여야 한다.

테스트 주도 개발이 항상 필요할까

도구나 실행 관례를 선택할 때는 실제로 처한 맥락을 반드시 고려해야 한다. 한 가지 안타까운 것은 TDD 에 능숙한 사람 중에는 그런 말을 하는 사람이 없다는 점이다. 실행 관례에 의문을 표하는 사람들은 그들이 뒤에 남길 골칫덩이에 대해서는 인지하지 못하고 당장 뭔가를 만들어 내는 것에만 집중한다.

경험 많은 XP 개발자들은 모든 것을 테스트 기반으로 수행한다. TDD 에 능숙한 개발자들은 TDD 때문에 개발이 지연되었다거나 시간이 없어서 테스트를 작성하지 못했다는 변명은 절대 하지 않는다. TDD 등 XP 실행 관례를 전파하고 싶다면 먼저 스스로 충분히 능숙해져야 한다.

리펙토링

리펙토링을 위한 리펙토링은 시간낭비다. 할 일이 없어서 시간이 남아 도는 것이 아니라면, 특별한 이유도 없이 코드를 열어서 재정리하는 일은 아무런 의미가 없다. 그렇게 하는것이 나쁘다는 것은 아니지만 실용적인 관점에서는 그저 시간 낭비일 뿐이다.

TDD 의 레드/그린/리펙터 라이프 사이클에 맞추어 작은 리펙토링들을 연속해서 적용한다. 먼저 동작하게 만든 후 점진적으로 개선해 나간다. 분명한 필요에 의해 시스템을 변경하고, 그 와중에 작은 리펙토링을 꾸준히 하는 것이 실용적인 관점에서 바람직한 애플리케이션 개선 방법이다.

소프트웨어 개발 방법의 한 가지 예

소프트웨어 장인 정신 운동의 가장 큰 목적은 소프트웨어 개발이라는 업무의 수준을 기술적, 사회적으로 높이는 것이다.

기존과는 다른 사고 방식과 이데올로기를 전파하여 소프트웨어 개발 직무의 위상을 높이고자 한다. 더불어서 현재 가장 바람직한 것으로 평가되고 있는 여러 기술적 실행 관례들의 사용을 장려하고 있다.

개발자로서의 여정을 이제 막 시작해서 어떤 것이 좋은지 판단할 경험이 부족한 사람들에게는 소프트웨어 장인정신 운동에서 권장하고 있는 실행 관례들을 따르길 권한다. 커리어 사다리를 올라가면서 경험이 쌓이면 스스로 더 나은 다른 방법을 찾고, 실제 프로젝트에서 시도해보아야 한다.

실황 관례와 절차들은 그보다 더 나은 실행 관례와 절차가 나타나기 전까지만 가치가 있다. 프로그래밍 언어나 개발 도구에서도 마찬가지다.

장인이라면, TDD 와 같은 XP 실행 관레들을 절대 불변의 진리라고 믿어서는 안 된다. 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리의 진화를 멈추게 된다. 특정 기술이나 실행 관례, 도구들에 대해 개별 상황에 대한 이해 없이 절대적, 교조적으로 판단하는 것은 소프트웨어 장인정신이라 할 수 없다. 여러 가지 훌륭한 도구들을 포용하면서 맡은 일의 맥락에 가장 적합한 것을 꺼내어 적용할 수 있어야 한다.

특정 실행 관례를 사용하지 않는다는 이유로 누군가를 프로페셔널하지 않다고 성급하게 폄하해서는 안 된다. 그들이 사용 중인 실행 관례가 무엇인지 물어보고 당신이 사용하고자 하는 실행 관례와 비교해서 그들의 것이 어떤 점에서 더 나은지 찾아보아야 한다.

비즈니스 돕기

진정으로 원하는 바가 무엇인지 비즈니스 담당자 스스로도 잘 모르는 프로젝트들을 흔하게 볼 수 있다. 애자일 코치들은 개발자들이 비즈니스 담당들과 직접 대화하면서 질문하고 솔루션을 제안할 것을 권장한다.

문제는 큰 그림에서는 목표가 무엇인지 모두 알고 있었지만 구체적인 수준에서는 모든 것이 모호하고 복잡하다는 것이다. 가장 좋은 방법은 뭐든 최대한 빨리 만들어서 이들 앞에 내놓는 것이다. 비즈니스 담당이 마음을 바꾸는 것과 거의 같은 속도로 코드를 바꿀 수 있어야 한다. 이렇게 비즈니스 담당들이 그들의 아이디어를 가지화하고 그 애플리케이션을 사용할 사람들로부터 피드백을 받을 수 있다.

단순하고 빠른 솔루션

‘빨리 만들었다는 것이 엉망이다’라는 것이어선는 안 된다. 요점은 기능을 수직으로 자르느냐 수평으로 자르느냐도, 테스트를 작성해야 하느냐의 여부도 아니다. 개발팀 차원에서 비즈니스를 도울 방법을 찾아서 실행했다는 점에 주목해야 한다. 소프트웨어 프로젝트에서 예측 못한 변경의 양 자체는 문제가 아니다. 문제는 그러한 변화를 따라갈 수 있는 역량의 부족이다. 잘 작성된 소프트웨어는 고객에게 가치를 제공하기 위한 수단이다.

소프트웨어 프로젝트는 우리를 위한 것이 아니다

프로페셔널로서, 소프트웨어 프로젝트가 개발자를 위한 것이 아니라는 사실을 이해할 필요가 있다. ‘나는 내가 뭘 하는지 알고 있고 나는 테스트를 작성할 필요가 없다’라는 태도는 이기적이고 오만한 것이다. 프로젝트는 한두 명의 슈퍼 개발자를 위한 것이 아니다. 프로젝트를 수행한 사람들이 떠나간 후 그것을 유지보수할 사람들을 고려해야만 한다. 원저작자들 없이 소프트웨어를 진화시켜야 하는 회사의 어려움을 이해해야 한다. 프로젝트에 추가하는 가치들이, 원저작자들의 참여를 조건부로 한다면 그것은 가치가 아니다. 그것은 실패 요인이다.

비범함과 평범함

비범한 개발자와 평범한 개발자를 가르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐이다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적인 개발자가 이해하는 데 아무런 문제가 없도록 한다.

비범한 개발자들은 심지어 단순하고 짧은 솔루션 이상의 것을 추구한다. 그들은 코드 한 줄도 짜지 않고 문제를 해경할 방법을 찾는다. 가장 훌륭한 코드는 작성할 필요가 없는 코드다. 코드는 버그와 고통의 근원이다. 더 적게 작성할수록 더 좋다.

단순한 설계를 위한 네 가지 원칙

켄트 벡이 말한 ‘단순한 설계를 위한 네 가지 원칙’

1. 모든 테스트를 통과해야 한다.
2. 명료하고, 충분히 표현되고, 일관되어야 한다.
3. 동작이나 설정에 중복이 있어서는 안 된다.
4. 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

많은 사람들이 이 네가지 원칙을 다른 방식으로 표현한다. J.B 레이인스버거의 버젼

1. 모든 테스트의 통과
2. 중복의 최소화
3. 명료성의 최대화
4. 구성요소의 최소화

좋은 네이밍과 비즈니스 콘셉트를 잘 투영한 추상화에 집중한다. 이 접근 방법이 도메인 기발 설계, SOLID 원칙과 결합되면 꽤 괜찮은 코드를 만들어 낼 수 있다.

디자인 패턴

1990년대에는 디자인 패턴 책을 참고하지 않고 단 한 줄이라도 코드를 작성할 생각은 할 수가 없었다. 모든 것이 범용적이도록 설계했기 때문에 과잉 엔지니어링에다가 상당히 복잡한 솔류션을 유도했다. 그야 말로 미래를 위해 모든 것이 일반화, 범용화해야 했다.

충족시켜야 할 실제 비즈니스 기능보다 개발자가 적용한 디자인 패턴을 알아보는 것이 훨씬 더 쉽다. 범용 코드는 물론 좋다. 하지만 공짜가 아니다. 코드가 범용화될수록 더 복잡해진다.

TDD 를 기본으로 하여, 애자일과 XP 실행 관레를 몸에 익히면, 당장의 필요를 충족시키는 구체적인 코드를 작성하는 것으로 옮겨가게 된다.

패턴을 위한 리펙토링

TDD 에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다. 테스트 코드는 비즈니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것은 아니다. 코드는 테스트 통과에 꼭 필요한 만큼만 작성된다.

실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다. 그렇게 하면 전체적인 복잡도를 낮추는 데 도움이 된다. 다연하지만 복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다.

디자인 패턴 자체가 나쁜 것은 아니다. 하지만 패턴이 먼저가 아니다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리펙토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다.

장인정신과 실용주의

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.

요약

품질은 비싼 것이 아니다. 스킬 부족이 잘 작성된 코드를 비싼 것으로 만드는 원인이다. TDD 가 개발자를 느리게 만들지는 않는다. 새로운 스킬, 새로운 실행 관례, 새로운 기술을 배우고 마스터하는 것은 병목점이 된다.

장인으로서 우리의 역할은 특별히 이슈가 되지 않을 정도까지 품질 비용을 낮추는 것이다. 그렇게 하기 위해서는 좋은 실행 관례들을 마스터하고 실용주의적인 입장을 취할 필요가 있다. 함께 일하는 고객이 품질에 대해서는 걱정하지 않게 해야한다.

참조

• 소프트웨어 장인