왜 같은 페이지를 동시에 수정하면 오류가 날까?

주니어 기획자의 이해를 돕기위한 비유설명법

*본 시리즈는 우리 주니어들에게 제가 설명하는 방식들을 정리한 내용으로, 기획자가 딱 일할 수 있을 정도로만 문과적 비유를 들어 설명합니다.

개발 프로그래밍을 언어라고 하잖아,
그래서 여러 사람이 같은 글을 고쳐서 쓰면은
글의 문맥이 앞뒤가 안맞게 돼.
그게 오류나는 이유야.

현업에서 요구사항을 들고 왔다. 마침 요즘 수정중인 프로젝트가 진행중인 화면에 큰 기능을 비슷한 시기에 오픈해달라고 한다. 나는 난색을 표했다.

"그 화면이 10월까지 수정중인 프로젝트가 있어서 동시에 진행 가능한지는 확인해봐야될 것 같아요."

"인력이 부족한 거라면 저희가 추가인원을 뽑을 수 있도록 예산 지원을 요청할께요."

나는 피식 속으로 웃었다. 오프라인 계열사에서 넘어온 많은 사람들이 저 말을 한다. 가장 슬펐던 말은 오픈이 딜레이 된다고 했을 때 개발자를 3교대로 쓰면 빨리 되지 않냐는 말이었다. 미안하지만 개발은 벽돌쌓기가 아니다. 중간에 갑자기 늘어난다고 효율이 올라가지 않는다. 왜냐하면 개발은 수학문제풀이나 벽돌쌓기가 아니라 '긴 글짓기'이기 때문이다.

이렇게 운영중의 수정개발은 이미 쓰여진 긴 글에 중간중간 문단을 끼워넣는 것이라고 봐야한다. 그래서 문장을 내 맘대로 써서 넣으면 앞뒤와 맞지 않아진다. 어휘 사용이 갑자기 다르면 이해가 안가고, 문체가 갑자기 바뀌면 읽는 사람은 당황한다. 갑자기 한글로 쓰다가 영어로 써서도 안된다.

개발이 왜 긴 글이냐면 누가 읽는걸까? 바로 브라우져다. 브라우져는 소설을 읽으면 머리속에 그림을 그리듯이 우리가 사용하는 화면을 출력하는 것이다. 그래서 브라우져가 일관성있게 글을 읽고 모든 기능을 문맥적으로 정확하게 파악할 수 있게 써야한다. 간결하며 이해가 잘 가는 글이 좋은 글이듯 개발언어로 작성된 글도 그렇다.

그런데 오프라인 방식의 사고관에서 개발은 자칫 벽돌공사처럼 오해된다. 1층 위에 2층 쌓듯이 벽돌처럼 분리되어 있고 일이 규격화 되어있다면 일정 수준 이상의 인원을 보강하여 속도를 높이겠지만 미안하지만 개발은 그러기가 어렵다. 일하는 방식자체가 다르기 때문이다.

벽돌은 쌓는 것이 바로 보이고 측정된다. 개발로 치면 운영기 서버에 바로 반영되게 수정하는 수준이다. 물론 그러면 이용자는 정상적으로 사용이 불가능하다.

그래서 여러명이 정상적으로 운영중인 서비스를 뜯고 있다면 운영기의 개발 소스를 수정할 수 없다. 그래서 개발자들은 브랜치라는 복사본을 따서 로컬 컴퓨터로 내려받고 브랜치에 개발 소스를 업로드하여 반복적인 디버깅 테시트를 하는 절차를 거친다.

문제는 개발기간이 길어질수록 커진다. A개발자와 B개발자는 서로 다른 프로젝트에서 같은 화면을 수정하는데 브랜치 생성하여 소스를 다운한 시점이 다르다. 오픈시점에 둘 중 하나가 먼저 오픈된 상태라면 나중에 오픈하는 개발자는 오픈시점으로부터 모든 수정내용이 포함된 상태로 운영 서버에 개발된 언어를 올려야한다.

이런 과정을 소스머지(source merge)라고 한다. 쉽게 말하면 개발자들이 다 제각각 만들어놓은 소스들이 서로 연결되도 전체가 문제없이 이해될 수 있도록 합치는 작업이다. 그리고 이 작업은 숙련된 1명의 개발자가 진행하다. 마치 문단별로 작성한 글을 하나로 합치면 앞뒤 내용을 가장 잘 아는 사람 1명이 자연스럽게 윤문을 해야하는 것과 같다.

하지만 현업에 구구절절이 설명하긴 어렵다.

"동시에 같은 페이지를 다른 목적으로 개발해서 오픈시키는 것은 오류발생이 많을 수 있거든요. 오류나도 원인찾는데 한참 걸리고요. 명확한 성과 측정을 위해서도 가급적 피하는게 종아요. "

현업은 방어적이라고 입이 잔뜩 나와서는 투덜대며 돌아간다. 미안하지만 현업을 이해시키는 시간에 투입되는 비용이 너무 크다. 정말 사업적으로 중요한게 아니라면 불확실성을 높이는 것은 피하는 것이 좋다. 그 시간에 기획을 더 깊이 고민하고 짝꿍 개발자가 비즈니스를 잘 이해하도록 도와서 머지도 두렵지 않도록 하는 것이 장기적으로 이롭다고 본다.