기획/디자인의 중도 변경에 대한 프론트엔드 개발자로서의 생각

이번 offsite에서나 온라인에서 기획/디자인이 중도에 변경되는 데 있어서 개발자들이 많이 고충을 토로하는 걸 알고 있다. 심지어 디자이너가 변경되었다는 걸 공개적으로 명시하지 않고 변경 이력 표시가 명확하지 않은 Figma 상에서 슬쩍 디자인을 바꿔 놓고, 그 사실을 알 리 없는 개발자가 결과물을 내놓으면 구현이 잘못되었다고 개발자 탓을 한다는 케이스도 주변에서 직접 들었다. (이런 건 정말 프로라고 할 수 없는 모습이라 할 말도 없는 상황이긴 하다...^^)

 

이 문제에서 자유로울 수 있는 서비스 개발자는 없을 거라는 생각이 든다. 이러한 중도 변경은 개발자에게 예고 없는 공수 증가를 가져올 뿐만 아니라, 그러한 노력에 대한 치하는커녕 변경으로 인해 늘어난 개발 기한을 억울하게도 개발자의 탓으로 모두 돌리는 결과를 낳기 일쑤다. 특히 프론트엔드 개발자라면 공감하겠지만 제품 런칭 가장 마지막까지 개발을 하게 되는 보직으로서 모든 잘못을 뒤집어쓰기 쉽다.

 

그렇다면 기획자와 디자이너들에게 '제발 최대한 중도 변경이 없도록 해 줘'라고 단단히 일러두고, 변경이 일어나면 불만을 가지고 일하는 것이 답일까? 나는 그렇게 생각하지는 않는다. 한 서비스가 수익을 내고 그 수익을 점차 늘려나가는 일이 얼마나 어려운지 알고 있다. 그래서 만약 더 나은 방향으로 바꿀 수 있는 방향이 있다면, 정말이지 최대한 빨리 소통해서 알려주고 바꿀 수 있도록 해주면 좋겠다. 그러니까 나는 오히려 변경이 일어나는 게 더 건강한 제품 팀이라고 생각한다. 그리고 이러한 변경 가능성을 항상 염두에 두고 기민하게 개발하는 것이 프론트엔드 개발자로서의 중요한 덕목 중 하나라고 생각한다.

 

그래서 중요한 건 변경이 일어나지 않도록 무언가 하는 것이 아니라, 공수 산정 과정이나 인사 평가에 있어서 이러한 변경이 필연적이고 나아가 좋은 제품에 필요한 것이라는 걸 인식하고 있는 것이라고 생각한다. 상황에 따라 쉬운 일은 아니겠지만 업무의 공수를 산정 할 때 이러한 변경 가능성까지 염두에 두고 산정해 개발자가 마음의 여유를 두고 변경 사항을 받아들이며 개발할 수 있도록 해주고, 직원 평가를 할 때는 그 직원이 구현을 넘어 얼마나 기획과 디자인의 변경 사항에 잘 대처했는지를 보고 플러스 요소로 생각해야 한다고 본다. 내 경험으로 어떤 PM, 디자이너와 일하든 이런 환경이 잘 만들어져 있으면 대응하는 것이 어렵지 않았다. 팀이 좋은 프로덕트, 좋은 수익을 내는 프로덕트를 향해 일치된 목표를 가지고 있고 그 목표 달성에 다방면으로 노력하는 개발자를 위해 보상한다면 개발자들이 어려움을 느낄 만한 상황이 거의 없어질 거라고 생각한다.

 

사진: Unsplash 의 History in HD