Archive for the 'Developers' Category

지난 3일 연세대에 조촐한 규모로 진행 된 오픈소스 뛰어들기 행사 후기를 아주 늦게나마 올려 봅니다.

곧 겨울 방학도 시작되고 Winter of Code 행사도 있기에 오픈소스에 관심 있는 학생분들에게 어떻게 하면 오픈소스에 참여 할 수 있는가 하는 입문서 같은 내용으로 진행 된 행사였습니다.
세션의 주된 내용은 오픈 소스에 대한 이해와 오픈소스에서 많이 사용하고 있는 도구들을 다뤄보는 것으로 실습 형태의 소규모 세션들이 주를 이뤘습니다. 덕분에 세션 분위기도 아주 좋았죠.
행사 당일 갑자기 추워진 날씨 덕분에 많이들 안 오시면 어쩌나 걱정스러웠지만 참가비 선입금이 위력을 발휘한 것인지 찾기 어려운 곳까지 많은 분들이 오셨습니다.

입구에 붙여 놓은 행사 안내문 입니다.

스티커로 할 수 있는 간단한 OX 퀴즈를 만들고 있었습니다.

행사 시작하기 전 휴계실에서 강사분들과 자원봉사자분들이 모여서 이야기를 하고 계십니다.

행사가 시작되고 장혜식님의 행사 소개가 있었습니다.

조교로 참여 했던 eclipse로 하는 php 개발 세션입니다. 전체 세션 중 여자분들이 가장 많은 초 인기 세션이었습니다.

개인적으로 자원봉사자로 참여한 행사였는데 많이 봉사하지 못 해 아쉬웠습니다. 다음 행사때는 좀 더 열심히 해야겠단 생각과 행사는 너무 재미있었다는 겁니다. 이런 행사에 더욱 많은 분들이 참여하셨으면 합니다.

오늘 GMC에서 오픈 커뮤니케이션 교육이 있었습니다.
주옥같은 내용 참 많았고 재밌있는 교육내용이었는데요.. 그 가운데 가장 머릿속에 남는 말이 “배려” 입니다. 개발자, 기획자 이 두 단어 자체도 별로 어감이 좋게 느껴지지 않는것은 제 개인적인 견해이련만, 별다른 대체할만한 단어가 떠오르지 않아 그냥 쓰겠습니다.^^; 항상 상대되는 개념으로 이야기 되죠.. 개발자와 기획자. 개발자들은 자신들의 여집합을 기획자라 하죠.. 전 개발자 집합에 속해 있는지라, 기획자분들이 어떤 사람을 개발자라 칭하는지는 잘 모르겠습니다만..

기획자여러분..
개발자들을 존중해 주세요.. 개발자들의 마법주문같은 말이라도 귀기울여 주세요.. 개발자들을 무시하지 마세요.. 여러분들이 어려운 문서를 거뜬히 읽어낼 수 있고 작성도 할 수 있고, 논리적이고 일목요연한 제안서를 만들수 있게 되기 까지 엄청난 공부와 경험을 해 오셨다는거 잘 압니다. 그치만 공부하시는 동안에 노-하우를 쌓아오시는 동안에 개발자들은 눈 시뻘개져 가면서 소스코드와 싸워가며 벌레들을 잡으면서 기술을 쌓고 역시 노-하우를 길러왔답니다.

개발자들의 목소리를 여러분의 재치 번득이는 제안서에 포함시켜주세요.. 개발자는 단순하답니다. 자기가 한 말이 달랑 한문장 기획서에 들어간것을 보고, 맨끝에 나오는 thanks to..에 자기 이름을 보고.. 초인적인 힘을 발휘한답니다. 자기가 했던 말 한줄이 받아들여진걸 알면 그때부터는 “저건 내가 기획한 프로젝트야” 라고 마음먹고 정말 애착을 가지고 밤을 세워 구현한답니다.

개발자 여러분..
기획자들에게 고마워할 줄 아세요.. 기획자에게 친절하세요.. 기획자들을 무시하지 마세요.. 여러분들이 하루가 다르게 쏟아져 나오는 신기술을 쫓아가느라 얼마나 머리가 아픈지 압니다. 매일같이 튀어나오는 버그와 어떤 전쟁을 치르는지도 압니다. 단지 0.5초 빠른 서비스를 위해 아무도 알아주지 않고 티도 안나는 그런 작업을 얼마나 많이 하는지 압니다. 다년간 그토록 많은 노-하우를 쌓기 위해 손가락이 부르트고 눈이 아프도록 모니터에 코를 박고 있었다는거 압니다.

