만화로 새로운 것 설명하기

최근 Mozilla Hacks Blog에 올라온 글이 화제가 되고 있는데, 그림으로 Mozilla WebRender를 잘 설명했다.

보통 소프트웨어 기술을 설명하면,  위와 같이 블록 다이어그램에 몇가지 화살표를 이용해서 개념적으로 설명하는데, 기반 기술을 이미 알고 있는 사람만 이해하 가능하다. 참고로 ChromeOS에 적용된 zero-copy texture upload를 설명하는 그림이다.

그래서 때로는 위와 같이 실물 사진으로 동작을 표현하기도 하는데, 이렇게 하면 좀 더 많은 사람들이 이해할 수 있다. 하지만, 이런 그림을 일반 개발자가 표현하는데는 한계가 있다. 직접 없는 사진을 만들어 낼 수 없기 때문이다. 게다가 이러한 개념적 표현은 어떤 표준도 없기 때문에 때로는 서로 다른 표기법으로 혼란을 줄 수 도 있다.

https://xkcd.com/934/

이 Mozilla blog글은 이러한 한계를 극복하고 만화 캐릭터로 브라우저 동작을 잘 표현했다. 물론 저자의 캐릭터와 스타일은 이미 있는 xkcd라는  캐릭터와 책을 참고한 듯 보인다.

구글에서 예전에 크롬 브라우저를 출시할 때, 브라우저 Multiple Process Model을 광고하려고 위와 같은 만화를 그린적이 있다. 지금 봐도 신선한 시도다. 뭔가 새로운 것을 만들 때는 이런 방식으로 사람들에게 설명하면 더욱 효과적일 듯!

만화 업데이트 - 오픈소스 개발자와 영어

한달만에 만화를 업데이트했다. 이번 주제는 영어에 관한 내용이다. 오픈소스를 시작하면서 겪은 영어와 관련된 내용을 짧게 만화로 그려봤다. 참고로, 이번 만화에는 WebKitGtk+ 팀 멤버들이 출현하고 있다. 기회에 되면 영어 버전을 만들어서 좀 보여주고 싶다. :-)

이 만화는 원래 kldp에 올린 그림에서 시작한다. 해당 그림도 만화에 한 컷을 차지하고 있다. 정균님도 잠시 출현한다. :-)

오픈소스에서 영어는 산 넘어 산인 것 같다. 다행스러운 것은 올린 patch수 만큼 영어가 는다는 사실이다.

다음 만화 부터는 자유소프트웨어와 오픈소스가 무엇인지 좀 더 기본적인 내용을 다루어볼까 한다. 아마 리차드 스톨만 옹께서도 출연할 날이 올 것 같다. 이미 리누스 토발즈, 에릭 레이몬드도 나왔는데, 본인은 안나왔다고 화내고 있을 것 같다. :P

만화로 나누는 오픈소스 이야기

드디어 "만화로 나누는 오픈소스 이야기"라는 블로그를 열었다. 정말 오랫동안 머리속에서만 생각한 것을 드디어 실행에 옮겼다. 뭔가를 새로 시작하는 것은 엄청난 노력과 시간이 드는 것 같다. 뭐든지 다 직접 해본 분(?)도 있지만, 진짜 만화를 그려보면 이것이 얼마나 큰 노동인지 알 수 있다. 정말 만화는 정당한 댓가를 주고 봐야한다.

이 만화를 그리는데, 큰 동기를 준 만화가 있다. 바로, "Jazz it Up!, 만화로 보는 재즈 역사 100년"다. 이 만화는 전문 만화가가 아닌 재즈 평론가가 그린 만화다. 이 분이 미술을 전공한 분 같지는 않지만, 재즈에 대한 열정으로 이 만화를 그린 것 같다. 그림은 약간 투박하지만, 오히려 만화 내용과 잘 어울린다.

