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

‘측정하지 않은 것은 관리할 수 없음’이라는 안티패턴
데이터의 중요성을 강조되면서 새롭게 회자되는 오래된 격언이다. 매트릭스가 나쁘다는 의미는 아니다. 모든 것을 포착할 정도는 되지 않는다는 의미이다. 오래 전, 관리자들은 개발자가 생성한 코드 줄의 수를 계산하려 시도했다. 그러자 개발자들은 주석이나 기능과 상관없는 부분을 추가해 아웃풋(결과물)을 배가시키는 방법을 생각해냈다.

최근 들어, 일부 관리자들은 업무에 추상적인 ‘점수’를 할당하고, 분기 또는 연도 별로 이러한 점수를 합산한다. 그러나 적합한 점수를 파악하는 것은 애초 문제를 해결하는 것만큼 어렵다. 정말 지독한 팀은 더 정확한 평가를 위해 서로를 경쟁시키기도 한다. 이는 팀웍이나 협업에 도움이 되지 않는다.

가장 큰 위험은 개발자들이 힘든 일이나 예측하기 어려운 일을 피하게 되는 것이다. 분기말, 연말에 충분한 점수를 얻게 되지 못할까 우려하는 행태가 번기는 것이다. 해결책은 이런 매트릭스를 지나치게 신뢰하지 않는 것이다. 점수를 추적 관리할 수는 있다. 그러나 이런 점수를 절대적인 척도로 간주해서는 안 된다.

‘어리석은 일관성은 편협한 사람들의 망상’이라는 안티패턴
개발자는 자유로울 필요가 있다. 개발자들에게 질문을 하면, 멋진 새 코드를 혁신적으로 만들어내는 자신의 능력을 억누르지 않았으면 좋겠다는 답이 종종 나올 것이다.

문제는 개발자를 방치하면 전혀 다른 방향으로 나갈 수 있다는 것이다. 일정한 기준이 필요한 이유가 여기에 있다. 코드에 어느 정도 일관성이 있을 때의 장점은 잘 알려져 있다. 패턴과 시각적인 리듬의 예측성이 높을 때, 코드를 더 쉽게 판독할 수 있다.

꽤 괜찮은 해결책이 자동으로 적용될 수도 있다. 규칙을 사용, 규정한 규칙에 부합하도록 모든 코드의 형식을 바꾸는 아톰(Atom) 같은 코드 편집기 등이 있다. (참조: ESLint.) 개발자는 이를 활용, 기준의 세부 사항을 걱정하지 않고도 충분히 깨끗한 결과물을 만들 수 있다.

‘기준이 구원자’라는 안티패턴
현재 소프트웨어 기준이 정말 많다. 신입 개발자들은 항상 더 많은 코딩 규칙을 만나게 된다. 예를 들어, 에어비엔비의 자바스크립트 코드 버전이 인기를 끌고 있다.

그러나 기준이 분노와 적의를 이끌어내고 개발자에게 싸울 또 다른 이유를 주는 경우도 있다.  에어비엔비를 예로 들면, 누군가 코드 사이의 스페이스 위치에 대한 규칙에 많은 시간을 투자했다. 스페이스를 중괄호(Curly brackets) 사이에 집어넣어야 한다(19.11), 꺾쇠 괄호 사이에 집어 넣는 것은 금지되어 있다(19.10). 

주의 깊게 살피면, 개발자들이 이런 사소한 문제 때문에 시간을 낭비하고 있다는 것을 알 것이다. 이들은 기준이라는 말을 사용하는 것을 좋아한다. 기준이라는 말을 사용하지 않으면 큰 일이 일어날 것 같은 생각이 들게 만든다.

사실 이른바 기준이라 불리는 것들 가운데 상당수는 보기 좋게 만드는 역할을 할 뿐이다. 코드 실행 속도, 코드로 적절한 답을 얻는 것에는 차이를 만들지 못한다. 추가적인 여백(화이트 스페이스)는 컴파일러나 인터프리터에 의해 무시된다. 

실행 코드의 품질에 거의 영향을 주지 않는 기준을 강제하는 것은 좋지 않다. 스페이스의 위치 같은 것은 사람을 위한 것이다. 사람들이 지나치게 많은 것을 주장하지 않도록 만드는 데 목적이 있다. 기준을 사용하고 싶다면, 적용하기 쉽고, 실제 유의미한 세부 사항만 신경 쓰도록 단순하게 만들어야 한다.

