루미넌스 - miscellaneous

난 '개발자'다.

국제표준용어-_-로 개발자와 기획자가 어떤 뜻인지는 모르겠으나, 적어도 한국어를 모국어로 쓰는 사람들 가운데, IT라는 산업에 종사하는 사람들 사이에는, '기획자'는 수요자로 표현되고 '개발자'는 공급자로 표현된다. 진정한 수요자는 유저일텐데 개발 현장에서는 이상하게도 그렇게 표현되곤 한다.
즉, 기획자가 만들어달라고 요구하는 것을 구현해 주는 것이 개발자라고 표현되는 것이다. 맘에 안들지만 받아들이자..

근데 왜인지 이 '기획자'와 '개발자'의 영역 구분은 매우 모호하다.. 그래서 갈등을 유발하기도 한다..
뭐가 모호한가?
소프트웨어 개발 프로젝트는 대략 다음의 과정을 따라 진행된다. (엔지니어링의 결과물이 최종산물이 되는 영역에서는 보통 대동소이하지만 일단 소프트웨어 개발로 국한하자)

문제의 발견 > 요구사항(니즈)의 정립 > 실현방안의 수립 > 소프트웨어 설계 > 구현 > 테스트 > 출시

'니즈의 정립부터 소프트웨어 설계까지'를 보통 '설계'라 부른다. 그리고 개발자들은 이건 자기의 할일이라고 생각한다. 그래서 적극적이다. 이 때 참여하지 않으면 나중에 피똥싸는거 한두번 경험한게 아니니...
근데 보통 '문제의 발견부터 실현방안의 수립까지'를 보통 '기획'이라 부른다. 여기서 모호함이 드러난다. 기획의 상당부분을 개발자들은 설계과정이라 생각한다는 거다. 물론 개발자들도 그 부분을 기획이라고 부르긴 한다. 스스로 프로젝트를 대함에 있어 모호함을 안고 있는거다. 기획자에게 맡겨야 하는 일이면서 자기가 해야 하는 일이기도 하다. 그러다 보니 개발자는 허구헌날 기획자랑 싸운다. 자기가 한 설계가 아니니 신뢰를 못하는 경우도 많다.

개발자와 기획자는 서로 '말귀를 못 알아들는다'고 하며 성질만 부린다.
밥그릇 싸움인듯 하지만 사실은 의사소통의 문제인 것이다.

개발자가 고자세로 나오니 기획자는 저자세로 파고 들수 밖에 없다. 이 과정에서 거의 항상 잊혀지는건 '니즈'다. 소프트웨어의 진짜 수요자인 고객으로 부터 발생하는 유일한 기획요소인 '니즈'가 간과된채 기획이 수정되고 소프트웨어 설계가 이루어진다. 대부분의 소프트웨어 개발 프로젝트가 성공하지 못하는 이유의 큰 부분이 여기에 있다. 사용할 사람들에게 어필하지 못하는 결과물을 만들게 되는거다.

결과가 나온뒤에 되돌아보며 개발자 대부분은 기획을 탓한다. '왜 쓸데없는걸 만들어달래서...' 이런식이다.
참으로 바보같은 생각이다. '니즈'를 잊혀지게 하는 가장 결정적인 역할을 한 사람은 바로 개발자다. '문제발견'단계에서는 보통 아무것도 하지 않은(문제를 감지조차 못한) 개발자인 주제에 이미 발견된 문제로부터 괴발개발이나마 니즈를 적어 들고 나타난 기획자에게, 극렬히 저항하며 실현방안 수립단계를 뒤엎었기 때문에 '니즈'는 뒷전으로 밀려나는 거다. 니즈 정립부터 설계까지의 과정에서 양(positive)의 피드백을 하지 못하고 심지어 부(negative)의 피드백 조차 아닌, 그저 역행만을 만들어 냈기 때문인거다.

반성해야 한다. 어떤 문제로부터 어떤 니즈를 발견해서 가져온 기획안인지 생각은 해 보았는가? 그들(기획자)은 기술적 기반이 취약하다는걸 전제로 개떡같이 말해도 찰떡같이 새겨 들으려 노력하며 들어본 적이 있는가? 모호하게 반복되는 용어나, 과도한 부하를 유발하는 비지니스 로직을 무턱대고 성질부리며 반송하지 않고, 교정해주거나 대안을 제시한 적이 있는가? 설계과정에 '참여'하고 있는가, '딴죽'걸고 있는가... 이 기획이 '쓸데없는 것'이라면 어떤게 '쓸모있는 것'인지 제시해 본적 있는가?
개발자들은 기획자들이 구사하는 '기획어'를 모른다. 생각하고 대들어라.

