까탈스런 프로그래머

semmal의 이미지

내가 생각하기에 프로그래머는 까탈스러워야 한다. 너무나도 까탈스러워서 보통 사람들이라면 "저 사람하고 말하면 정말 피곤하구나."라고 느낄 정도는 되어야 한다. 까탈스럽고 피곤하게 느껴져야하는 이유는 그만큼 남들보다 꼼꼼해야하기 때문이다.
하지만 프로그래머로 일하면서 만난 대부분의 프로그래머가 대범하다. 너무나도 대범해서 내가 보기에는 꼼꼼히 따지고 넘어가야할 사항을 그냥 "원래"나 "당연"과 같은 단어를 써서 표현하거나 "잘 아시죠?"와 같은 말로 넘어가 버린다. 그래서 나와 같이 일하는 사람들은 대부분 피곤을 많이 느끼는 편이다. 당연히 나도 편하기만 한건 아니다.
버그를 찾으려고 코드를 처음부터 꼼꼼히 살펴본다고 프로그래머가 까탈스러워지는 게 아니다. 그건 그저 바보같은 짓일 뿐이다. 모르는 것이 생길 때마다 일일이 물어보는 성격때문에 까탈스럽다고 말을 들을 이유는 없다. 그건 그저 학구열이 좋은 것일 뿐이다. 자신이 만든 프로그램이 만족스럽게 안돌아간다고 새벽까지 코드를 살펴보는 게 까탈스러운 행동도 아니다. 그저 능력이 부족해서 일을 제대로 못한 것일 뿐이다.
그럼 어떻게 해야 까탈스럽다는 것일까? 첫째는 아무리 당연한 것도 빠뜨리고 그냥 넘어가서는 안된다는 것이다. 메뉴의 맨 앞에 왜 "파일" 항목이 와야하고, 파일 메뉴의 맨 처음은 왜 "새 파일"이 와야하는지 의심해야한다. 그 하나 하나에 대해서 합당한 이유를 달아서 프로젝트에 참가하는 모든 사람이 알아야 한다. 둘째는 아무리 사소한 것도 빠뜨리고 그냥 넘어가서는 안된다는 것이다. "경고창을 띄운다"에서 끝나는게 아니라 그 창에 "OK"버튼만 있는지 "Cancel"버튼이 있는지 아니면 다른 버튼이 있어야 하는지 모두 알게 해야한다. 당연히 합당한 이유도 준비해야한다. 셋째, 잘못되었다고 생각하는 건 무조건 지적하고 봐야한다. 시간에 쫓겨 잘못을 고칠 수는 없다고 하더라도 고칠 수 없는 합당한 이유와 나중에라도 적용할만한 대안이라도 가지고 넘어가야한다.
언젠가 중국에서 만든 캠코더 복제품을 본 적이 있다. 그 캠코더에는 비디오테이프와 녹음테이프 두 개가 들어간다. 겉모습만 보고 "당연히" 동작할거라고 사람들은 그 캠코더를 사겠지만 문제는 REC버튼이 두 개라는 것이다. 내 생각에는 당연한 것을 의심한다는 것은 그 프로그램이 어떤 것을 중요하게 생각하고, 어떤 것을 중요하게 생각하지 않는지를 판단하는 요소다. 프로그램의 요소 하나하나는 "당연히" 붙어있는 것이 아니라 프로그램이 가지는 원래의 "목적에 맡게" 붙어있는 것이다. 목적이 없다면 그런 기능은 아무리 많아도 전혀 쓸모없다. 저런 캠코더가 아무리 해상도가 높고 소리의 질이 높더라도, 사람들은 결국 REC버튼이 하나인 캠코더를 원하기 마련이다.
사소한 것을 중요하게 여기는 것은 사용자를 배려하느냐 안하느냐를 판단하는 요소다. 어떤 사이트에 이미지를 업로드 하는 기능이 없을때는 사람들은 보통 그런 기능이 어서 생기기를 바랬지만, 후에 그런 기능이 생겼음에도 불구하고 너무나도 쓰기에 불편했기때문에 그 사이트를 다시는 쓰지 않는 경우도 있다. 개발자 자신이 쓴다고 생각하고 그 기능을 만들었다면 그런 엉터리같은 인터페이스는 나오지 않았을게 분명하다. 그 개발자가 그 기능을 스스로 그렇게 쓸려고 만들었다면 그 사람에게는 어떤 일을 맡겨도 제대로 나오지 않을게 분명하다. 난 그런 사람이 만든 사이트를 신뢰할 수는 없을 것 같다.
잘못한 점이 있을 때의 대처는 그 프로그램의 앞날을 판단하는 요소다. 그저 "시간이 없어서"라는 핑계로 넘어가는 것이 아니라, 시간이 없더라도 정확히 어떤 것을 못하는지, 일부라도 만들 수 있는지, 그렇게 일부라도 만든 것이 과연 가치가 있는지 따져봐야한다. 못만든 부분이 있다면 다음 릴리즈때 내보낼 수 있을지, 버그가 있다면 언제쯤에 패치를 할 수 있을지, 구조상의 문제라면 그에 대한 대안은 어떻게 가져갈지 당연히 생각하고 논의해봐야한다. 시간이 없다는 핑계로 밤새워 만들어봐야, "당연"하게 아무 생각없이 기능이 들어가고 배치되어있고, "사소"한 부분에는 신경도 안썼을게 분명하다. 다음 버전이라고 다를까? 난 그런 프로그램을 쓰고 싶지 않기때문에 만들고 싶지도 않다.
어느 프로그래머나 자신이 만든 프로그램이 사용자들에게 사랑받기를 원한다고 생각한다. 이런 것은 자식을 놓아 기르는 것과 마찬가지다. 프로그램을 "당연"하게 만드는 사람은 아기를 키우면서도 별 고민없이 그저 "당연"하게 키우는 부모일지도 모른다. 프로그램의 요소를 "사소하게" 생각하는 사람은 유모차 바닥에 못이 박혀서 아기가 울어도 "사소하게" 생각하고 아기가 왜 우는지 모를 수 있다. "시간이 없어서" 프로그램을 대충 짜는 사람은 아기가 커갈때도 "시간이 없어서" 아기가 대충 자라는 모습을 보게 될 지도 모른다.
그래서 프로그래머는 까탈스러워야 한다.

