대부분의 기술적인 문제는 사람 문제다

Source: Hacker News

배경

저는 한 번은 기술 부채가 엄청난 회사에서 일한 적이 있습니다—수백만 줄의 코드, 단위 테스트가 없고, 10년 이상 된 프레임워크 위에 구축된 상황이었죠. 특정 프로젝트에서는 Windows 전용 모듈을 Linux에서 실행해야 했습니다. 교차 컴파일을 시도하기보다, 다른 팀은 수십만 줄의 코드를 복사·붙여넣고 Windows‑전용 컴포넌트를 Linux‑전용 것으로 바꾸었습니다.

비기술적인 독자에게는 이것이 큰 문제를 일으킵니다: 이제 두 버전의 코드가 존재하게 되고, 모든 기능 추가나 버그 수정은 두 코드베이스에 모두 적용해야 하며, 시간이 지나면서 두 코드는 점점 갈라지게 됩니다. 이 이야기를 들었을 때, 순수하고 순진했던 저는 상황을 바로잡겠다고 결심했습니다…

기술 부채 프로젝트는 경영진에게 항상 팔기 힘듭니다. 왜냐하면 모든 것이 완벽히 진행되더라도 코드는 이전과 거의 같은 일을 할 뿐이기 때문이죠. 외관상으로는 좋지 않았지만, 저는 정치적인 부분을 무시하고 머리를 숙여 일을 끝냈습니다. 프로젝트는 오래 걸렸고, 그 과정에서 저는 많은 신뢰를 잃었습니다.

저는 기술적인 해결책으로 사람 문제를 해결하려 하고 있다는 것을 깨달았습니다. 대부분의 개발자는 어제—그리고 5년 전—했던 일을 그대로 반복하는 데 만족했습니다. Andrew Harmel‑Law가 지적하듯, 코드는 그 코드를 만든 사람들의 성격을 반영합니다. 개발자들이 경직돼 있었기 때문에 코드도 경직되었습니다; 변화를 싫어하는 성격 유형은 미래 변화를 염두에 두고 코드를 설계하지 않으니까요.

대부분의 기술 문제는 실제로 사람 문제입니다. 기술 부채가 존재하는 이유는 무엇일까요?

• 작업을 시작하기 전에 요구사항이 제대로 명확히 정의되지 않았음.
• 영업 담당자가 고객에게 비현실적인 마감일을 약속함.
• 개발자가 편안함 때문에 구식 기술을 선택함.
• 경영진이 너무 반응적이어서 프로젝트를 중도에 취소함.
• 누군가의 자존심이 더 나은 방법을 보지 못하게 함.

핵심 문제는 리팩터링이 필요하다는 것을 인정하는 것이 곧 회사의 소프트웨어 개발 프로세스가 망가졌으며 개인의 역량이 구식이라는 것을 인정하는 것이었습니다. 저의 작은 팀은 한 모듈을 고치려 애쓰는 반면, 다른 개발자들은 수십 년 동안 해오던 대로 코드를 계속 작성했습니다. 어느 개발자는 “새로운 것을 배우고 싶지 않다”고까지 말했습니다. 저는 다른 사람들이 부채를 만들기보다 더 빨리 정리할 수는 없다는 사실을 깨달았습니다. 이는 응급실에서의 응급 처치와 같습니다: 먼저 출혈을 멈춰야 하고, 그 뒤에 깨진 부분을 고칠 수 있습니다.

이상적인 세계

이 프로젝트는 저에게 엔지니어가 “정치”에서 벗어나 작업 자체만으로 문제를 해결할 수 있다는 이상적인 세계—마감일도 없고, 솔직히 말해 고객도 없는—가 실제로는 거의 존재하지 않는다는 사실을 일깨워 주었습니다. 대부분의 프로젝트에는 비기술적인 이해관계자가 존재하고, “그냥 믿어 주세요, 작업 중입니다”라고 말하는 것만으로는 충분하지 않습니다.

저는 팀이 많은 일을 하고 있다는 인식이 실제로 많은 일을 하는 것만큼이나 중요하다는 점을 깨달았습니다. 비기술적인 사람들은 노력의 규모나 기술 부채 정리의 필요성을 직관적으로 이해하지 못합니다; 이는 엔지니어링 팀이 초기 견적과 프로젝트 업데이트 모두에서 효과적으로 전달해야 합니다. 리더십이 엔지니어링 배경을 가지고 있지 않다면, 기술 부채 작업의 가치는 정량화되어 비즈니스 가치로 보여져야 할 가능성이 높습니다.

미리 알려드립니다

아마도 이러한 교훈들이 더 높은 직책을 준비하게 할 것입니다. 제 의견으로는, 시니어 엔지니어 수준을 넘어서는 사람은 기술 트랙이든 관리 트랙이든 관계없이 교차 기능 협업 방법을 알아야 합니다. 학교에서는 컴퓨터 과학을 가르치지만, 성격, 자아, 개인적인 사각지대를 탐색하는 방법은 가르치지 않습니다.

저는 저보다 뛰어난, 거의 모든 기술에 대해 깊은 지식을 가진 놀라운 엔지니어들과 일해 왔습니다. 젊었을 때 저는 그런 엔지니어—‘엔지니어의 엔지니어’—가 되고 싶었습니다. 하지만 이제는 그것이 제 성격이 아니라는 것을 깨달았습니다. 저는 그걸 감당하기엔 너무 ADD(주의력결핍 과잉행동) 입니다.

그들의 (상당히 큰) 강점에도 불구하고, 그런 엔지니어들은 종종 대인 관계 측면을 회피합니다. 비극적인 점은 그들은 엄청난 생산성을 가진 개인 기여자이지만, 한 사람에 불과하기 때문에 큰 이니셔티브에서는 실패할 수 있다는 것입니다—단일 프로세서 코어는 속도가 제한됩니다. 동등하게 가치 있는 존재는 깊은 기술력을 가지고 있으면서도 머리를 들어 프로젝트 위험(기술적이든 아니든)을 파악하고 팀을 그 위험에서 벗어나게 이끌 수 있는 “미리 알려주는 코더”입니다.