소프트웨어 개발자라면 흔히 알고 있는 이야기로 '개밥먹기'란 것이 있다.
개밥은 사람이 만든다. 개밥은 개가 먹는다. 따라서 사람은 개밥을 먹지 않으므로 개밥이 어떤지 알기 어렵다.
소프트웨어도 마찬가지다. 내가 만든 소프트웨어가 사용자의 입장에선 어떻게 보일 수 있을지 알기 어렵다.
따라서 우리는 개밥먹기를 한다. 우리가 직접 소프트웨어를 사용해보고 체감하여 평가해보는 것이다.
그러나 그런 것으로는 충분하지 않다. 사용자와 개발자는 사전지식이 다르기 때문이다.
개발자에게 있어 당연하여 설명할 필요조차 없으리라 생각되었던 버튼 하나 조차도 사용자에겐 이해할 수 없는 버튼이 되어버리는 경우가 종종 있다.
그래서 개발자가 만든 소프트웨어에 대해 사용자는 많은 불평을 하고 처음에 이야기했던 그림과 다른 이야기를 하기 시작한다.
여기가 많은 개발자가 힘들어하는 지점이다.
최근에 본 서적 중에 'Prefactoring'이란 책이 있다.
책에서 개발자는 사용자와 커피를 함께 마시며 함께 대화를 통해 개발을 진행해나가는 모습을 보여준다. 게다가 유쾌한 농담까지.
이 얼마나 멋진 모습인가!
그러나 예제는 예제일뿐... 현실에서는 그와 같은 여유를 가지기 어렵다. (물론 여기에는 개발자의 역량부족과 현실적 기타 제약요소들의 복합적 원인이 존재하겠지만)
따라서 실제로는 싸워 이긴다 라는 표현이 무색할만큼 충돌이 빈번하게 일어난다.
자, 이쯤되면 슈퍼맨처럼 해결하는 개발서적의 저자들에게 돌을 던질 만하다.
왜 이렇게 현실 세계는 다른 것일까
왜 개발자는 이렇게 힘든 것일까
그러나 전산학은 다른 학문에 비해 특별하지 않다. 경제학을 참고하자.
수많은 경제 법칙에도 불구하고 현실은 시궁창 아닌가. 절대 공리인 수요와 공급의 법칙으로 설명이 되지 않는 수많은 예외와 혼돈이 경제를 지배하지 않던가.
이제 여유를 가져보자. 항상 말도 안되는 사용자의 요구사항에 대해 한걸음 물러나서 이해해보자.
받아들일 수 없는 요구사항이라 할지라도 한번 생각이라도 해보는 것이 좋다.
이것은 요구사항을 모두 받아들이라는 것과는 다르다. 차를 판다고 생각해보자. 소형차에 대형엔진을 달아달라는 고객의 요구를 받아들일 수는 없다.(물론 충분한 가격을 지불한다면 고려해보자. 혹 100억을 줄지도 모르니까;...)
그것이 불가능하다는 것을 고객에게 납득시키기란 어렵지 않다. 그러나 소프트웨어는 쉽지 않다.
소프트웨어는 보이지 않는다. 우리에게 당연하다고 생각되는 것들이 사용자에겐 전혀 당연하지 않다.
그들에겐 미지의 세계이다. 따라서 말도 안되는 요구를 할 수 있다. 아파트를 다 짓고 나서 아파트 기둥의 철근을 바꿔 달라는 사람은 없어도 DB나 OS를 바꿔달라는 사람은 많다.(설계 당시부터 이러한 점이 고려되지 않았다면 아파트 기둥을 바꾸는 것만큼이나 자원이 소비된다.)
이쯤되면 자부심을 가져도 된다.
우헤헤, 불가능이란 없어보이는 소프트웨어 개발자가 아닌가!
아무리 극단적 설계를 하더라도 소프트웨어의 변경은 피할 수 없는 숙명이다. 개발자라면 누구나 대단하다고 생각하는 설계조차 아무짝에도 쓸모없게 만들어주는 슈퍼 유저의 요구사항 변경이 일어난다.
진부한 이야기지만 어쩔 수 없다. 피할 수 없으면 즐기자.
고객의 요구사항을 대비한 내 설계로 인해 문제가 쉽게 해결된다면 그 얼마나 기쁘지 아니할까.
또한 소프트웨어가 모든 문제를 해결해주지 못한다. 다른 방법으로 해결할 수 있다면 그 방법도 적극 도입하라.
개밥은 사람이 만든다. 개밥은 개가 먹는다. 따라서 사람은 개밥을 먹지 않으므로 개밥이 어떤지 알기 어렵다.
소프트웨어도 마찬가지다. 내가 만든 소프트웨어가 사용자의 입장에선 어떻게 보일 수 있을지 알기 어렵다.
따라서 우리는 개밥먹기를 한다. 우리가 직접 소프트웨어를 사용해보고 체감하여 평가해보는 것이다.
그러나 그런 것으로는 충분하지 않다. 사용자와 개발자는 사전지식이 다르기 때문이다.
개발자에게 있어 당연하여 설명할 필요조차 없으리라 생각되었던 버튼 하나 조차도 사용자에겐 이해할 수 없는 버튼이 되어버리는 경우가 종종 있다.
그래서 개발자가 만든 소프트웨어에 대해 사용자는 많은 불평을 하고 처음에 이야기했던 그림과 다른 이야기를 하기 시작한다.
여기가 많은 개발자가 힘들어하는 지점이다.
최근에 본 서적 중에 'Prefactoring'이란 책이 있다.
책에서 개발자는 사용자와 커피를 함께 마시며 함께 대화를 통해 개발을 진행해나가는 모습을 보여준다. 게다가 유쾌한 농담까지.
이 얼마나 멋진 모습인가!
그러나 예제는 예제일뿐... 현실에서는 그와 같은 여유를 가지기 어렵다. (물론 여기에는 개발자의 역량부족과 현실적 기타 제약요소들의 복합적 원인이 존재하겠지만)
따라서 실제로는 싸워 이긴다 라는 표현이 무색할만큼 충돌이 빈번하게 일어난다.
자, 이쯤되면 슈퍼맨처럼 해결하는 개발서적의 저자들에게 돌을 던질 만하다.
왜 이렇게 현실 세계는 다른 것일까
왜 개발자는 이렇게 힘든 것일까
그러나 전산학은 다른 학문에 비해 특별하지 않다. 경제학을 참고하자.
수많은 경제 법칙에도 불구하고 현실은 시궁창 아닌가. 절대 공리인 수요와 공급의 법칙으로 설명이 되지 않는 수많은 예외와 혼돈이 경제를 지배하지 않던가.
이제 여유를 가져보자. 항상 말도 안되는 사용자의 요구사항에 대해 한걸음 물러나서 이해해보자.
받아들일 수 없는 요구사항이라 할지라도 한번 생각이라도 해보는 것이 좋다.
이것은 요구사항을 모두 받아들이라는 것과는 다르다. 차를 판다고 생각해보자. 소형차에 대형엔진을 달아달라는 고객의 요구를 받아들일 수는 없다.(물론 충분한 가격을 지불한다면 고려해보자. 혹 100억을 줄지도 모르니까;...)
그것이 불가능하다는 것을 고객에게 납득시키기란 어렵지 않다. 그러나 소프트웨어는 쉽지 않다.
소프트웨어는 보이지 않는다. 우리에게 당연하다고 생각되는 것들이 사용자에겐 전혀 당연하지 않다.
그들에겐 미지의 세계이다. 따라서 말도 안되는 요구를 할 수 있다. 아파트를 다 짓고 나서 아파트 기둥의 철근을 바꿔 달라는 사람은 없어도 DB나 OS를 바꿔달라는 사람은 많다.(설계 당시부터 이러한 점이 고려되지 않았다면 아파트 기둥을 바꾸는 것만큼이나 자원이 소비된다.)
이쯤되면 자부심을 가져도 된다.
우헤헤, 불가능이란 없어보이는 소프트웨어 개발자가 아닌가!
아무리 극단적 설계를 하더라도 소프트웨어의 변경은 피할 수 없는 숙명이다. 개발자라면 누구나 대단하다고 생각하는 설계조차 아무짝에도 쓸모없게 만들어주는 슈퍼 유저의 요구사항 변경이 일어난다.
진부한 이야기지만 어쩔 수 없다. 피할 수 없으면 즐기자.
고객의 요구사항을 대비한 내 설계로 인해 문제가 쉽게 해결된다면 그 얼마나 기쁘지 아니할까.
또한 소프트웨어가 모든 문제를 해결해주지 못한다. 다른 방법으로 해결할 수 있다면 그 방법도 적극 도입하라.
TAG 개밥먹기