그렇지만 그렇게 날밤을 세우는 동안, 기획자 여러분은 아이디어를 짜내고 단순한 개발자들에게 설명하려 얼마나 애쓰는지도 알아주세요.. 여러분의 마법주문같은 불평 한마디가 기획자를 얼마나 당혹스럽게 하는지 헤아려 주세요.. 기획자 분들은 여러분의 마법주문같은 전문용어를 다 배울만큼 시간이 많지 않았습니다.

저도 개발자로서 이런글을 쓰기 참 쑥스럽습니다. 하지만 개발자는 기획자에게, 기획자는 개발자에게 있어 정말 고마운 존재임은 틀림없습니다. 서로를 먹고 살수있게 해주는 존재니까요.. 설마, 기획자 없이 개발자들의 머리에서 쏟아내는 아이디어로 유저들에게 장사를 할수 있다고 생각하시나요? 혹은, 아무도 구현해 줄 사람은 없는데 기획만 하면 어느 유저가 그 훌륭하고 재치가 넘치는 아이디어를 알아볼 수 있을까요? 고마워해주세요..

요즘들어 업무상 다툼(?)을 자주 보게 됩니다. 연말이라 그런지 자주 보이더라구요..

우리 “다음커뮤니케이션”이란 회사에서는 “배려” 따위는 누가 강조하지 않아도 될 기본 덕목이 되길 희망해 봅니다.

저부터 고치겠습니다.
꾸벅~ (_ _)

얼마전 3층 발코니에 나가서 커피 한잔 마시면서 좀 쉬고 있는데 저희 팀장님이신 동욱님이 마침 나오시더군요.. 그냥 이런저런 얘기 하면서 머리를 식히다가 나온 얘기가, 누구나 기억할 만한 중학교 국어책에서 배운 윤오영님의 수필 “방망이 깎던 노인”이야기가 나왔습니다. 투철한 장인정신과, 책임감, 서두르지 않는 여유로움의 미덕 등을 강조하는 내용이라고 참고서에는 나와있죠^^
프로그래머에게 있어 장인정신이란 무엇일까요? 우리는 방망이를 깎아야 하는 걸까요?

버그 없는 프로그램을 만드는 것, 완전 무결한 에러율 0%의 로직을 구현해 내는 것, 누구나 언제든지 필요한 기능을 손쉽게 추가하고 개선해 나갈수 있도록 이해하기 좋게 코딩하는 것, 최소의 자원으로 최고의 퍼포먼스를 내는 최적의 프로그램을 짜는 것, 발생가능한 모든 상황을 미리 예상하고 대안을 보유하고 있도록 작성하는 것… 조금씩 말만 다르지 프로그래밍 분야에서 말하는 장인정신이란 대충 비슷합니다.
그런데 정말이지 이런것들이 개발자가 갖춰야할 장인정신일까요?

일단은 맞다고 하고 싶습니다. 완벽한 제품을 만드는 것이 장인의 정신이죠.. 하지만 반드시 장인정신의 덕목을 엄수해야 한다고 생각하지는 않습니다. 이건 제조업이 아닙니다. 제조업과는 다른 잣대로 생산물을 평가해야 하죠..
게다가, 사실.. 먹고 살자고 하는 짓이지 않습니까.. 주어진 시간 안에(정말이지 모호한 표현입니다만..) 계획된 목표물(역시 모호합니다.)을 만들어야 하는 것이 비지니스의 원리죠.. 시장경제가 어쩌니 하는 말들을 굳이 꺼내지 않아도 누구나 알고 있을 겁니다. 프로그래머는 엔지니어지 사이언티스트가 아니지 않습니까? 실용성이 있는 무언가를 만들어야 하는 것이지요.. 실용성을 생각한다면 비용와 이윤의 트레이드 오프가 무시할수 없는 변수로 등장 하게 되구요..

제 결론을 말할까요? 고쳐야 되는 버그를 찾아서 고치자 하는 겁니다. 물론 자원이 허락하는한 모든 버그를 고쳐야 하죠. 개선의 여지가 있는 모든 로직을 개선해야 하구요.. 하지만 때로는 포기할 줄도, 기약없지만 미룰 줄도 알아야 한다는 겁니다.

