오늘 글은 가벼운 주제로 써볼까 한다.
바로 개발자가 화나는 순간이다. 아마 대부분의 직업이 비슷한 상황이 있을 것 같지만, 완전히 개발자 관점으로 써보려고 한다.

기획의 변경

기획은 언제나 변경된다. 기획을 픽스하고 개발하는 외주 프로그램 제작인 경우에도, 기획이 변경되는 경우가 꽤 자주 있다. 오죽하면 계약 당시에 기획 변경에 따라 일정이 지연될 경우, 비용을 추가로 지급해야 한다는 조항이 있어도 요구할 때가 있다.

기획이 변경될 수 있다는 것을 아는 것과 받아들이는 것은 조금 다르다. 기획대로 만드는 사람 입장에서는 거의 다 완성해 가는데 갑자기 엎어야 하는 경우가 생길 수도 있다는 것이다.
요즘에는 개발자 대우가 좋아진 편이라, 이러한 기획 변경을 최소화하려는 장치나 문화가 있지만 과거에는 시도 때도 없이 기능을 제안하거나 변경하는 경우도 있었다.

기억에 남은 기획 변경이 있다. 관리자 페이지에서 강의를 업로드하면 사전에 등록한 계정을 통해 강의를 볼 수 있는 아주 간단한 웹 사이트를 의뢰받았다. 금액과 일정을 전달하고 계약을 진행하면서 약간의 기획 변경이 있다고 하더니, 회원별로 볼 수 있는 강의를 구성할 수 있게 해달라고 했다. 그래서 안 했던 기억이 있다.

git rebase 충돌

git은 개발자들이 협업하는 과정에 쓰는 대표적인 툴이다. 팀의 룰에 따라 커밋을 관리하기 때문에 rebase를 사용할 때가 있는데, 자칫 잘못 관리하면 굉장히 귀찮은 일이 생긴다.

코드는 결국 문서이고, 여러명이 편집하기 때문에 하나의 문서로 유지하기 위해서 합치는 과정이 필요하다. 이 과정을 git이 도와준다.git은 코드의 변경 내용을 이력으로 관리한다. 그런데 여러 명이 코드를 편집하기 때문에 여러 이력이 존재하게 된다.

나와 팀원 1명이 있다고 가정을 해보자. 처음 프로젝트를 시작할 때 각자 컴퓨터에 초기 이력을 설정한다. 나의 코드 이력이 1,2,3 이고 팀원의 코드 이력이 1,2,3 로 설정된다.
그 이후에 나는 열심히 개발해서 1,2,3,4,5 가 되었고, 팀원도 열심히 개발해서 1,2,3,4,5 이 되었다. 그런데 각자 자기 컴퓨터에서 개발한 4,5의 변경 내용은 나와 팀원이 다르다. 이를 합치기 위해서 공용 저장소를 사용하게 되는데, 공용 저장소에 팀원들이 합의한 코드 이력이 관리된다. 즉 1,2,3이 들어있다.

이때 git 서비스가 제공하는 도구를 통해 나의 4,5와 팀원의 4,5가 적절히 섞여서 1,2,3,4,5,6,7 로 들어가게 된다. 그 이후에 각자 공용 저장소의 내용을 내려받아 맞춘다.

그런데 rebase는 이 이력을 직접 변경할 수 있는 명령어이다. git은 1,2,3,4,5,6,7 로 이력을 관리했다면 각각의 이력마다 변경 점으로 기억하기 때문에 중간에 하나가 누락되거나 변경되면 추적이 불가능해진다.
만약 팀원이 1,2,3,4,5로 개발했는데, rebase를 통해 본인이 개발한 4,5 이력을 3에 합쳐서 1,2,5 이력으로 변경해서 공용 저장소에 넣게 되면 아주 곤란해진다..

이런 과정을 서비스 차원, 팀 차원에서 많은 장치를 통해 당연히 막혀있지만, 드물게 발생하기도 한다. 이런 상황이 생기면, 개발해야 할 일이 산더미더라도, 최우선으로 해결하는 이슈가 되기 때문에 매우 귀찮고 고생스럽다.

기획 미팅 중 “이거 왜 안 되나요?”

언제나 이면이 있기 마련이다. 외부 기획자, 디자이너 등 개발자가 아닌 직군과 개발 관련 미팅을 하다 보면, 자기가 생각했을 때 너무 쉬운 것 같은데 개발자가 막무가내로 안 된다고 하면서 하소연하는 경우가 많다. 심지어 개발자 대우가 좋아지면서 개발자에 대한 콘텐츠가 많아져서인지 비슷한 종류의 밈도 심심치 않게 볼 수 있다. 심지어 “오늘도 개발자가 안 된다고 말했다“라는 책도 있다.

악용하는 사람도 물론 있겠지만, 아마 막무가내가 아닐 것이다. 하지만 아무래도 이런 분위기가 조금은 깔려있어서인지, 오해하는 사람도 있을 것 같다. 직접 겪어보지는 않았지만, 이런 글들이 많으니 상상해 봤다.
정말 어려워서, 시간이 오래 걸리니 불가능하다고 얘기했는데, 마치 하기 싫어서 안 하는 것으로 받아들인다면 어떨까.

아주 괴로울 것 같다. 그리고 자세히 설명하려고 할 것 같고, 반복하다 보면 설명 없이 안 된다고 할 것만 같다. 그래도 다행히 충분히 설명하면 대부분 이해하고 같이 다른 방안을 논의하게 된다.

프리랜서 시절을 생각해 보면, 자매품으로 이거 쉬워 보이는데, 견적에 포함 안 하고 그냥 해주실 수 없나요? 정도가 있겠다. 이 경우는 아주 비일비재하다. 하하하하하. 때에 따라 진짜 쉬우면 해주기도 했었다.

작성해 보니 의외로 개발 과정에서 화나는 순간은 없다. 스트레스를 받을지언정 화나진 않았던 것 같다.
(비슷해 보일 수는 있다)

또 다른 화나는 순간이 생긴다면 시리즈로 가야겠다.