소프트웨어 개발에서 우리의 핵심가치와 실천사항은 무엇인가?
* 이 글은 여전히 직접 개발하는 수석 기술자[1] Evan Bottcher가 ThoughtWorks 블로그에 올린 What are our core values and practices for building software?을 번역한 글입니다.
올해 들어, 소트웍스에서 개발자로 근무하면서 내 경력과 인생에서 어떤 의미가 있는지 많이 생각하게 되었다. 그 중에는 훌륭한 사람들과 함께 일하는 점이 돋보인다. 그들은 신뢰와 정직은 기본이고, 소프트웨어 산업 증진에 필요한 추진력도 골고루 갖추고 있다. 소프트웨어를 구축하는 기술을 보면, 우리 회사에서 통하는 근본적인 소프트웨어 공학 가치는 여느 열정 있는 개발자 커뮤니티에서도 통용된다. 그러한 핵심 가치와 그것을 지원하는 실천사항에는 어떤 것이 있는지 밝히고자 이 글을 쓴다.
나는 핵심 가치로 네 가지를 선택했다. 이러한 가치는 수작업 배포의 노력과 위험을 줄이려고 스크립트를 작성하거나, 새로운 모바일 애플리케이션을 구축하여 쇼핑을 즐기게 하거나, 테라 바이트의 데이터를 처리할 때도 응용할 수 있다.
그림1: 핵심가치와 실천사항
그리고, 여덟 가지 핵심 실천사항이 있는데, 각각은 한 개 또는 여러 핵심 가치를 지원한다. 실천사항은 우리가 실제로 수행하는 조치, 즉 우리가 적용하는 방법 또는 접근 방식이다.
이러한 가치와 실천사항은 새로운 것이 아니고, 일부는 XP에서 추구하는 가치와 실천사항을 가져온 것이다. 나는 여기서 핵심 가치와 실천사항을 줄여서 일부에만 집중하려고 한다. 그리고 우선순위는 내가 임의로 정한 것임을 밝힌다.
핵심 가치
위 그림에서 가장 안쪽에는 네 가지 핵심 엔지니어링 가치가 있다.
빠른 피드백: 우리는 변화가 성공했는지 아는데 며칠 걸려서가 아니라 바로 파악하는데 가치를 둔다. 이를테면, 단위 테스트를 통과했는지, 장애 발생 없이 돌아가는지, 고객은 우리가 구축한 새 시스템에 만족하는지 등이다.
재현능력: 우리는 자신감과 예측 가능성에 가치를 두는데 이들은 이상한 모순을 야기하는 수작업을 제거함에 따라 얻어지는 것들이다. 또한 원래 잘 작동해야 하는데, 안 되는 문제를 해결하는 것보다는 더 중요한 활동에 시간을 보내기를 원한다.
단순함: 우리는 일을 하는데 필요한 수준의 복잡도를 넘지 않는 소프트웨어를 소중히 여긴다. 우리는 지금 당장 필요한 것을 만들어야지 필요할 것으로 예상하는 것을 구축해서는 안된다. 하지만 우리는 향후 요구사항을 신속히 수용할 수 있는 선택을 해야 한다.
핵심 실천사항
그림에서 가치를 둘러싸는 테두리는 8개의 핵심 엔지니어링 실천사항으로서, 핵심 가치를 지원하는 방법이다. 이 기사에서는 각 핵심 실천사항에 대해서는 상세히 설명하지 않는다. 각 방법을 설명하는 참고 문헌이 충분히 있기 때문이다.
'데브옵스DevOps' 업무를 맡고 있는데, 나도 해당되는가?
우리들 중 몇몇은 특정 기술 분야에서 통달할 수 있는 경로에 들어선 것으로 확인했다. 깊이 있는 지식을 습득할 수 있는 분야로는 모바일 개발과 데이터 엔지니어링, 클라우드 인프라, 데브옵스가 있다. 몇 년 전에 나는 클라우드 인프라와 자동화를 계획적으로 학습했고, 얼마 동안은 그 분야에서 거의 모든 일을 섭렵했다.
인프라와 자동화 툴을 구축할 때도 애플리케이션 소프트웨어를 구축할 때와 동일한 핵심 가치와 실천사항을 적용했다고 생각한다. 이러한 가치와 실천사항을 지킴으로써, 항상 짧은 피드백 주기로 귀중한 결과를 전달하고, 그 변화의 속도를 지속적으로 유지할 수 있었다.
따라서, 전문 기술 영역도 동일한 가치와 실천 사항의 핵심 위에서 구축될 수 있다고 믿는다. 다음과 같이:
그림 2: 데이터, 클라우드, 모바일, 기계 학습 또는 로봇 공학 분야에서 동일한 공통적인 핵심 가치 및 실천사항을 활용한다.
하지만 나는 MVP[2]를 하고 있는데!
물론, 일시적으로 쓰다가 버릴 소프트웨어를 만들면 좋은 점과 불편한 점이 있다. 그럼에도 여기 있는 것들은 항상 적용되는 핵심 가치와 실천사항이다. 단 기간 내 인도해야 할 때나, 지속 가능 여부가 불확실 할 때도 마찬가지다. 이러한 실천사항을 놓친다면 단 기간 일에서도 더 늦어질 것이다.
핵심 실천사항은 프로토타입 개발, MVP, 테스트 및 학습과 기타 지름길로 갈 수 있는 거라면 다 해당한다. 또 조정할 수도 있다. 예를 들어, 우리는 짧은 기간 동안은 인프라에 대한 투자 수준을 낮출 수 있다. 개발자가 세 명뿐인 팀이 2주짜리 프로토타입을 제작하는 경우, 이들은 중단 없는 통합 서버를 구성하고 문제 해결하는 일에 온종일 투자할 생각은 없다. 그렇더라도 팀은 여전히 지속 통합을 실천해야 한다. 즉, 소프트웨어가 여전히 작동하는지 확인하면서 지속적인 통합을 수행해야 한다. 만일 그렇게 일하지 않으면 늘어난 피드백 주기 때문에 재작업과 지연을 야기하여, 나중에 여유가 없을 때 귀중한 시간을 허비해야 한다.
이틀 정도 일인데도 가설을 입증하려고 테스트중심 설계(TDD, test-driven design)를 써야 하는가? TDD에 집중해서 테스트로 설계를 이끌어 가면서 전체가 아닌 일부에만 적용할 수 있다. 하지만 TDD를 아예 중단한다면, 필요 이상을 구축할 것이 확실하고, 모듈형 설계 기준에 미치지 못해 어려움을 겪을 것이며, 단기간에 완료하기도 어렵고, 이해하기도 힘든 코드를 만들 수 있다.
그래서 어쩌라고?
이들 핵심 실천사항들은 열심히 하는 개발자라면 기본으로 적용하는 것이다. 만일 이러한 핵심 실천사항 절충을 너무 과하게 한다면 그 때는 큰 문제가 생긴다. 자신은 회사 가치와 엇박자로 일하고 태만해지기 때문이다.
만약 당신이 TDD를 사용하지 않는다면? 그렇다면, 설계를 단순화시키고 의미 있는 피드백을 신속히 받을 수 있는 대안은 무엇인지 묻고 싶다. 만일 TDD 대안이 작동하는 것을 확신한다면(또는 작동하지 않는 경우를 안다면) 그걸로 족하다. 페어 프로그래밍을 포함해서 다른 핵심 실천사항도 다를 바 없다. 만약 다른 대안이 효과가 없거나 혹은 두개 이상의 핵심적인 실천사항을 무시해 버린다면, 정말로 걱정할 일이다.
마지막으로, 만일 당신이 이러한 핵심 가치를 인식하는 진보적인 소프트웨어 엔지니어라면, 조직에서는 이러한 핵심적인 실천사항을 적용하는 것을 막더라도 결코 포기하지 마라! 학습시키고, 전도하고, 지지층을 만들고, 사례를 만들자. 자신이 추구하는 가치와 일치하지 않는 방식으로 일한다면 무슨 즐거움이 있겠는가?
편집자 주
[1] 소트웍스 블로그 상에 직함은 TECHNICAL PRINCIPAL / HANDYPERSON으로 소개되어 있다.
[2] Minimum viable product 약자로 Lean 소프트웨어 개발 환경에서 쓰이는 말로 해당 프로젝트(혹은 사업 여정)가 지속하기 위한 최소한의 제품 출시 방식 혹은 단위를 의미한다.