2019.03.11

SW 프로젝트를 산으로… 서툰 리더십 행태 11가지

Peter Wayner | CIO
소프트웨어 개발자들은 ‘해서는 안 될 일’을 경고하는 ‘안티패턴(Antipattern)’이라는 개념을 만들어냈다. 중세 시대 지도의 ‘용이 있는 지역이니 조심’ 표시 같은 것이다. 코드를 구성할 때 적용해서는 안 되는 방법, 아키텍처로 적용해서는 안 되는 방법, 데이터베이스 스키마 디자인(고안)에 적용해서는 안 되는 방법 등이 이에 해당된다. 이런 안티패턴은 오늘날 여러 개발자들이 기능적 디자인 패턴으로 존중을 할 만큼 유용해졌다.

소프트웨어 프로젝트에도 고유의 ‘안티패턴’이 존재한다. 물론 프로젝트 운영과 팀 관리는 코드 개발과 같이 특정한 체계를 적용하기 어려울 수 있다. 또 일부 안티패턴은 서로의 ‘거울상’이다. 같은 것을 놓고, 수용하라기는 이야기와 피하라는 이야기가 공존할 수 있다. 그러나 실제 요구하는 것은 ‘중용’이다. 제 아무리 좋은 개념도 지나치면 팀 관리에 도움이 되지 않는다.

지금부터 소프트웨어 개발 관리와 관련된 11가지 안티패턴을 소개한다. 개발자들을 인도하거나 관리할 때 피해야 할 행동이나 행태로 생각하면 된다.
 
ⓒ Credit: Mubariz Mehdizadeh



‘팀 플레이’라는 안티패턴
로버트 프로스트는 ‘좋은 울타리가 선한 이웃을 만든다’는 말을 즐겨 했다. 사람은 자신만의 공간이 필요하며, 이는 개발자도 마찬가지이다. 사람이 많으면 일이 쉬워질 것이라고 기대하면서, 팀에 더 많은 개발자를 추가 영입하려 들기 쉽다. 그러나 지나칠 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다. 그러면 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.

마이크로서비스 아키텍처는 여러 단점도 가지고 있지만, 개발자에 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다. 코드를 커밋하고, 테스트를 생성하는 등 작업을 해 나갈 수 있다. 이런 단계들을 동조시키려 노력할 필요가 없다. 개발자들이 각자 자신의 공간에서 마음 편히 일을 하도록 만들면 큰 성과를 거둘 수 있다.

‘분할 관리’라는 안티패턴
개발자를 분리시키는 경우, 최종적으로 코드가 서로 함께 작동하도록 만들어야 할 때 문제가 발생할 수 있다. 한 API는 스트링(문자열)을 전달하는 데, 다른 API는 정수(Integers)를 원하는 식이다. 또는 한 팀은 열 데이터를, 다른 팀은 행 데이터를 기대한다. 화이트보드에 급하게 그린 스케치가 다양하게 해석될 수 있다. 그러면서도 각자의 결과물이 모든 테스트를 통과한다. 각 그룹이 각자의 비전을 사용해 자신의 코드에 대한 테스트를 만들기 때문이다.

해결책은 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이다. 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다. 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다. 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.

‘비전을 따르라’는 안티패턴
충분한 ‘돈’이 있다면 무언가 멋진 코드를 만들 개발자들을 채용할 수 있을 것이다. 모든 개발자가 전체 스택에 대한 전체 비전을 전달하는 창의적인 천재성이 폭발하는 것을 상상한다. 동시에 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다. 코드 편집기를 실행시키고 이런 신기루를 향해 달려간 적이 몇 번이나 되는가?

우리에게 방법론이 필요한 이유가 이것 때문이다. 멋진 신기루를 한쪽으로 치워 놓고, 상세한 계획을 구상하도록 만드는 도구를 의미한다. 멋진 상상의 다음 날에 문제점을 파악하기 시작할 수 있다. 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다. 

‘교과서대로’라는 안티패턴
모든 방법론에 ‘반드시 해야 할 일’, ‘반드시 피해야 할 일’을 규정하는 가이드라인, 컨퍼런스, 컨설턴트들이 존재한다. 이런 원칙, 규칙들은 종종 절대적인 권한을 부여받을 채로 강제된다.

