어디서 본 장면

첫 미팅에 대표가 나옵니다. CTO가 기술 비전을 설명하고, 팀장이 유사 프로젝트 경험을 이야기합니다. 믿음직합니다. 계약서에 도장을 찍습니다.

2주 뒤, 메일이 옵니다. "안녕하세요, 이번 프로젝트 담당 PM입니다." 처음 보는 이름입니다. 그리고 그 뒤로 대표를 다시 만나는 건 분쟁이 생겼을 때입니다.

나쁜 사람이 아니라 구조입니다

이 장면의 누구도 거짓말을 하지 않았습니다. 영업과 생산이 분리된 회사에서 대표가 미팅에 나오는 건 당연하고, 그 자체는 문제가 아닙니다.

문제는 하나입니다. 실제로 만들 사람이 누구인지가 계약 전에 공개되지 않는 것. 미팅에서 신뢰를 만든 사람과 결과물을 만드는 사람이 다른데, 발주자는 앞사람을 보고 뒷사람과 계약한 셈이 됩니다. 하청 구조가 깊다면 뒷사람이 누구인지는 계약한 회사조차 끝까지 모를 수 있습니다.

실제 사례를 하나 들겠습니다. 문제가 생긴 뒤 저희를 찾아오신 분 중에, 이전 프로젝트에서 1년 동안 개발자와 한 번도 이야기해 본 적이 없다는 분이 있었습니다. 요구사항은 늘 중간 담당자를 거쳐 어딘가로 전달됐고, 결과물만 돌아왔다고 합니다. 저희 짐작으로는 개발이 해외 어딘가에서 진행된 게 아니었을까 싶었습니다.

그 1년이 어땠느냐면 이렇습니다. 결과물에는 버그가 많았습니다. 이슈 하나를 전달하면 몇 주 뒤에야 답이 오고, 버그 하나를 고치면 그 옆에서 다른 버그가 나오고, 어떤 요구는 중간에서 잘못 전달돼 엉뚱하게 구현됐습니다. 그 핑퐁을 1년 내내 반복하다가 프로젝트는 결국 쓸 수 없는 상태로 끝났고, 코드는 폐기됐습니다. 1년을 함께 만든 시스템인데 만든 사람의 목소리를 한 번도 듣지 못했고, 남은 것은 버릴 코드뿐이었습니다.

질문 하나면 판별됩니다

"이 프로젝트, 실제로 누가 설계하고 누가 코드를 쓰나요? 그분과 언제 이야기할 수 있나요?"

반응은 대략 세 가지입니다. 즉시 이름과 함께 미팅을 잡아 주는 곳은 신뢰해도 됩니다. "저희 내부 정예 인력이…"라며 사람 대신 형용사로 답하는 곳은 더 물어봐야 합니다. "그건 계약 후에 배정됩니다"라면, 지금 본 사람들은 만들지 않는다는 뜻입니다.

저희의 답

저희는 이 질문이 반갑습니다. 미팅에 나온 사람이 만드는 사람이기 때문입니다. 상담에서 기술 이야기를 한 그 사람이 설계하고, 코드를 쓰고, 장애가 나면 책임집니다.

정직하게 덧붙이면, 이 구조가 늘 장점만 있는 건 아닙니다. 만드는 사람이 직접 상담하니 동시에 받을 수 있는 프로젝트 수에 한계가 있고, 그래서 저희는 프로젝트를 가려 받습니다. 대신 맡은 프로젝트에서 "담당자가 바뀌어서 히스토리가 날아갔습니다"라는 말은 구조적으로 나올 수 없습니다.

다음 미팅에서 저 질문을 꼭 던져 보십시오. 저희에게 하셔도 좋습니다. 상담 신청은 여기입니다.