본문 바로가기

개발자

'수동적인 개발자'가 아니라 '능동적인 개발자'가 되기로 했다.

- 말하자면 그동안 나는 맞춤 정장 제작자 -

그동안 나는 수동적인 개발자였다.
무슨 말이냐 하면, 
클라이언트가 요구하는 기능이 있으면 되도록 구현해 주고,
클라이언트가 요구하지 않는 기능은 굳이 구현하지 않았다.
무언가 기능을 구현해 달라고 하면,
기술적으로 불가능하거나 매우 어려운 것이 아닌 이상
군말없이 구현해 주었고,
딱히 질문이나 상의를 시도하지도 않았다.


이것은 귀찮거나 일을 줄이고 싶어서가 아니었다.
내 나름대로 개발자로서의 가치관 때문이었다.
나는 일종의 주문제작자 같은 존재라고 생각했다.
개발자는 클라이언트를 도와주는 서포터라고 생각했다.
개발자의 역할은, 클라이언트가 머릿속으로 구상하고 있는 
바로 그 기능과 바로 그 페이지를 
그대로 눈앞에 구현해내는 일을 도와주는 역할이라고 생각했다.


비유하자면 고객의 몸에 딱 맞는 맞춤 정장을 만드는 테일러라든가,
내 몸의 일부처럼 써야 하는 의수나 의족을
한 명 한 명에 맞추어 정밀하게 제작해야 하는 제작자를 떠올렸다.

 

 

- 이렇게 만들어주세요. 아니, 그냥 다시 없애주세요. -

그런데 최근에 이런 가치관을 조금 바꾸게 되었다.
한 번은 목록 페이지를 만들고 있었다.
그 페이지는 '인기글 전체보기' 페이지이기 때문에
이미 '조회수'로 정렬해 놓은 상태였다.
그런데 클라이언트는 거기에 더해서 '최신순' 정렬을 추가하고 싶어 했다.
그러니까, '조회수' 정렬을 기본으로 깔고, 그 위에 '최신순' 정렬을 얹고 싶어 했다.


기술적으로 어렵지는 않았다.
그냥 order by에 정렬 기준 하나를 더 뒤쪽으로 붙여주면 되었다.
화면 단에서는 정렬 기준을 선택하는 select box와 '조회' 버튼을 만들어 두었다.


구현이 끝났고, 클라이언트가 시연해 보았다.
그러더니 다시 그 기능을 없애달라고 했다.
.....?
이유가 무엇인지 궁금했다.
구현이 잘 안 된 것도 아니고 제대로 작동하고 있었기 때문이다.
아니, 해달라고 해서 해줬더니 또 자기가 원하던 게 아니란다.
헛수고를 한 것 같아서 살짝 기분이 상하기도 했다.


이유를 들어 보니 이 기능이 완성됐을 때 모습을 제대로 상상하지 못했던 것 같다.
클라이언트가 이 기능을 만들어 달라고 할 때는 이렇게 말했다.
'사용자가 글들을 인기순으로 보고 싶어서 들어왔지만,
그 안에서 다시 최신순으로 보고 싶어할 수도 있으니까'


그런데 완성된 기능을 보니 막상 그렇지 않았던 것이다.
'최신순' 정렬을 적용하더라도 겉으로 보기에는
딱히 변하는 게 없어 보였기 때문이다.
무슨 말이냐 하면,
일단 '조회순'을 더 높은 우선순위로 두고 정렬했기 때문에
조회수가 겹치는 글이 있을 때에만 
그 글들끼리 '최신순' 기준이 적용되었다.


그런데 문제는 '조회수'가 완전히 똑같이 겹치는 경우가 많지 않았다.
겹치는 글이 있더라도 두세 개 정도이고,
그 안에서 정렬 기능이 따로 필요할 만큼 겹치는 경우는 거의 없었다.
그러니 '조회수' 정렬을 적용하나 마나 사실상
전체적인 글들 순서는 거의 변하지 않았다.


클라이언트가 이 기능을 요구할 때는 
이런 것까지 생가하지 못했던 모양이다.
클라이언트는 자신이 무엇을 요구하는지도 모르는 채로
구현하기를 요구하고 있었던 것이다.

 

- 더 많이 아는 쪽이 더 적극적으로 알려줬어야지! -

이게 과연 클라이언트만의 잘못인지 하는 생각이 들었다.
어쨌든 기술적으로 구현하는 과정과 그 결과는 개발자가 더 잘 알 것이다.
개발자가 더 전문가 쪽에 해당하는 것이다.
그러면 이 기능이 좋은지 나쁜지,
이러한 방법도 있지만 저러한 방법은 어떤지,
이 기능이 구현되면 어떤 결과물이 나올지,
그 결과물은 어떤 단점이 있는지,
그런 총체적인 정보를 개발자가 더 잘 알 것이다.


그렇다면 이러한 부분에 대한 상담이나 질문, 제안까지도
클라이언트와 함께 하는 것이 좋은 개발자가 아닐까?
그러니까, 이런 개발자는 말하자면 '능동적인 개발자'다.


비유하자면, 고객이 소매를 이렇게 만들어 달라는 요구를 하거나,
바지를 이렇게 수선해 달라고 요구하거나 할 때,
만들어 주는 쪽은 그 결과물이 어떻게 나올지 더 잘 알고 있으므로,
'만약 그렇게 하시면 이러이러한 점에서 불편할 수 있습니다.'
라든가, '이러이러한 단점이 생겨서 많은 고객들이 다시 찾아오십니다'
라고 경고를 해주거나, '대신 이러이러한 절충 방법이 있는데 어떠신지요'
라고 더 나아가서 제안까지 해주는 테일러가 더 좋은 전문가 아닐까?

 

- 클라이언트가 '만족해 하는' 결과물이란 -

나는 클라이언트가 결과물을 보고 만족해했으면 좋겠다고 생각했다.
그래서 최대한 원하는 대로 만들어주고 싶었다.
내가 만들고 싶은 페이지를 만들기보다,
상대방이 만들고 싶어 하는 페이지를 만들고자 했다.
그것이 클라이언트가 만족하는 결과물이라고 생각했기 때문이다.


그런데 그렇게 해서 만든 결과물이 어쨌든 결과적으로 문제가 많다면?
단점이 많고 이용하기 불편한 페이지라면?
클라이언트 자신이 요구해서 그렇게 만들기는 했지만,
만족스럽지는 못할 것이다.


반면에, 전문가 쪽인 개발자가 충분히 
경고를 주고, 제안을 하고, 절충안을 찾아 가며 구현해서,
퀄리티가 높은 페이지가 나왔다면?
클라이언트가 원하는 그대로를 만들지는 못했어도,
사용하기 편하고 기능적으로도 더 좋은 페이지가 나왔다면?
분명 클라이언트의 만족도도 높아질 것이다.

그래서 '수동적인 개발자'에서 '능동적인 개발자'가 되어야겠다는 생각이 들었다.
클라이언트가 원하는 대로 그저 그대로 따라주는 것이 아니라,
이런 저런 마찰을 조금 더 겪더라도 토론과 토의와 상의와 협상을 거치면서
더 좋은 결과물을 만드는 과정에 조금 더 힘을 싣는 개발자가 되기로 했다.

 

-220731




반응형