문제는 이런 ‘법규’에 완벽하게 들어 맞는 것이 단 하나도 없다는 것이다. 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다. 유연함과 민첩성을 유지하려 시도할 수 있지만, 계획 수립 단계에서 더 쉽게 문제를 해결할 수 있는 것을 예상하지 못하는 실수를 저지른다. 항상 깨닫는 순간이 있다.

유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다. 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.  

‘프로세스 신뢰’라는 안티패턴
창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다. 새 데이터베이스 설치에 얼마나 많은 시간이 소요되었을까? 팀이 SSO(Single Sign On) API를 다시 디자인하기로 약속했던 때는 언제일까? 마지막 코드 스프린트에 남겨진 ‘기술 부채를 리팩터(리라이팅)하기 위해 코드를 확인하는 데 투입된 사람은 몇 명인가?

책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다. 소프트웨어 개발 매트릭스가 부정확할 수 있다. 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다. 




2019.03.11

SW 프로젝트를 산으로… 서툰 리더십 행태 11가지

Peter Wayner | CIO
소프트웨어 개발자들은 ‘해서는 안 될 일’을 경고하는 ‘안티패턴(Antipattern)’이라는 개념을 만들어냈다. 중세 시대 지도의 ‘용이 있는 지역이니 조심’ 표시 같은 것이다. 코드를 구성할 때 적용해서는 안 되는 방법, 아키텍처로 적용해서는 안 되는 방법, 데이터베이스 스키마 디자인(고안)에 적용해서는 안 되는 방법 등이 이에 해당된다. 이런 안티패턴은 오늘날 여러 개발자들이 기능적 디자인 패턴으로 존중을 할 만큼 유용해졌다.

소프트웨어 프로젝트에도 고유의 ‘안티패턴’이 존재한다. 물론 프로젝트 운영과 팀 관리는 코드 개발과 같이 특정한 체계를 적용하기 어려울 수 있다. 또 일부 안티패턴은 서로의 ‘거울상’이다. 같은 것을 놓고, 수용하라기는 이야기와 피하라는 이야기가 공존할 수 있다. 그러나 실제 요구하는 것은 ‘중용’이다. 제 아무리 좋은 개념도 지나치면 팀 관리에 도움이 되지 않는다.

지금부터 소프트웨어 개발 관리와 관련된 11가지 안티패턴을 소개한다. 개발자들을 인도하거나 관리할 때 피해야 할 행동이나 행태로 생각하면 된다.
 
ⓒ Credit: Mubariz Mehdizadeh



‘팀 플레이’라는 안티패턴
로버트 프로스트는 ‘좋은 울타리가 선한 이웃을 만든다’는 말을 즐겨 했다. 사람은 자신만의 공간이 필요하며, 이는 개발자도 마찬가지이다. 사람이 많으면 일이 쉬워질 것이라고 기대하면서, 팀에 더 많은 개발자를 추가 영입하려 들기 쉽다. 그러나 지나칠 경우, 개발자들이 서로 반목하면서 동일한 코드를 업데이트하려 경쟁하게 된다. 그러면 검토할 코드가 많아지고, 그 누구도 코드를 일일이 검토해 통합하기 원하지 않게 된다.

마이크로서비스 아키텍처는 여러 단점도 가지고 있지만, 개발자에 숨쉴 공간을 준다. 독립적으로 자신이 맡은 코드 작업을 할 수 있다. 코드를 커밋하고, 테스트를 생성하는 등 작업을 해 나갈 수 있다. 이런 단계들을 동조시키려 노력할 필요가 없다. 개발자들이 각자 자신의 공간에서 마음 편히 일을 하도록 만들면 큰 성과를 거둘 수 있다.