이 만화 역시 오픈소스에 대한 이해를 높이고 개발자 문화를 공유하기 위해 재미로 그려보았다. 오픈소스가 재즈 만큼 대중적이는 않아서 일반인들까지 즐길 수 있을지는 잘 모르겠다. 재미로 그리는 만큼 별다른 제약없이 그려볼까 한다.

웹이후의 세계를 읽고...

웹 자유주의를 위해 다 같이 힘써요~

갈라파고스섬 탈출하기

[진정한 개발자]는 코드를 작성한다

진정한 개발자 또는 아키텍트라면 다이어그램이 아닌 코드로 말할 수 있어야 하고, 코드로 프로젝트를 리드할 수 있어야 한다. UML은 그 다음이다.

참고

"Java 프로그래머를 위한 UML"

[진정한개발자] KLDP 11주년 기념

KLDP 11주년을 맞이해서 그려보았습니다. 그림속에 숨어 있는 의미가 좀 있는데, 무엇이 있을까요?

이번 행사는 Barcamp형식으로 진행됩니다. 단, 참가는 40명, 발표는 5명으로 제한되어 있는데, 이미 자리가 다 찼네요. 열정만 있다면 그냥 참석해도 내 쫓지는 않으니 관심있는 많은 분들의 참여를 기다립니다~

[진정한 개발자] 오픈소스 개발자의 휴일 한 때..

제가 대단한 오픈소스 개발자는 아니지만, 집에서 코딩에 전념하기가 쉽지 않습니다. 우선 아내가 집에와서까지 코딩하는 것을 잘 이해하지 못하지요. 그렇다고 주중에 회사에 남아서 작업을 하기도 그렇고 집에 와서는 시간이 많지 않습니다.

그래도 짬내서 하는 작업들이 개인적으로는 무척이나 가치가 있답니다~

[진정한 개발자] SW 프로세스에 대한 서로 다른 생각...

KLDP에 올린 만화입니다.
SW를 개발하는 어느 조직이나 자신들만의 SW 프로세스를 갖고 있습니다. 교과서에 나오는 여러 SW 프로세스를 자신들의 환경에 맞추어 수정하고 템플릿 문서도 정리해 놓았겠지요. 하지만 실제로는 SW 프로세스에 대한 구성원 각자의 생각이 서로 다른 경우가 많습니다.

SW 프로세스는 프로젝트 관리자(PM) 머릿속에만 있고 직접 SW를 구현하는 개발자에게는 잘 안보이는 경우가 많고, PM 위에 있는 사람들은 아예 SW 프로세스에 대해 고민하지 않고 납기일에만 관심을 갖습니다.

SW 프로세스가 거창할 필요는 없겠지만 모두가 잘 알고 있고 실천하기 쉬워야 조직내 진정한 프로세스로 자리잡을수 있습니다. 조직 수준에 맞는 쉬운 SW 프로세스가 필요한 셈이지요.

[진정한 개발자] 새로산 맥 신용카드 결제 안된다

벼르고 별른 오픈웹에 관한 만화를 드디어 그려보았습니다.
이미 KLDP에 올렸고, 사람들이 조금이나마 오픈웹의 중요성을 인식했으면 좋겠습니다.

아울러 많은 사람들이 사용하는 웹사이트의 경우, 사양이 낮은 컴퓨터에 대한 배려도 필요합니다. 영화 예매 사이트인 CGV의 경우, 모든 메뉴를 플래시로 도배하여 펜티엄3 컴퓨터에서는 답답할 정도로 사용하기가 힘들더군요. 또한 많은 화면 구성을 플래시로 작성했음에도 불구하고 리눅스나 맥에서는 한글이 깨지거나 화면이 망가져버려 예매는 불구하고 무슨 영화를 하는지 알아보기도 힘들 정도입니다. 특히 인천/부천에서는 CGV가 거의 독점이기 때문에 윈도를 쓰지 않는다면 영화도 예매할 수 없는 상황입니다.