댓글

joone의 이미지

그러다보니 생활할때도 유독 까탈스러워질때가 있습니다.

토마토 쥬스가 너무 싱거울 때... (대부분 친절하게 다시 만들어주더라구요)
쓸모없이 주민번호를 요구할 때... (video렌탈 직원을 15분간 설득함)
라떼가 너무 맛이 없을 때... (맛이 있을 때까지 3번 교환해주더라고요.. 2번째는 제 시덥지 않은 표정만 보고 다른 메뉴로 바꿔줌.. 저도부담스러웠음)

이렇게 해야 만드는 사람들도 본인이 잘못 만들고 있다는 것을 깨닫게 되는 것이죠..
그래야 그 집 장사에도 도움이 되고, 저도 만족스럽게 다음에 다시 올 수 있지요.

http://joone.net/blog

jhumwhale의 이미지

그렇게 해서 좋게 받아들이는 직원이 있는 반면
진상 손님이 왔다는 표정을 얼굴에 드러내는 경우를 종종 봐서

안좋으면 다음에 이용하지 않고,
동료나 아는 사람이 같이 가자고 하면 다른 곳을 이용하게끔 유도하는 편이죠...

안티도 애정이 있어야 한다고 하지만,
제 돈 내고 건의를 해서까지 가게 이용을 하고 싶진 않더라고요..
그 가게 아니어도 비슷한 품질의 상품과 서비스를 제공 받을 곳은 무척 많은데...:)

권순선의 이미지

완벽주의와도 좀 일맥상통하는 것 같은데 여러가지로 본인이 스스로 컨트롤할 수 없는 상황-특히 일정-때문에 현실과 타협하는 경우가 많을 것입니다. 그렇지만 그것을 극복하고 완벽주의를 고수해 내는 것 역시 매우 중요한 능력이죠...

마잇의 이미지

쓰레기 같은 프로그램들 많이 만났었죠. 노력과 창작의 결과물에 쓰레기라는 표현 쓰기는 참 조심스럽지만 이미 구매를 끝낸 후라면 쓰레기라는 표현도 모자란다고 느껴질 때도 있습니다. 이런 쓰레기일수록 가격이 턱없이 비싼 경향이 좀 있는 것 같습니다. 그래서 더욱 쓰레기라고 불르고 싶어집니다.

리눅스를 알게 되면서 자유소프트웨어쪽으로 건너오기 시작하니까 이런 쓰레기를 만나는 횟수가 확 줄더군요. 그래서 여지껏 불편한 것 참아가면서 계속 쓰고 있나 봅니다.

--
마잇


--
마잇

hey의 이미지

뭘 말씀하시려는 건지는 알겠는데, 사실 예로 들어주신 것들은 프로그래머에게만 요구되는 건 아니라고 봐요. 오히려 기획자에게 맞는 것 같습니다. 사소한 것 하나도 허투루 보지 않아야, 고객이 원하지도 않는 기능을 프로그래머가 만들도록 놔두지 않을 수 있겠죠. 물론 프로그래머도 자기들이 하는 일에서 그래야 할 거고요.

참고로, 전 프로그래머입니다. :-)

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


lindolsang의 이미지

저도 어느정도 동의 하지만..

기획자의 일에.. 한표 추가합니다.

정말로 고객이 원하는 기능.. 뭐. 파일 메뉴가 맨앞에 와야 한다든지..
의 것들은 기획자가 허투로 넘기지않고 꼼꼼히 하는것은 기획자의 일이 아닌가요?

대충대충 저도 넘어가는 경우가 많았는데.. 많이 찔리네요..

funkcode의 이미지


프로그래머가 단순히 자기의 일을 제한하지 않고, 고객의 입장을 충분히 고려하려고 노력하는건
좋은 습관 같습니다 ^^

그리고, 그러한 부분까지 생각해야 프로그램의 퀄리티와 만족도 또한 높아진다고 생각되네요.

--------------------
Dance is my life..

--------------------
Dance is my life..

shji의 이미지

무엇이든 지나치면 병이됩니다. 까탈스러움/완벽주의가 우리에게 특히
부족한 것은 맞습니다. 주변에 너무나 어이없는 결과물들을 봐 왔구요..
하지만 경우에 따라서는 조금은 완벽에의 욕구를 억제할 필요도 있는
것 같습니다. 최근의 기술 개발은 완벽도와 함께 스피드도 중요하고..
또한 프로젝트의 규모도 커지고 있으므로 지나친 완벽주의는 팀에 좋지
않은 영향을 주기도 합니다.
주관적이고 지나친 까탈스러움을 피하고 객관적이고 적절한 완벽주의를
추가하는 밸런스가 중요하게 생각될 때가 있습니다.

익명 사용자의 이미지

이 직종에 종사하면서 괴팍한 사람 좀 보았고, 이제 스스로도 괴팍하고 유별난 사람이 되어간다고 느끼고 있습니다. 서비스를 제공받을 일이 생기면 90%정도 거의 항상 하자가 눈에 지적하고 심지어 싸우기도 합니다. 인생을 사는 데 있어서 좋은 직종은 아닌 듯. :(

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.