간단한 한 페이지짜리 프로그램 소개문을 디자인한다고 해보자. 나는 디자인을 못하므로 디자이너에게 디자인을 부탁하게 된다. 그런데 결과로 나온 시안을 보니 글씨가 작아서 눈이 나쁜 내게는 잘 읽히지가 않는다. 그래서 디자이너에게 이렇게 말한다.
“본문 글씨가 작은데 좀 키워주실 수 있나요?”
이 부탁을 어떻게 개선할 수 있을까? 나라면 종이를 눈 앞에 바짝 가져다 대고 이렇게 얘기하겠다.
“본문은 읽기가 어렵네요.”
혹은 아예 제3자의 사례를 들어서 설명할 수도 있겠다.
“저희 아버지한테 보여드렸더니 돋보기 안경을 쓰셔도 잘 안 보인다고 하시더라고요.”
나는 디자이너(뿐만 아니라 나 대신 어떤 문제를 해결해주는 사람들)에게 의식적으로 요구사항에서 내가 임의로 선정한 해결책을 배제하려고 노력한다. 왜냐면 그 해결책을 선택하는 것이 바로 그 사람들의 임무이기 때문이다. 글씨를 키워달라는 것은 내가 해결책까지 몽땅 제시했기 때문에 바람직하지 않은 요구다. 글씨를 키우고 싶으면 그냥 AI 파일을 받아서 내가 열어서 글씨 키우면 그만이다. 디자이너는 결코 스스로 포토샵 리모컨이라고 여기지 않으며, 실제로도 그렇다.
해결책을 배제하고, 대신 문제시되는 현상 자체를 잘 묘사하면 된다. 사실, 그것만으로도 대부분의 디자이너들은 만족스러운 해결책을 제시해줄 때가 많다. 본문을 못 읽겠다고 하는데 어떻게든 해결책을 내줄 것이 아닌가. 글씨를 키우거나, 혹은 글씨를 작게 유지해야 하는 이유가 있다면 다른 workaround라도 적용할 것이다. 어쨌든 중요한 것은, ‘본문이 안 읽힌다’라는 문제에 대한 해결책은 디자이너가 선택할 것이고, 만약 그 해결책이 여전히 문제를 만족스럽게 해결 못한다고 해도 “제가 눈이 나빠서 여전히 본문은 보이지가 않네요”라고 얘기하면 그만이라는 것이다.
이런 생각은 예전부터 했지만, 이런 태도를 실제로 지키려고 의식적으로 실천하게 된 것은 어떤 계기가 있기 때문이었다.
작년 초에 PyPy에 버그 리포팅을 할 일이 있었다. 나는 나름대로 문제의 원인도 파악했다고 생각해 내 추측을 함께 적어서 개발자가 디버그를 쉽게 할 수 있도록 썼다. 혹시나 해서 PyPy 커미터인 서상현 씨에게 초안을 보여줬는데 쓱 읽으시더니 해주신 조언이 이랬다. 이미 기여를 많이 해서 훤하게 아는 코드가 아니면 추측은 빼고 현상만 써라. 하긴, 추측이 딱딱 들어맞을 정도로 훤히 아는 코드면 버그 리포팅이 아니라 직접 고친 패치를 보낼 수 있었을 것이다. 가장 좋은 버그 리포팅은 기대한 출력(expected output)과 실제 출력(actual output)을 대비시켜 적는 것이다. 그리고 동일한 출력을 재현할 수 있는 방법을 쓰면 된다.
그런데 이게 결국 디자이너에게 요구 사항을 전달할 때도 마찬가지로 적용할 수 있는 태도이다.
내가 디자인 솔루션을 낼 수 있으면, 그냥 내가 직접 디자인을 하면 된다. 그럴 엄두가 안나면, 당신은 디자인을 못하는 것이니 디자이너에게 해결책을 맡기면 된다.
물론 디자이너가 일부러 “어떻게 하는 것이 좋을까요?”라고 솔루션에 대한 조언을 구한다면, 그 때는 주저하지 않고 자기가 생각하는 방법들을 제시하면 된다. 하지만 묻지도 않았는데 먼저 이렇게 하면 될 것 같다는 둥 해결책을 제시하는 것은 서로를 위해 안 하는 게 낫다고 생각한다.
출처: http://blog.dahlia.kr/post/66778859403