다행히도 정부에서 문제의 심각성을 인식하여 내년부터 전자정부 웹사이트에서 리눅스와 맥을 지원하기로 하였으니까, 앞으로 많은 개선이 이루지기를 기대해 봅니다.

여러분도 오픈웹을 위해서는 불편함을 감수하지 말고 적극적으로 항의하시기 바랍니다.

* 참고
http://www.openweb.or.kr/

me2day 100일 기념 축하~

한줄 블로그로 유명한 me2day가 서비스 개시 100일째를 맞이하였습니다.
축하드리며 앞으로 Twitter를 능가하는 최고의 서비스가 되길 기원합니다.

앞으로도 좋은 서비스 많이 만들어주세요~

미투데이 백일잔치 태그 보기

[진정한 개발자] CG 디자이너와 SW 개발자

우연히 cgland라는 사이트 가서 글을 보게되었습니다.
이들도 값싼 대우, 노동강도, 불투명한 미래 등 사회적 대우에 불만이 많은 것 같습니다. "Starcraft2가 나오는 동안 뭘했느냐"하면서 스스로 발전해서 부가가치를 키우자라는 자기반성의 글도 있네요. 물론 이땅에서 그것이 가능하겠느냐는 반론도 볼 수 있습니다...

비단 IT분야 뿐만 아니라 문화, 예술계도 이런 현상은 비슷해 보입니다.

우리나라 사회가 시장에 비해 인력 쏠림 현상이 많다 보니 노동가치에 대해 인식이 낮습니다. 이러다 보니 그만 그만한 기술자는 넘쳐나고 임금은 싸지고 기술이 성숙되기 전에 일을 그만두는 사람이 많아서 고급 기술자는 찾아보기 힘들지요. 게다가 제대로된 기술을 전수해 주어야 할 고급기술자는 해외로 유출되고 있습니다.
정말 좋아서 하지 않으면 그 분야에서 버티기 힘든 구조라 할 수 있습니다. 실력 만큼 대우를 받으면서 좋아하는 일을 늦은 나이까지 할 수 있는 때는 언제올까요? 우리만의 문제라면 열심히 노력이라도 해볼텐데...

[진정한 개발자] 최신형 PDA폰의 슬픔

http://kldp.org/node/78497

KLDP 블로그에 올렸던 그림입니다.

3년만에 핸드폰을 PDA폰으로 바꿨습니다. 기술적 발전으로 PDA폰이 전화기만큼 작아져버렸고 쓸만하다고 생각을 했습니다. 그러나 겉은 화려할지 몰라도 내부를 보면 아직 쓸만한 환경은 아닙니다.

PDA폰이면 당연히 Wi-Fi와 블루투스를 지원해야겠지만, KTF용만 Wi-Fi을 지원하고 블루투스는 KTF, SKT 모두 지원하지 않습니다. SKT는 VOIP, 블루투스때문에 음성통화가 줄어들지도 모른다는 두려움을 갖고 있나 봅니다.

KTF의 경우도 Wi-Fi를 지원하지만 지금도 음성통화만으로 2-3만원씩 요금이 나오는데, 여기에 데이터통신까지 사용하기가 겁이 납니다. 브라우징 몇 번 잘못하면 몇 십만원씩 요금이 나오는 것은 아닐까 괜히 의심이 들기도 합니다. 그래서 집에서 잠깐 무선랜 테스트 해보고는 실제 사용을 안하고 있습니다.

요즘은 내가 왜 PDA폰을 샀나 하는 후회가 들기도 합니다. RTOS가 아니라 그런지 UI반응도 느려서 SMS메시지 확인하려면 2-3 초가 소요됩니다. 게다가 윈도우UI와 핸드폰 UI의 부적절한 만남으로 인해 UI의 일관성도 떨어지고 사용하기 불편합니다.

