한빛출판네트워크

우리는 독방에 갇혀서 시스템을 만들지는 않습니다 - 아키텍처(시스템 전체 구조)는 반복해서 전달하는 장기적인 비전으로 봐야 합니다. 

편집자 주 : 이 기사는 초보 매니저가 겪는 시련과 역경에 관한 경험담의 일부입니다. 렌트 더 런 웨이의 전 CTO인 카밀 푸르니에는 종종 이런 질문을 받습니다. 혼자서 업무를 처리하던 직원에게 매니저 업무를 어떻게 알려줘야 할지 모르겠다는 것이죠. 격월간 기고 될 칼럼을 통해, 그녀는 이와 관련해 가장 많이 받은 질문들과 이슈를 해결할 수 있는 최고의 접근 방법들을 알려드릴 겁니다.

문제점: 제품의 마일 스톤을 지켜야 함에도 불구하고 더 뛰어나고 새로운 시스템을 구축하려는 팀원들의 열정을 어떻게 조율해야 할까요?

저는 오래된 코드로 작업을 하고 있는 개발팀의 매니저입니다. 이미 낡은 기술로 만들어서 좋은 시스템이라고 할 수는 없지만, 현재 잘 동작하고 있고, 저희도 새로운 기능들을 개발해서 여기에 계속 추가하고 있습니다. 지난 몇 달간 저희 팀은 새로 온 시니어 멤버들 몇 몇과 함께 일하게 됐습니다. 그리고 이들은 지금 사용중인 구식 시스템이 새로운 구조로 변경 되야 한다고 강력하게 주장 중입니다. 그들은 무엇이 반드시 바뀌어야 하는지, 그리고 완성까지 대략 2년 정도가 소요되는 일정을 제안했습니다.

그들이 제안서를 내미는 동안 생산 팀에서 사업을 성장시킬 만한 몇 가지 기능들을 가져왔습니다. 저는 실제로 해당 기능을 구현하는데 걸리는 시간에 대해 고민하고 있었는데, 현재 시스템을 이용해서 몇 개월이면 개발이 가능할 것으로 보였습니다. 문제는 개발자들이 그렇게 하고 싶어하지 않았다는 겁니다. 그것뿐만 아니라 새로운 구조를 만들 때까지 기다리자는 입장이었죠. 매번 조금 도와줄 수 없겠냐고 할 때마다, 우리 팀은 새로운 기능의 추가 때문에 구조의 변경을 미루고 싶지는 않다고 합니다. 가치 있는 일이 아니라는 거죠. 제가 도대체 어떻게 해야 하는 걸까요?

해결책: 개혁이 아니라 개선해야 한다는 사실을 잊지 마세요.

팀원들이 제품과 연관 없는 장기적인 계획을 가져왔다면, 아마도 그들은 업무를 하는 것이 아닐 겁니다. 이 부분이 중요합니다. 그들의 업무는 구조 자체를 만드는 것이 아니라, 우리 회사의 사업 성장을 지원할 수 있는 잘 운영되는 시스템을 만드는 겁니다. 수 많은 제약 속에 퍼즐을 풀기 위해 어떻게 해야 하는 지 생각해보세요. 시스템을 어떻게 분석하고, 올바른 조각을 어떻게 찾을지, 언제 옮겨야 할지. 이 모든 것 들이 굉장한 지적 도전이고 엄청난 배움의 기회가 될 겁니다. 여기서 당신이 해야 할 일은 이것이 기회임을 알게 하는 겁니다. 오랫동안 반복해온 코드 재 작성 같은 일들이 일어나도록 방치해서도 안되겠죠.