그럼 뭐... 기획자는 잘했나? 기획은 피해자라고?
웃기지도 않은 소리다. 개발자가 고자세로 나오는 이유도 모른채 기획의 관철만을 위해 일단 저자세로 파고드니 본인조차 '니즈'를 잊는거다. 우리가 가진것이 무엇이며, 기지지 못한 것이 무엇이며, 그래서 지금 만들어 가지려 하는것이 무엇인가를 절대 잊지 말아야 하는 것이 기획자의 업무인 것이다. 개발자가 자꾸 땡깡부려서 프로젝트가 산으로 간다고? 그걸 막지 못했다면 기획자도 업무 태만이고 역량 부족인거다. (난 아니라고 믿고 싶지만) 혹시, 정말로 '니즈'가 결여된 상상의 나래로 만든 기획안은 아니었는가하는 점 역시 돌이켜 반성해야 한다.

개발자가 들이박으면 기획자들은 보통 겁을 먹고 수그리는데, 왜그런가? 기술적 기반이 취약해서다. 개발자가 안된다고 하면 그냥 진짜 안되는게 아니다. 직접 코드를 작성하거나 데이터플로우를 설계할 정도로 기술적 소양을 갖출 필요는 없다. 적어도 SQL정도의 데이터를 보는 방법이라던가, 비지니스 로직이 품게 될 복잡성에 대한 추측 정도는 공부해 두란 말이다. 그정도를 생각할 수 있다면 개발자가 안된다고 하는 기획안을 작성하지 않게 될 것이며, 설령 개발자가 안된다고 뻗대도 소신껏 관철시킬수 있는 근거를 확보하게 될 것이다. 그리고 개발자들이 구사하는 '개발어'를 서서히 이해하게 될 것이다. 기획자들이 공부해야 하는건 ppt 작성 기법이 아니다. 메모장으로 만든 기획안이 ppt보다 훌륭할 수 있다.

결국 의사소통의 문제다.

길거리에서 한국어를 잘 못하는 외국인이 뭔가 물어본다. 보통은 이사람이 하는 말이 뭔지 잘 들어보고 대답을 해준다. 그 외국인이 스와힐리어를 사용하고 있지 않는한은 말이다ㅡ_ㅡ;
제발 외국인을 대하는 마음으로 서로를 대하자. 개발자나 기획자나 한국어를 하고 있다고 착각하기 쉬운데, 소리나 단어나 문법은 한국어와 같지만, 단어의 뜻이나, 단어의 배치에 따라 달라지는 의미등이 거의 외국어나 마찬가지로 다르다.

절대 개발자는 완벽한 기획어를 구사하지 못한다. 반대도 마찬가지다. 자기들이 맡은 업무 영역의 특성상 어쩔수 없다. 기대해선 안된다.

개발자는 기획자의 요청을 개발어로 번역한 후 이해하여 다시 스스로 기획어로 번역해서 본인이 이해한 내용이 맞는가를 확인해야 한다. 기획자 역시 스스로 개발어를 최대한 구사하여 기획안을 작성하고 개발자가 주는 피드백을 기획어로 번역한 후 스스로 개발어로 번역해야 한다.

후...
갑갑하면 한번씩 요딴글을 끄적여 두는구나..
블로그는 내 화장실이었나ㅠㅠ
또 흥분한채 글쓰고 말았네;;; 쩝..

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

쉬운일이 아니다.. 거의 초등학생 학급회의 지도하는 수준으로 보면 된다. 시키는 대로밖에 못하는 컴퓨터와 대화하는 것에 익숙해진 나머지, 자기 생각이나 주장, 선호하는것 등을 가지고 있는 '사람'과는 대화하는 법을 잊어버린 존재들이 '개발자'다.

• 회의 시작 전에 발언권의 이동에 대해 꼭 주지시킨다.
  개발자들은 자기가 아는 것에 대해서는 끼어들어 아는것을 이야기 하는 안좋은 습성이 보통 있다. 말하고 있는 사람이 도움이나 상세 발언을 요청할 때가 아니면 발언 하지 말 것과, 말하는 사람은 다른 이의 상세 설명이 필요할때 발언권을 잠시 양도하고 부연설명을 요청할 수 있다는 것을 알려줘야 한다. 단, 회의 진행자는 지금이 메인테마를 얘기하는 중인지, 중간에 끼어든 상세설명을 하고 있는 중인지를 항상 파악하고, 메인테마로 돌아갈수 있도록 계속 주의를 기울여야 한다.
  
  