하드웨어 기술은 분명 발전했습니다. 미끈한 디자인에 작은 크기에 불구하고 다양한 기능이 집합되어 있습니다. 하지만 이런 기술을 보다 편하기 사용하기 위해 인프라 환경과 SW기술은 여전히 멀어보입니다.

무선랜 같은 경우 굳이 PDA폰을 써야 할 만큼 킬러 애플리케이션을 찾기 힘들며 1-2시간 후 집에서 가서 쓰면 되지 하는 생각에 쓸 필요를 못 느낍니다. 만약 무선랜이 저렴한 비용으로 정약제라면 (2-3천원정도) 뭔가 활용성을 찾아볼 수 있을 것이고 나름대로 나만의 라이프스타일을 만들수 있을 것 같습니다. 하지만 지금은 꿈도 못꾸겠습니다.

기술의 발전만큼 세상이 바뀌기는 참 힘든가 봅니다.

듣는이와 말하는이

kldp blog에 올린 그림입니다.

지난 두 달동안 같은 보고서를 계속 업데이트 하면서 발표를 했습니다. 검토하시는 분들이 많고 제 생각도 있고 해서 많은 수정을 거쳤으며, 편집 방향도 자주 변경되었습니다. 그래도 변하지 않는 것이 있다면 상대방에게 궁금증이 들지 않도록 하고 한 눈에 내용이 파악되도록 작성해야 한다는 것입니다.

발표하는 사람은 자신의 지식을 전문용어를 사용해 가면서 장황하게 과시하려고 하는 반면, 듣는 사람은 바쁜 사람이기 때문에 발표 내용의 결과와 근거를 원하게 됩니다. 그래서 발표하다보면 이런 저런 핀잔을 많이 듣게 됩니다.

" 결론이 뭐야?"

"하고 싶은 이야기가 뭔데?"

"말하려는바가 뭐지?"

"무슨 근거를 가지고 이런 말을 하지?"

보고 받는 사람의 입장에서 한 번 더 생각하면 좋은 발표를 할 수 있을 것입니다.

윈도우를 어떻게 찾죠?

몇 년전에 그렸던 만화...

제일 처음 알았던 윈도API였죠

지금 보니 무척 썰렁하군요... ^^;

개발자의 참 즐거움

(KLDP blog에 올렸던 그림입니다) "그림하고는 영 다른 이야기가 됐군요.."

코딩만 하고 살수는 없을까요? 하지만 현실은 그렇지 못합니다. 개발자는 단순히 코딩만 하는 사람은 아니며, 경험이 늘어날 수록 년차가 늘수록 더 다른 능력을 갖추어야 합니다.

- 문서화, Communication Skill, 리더쉽

내 자신의 아이디어를 구체화하려면 남을 잘 설득해야 하고 글도 논리적으로 잘 써야 합니다.
주위를 보면 개발자 출신 영업맨, 기획자는 우대를 많이 받습니는다. 기술적 지식과 함께 깔끔한 마스크와 언변을 갖춘다면 영업으로 더 큰 능력을 발휘할 수 있고 글 잘 쓰고 기술을 보는 시각이 넓으면 좋은 기획자가 될 수 있습니다. 아니면 SE, SQA로 업무를 바꿀 수 있습니다.

개발자는 변해야 합니다. 아니 변하기 싫어도 변하게 되는 것 같습니다.  다만, 개발에서는 멀어질지는 몰라도 개발자와 떠나서는 일하고 싶지는 않습니다. 그들과 함께 기술을 논하고 고민하는 시간은 참 즐겁습니다.

개발자라는 연대감. 기술을 선도하고 세상을 바꿀 수 있다는 자신감. 그리고 계속 발전하는 세상. 힘들때 마다 이 길을 걷게 만드는 힘이 됩니다.

BarCamp Seoul 참석 후기

BarCamp란?