완벽한 코드 재 작성의 신화는 여전히 우리 업계에서 통용되고 있습니다. 이런 신화는 영업에서 제품을 완성 할 때까지 기다리는 동안 어플리케이션 재 작성에만 집중하면 되는 것처럼 말합니다. 또한 구조를 완성하는데 걸리는 시간은 중요하지 않은 것 같죠. 이런 이야기들을 계속 듣기 때문에 우리 팀들이 실패하고 있는 겁니다. 예를 들어 지금 운용중인 업무용 어플리케이션을 다시 작성해야 한다면, 이제는 반드시 반복해서 제공할 수 있는 컴포넌트 단위로 쪼개서 작성할 수 있어야 합니다. 업무에 필요한 기능과 기능의 개선이 계속 전달 되어야 하니까요. 새로운 스토리지 레이어나 데이터베이스 같이 버전 1이 나올 때까지 전혀 사용할 수 없는 시스템을 만들 때도 다르지 않습니다. 고객에게 전달될 때는 반드시 컴포넌트 단위로 나뉘어져 있어야 합니다. 복잡한 업무들은 이렇게 완성 됩니다. 

매 18개월마다 직장을 옮겨 다니는 상황에서 이런 감각을 유지하는 것이 쉽지는 않습니다. 하지만, 시스템의 구조는 장기적인 비전이며 이 비전을 반복적으로 전달하는 과정입니다. 시스템을 설계하는 사람이 말단 컴포넌트의 구조에 대해 분명히 알지 못하고 어떤 순서로 배포해야 하는지 모른다면, 3년짜리 프로젝트를 성공적으로 마무리했다 한들 무슨 의미가 있을까요. 혼자서 장기간에 걸쳐 새로운 시스템을 개발해도 좋다는 식의 환상을 숙련된 개발자들에게 보여준다면, 그건 정말 해선 안될 일을 하는 겁니다. 물론 나는 당신이 이 사실을 모른다고 생각하진 않지만, 이런 식의 이야기를 팀원들과 나누기가 쉽진 않을 겁니다.

실질적인 충고: 당근과 채찍을 사용하라.

제가 알려드릴 첫 번째 조언은 당신이 테크 리드, 시니어 엔지니어, 시스템 설계 모두에게 바라는 것이 무엇인지 분명히 하라는 겁니다. 당신은 이들이 업무를 빠르게 전달할 수 있게끔 아주 작게 나눠 놓길 바랄 겁니다. 이렇게 하는 것이 괜찮은 시스템 디자이너가 되는 아주 중요한 부분임을 이해시킬 수 있다면 더 좋겠죠. 시스템은 필연적으로 그들이 지원하고 있는 세계라는 제약 속에서 만들어집니다. 당신의 세계에서, 이 말은 곧 새로운 기능에 대한 요청을 최대한 빨리 처리할 수 있도록 시스템이 디자인 되어야 한다는 말이겠죠. 뭔가 새로운 것을 배울 기회가 되는 도전이라구요!

이렇게 하면 조금 더 빨리 이루어 질 겁니다. 생각하고 있던 테크놀로지에 대한 기본 규칙을 정하세요. 혹은 여러 테크놀로지를 평가할 수 있는 과정을 만들어 두세요; 이렇게 해두면, 나중에 어떤 언어로 개발 하느냐를 두고 싸우는 일을 미연에 방지 할 수 있습니다. 이미 많이 사용되고 있는 오픈 소스와 잘 활성화되어 있는 커뮤니티를 활용하는 것도 괜찮은 방법이 될 겁니다. 이런 과정을 통해 배우게 되는 것들도 꽤 많습니다. 예를 들어, 나중에 바꾸는 것이 굉장히 어려운 민감한 결정 혹은 수시로 변경 가능한 것의 구분을 명확히 하도록 팀원들을 유도할 수 있습니다. 팀원들이 제안한 모든 것들은 새로운 기능을 만들기 전에 검토가 끝나야 하기 때문에, 지금 완벽하게 만드는 것과 나중에 변경하도록 하는 것 사이의 비용에 대한 검토도 해야 합니다.

주의해야 할 것은 두려움 때문에 팀원들의 사기가 수시로 안 좋아질 수 있다는 겁니다. 잘못된 결정과 그로 인한 부끄러움이나 불편함을 감수해야 하는 두려움. 뭔가 엄청난 일을 해내야 한다는 두려움. 실패에 대한 두려움 등 일겁니다. 실제로 시스템 설계에 관한 장기 프로젝트를 성공시킨 사람은 얼마 되지 않습니다. 당신의 팀 역시 외부에는 허세로 가득할지 몰라도 내부적으로는 알 수 없는 엄청난 두려움으로 떨고 있을지도 모르죠.

