한빛출판네트워크

명확한 피드백 고리와 품질 기준을 갖추고, 비즈니스 가치를 위해 최적화하라

"어떤 조직에서 소프트웨어가 설계되고 개발되는 방식은 그 조직의 문화와 커뮤니케이션 구조를 닮는다." 이 말은 콘웨이 법칙으로 더 잘 알려져있다. 너무 당연하게 느껴지는 이 말을 가볍게 여기다간 개발팀이 효율성과 비즈니스 가치를 이끌어내지 못할 수 있다.  

우리는 운이좋게도 다양한 산업 분야의 클라이언트와 일하며 이들 조직에서 소프트웨어를 어떻게 여기는지 볼 기회가 있었다.  또 경쟁 관계의 조직들이 똑같은 종류의 시스템(예를 들어 ERP)을 두고 완전히 다른 문제를 제기하거나 과제를 던지는 것도 종종 보곤 했다. 이런 경험 끝에 소프트웨어 아키텍처의 품질을 높이기 위해서는 시스템으로부터 가치를 모색하는 모든 프로젝트 멤버가 서로 효과적으로 커뮤니케이션 해야 함을 알 수 있었다.

즉, 소프트웨어 아키텍트/개발자가 아키텍처/코드를 개선하고 싶다면, 조직 구조와 관련된 것도 무시해선 안된다는 뜻이다. 연구에 따르면 소프트웨어 개발은 조직적 요인으로부터 지대한 영향을 받는다. 또, 소프트웨어 품질과 개발 생산성 향상을 위해서 매우 중요한 것은 개발자의 행복과 만족감이다. 결국 기술적 차원뿐 아니라 조직적 차원의 접근도 필요하다. 

개발자들은 일에서 성취감을 느끼고 싶어한다. 개발 조직은 개발자들이 각자의 코딩 스킬을 연마하고 소프트웨어 품질에 더 집중할 수 있는 환경을 만들어야 한다. 개발자들이 행복감과 만족감을 느끼며 지속적으로 고품질의 제품을 만들어낼 수 있도록 말이다. 그뿐만 아니라 조직 역학까지 고려해 개발 프로세스를 최적화해야한다. 

팀의 커뮤니케이션 구조 정의하기

사회적, 조직적 관점으로 봤을 때 개발 프로세스에서 커뮤니케이션 구조는 매우 중요하다. 개중에도 피드백 루프(feedback loop)는 특히 중요하다. 효과적인 피드백 루프에서 전송자는 메시지를 작성하며, 수신자는 그 메시지를 읽고 해석한 뒤 전송자에게 피드백을 제공한다. 적절한 피드백 루프를 마련했는지 여부는 소프트웨어 개발 방향의 명확성에 극단적인 차이를 가져온다. 

개발자와 시스템 혹은 개발자 간의 피드백 루프는 보통 잘 작동한다. 하지만 그 외의 사람들(아키텍트, PM, UX 디자이너, 매니저)이 끼게 되면 완전히 상황이 달라진다. 목표의 명확함, "완료"의 기준, 기술적 선택에 대한 합의가 사라진다.  즉, 판단이 어려울 정도로 비대해진 피드백 루프 하나만 남아버린다는 것이다. 그러므로 피드백 루프를 판단할 수 있도록 커뮤니케이션 대상을 명확히 지정하고, 서로 분리된 여러개의 피드백 루프를 구성하는 것이 중요하다.

소프트웨어 품질 기준을 명확히 세우기

기술적 관점에서 명확성, 그리고 원활한 커뮤니케이션이 중요하다. 한번 상상해보자. 어떤 소프트웨어 개발팀이 조직을 재정비하고  자신들이 만든 시스템에 대해 유지보수성(maintainability)과 같은 비기능적인 요구사항(코드 품질과 관계가 깊은)들을 정의하려한다. 이 팀은 평가 항목을 정해야할 뿐만 아니라  목표 기준과 평가 방법도 정해야한다.  대부분의 경우에는 기준을 세우는데 아예 실패하거나 큰 어려움을 겪기 마련이다.  SIG^{Software Improvement Group}에서 시행한 코드 품질 관행에 관한 조사에 의하면 품질 기준을 적용하는데 실패하는 가장 흔한 이유가 "소프트웨어의 품질은 무엇이고 어떤 기준으로 평가해야하는지에 대한 동의"가 부족하기 때문이라고 한다. 

우리는 여기서 생각을 조금 달리해 소스 코드의 유지보수성은 측정하고 표준화할 수 있다고 주장하고자 한다. 유지보수성은 간단한 가이드라인을 따르는 것만으로도 얻을 수 있어야 한다. 다음 가이드라인은 충분한 유지보수성을 보장한다. 

• 짧고 간단한 단위로 코드를 짜라: 개발자는 코드 덩어리 하나를 15줄 이내로하려고 노력해야한다. 이 단위보다 길게 코드를 작성하지 않고, 이보다 큰 덩어리는 15줄 이내가 될때까지 반복해서 쪼개야한다. 작은 단위의 코드가 이해하기 쉽고, 테스트하거나 재사용하기도 쉽다.
  
  
• 코드는 한번만 작성하라: 코드를 복사해서 사용하는 것을 피하고, 재사용가능하고 범용적인 코드를 작성하거나 이미 존재하는 메서드를 활용해야한다. 이렇게 함으로서 유지보수성을 키울 수 있다. 코드를 복사해서 사용하게 되면 여러 군데를 고쳐야 하므로 비효율적이고 실수하기 쉽기 때문이다. 
  
  
• 모듈 간의 관심사를 분리하라: 개발자는 모듈간의 결합도를 낮추기 위해 모듈들이 커지는 것을 피해야한다. 이를 위해 각각의 모듈의 책임을 나누고 세부 구현은 인터페이스 뒤로 숨겨야한다. 밀접하게 결합된 코드베이스보다 느슨하게 결합된 코드베이스가 변경을 가하고 관리하는 것이 쉽다. 
  
  
• 아키텍쳐 컴포넌트는 느슨하게 결합해야한다: 이것은 다른 컴포넌트의 모듈에 노출시킨 모듈, 즉 다른 모듈이 호출할 수 있는 모듈의 코드를 최소화하는 것으로 가능해진다. 이렇게 함으로써 유지보수성도 증대된다. 독립된 컴포넌트는 독립적으로 유지보수할 수 있기 때문이다.

소프트웨어 팀에서 아키텍쳐 품질을 유지하는게 만만찮은 일이라는것을 알 수 있다. 명확한 피드백 루프와 품질 기준을 토대로한 효과적인 커뮤니케이션이 필요하다. 이와 더불어 비지니스 가치에 맞춰 최적화하기 위해선 조직과 개발 구조 모두에 대해 오랜시간 고민해야한다. 

*****

원문 : Delivering effective communication in software teams
번역 : 고상우