자발적인 참여를 기반으로 특별한 형식과 주제없이 서로 준비한 내용을 발표하여 토론하고 배우는 형식없는 컨퍼런스입니다.

우연히 지인의 블로그에 갔다가 BarCamp Seoul행사가 열린다는 소식을 접했고 선착순 50명에서 등록이 마감된다고 하기에 바로 참가 신청을 하게 되었습니다. 한국 모질라 운영자인이 channy님이 개최한 행사라 웹과 관련한 많은 회사 사람들이 참가 신청을 해서 손꼽아 행사 날을 기다렸습니다. 하지만 막상 날짜가 다가오니 회사일로 생각했던 발표 자료를 준비할 겨를이 거의 없었습니다. 참가를 취소할까 고민도 했지만 언제 다시 이 행사가 열릴지 불분명하기도 하고 간만에 지인들도 만날겸해서 다소 바쁜 일들을 뒤로 하고 참석을 했습니다.

IT업계 종사자들이 서로의 관심사와 정보를 공유하는 이런 모임을 참 좋아합니다. 게다가 업계를 대표하고 열정을 가진 분들을 만날 수 있으니 이 보다 좋은 모임이 어디있겠습니까?

주제와 상관없이 네개의 세션으로 나누어 행사가 진행되었습니다. 참석한 분들 모두에게 20분에 해당하는 발표시간이 주어졌습니다. 처음에는 벽을 치고 각 세션을 진행했으나 세션간이 이동이 힘들다는 이유로 완전히 벽을 걷어내고 진행했습니다. 이 역시 여러 사람이 한 공간에서 발표를 진행하다 보니 다시 소란스럽고 발표내용에 집중하기 힘들어 벽을 반만 지키로 했습니다. 이렇게 하니가 중간 중간 세션에 이동이 쉬워져서 듣고 싶은 발표를 놓치지 않고 들을 수 있어서 좋았습니다.

주제는 기술적인 부분에서 기획에 관련된 부분까지 다양했으며 현재 인터넷 활용 추세와 기술의 발전 방향을 미리 확인해 볼 수 있는 소중한 시간들였습니다. 저는 "프로그래머 야이기"라는 주제로 제 블로그와 KLDP블로그에 올렸던 삽화를 가지고 프로그래머와 연관한 이야기를 소개하였습니다. 개인적인 부분 부터 개발자면 누구나 공감할 만한 내용으로 꾸며보았습니다. 좀 더 기술적이고 도움이 될만한 주제로 발표하고 싶었으나 제가 회사에서 하는 업무를 소개하기에는 참석한 분들의 배경과 잘 어울지 않았고 그렇다고 웹을 주제로 하기에는 부족한 부분이 많기에 일반적인 내용으로 진행하였습니다. 다음에 기회가 되면 준비를 좀 더 많이해서 유익한 내용을 발표를 하고 싶네요.

든든한 스폰서 덕분에 최고의 점심 도시락을 즐길 수 있있고 이쁜 기념품도 받았습니다. 어디 돈내고 듣고만 오는 다른 컨러펀스 비하여 큰 부담없이 제가 직접 참여도 할 수 있어서 훨씬 좋았습니다.

앞으로 다양한 분야에서 좀 더 전문적인 BarCamp 행사가 열리기를 기대하며 제가 몸담고 있는 조직내에서도 이런 행사를 진행해도 좋을 것 같다는 생각이 들었습니다.

이번 행사를 준비하는 수고하신 자원봉사자 여러분과 바쁜 시간에도 불구하고 멋진 발표를 해주신 열정적인 참석자들 모두에게 감사를 드립니다.

제 발표자료는 여기 블로그 만화를 소개하였기 때문에 풀그리미 태그를 클릭하시면 내용을 실제 발표 보다 더 자세하게 볼 수 있습니다.

그 정도 보안으로 어디 인터넷 뱅킹을?