프로젝트를 나누고 계획된 대로 업무를 진행하는 것이 재미없다는 것은 분명합니다. 당신의 팀 역시 뭘 어떻게 해야 할지 전혀 모를 겁니다. 이 전에 큰 프로젝트를 맡은 시니어 엔지니어들에게 같은 조언을 한 적이 있었는데, 누구도 즐겁지 않더군요. 내가 책임졌던 첫 번째 큰 프로젝트 역시 잊지 못합니다. 선임과 함께 사무실에 앉아 내가 만든 계획을 검토하고 있었죠. 그 사람은 불확실성과 위험성이 너무 많다는 이유로 내 계획을 거의 난도질 한 다음에야, 다시 생각해 보라며 돌려주더군요. 짐작 가는 것들이 너무 많았고, 구체화 하기 위해 고심해야만 했습니다. 미칠 것 같았죠. 이 일을 하는 내내 좌절했고, 인내심은 바닥을 쳤습니다. 그럼에도 불구하고, 이 일이 끝나갈 즈음에는, 이 큰 프로젝트를 낱개로 전달 할 수 있게 나누었습니다. 약간 복잡한 구조임에도 불구하고, 스케줄에 쫓기면서 눈에 띌만한 설계상의 변화도 성공적으로 이끌어냈죠. 원래 계획이 틀어지면서 미칠 것만 같았지만, 이는 동시에 엄청난 성취감으로 다가왔습니다.

코드 재 작성에 관한 MVP들은 분명 있습니다. 그들은 새로운 시스템에 투입 가능하고 확장 가능한 기능들을 만들죠. 또한 기존 업무에 쓰이던 것들을 단 한 부분도 가져오지 않고 새로운 도구로 작성합니다. 이런 방법으로는 완벽한 시스템이 될 수 없습니다. 그들이 만들고 싶은 대로 시스템을 만들 자유는 얻었을지 모르나, 그들의 선택은 불완전한 시스템으로 이어질 겁니다. 끊임없이 트렌드가 달라지는 요즘 시대에, 겉보기만 멀쩡한 시스템이 6개월 이상을 아무 고장 없이 버티긴 어려울 겁니다.

정리

팀원들이 업무를 충분히 관리 가능한 작은 형태로 나눈다 하더라도, 여전히 문제는 남아 있습니다. 아무리 좋은 계획도 실패할 때가 있으니까요. 어떤 부분은 누가 봐도 잘못된 기술을 사용할 수 있을 겁니다. 그리고 수 년 안에 다시 고치려 하겠죠. 어쩌면 더 안 좋을 수도 있는데, 기능 몇 가지만 추가 할 뿐, 기술적인 진보까지 이룰 생각이 없는 팀원들과 맞서 싸우고 있을 수도 있습니다. 반복 계획을 아무리 잘 세운다 하더라도, 주요 구조를 바꾸는 일은, 엄청나게 많은 기능을 쓰고 있는 이들의 입장에서는 납득하기 어려울 겁니다. 그들은 구조 변경을 위해 준비한 개발 주기도 무산시킬 기회만 찾을 겁니다. 반드시 정기적으로 새로운 기능들을 내놓으세요. 그렇지 않으면 프로젝트를 통째로 놓칠 겁니다. 운이 없다면 직업도 잃을 수 있을 겁니다. 집중해서, 성공 할 수 있는 일에 우선 순위를 매기세요. 험난한 여정에 강해져야 합니다.

*****

카밀 푸르니에는 렌트 더 런웨이에서 엔지니어링 수장이었습니다. 그 전엔 골드만 삭스의 부사장을 역임했습니다. 카밀은 아파치 주키퍼 커미터이자 PMC(Project Management Committee) 멤버이고, Dropwizard framework의 PMC멤버이기도 합니다. http://www.elidedbranches.com 에서 그녀의 더 많은 이야기들을 찾아볼 수 있습니다.

원문 : Ask the CTO: Balancing development desire with product goals 

번역 : 김상훈