[14장 보충] 코딩 파이프라인과 분기 예측

"The Art of Project Management" 전체 내용을 통틀어 가장 흥미로운 부분을 손꼽아 보라고 하면 반드시 들어갈 내용이 바로 14장에서 다루고 있는 '코딩 파이프라인'입니다. 코딩 파이프라인은 구현 전에 수행했던 계획과 설계를 모두 정해진 시간 내에 프로그래머가 막힘없이 효율적으로 진행하기 위해 필요한 작업 연속성으로 생각하시면 됩니다. 코딩 파이프라인을 막힘없이 돌리는 작업은 PM에 달려있으며, 프로그래머보다 며칠 앞서 설계안을 마무리하고 파이프라인을 채워넣는 작업을 진행해야 합니다.

(그림은 '반지의 제왕'으로 유명한 웨타 디지털에서 수행하는 프로젝트 진행 파이프라인)

보통 PM은 여러 개발자 작업을 관리하므로, PM 자신의 시간을 잘 분배해서 여러 파이프라인을 잘 조율해야 합니다. 혼자 모든 일을 처리하기 어려우므로 PM이 수석 프로그래머와 협력해서 작업을 진행하는 경우가 많습니다. 그렇다면 효율적인 코딩 파이프라인을 유지하는 비법(?)은 무엇일까요? 다음 네 가지를 생각해봅시다.

• 현재 활발히 구현 중인 작업을 파악합니다. 그래서 프로그래머가 이런 작업을 진행하는 과정에서 발생하는 장애물을 치워줍니다.
• 현재 작업 항목을 명세서에 맞게 구현하는 데 필요한 모든 사항을 프로그래머가 파악하고 있는지 살펴봐야 합니다. PM과 설계자는 빈틈을 찾아내고 해결하는 과정에 적극적으로 참여할 필요가 있습니다.
• 다음으로 구현할 작업 항목을 파악합니다. PM은 항상 한발 앞서 프로그래머가 현재 구현 중인 작업 항목 다음에 이어지는 작업 항목이 무엇인지 파악해서, 현재 진행 중인 작업에 문제가 없다면 바로 다음에 이어지는 파이프라인을 채울 작업 항목에 초점을맞춰 야 합니다. 프로그래머가 작업을 시작할 시점에 프로그래머를 지연시키거나 중단시킬 미해결 사안이 있다면, 프로그래머에 한발 앞서 이를 해결해놓아야 합니다.
• 완료한 작업이 정말로 완료되었는지 확인해야 합니다. 단위 테스트와 일일 빌드를 사용해서 정말로 파이프라인에 들어있는 작업 항목이 끝났는지 점검할 필요가 있습니다.

우와! 코딩 파이프라인은 프로젝트 중반 이후에 실제 코딩에 들어가면서부터 등장하는 정말 중요한 개념이므로 관리자나 프로그래머는 항상 코딩 파이프라인에 문제가 없는지 촉각을 곤두세워야 합니다. 하지만 프로젝트 관리에서도 일반적인 CPU 아키텍처와 마찬가지로 '분기 예측'이라는 골치 아픈 문제가 등장합니다.

분기 예측은 파이프라인을 채워서 명령을 수행하고 있는 도중에 조건문이 걸려서 명령 분기가 일어나기 때문에 기존 파이프라인을 비우고 새로운 명령을 채워넣도록 만드는 현상입니다. 분기 예측이 정확하다면 파이프라인을 비울 필요가 없으므로 프로그램(컴퓨터 아키텍처 관점)이나 프로젝트(프로젝트 관리 관점) 수행 속력에 영향을 미치지 않지만, 분기 예측이 부정확할 경우에 심각한 문제가 발생합니다. 바로 앞으로 수행을 위해 준비하고 있던 작업 계획이 엉망이 되어버린다는 사실입니다.

이론과는 달리 현실에서는 분기 예측이 자주 실패합니다. 예를 들어 철썩같이 믿고 있었던 클래스 라이브러리에 심각한 버그가 있어서 이를 활용하지 못하고 직접 구현해야 한다거나, 하드웨어 명세와는 달리 실제 지원 범위에 제약이 있어서 구현 과정에서 다른 하드웨어 기능을 사용해야 하는 외부적인 문제점 노출과 요구 사항에 결함이 구현 과정에서 발견되어 설계부터 뒤집어 버리는 경우가 여기에 해당합니다.

코딩 파이프라인을 원활히 유지하도록 치밀하게 계획을 작성하는 임무 이외에도 코딩 파이프라인이 돌아가면서 발생하는 분기 예측에 대한 임무가 PM에게 하나 더 추가되는 셈입니다. 바로 여기서 유능한 PM과 무능한 PM의 차이점을 여기서 찾아낼 수 있습니다. 유능한 PM은 분기 예측 실패 확률을 최소로 줄입니다. 무능한 PM은 분기 예측 자체에 대한 감이 없기 때문에 잦은 파이프라인 미스를 유발합니다. "여러분 미안합니다. 이 산이 아니라 아까 저 산이었습니다. 설계와 프로그램을 모두 다시 하시기 바랍니다."라는 말 한마디에 코딩 파이프라인은 공황상태에 빠져들며 개발자는 왕짜증 모드에 무한 야근 모드로 돌입하게 되므로 전반적인 생산성이 낮아질 수 밖에 없습니다.

결국 이런 코딩 파이프라인 해악(hazard)를 얼마나 줄이느냐에 따라 중반 이후 프로젝트 승패가 갈립니다. 리눅스 커널에서는 분기 예측을 돕기 위해 프로그래머가 likely()와 unlikely()를 명시적으로 사용하는 경우가 있는데, PM도 프로그래머와 밀접한 의사소통을 통해서 사전에 분기 예측 확률을 구할 필요가 있습니다. PM이 일방적으로 명령을 내리고 프로그래머가 이를 따르는 방식이 큰 효과가 없다는 중요한 이유 하나가 오늘 밝혀지네요. 당신이 PM이나 수석 프로그래머라면 종종 프로그래머들과 맥주집에 가서 허심탄회하게 코딩 파이프라인을 막는 문제점을 파악하고 분기 예측에 도움이 되는 정보를 얻으십시오. 그리고 이렇게 얻어낸 정보를 프로젝트 관리에 활용하십시오.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림