‘분할 관리’라는 안티패턴
개발자를 분리시키는 경우, 최종적으로 코드가 서로 함께 작동하도록 만들어야 할 때 문제가 발생할 수 있다. 한 API는 스트링(문자열)을 전달하는 데, 다른 API는 정수(Integers)를 원하는 식이다. 또는 한 팀은 열 데이터를, 다른 팀은 행 데이터를 기대한다. 화이트보드에 급하게 그린 스케치가 다양하게 해석될 수 있다. 그러면서도 각자의 결과물이 모든 테스트를 통과한다. 각 그룹이 각자의 비전을 사용해 자신의 코드에 대한 테스트를 만들기 때문이다.

해결책은 더 중앙에서 통제를 하고, 더 중앙에서 테스트를 하는 것이다. 일부 개발자를 지정, 부분들이 가능한 원활하게 함께 작동할 수 있도록 통합을 지속적으로 모니터링하는 일을 맡긴다. 부분들이 함께 작동하도록 만드는 일은 부분들을 구현하는 것만큼 힘든 일이다. 개발자들을 동일한 방향으로 계속 유도하는 것 자체가 하나의 ‘일’이다.

‘비전을 따르라’는 안티패턴
충분한 ‘돈’이 있다면 무언가 멋진 코드를 만들 개발자들을 채용할 수 있을 것이다. 모든 개발자가 전체 스택에 대한 전체 비전을 전달하는 창의적인 천재성이 폭발하는 것을 상상한다. 동시에 모든 개발자가 이런 상상 후, 단 몇 줄의 코드로 모든 기능을 구현하는 ‘초능력’에 대해 상상한다. 코드 편집기를 실행시키고 이런 신기루를 향해 달려간 적이 몇 번이나 되는가?

우리에게 방법론이 필요한 이유가 이것 때문이다. 멋진 신기루를 한쪽으로 치워 놓고, 상세한 계획을 구상하도록 만드는 도구를 의미한다. 멋진 상상의 다음 날에 문제점을 파악하기 시작할 수 있다. 계획 수립은 번거로운 일이다. 그러나 나중에 코드를 디버깅하는 것보다 빨리 할 수 있다. 때로는 다짜고짜 저지르기보다 그저 앉아 있는 게 나을 수 있다. 

‘교과서대로’라는 안티패턴
모든 방법론에 ‘반드시 해야 할 일’, ‘반드시 피해야 할 일’을 규정하는 가이드라인, 컨퍼런스, 컨설턴트들이 존재한다. 이런 원칙, 규칙들은 종종 절대적인 권한을 부여받을 채로 강제된다.

문제는 이런 ‘법규’에 완벽하게 들어 맞는 것이 단 하나도 없다는 것이다. 스펙을 만드는 데 몇 달을 소비하고도, 모든 것이 거의 마무리되었을 때 새로운 각도나 문제를 발견하게 된다. 유연함과 민첩성을 유지하려 시도할 수 있지만, 계획 수립 단계에서 더 쉽게 문제를 해결할 수 있는 것을 예상하지 못하는 실수를 저지른다. 항상 깨닫는 순간이 있다.

유능한 관리자는 방법론을 선택한 후, 이 방법론이 실패할 가능성에 대비한다. 어느 누구도 항상 성공할 수는 없다. 대비가 중요하다.  

‘프로세스 신뢰’라는 안티패턴
창의성을 방해할까 두려워 세부 사항을 계속 추적하지 않으면 악성 결과가 초래될 수 있다. 새 데이터베이스 설치에 얼마나 많은 시간이 소요되었을까? 팀이 SSO(Single Sign On) API를 다시 디자인하기로 약속했던 때는 언제일까? 마지막 코드 스프린트에 남겨진 ‘기술 부채를 리팩터(리라이팅)하기 위해 코드를 확인하는 데 투입된 사람은 몇 명인가?

책임자는 항상 지연을 초래하는 많은 장벽, 장애물, 문제에 직면하게 된다. 책임자의 도전과제는 효율적으로 일어나는 일을 모니터링하고, 현명한 결정을 내리기에 충분한 정도로 세부사항을 계속 추적하는 방법을 찾는 것이다. 소프트웨어 개발 매트릭스가 부정확할 수 있다. 그러나 지나치게 많은 기대를 하지 않으면, 누가 무슨 일을 하고 있는지 추적할 수 있도록 도와준다. 


X