"이쁘지 않다"

예전에 한 10년 전 쯤에, 핸드폰용 퀴즈 게임을 만들고 있었다. 지금같은 스마트 폰이 아니고, 폴더폰이 득세하던 시절이다. 프로젝트 개발을 맡았을 때, 디자인은 이미 완수되어 있었고, 기획도 문서로 나와 있었다. 이미지들이 원하는 기획에 맞춰 움직이도록 코딩만 해주면 되는 상황.

우선 주어진 리소스들로 구현을 완료 했다. 그걸 봤던 매니저의 의견은 "이쁘지 않다." 였다. 이쁘지 않으니 이쁘게 만들어 달라고 했다. 이미 해당 작업을 떠나 다른 일에 배치되었던 디자이너를 찾아가서 이미지를 조금 손봐달라고 했다. 바뀐 업데이트를 리뷰한 다음 평가도 역시 "뭔가 부족하다. 애니메이션 등을 넣어보라." 였다. 별다른 프레임웍도 없이, 이미지 옮겨 그리는 작업을 통해 약간의 애니메이션을 추가했다. 그리고 최종 리뷰 결과는 "이런 수준으로 팔려고 내놓을 순 없다." 그리고 프로젝트 드랍. 처음 맡았던 모바일 게임 프로젝트의 실패는 마음에 상처로 남았다.

그 후 새로운 신입 디자이너가 들어왔고, 해당 퀴즈 게임은 마침 한 달 뒤 있을 수능을 대비해서, 수능 퀴즈 게임으로 탈바꿈. 게임 전체 색상을 모두 바꾸고 디자인을 전부 새로 했다. 개발에서는 화면에 그려주는 부분 말고는 크게 손댈 게 없었다. 퀴즈 문제 데이터들과 정답지만 교체해주면 되었기 때문이다.

결과는 좋았다. 신문에서도 인터뷰해 갔다. "역시 디자인이 이쁘니까 좋다"는 매니저의 평가가 있었다.

이 일화에서 개발자가 얻어야 되는 교훈은 무엇인가?

첫째, 개발팀이 "이쁘지 않다" 는 피드백을 그대로 받아들인 것이 잘못이다. 개발자는 이쁘게 만드는 재주를 부리는 사람들이 아니다. 깔끔하게 만드는 정도는 할 수 있겠지만, 이쁘지 않은 무언가를 이쁘게 바꿔 놓진 못한다. 그건 전적으로 아티스트 또는 디자이너의 작업이다. 그러한 요구사항이 개발팀에 전달 됐을 때, 어떤 부분이 제품을 이쁘지 않게 만드는지 요모조모 따져봐야 한다. 예를 들어 레이아웃이 맞지 않거나, 화면 전환이 부드럽지 못하던가 하는 것은 개발팀의 몫일 수 있으나, 색상이 이상하다 라던가 전체적인 톤이 맞지 않다는 의견은 개발 이전의 문제이기 때문이다.

둘째, "뭔가 부족하다" 라는 애매모호한 잣대에 기대어 제품 개선 노력을 하는 것은 밑 빠진 독에 물 붓기와 같다. 개선을 하기 전에 해야 되는 것은 측정이다. 무언가 부족하다 싶으면, 그것을 어떻게 측정했더니 어떤 기준보다 얼마가 부족하다는 것을 정해야 한다. 개선은 그 다음에 따라오는 것이다. 코드를 바꾼다고 사람 마음 속의 그 '부족함'을 채워 줄 수는 없다.

셋째, 애매모호한 평가는 구체적인 이슈들로 바꿔야 한다. 애매모호한 평가는 애매모호한 결과만 낳을 뿐이다. 누군가 저런 평을 내렸다면, 그 사람과 대화를 해도 좋고 또는 간단한 설문을 해서, 고객이 느꼈던 불만을 구체화시켜야 한다. 대부분 이 과정에서 고객을 불편하게 하는 버그들 몇 개로 추려진다. 어떤 버그는 아주 쉽게 고칠 수 있는 것들도 있고, 어떤 것들은 디자인 단계로 피드백을 넘겨야 되는 경우도 있다. 단 이것은 해당 평가를 내린 사람이 고객일 때의 이야기이고, 만약 상대가 개발팀의 매니저 또는 팀장이라면? 글쎄다 빨리 개발 조직을 바꿔 타는 게 현명할 지도 모른다.