프로그램을 짜던 중 어떤 버그를 발견했습니다. 참으로 어처구니가 없는 일이었죠. 절대 일어날수 없는 입력값이 입력된겁니다. 심심해서, 또는 테스트 프로그램이 잘못 설정되는 바람에 그런 입력값을 주기도 어려운 입력값을 주게 된 것이죠. 이를테면 106키보드에서 358개의 키가 동시에 눌러졌다던지, 마우스 포인터의 좌표가 (-103.5, -87.3)이 되었다던지.. 웹서버에 전송할 HTTP Request 객체를 생성하고 소켓을 열기도 전에 Ethernet드라이벗로부터 HTTP Response가 수신되었다던지.. 상식적으로 일어나지 않을 거라고 확신이 드는 그런 입력값 말이죠.. 그랬더니 원래 의도했던 다이얼로그가 뜨지 않는겁니다. 물론 다시 버튼을 클릭 한번만 해 주면 이전의 이상한 입력값은 깨끗이 무시되고 의도한 다이얼로그가 뜨긴 합니다. 자.. 이 버그를 고쳐야 할까요? 장인정신이 투철한 개발자라면 예상치 못했던 입력값이 주어졌을 때, 예외상황을 선포하고 적절한 핸들링을 하기 위해서 말도 안되는 입력값을 상상력을 동원하여 재현해 보고 분석하여 몇가지를 무시한 결과로 다이얼로그를 보여주려고 할 겁니다. 유저는 입력이 이상했다는 것(노이즈가 개입되었을 수 있다는 것)은 전혀 느끼지 못한 채로 계속 프로그램을 작동 시킬 겁니다. 3일 밤을 꼬박 세워서 말이죠..

하지만 이런 종류의 버그에 대처하기란 쉽지 않습니다.
전세계에 배포하면 2억명의 고객에게 팔릴 이 제품에 대해, 107명쯤이 이 버그를 경험할텐데, 그중 92명은 버그를 눈치채지 못하고 버튼을 다시 클릭할겁니다. 15명은 뭔가 이상한 작동을 하는것 같다고 생각하지만 재현이 쉽지 않아 포기합니다. 하지만 개발자는 이 버그를 고치기 위해 불가능한 갖은 입력값을 프로그램에 던져보면서 모든 예외상황을 재현하려 애쓰면서 그에 적절한 반응을 보일수 있도록 코드를 수정할 것입니다. 3일 밤을 새면서 말이죠..
(사실 3일이면 다행이죠)
소프트웨어의 완성도는 고객에게 기업에 대한 신뢰를 높여준다지만, 이 버그가 수정된걸 눈치채고 역시 훌륭한 업체라고 생각하는 고객은 전 세계 2억명 고객중에 15명에 불과합니다. 어쩌면 이 15명 조차 못느낄 지도 모르죠..
15명에게 기업의 이미지가 매우 좋아졌지만, 소프트웨어의 신뢰도도 매우 높아졌지만, 15명의 충성도 높은 고객을 확보하였지만, 이 15명의 고객이, 프로그래머가 3일간 밤을 세우며 디버그 하는 바람에 출시가 일주일 늦어져 발생한 16억 3천만원의 매출을 올려주려면 정말 오래 걸릴겁니다.

예시가 적절치 못했을지도 모르겠습니다. 숫자도 제 멋대로 막 갖다 붙인겁니다. 하지만, “반드시 지금 고쳐야 하는 버그”와 “기회가 되면 고쳐야 하는 버그”는 구분할줄 알아야 합니다. 로또 1등을 19회 연속으로 맞아 앞으로 먹고 살 걱정 안하고 소프트웨어 공학의 발전과 자기 만족에만 인생을 쏟아부을 생각이 아니라면 말이죠..

버그대처와 관계되는 프로젝트 관리에 대해 이야기 하자면 끝도 없이 길어지겠지만 이미 스크롤의 압박은 충분히 만들었다고 생각되는군요^^; 다 써놓고 보니 어쩌면 비굴해 보일지도 모르는 글이지만 수정하지 않겠습니다. 비굴해지는 연습도 해봐야죠;;

이 글은 개발자로서의 저의 가치관에 대한 글입니다. 다음이 저희 회사라고 저와 입장이 같지는 않을수도 있습니다. 두달쯤 후엔 DNA에서 루미넌스를 볼수 없을지도 모른다는 말이죠..

ㅎㅎ 농담입니다.

Pi Lab 구준근님께서 드디어 건담(원래는 스카이 뭐뭐 .. 라하던데 저도 간단히 건담으로 부릅니다)을 조립완료 하셨습니다. Daum GMC 농구장과 제주의 맑은 하늘, 푸르른 바다를 배경으로 한컷!

각도상 잘 안보이지만 건담이 들고 있는 저 검의 길이가 어마어마합니다.