원본글 KLDP Blog
간만에 만화를 그려봤습니다. 초심으로 돌아가 펜선으로만 그림을 그려봤습니다. 윤곽선만 그려서 포토샵에서 색을 입히는 것도 즐겁긴 하지만 그림 그리는 실력은 느는 것 같지는 않습니다. 물론 색에 대한 감각은 좋아지지만 너무 툴에 의존하다보니 좀 지치기도 합니다. 게다가 시간도 더 많이 걸리기도 하지요..

아직 펜 터치가 좀 부족하지만 당분간은 마커없이 펜으로만 그림을 그려보려고 합니다..

밤샘 근무의 슬픔

http://kldp.org/node/71269

KLDP blog에 올렸던 만화입니다...

도움이 안되는 개발자

보통 여러 사람이 팀을 이루어 S/W개발을 진행합니다. 각자의 개발 능력도 중요하지만 팀웍도 중요합니다. 그런데 몇몇 구성원은 팀의 생산성에 도움이 안되는 경우가 있습니다. 개발 능력이나 기본 지식이 약할 수도 있겠지만 주먹구구식으로 S/W개발을 진행했던 습관이 문제입니다.

이들은 보통 개발자의 10%정도의 비율을 차지하는데[1], 초급 개발자 뿐만 아니라 오랜 경험을 가진 프로 개발자도 이런 타입에 속할 수 있습니다.

그들의 문제는 다음과 같습니다.

1. 코딩 스탠다드나 디자인 표준을 지키지 않습니다.
2. 다른 사람이 작업한 결과와 통합하기전에 버그를 다 수정하지 않습니다.
3. 자신의 일에 관해 예측을 잘 못합니다. 왜냐하면 사실 언제 끝날지 잘 모르기 때문이죠.[1]

S/W는 여러 연관성 있는 부분들이 모여서 하나의 시스템을 이루고 누구에게 자신의 기능을 제공하게 됩니다. 그 중 일부분에 문제가 생긴다면 S/W는 총체적인 문제를 일으킬 수도 있습니다. 그렇기 때문에 작은 문제로 프로젝트는 지연될 수 있으면, 완료되었다고 할지라도 품질에 문제가 있기도 합니다. 하지만 무엇보다도 팀웍을 깨뜨리고 향후 프로젝트에도 나쁜 영향을 끼칩니다.

초급 개발자이고 똑똑하다면 우리는 이것을 시행착오라고 생각할 수 있겠지만 어느 정도 경험을 쌓은 프로 개발자라면 그 문제는 심각합니다. 그래서 개발자를 뽑을 때 신중해야 무척 합니다. 관리자는 같이 일하는 개발자에게도 의견을 구하고 이력서만 평가하는 것이 아니라 기술면접으로 기본 기술 역량을 파악해야 합니다.

그래서 어떤 업체에서 개발자를 뽑을 때 간단한 시험을 본다고 합니다. 전산학의 일반적인 내용들인데, 자료구조나 데이터베이스, 운영체제와 같은 과목에서 기본적인 것들을 시험 문제로 낸다고 합니다.

다음 문제는 Joel on Software[2]라는 책에 발췌한 시험 문제입니다.

1. Reverse a sting in place
2. Reverse a linked list
3. Count all the bits that are on in a byte
4. Binary Search
5. Find the longest run in a string
6. atoi
7. itoa(great, because they have to use a stack or strrev)

종이에 바로 코딩을 해야하며 10줄 이내로 간단하게 구현될 수 있어야 합니다.

Joel on Software를 보면 이러한 시험은 단순히 코딩 능력 뿐만 아니라 코딩전에 얼마나 계획을 세우는지 확인도 가능하며 변수 이름은 어떻게 짓는지 등 많은 부분을 평가할 수 있다고 합니다.

여러분은 어떤 개발자인가요?

참고문헌
[1] Steve McConnell, Professional Software Development, 2004, p137-138
[2] Joel Spolsky, Joel on Software, 2004, p162