‘스택 단순화’라는 안티패턴
코드 기반에 원칙을 확보하는 가장 단순한 방법 중 하나는 단 하나의 언어만 허용하는 것이다. 그러면 모든 것이 일관되고, 모든 사람이 쉽게 이해를 할 수 있다. 해당 언어에 대한 스킬이 있는 사람이라면 누구나 채용할 수 있으며, 모든 사람이 함께 협업을 할 수 있다.

멋진 생각이다. 이를 적용하는 것이 합당하게 느껴진다. 문제는 이를 깨뜨리고 싶을 때이다. 매번 자신이 원하는 것을 할 수 있는 기능이 풍부한 오픈소스 코드, 새로운 라이브러리가 등장한다. 문제는 다른 언어로 작성되어 있다는 것이다. 

엄격히 코드 기반의 ‘순정함’을 유지하면, 그 대가로 속도와 효율성을 잃게 된다. 사용자가 코드를 보고 읽을 일은 없다. 코드가 하는 일만 중요하게 생각할 뿐이다. 사용자를 만족시킬 수 있다면, 코드 기반의 이탈을 어느 정도 용인하는 것이 합리적이다. 도전과제는 절충의 가치가 있는 때를 파악하는 것이다.

‘개발자가 직접 도구를 선택’이라는 안티패턴
크리스는 새로운 함수형 언어를 좋아한다. 더 엄격하고, 더 ‘type-checked’ 방식일수록 더 좋다. 반면 패트는 머신 코드에 아주 가까운 ‘클로즈 투 더 메탈’ 코드를 사용하기 좋아한다. 그리고 밥은 최신 헤드라인에 있는 것이면 아무 것이나 상관이 없다.

잘 어울릴 수 있을까?  여러 언어의 코드를 플로우차트에서는 충분히 깨끗하게 보이는 마이크로서비스 형태로 묶을 수 있을지 모르겠다. 각자 좋아하는 언어를 대충 하나로 연결하는 것이다. 언어 선택에 ‘유연성’을 허락하면 새로운 프로젝트를 시작할 때에 인기를 얻을 수 있을 것이다. 

그러나 나중에 문제가 발생한다. 코트린(Kotlin)을 좋아하는 개발자가 팀을 떠나고, PHP를 좋아하는 사람이 코드를 물려 받으면 이를 해독할 수가 없다. 적합한 스킬을 가진 사람들로 팀을 구성해 유지하는 경우에도, 자바스크립트 개발자들은 스위프트(Swift)로 작성된 코드를 확인할 때 고생을 하게 된다.

지나치게 개방적으로 모든 것을 수용해서는 안 된다.

‘성공의 열쇠는 동기 부여’라는 안티패턴
내 옆에 앉은 동료가 표준 라이브러리에 한 줄로 가능한 코드 대신, 2배나 많은 코드를 쓴 이유가 무엇일까? 그럴만한 이유가 있었다. 상사가 기트(Git) 레포지토리에 라이브러리 디렉토리에 추가되는 것에 대한 추가적인 검토 계층을 강요하는 덫을 놓았고, 검토를 담당한 사람은 변덕이 심하기로 유명한 사람이기 때문이었다.

몇 주 뒤, 나는 이 동료가 한 장의 티켓을 여러 티켓으로 분리해야 한다고 주장하는 것을 보았다. 봉급에서 보상을 받기 위해서이다. 이 동료는 풀 리퀘스트, 지원 티켓, 애자일 매트릭스를 ‘조종’하는 데 있어 ‘달인’이었다.

소프트웨어 프로젝트가 성공하기 위해 팀에 동기를 부여하는 것이 아주 중요할 수 있지만, 개발자들에게 진짜 동기를 부여하는 것은 수수께끼 같은 난제이다. 개발자들은 흔히 자신만의 생각을 갖고 있으며, 누구보다 도구를 잘 이해한다. 우리가 할 수 있는 최선은 ‘파트너십’에 대한 의식을 불어넣고, 큰 그림을 이해하도록 만드는 것이다. 그런 후, 이들이 추상적인 목표를 여러 수 많은 깨끗한, 테스트가 완료된, 버그가 거의 없는 코드로 바꿔 놓도록 바래야 한다. ciokr@idg.co.kr