• 회의성격/목적을 확실히 규정해야 한다.
  그간 개발한 것을 발표하고 공유하기 위한 자리인지, 어떤 문제점을 해결하기 위한 대책을 수립하기 위한 자리인지, 예기치 못한 생황에 대한 시급한 우회로를 찾아야 하는 자리인지, 구현에 앞서 설계를 위한 자리인지, 구현방법에 대해 아이디어를 나눠보는 자리인지, 구현 방법의 디테일을 결정하기 위한 자리인지, 구현에 착수하기 앞서 결정한 전반적인 것을 리뷰하면서 공유하는 자리인지 등등등 ...
  개발자는 이걸 명확히 말해 주지 않으면 항상 디테일의 구현에 집착하게 마련이다. 지금 그 디테일을 얘기하지 않아도 될 때에, 또는 지금 그 구현방법의 디테일을 얘기하고 있으면 안될때조차 그 디테일 밖에 생각해내지 못한다. 게다가 자꾸 잊어버린다. 회의 진행자는 미리 규정해 준 회의 성격을 중간중간 지속적으로 리마인드 시켜줘야 한다.
  
  
• '해 놓은 것'을 이야기 할 때에는 그에 대해 경청하고 나서, 질문한다.
  진행자는 질문시간을 만들어 내기 위해 의미상 phase를 중간 중간 끊어준다. 이 '끊어줌'이 잦으면 좋지 않고 회의가 산으로 갈 수 있다. 그러나 안끊어주면 질문 타이밍을 놓쳐 질문 자체를 잊어버린다. 결국 청중의 리액션이나 피드백을 기대할 수 없는 한국스런 발표자리가 돼버린다.
  
  
• 개발자에게 질문할 때는 단어 선택이 중요하다.
  따지거나 다른 방법을 제시하는 식의 느낌을 주면 안되는데.. 개발자끼리의 회의에선 보통 그런 느낌을 주게 되고, 여리고 순진한 우리의 개발자는 그런 느낌을 받으면 그 이면의 진의를 읽지 못하고 방어기제를 작동시킨다. 그러면 회의가 아니라 싸움이 된다. 아무것도 얻지 못하는 회의가 될 수 있다.
  개발자가 이야기하고 있는 구현한/할 내용중 의아한 부분은(개발자 회의의 99%는 구현 단계에서 로직이나 솔루션의 선택의 문제에서 싸움이 벌어지는데), 어떤 문제점을 예상/발생했기에 그렇게 결정했는가 등 그 결정이 내려진 배경이나 결정하게된 동기를 묻는게 좋다. 개발자들끼리 회의하면 이게잘 안된다. 개발자는 '지금 내가 떠올리지 못하는 문제점을 예상했는가 본데, 그게 뭔지가 궁금해요. 어떤 동기로 그 방법을 택했어요?'라는 문장을 머릿속에 만들지 못한다. '어? 왜 그렇게 해야돼요?' 라고밖에 말 못한다. 정작 본인은 이 질문을 들었을때 '어? 왜 그딴식으로 밖에 못한겁니까?' 라고 이해하면서 그 사실을 모른다.
  그걸 알게된 사람은 우리가 더이상 개발자라 부르지 않는다 - 매니저거나 구루거나..
  
  
• 위에 말한 성격이나 목적에서 벗어나는 내용을 위한 다른 회의를 잡는다.
  그리고 회의를 취소한다. 안그러면 주제에서 벗어나는 걸 막을 길이 없다.
  
  
• 회의를 많이/자주 하지 않는다.
  이게 가장 중요하다. 개발자는 회의를 많이 하면 안된다. 개발자 개개인에게 자기가 짠 코드블럭은 프라이버시의 영역이다. 코드 블럭 밖에서 코드 블럭을 블랙박스로 간주하고.. 그 내부를 시시콜콜 알려들면 안된다. 그 블랙박스를 다른 블랙박스에 붙여 조립하기 위한 회의는 필요하지만 그 이상은 절대 하면 안된다. 회의 자주하면 '그래서 원하는게 뭐야?' 라던가 '도대체 왜 이딴걸 만들라는거야?' 라면서 제대로 안짜온다.
  

믈론, 모든 개발자가 그렇다는.. 얘기다;;

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

작년에 이어 올해도, 가급적 자가용 승용차를 이용하라는 엄청난 공지와 함께 6월 18일 저녁, 제주시 해안도로변에 있는 화이트하우스에서 다음 제주 개발자 BoF가 있었다. 마침 시작해버린 장마로 구질구질한 날씨 속에서, 나름 잼있게 개발 내외의 관심사를 나눌 수 있는 자리였다.

근데 작년과 같은장소.. 은근 해비치나 신라호텔을 기대했지만 너무 크고 야무진 꿈이었던;;

루미는 "골프-우리도 싱글 할수 있다"를 발제하고 테이블을 차렸다..ㅎㅎ
(사진이 많은 관계로 전부 480px짜리 작은 이미지. 큰이미지는 웹앨범에서^^)

2008 다음 제주 개발자Bof_1024

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.