박피디의 게임 아키텍트 블로그

개콘의 봉숭아학당에는 개인 취향을 좀 타겠지만 재미없는 멤버들이 꽤 섞여 있습니다.
요즘 남미 말투 흉내내는 송중근씨이나, 한참 신체 개그를 시도하던 장도연씨 등등...

그런데, 다른 개그 기다리면서 이 분들 개그를 생각없이 보다 있다보면
어느새 그 분들 유행어를 따라하고 있는 제 자신을 발견하게 됩니다.

그리고 왕비호나 박지선 같이 스타를 만들어 낼 수 있었던 것도
봉숭아 학당 덕분에 아예 새로운 코너를 신설하는 것보다 적은 부담으로 새로운 개그를 시도해 볼 수 있었기 때문일 겁니다.

그럼 게임 포탈...
한게임 매출이 2008년 4분기에만 963억원이라고 합니다.
(그중 평균 90% 가 보드게임에서 나온다고)
http://www.gamtoon.com/new/gs/focus/view.gam?num=293&sele=FOCUS

엔씨소프트 같은 경우, 아이온과 리니지1, 2 에서는 큰 돈을 벌고 있지만 다른 부문에서는 계속 고전 중이라고 합니다.
그래서 보드게임 하시는 분들께 한게임이랑 플레이엔씨랑 차이가 뭐냐고 물어보면
게임성이 어쩌고가 아니라 "한게임에 사람이 훨씬 많아요" 라고 합니다.

한게임 포탈이 꼭 좋아서라기 보다 보드게임쪽에서 먼저 선점한 효과도 크겠지만,
아래 스샷을 보면 알 수 있듯이 회사 주력 게임이 다른 것도 큰 원인이라고 생각합니다.
뭐, 엔씨는 리니지1, 리니지2, 아이온 쓰리펀치로 다른 회사에서는 없는 대규모 게임 개발 능력을 보여줬지만 말이죠. :)

아무튼 좀 성급하게 결론을 내리자면

게임 포탈이 중심을 잘 잡아서, 많은 사람들의 취향을 만족시켜 줄 수 있는 다양한 게임이 포진해 있다면
회사 내에서 새로 개발하는 게임도 큰 부담없이 오픈해서 게임 플레이어들의 반응을 알 수 있고,
다른 게임들도 같이 상승효과를 받아 모든 게임이 잘 될 수 있을 거라고 생각됩니다.

회사 입장에서는 포탈이 끓는점에 오르기까지는 표가 나지 않지만, 언젠가 끊는점 이상 올라가면 부글부글 끓을거니까
너무 성급하게 생각하지 말고, 그 때가 올 때까지 (비용 조절은 필요하겠지만) 너무 쉽게 게임을 접지 말고,
계속 새로운 것을 시도할 수 있는 분위기를 만들어주자
입니다.
(쓰고나니 뭐 모두가 아는 사실을 왜 이리 길게 썼냐 싶네요.)

부록으로 가요계의 봉숭아학당인, 소녀시대와 여성시대의 뮤직비디오를 링크걸어 둡니다.

저작권 문제 생기면 바로 내립니다. 아휴, 저작권 어렵다
PS.1 :수영은 이쁜데 이번 메이크업은 좀 이상하네. 태연, 윤아, 티파니는 원래 귀여웠고, 제시카는 2레벨 정도 레벨업 된 느낌이고, 효연도 힘내자.
PS.2 : 여성시대는 씨야의 김연지,이보람, 다비치의 강민경, 이해리 티아라의 지연 이렇게 5명이 뭉친 그룹. 왜 이리 모르는 사람이 많은지. 여성시대라고 하면 장난치는 줄 안다니까

출처 : http://ongam.tistory.com/4131
 

스타크래프트 2 LAN 지원 안 한다고...
흠.. 그렇군요.
그렇다면 월정액을 받는다는 걸까요?

Will StarCraft II be available on consoles, or over LAN?

We got quite different answers about local area networking (LAN), where both Dustin or Sigaty said they were still discussing it, however, Pardo knew immediately: "we don't have any plans to support LAN," he said and clarified "we will not support it." The only multiplayer available will be on Battle.net.

Regarding consoles, it looks dark for anyone wanting to try out the RTS on anything but PC.  We asked how large chance it is to see StarCraft II on consoles and Pardo replied simply: "Zero percent."

Blizzard tries to approach each game, and see what platform it should be on. "In our opinion we just don't feel like we will deliver the type of RTS game that we've been creating [on consoles]."

"We have tried in the past, we actually tried the original StarCraft on Nintendo 64. It works, it's playable, it's just such a different playability gameplay experience than on PC and we really don't want to have it be that different."

대충 살아가는 게임개발자님 블로그 와 안티러브님 블로그 에서 트랙백 합니다.
댓글로 대충 쓰긴 했는데,
부족하기도 하고 겸사겸사 생각나는 것도 있어서 정리해서 블로그에 써 봅니다.

제가 알던 팀에도 개발자가 꽤 많았는데,
팀원 개개인의 능력만 놓고보면 다들 진짜 괜찮은 분들이었습니다.
문제는 성실하시기도 했지만, 야심도 많은 분들이었달까... 해서,
예를 들자면, 메인 아트가 나왔을 때 자신의 의견이 반영되지 않았다던가
기획이나 프로그래밍 쪽에도 자신의 생각이나 기법이 발탁되지 못하면
이 때문에 상처를 입고 팀을 옮긴다던가,
다른 팀원들끼리 모여서 파워게임을 하는 바람에
그 분이 하던 작업이 다 취소되고 새로 오신 분은 또 처음부터 자신만의 작업을 만들려고 하고...
이런 일이 반복되던 적이 있었습니다.

지금 생각해보면 그렇게 된 가장 큰 원인은
팀의 우두머리가 팀의 방향을 정확하게 제시하지 못하고
서로의 협력을 이끌어내지 못했기 때문이지 않았나 싶습니다.
하지만 많은 사람이 모여서 하는 프로젝트가 잘 굴러갈려면,
조직이 '머리'들만 모여있는 역삼각형 구조 대신
자신의 일에 대한 관심과 일에 대해 성실한 분들이 뒤에서 작업을 받쳐 주는
정삼각형 구조여야 하지 않을까 라는 생각이 들었습니다.

아마 이 분도 자기 게임의 장르는 잘 모르시더라도, 아트쪽에 대한 능력과 열정은 있으시겠지요.
혹은, 게임에 대한 관심은 없어도 건축이나 회화, 움직임, 무기, 카메라 워크 같은
다른 분야에 대한 관심이라도 많으실 수 있구요.
그리고 윤정님 말씀대로 마이크를 갑자기 들이대면 말이 잘 안 나오기도 합니다.
저도 '이소라의 프로포즈'때 이소라씨가 당시에 머리 묶고 있던 저에게 '락 하세요?' 물어 봤는데
아무 말도 안 나오더군요 ㅎㅎ 결국 편집되고 :)

약간 다른 얘기들을 좀 이것저것 하자면
게임에 대한 열정을 많은데, 너무 게임에 대한 열정만 많아서
하루 종일 게임만 하고, 회사에 와서도 타사 게임을 계속 하면서 자기 개발하지 않는 개발자보다는
게임은 잘 모르더라도 팀 내에서 자신이 할 수 있는 일을 꾸준히 해서
팀에 보탬이 되는 개발자가 더 필요하지 않을까 하는 생각도 해 봅니다.

또 팀에서 버그가 생겨서 디버깅 할 때도
꼭 디버깅을 잘 하는 사람만 버그를 찾는게 아니라,
각각의 상황에 따라 DB 를 잘 하는 사람이 버그를 찾기도 하고
웹을 해 봤던 사람이나, 스크립트 언어를 해 봤던 사람,
또는 타사 게임이나 우리 게임에서 비슷한 컨텐츠를 해 봤던 사람들이
같이 의논할 때 버그를 금방 잡을 수 있더군요.
닥터 하우스도 자기랑 같은 생각을 하는 사람은 팀원으로 안 뽑죠.
(이 부분은 나중에 다시 얘기해 보도록 하겠습니다.)

정리하자면,
기본적으로는 자신이 하고 있는 프로젝트에 열정이 있는 개발자가 꼭 필요합니다.
하지만 때에 따라서는 그런 열정보다 실력이나 감각이 있는 개발자가 팀에 더 필요할 수도 있고
여러 다양한 사람들이 모여 있어야 조직의 체질이 건강할 수 있지 않을까 라고 생각합니다.

PS : 공각기동대에서 가장 좋아하는 캐릭터가 토그사라는 ㅎㅎ

야구 얘기 써 놓으면 롯데야구덕후같아 보일까봐 조심하고 있었는데 ㅋㅋ
오래간만에 부산 내려가서, 부모님이랑 아내랑 해서 부산 사직 구장을 갔었다.
그러니까 아마 고등학교 졸업 이후로 처음 간 사직인 거 같다.
나름 심혈을 기울여 산 P석은 입구 통로 쪽이라
경기 내내 왔다갔다 하는 사람들, 먹을 거 파는 사람들,
'맛있어. 진짜야' 하면서 캐밥 파는 터키 사람 처럼 보이는 외국인,
맥주통 들고 다니면서 맥주 파는 남자들(왜 도쿄돔에서는 여자 아이들이 파는데!!)
때문에 계속 시야를 가려가면서 열심히 야구를 응원했다.
(절대 통로 라인에는 표 사지 말자!! 한 4 번째 줄 이상이 좋은 듯)

장원준 계속 볼 넷 주면서도 기아 어리버리한 주루 플레이 유도 해서 잘 막아냈고
올해 롯데의 굴러들어온 (잘 생긴) 호박 홍성흔 홈런도 보고
가르시아 공 놓쳐주는 기아 팬 서비스에
강민호 역전 홈런에 :)
강민호 8회에 교체될 때는 쟤까지 순번이 갈까 싶었는데, 역전 끝내기 3점 홈런이 왠 말이니...
아주 그냥 뽕을 뽑은 경기였다.
더해서 임작가 언제 이렇게 훌륭하게 성장한거지!!! 역시 야구는 성적으로 얘기하는 거다.
작년에 그렇게 욕하던 사람들도 임작가 인터뷰 할때 박수치고 다들 최고라고 소리질러 주고 ㅎㅎ

9회쯤 되자 미리 나갈려고 입구쪽에 나가 있던 사람들, 분위기가 이상하니까 다시 들어와서 응원하고 ㅋㅋ

개인적으로는 갈매기 모자를 못 산게 아쉽고
(이건 경기장 안에 있는 자이언트 샵에서 팔지 않는다. 경기장 밖 어느 업체에서 판다고)
대신 빨간 쓰레기봉투 받아왔으니 다음에 잠실 경기장 갈때 꼭 챙겨 가야겠다.
여튼 오래 기억될 명경기였다. 끝~

(사진 출처)

..

원본

특정 언어에서 좋아하는 언어 특징이 있나?

요즘 분위기는 주석 X, 말줄임 X

• 주석이 필요한가?
  
  • 오픈 소스의 주석을 다 지웠더니 코드를 보기가 쉬워졌다(Quake)
    
• 변수명, 함수명은 어떻게 정하는 게 좋은가?
  
• cnt 는 count 로 쓰자. vs 코드가 짧으면 이해하기 쉽다
  
• 생명주기가 짧은 변수는 짧게, 전역에서 쓸 수 있는 메서드나 변수는 길게
  

AOP 적용의 어려움

천재 재봉사 레빈같은 팀원과 같이 일하는 어려움. 어떻게 해야할까?

상황에 맞게 여러 프로그램 언어를 써 본 경험은?

프로젝트에서 쓰고 있는 도구들을 얘기해 보자

• check style, pc-lint, araxis merge, incredibuild, lua
  

오토들의 공격

• 무작위 테스트의 필요성
  
• IBM (concurrent test) 이나 ETRI (비너스) 에서 나온 테스트 도구
  

UX. 베낀 UI 인가, 친숙한 UI 인가?

• 가장 흥행에 성공한 게임의 UI 가 과연 UI 의 최종 형태인가? 너무 고민을 안 하는게 아닐까?
  

코드가 시적으로 보일려면

문서화를 잘 하는 방법, 기술 설계 문서를 잘 쓰는 방법은?

• 클래스 이름 같은 코드 레벨까지 내려오지 않게 써야 한다
  
• 오히려 자주 갱신하기 쉽게 만드는 게 더 중요하지 않을까?
  
• Fitness 를 발전시킨 NTAF 이란게 있다 (http://dev.naver.com/projects/ntaf/)
  

블로그 등 논쟁거리에 앞장서 보거나 덩달아 참여해 본 적이 있는가?

템플릿을 많이 쓰는 프로그래머 vs 쉬운 C++ 을 쓰는 프로그래머

• 툴이 이해하는 방식으로 일 해야 하는가?
  
  • 툴이 분석하지 못하기 때문에 템플릿 사용을 막기도 함
    

포팅, 생각보다 어려운 일이 아니다

• Windows 에서 리눅스로 게임 개발을 포팅한 경험
  
  • 심지어 iocp 보다 epoll 을 썼음에도 불구하고 성능은 더 잘 나왔다
    
• 웹 개발에서 php -> java 로 넘어간 경험
  
• 기본기가 잘 되어 있으면, 도구에 종속되지 않을 수 있다.
  

수명이 다 된 코드는 언제 삭제하는가?

원본

== 7장 프로그래밍 작업의 다양성 ==
프로와 아마추어의 차이
 *워드 커닝햄(위키위키 고안자, OOP, 디자인패턴, XP의 선구자)의 인터뷰
 "프로페셔널은 동료를 관찰하고 그들로부터 테크닉을 흡수할 수 있는 것이 매우 중요합니다.
 아마추어는 "저는 제 방식으로만 일합니다"라고 말할 수 있습니다. 프로페셔널은
 "한동안 당신의 방식으로 해보고 어떻게 되는지 봅시다"라고 말할 수 있어야 합니다."

 
 항상 훌륭한 것으로부터 배울것이 있는게 아니라, 잘못된 것에도 배우는 것이 있다. 좀더 넓게 크게 생각해서 지켜보는 마음가짐을 가져야 한다. [http://www.ologist.co.kr/399 ologist`s blog 인용]

 
 *생각해 볼 문제
  [http://www.gpgstudy.com/forum/viewtopic.php?p=117923 도구에의존하는 프로그래머는 나쁜것일까요?]

 
== 8장 개인의 성격 ==
 *미치광이 파괴자
 프로그래밍뿐이 아니라, 모든 것에서 통용되는 진리
 가장 무서운 적은 "어설프게 알고 있는 것"과 "자만"이다

 
 *[http://user.chol.com/~ilovehrl/mbti/mbti1.html MBTI 테스트]

 
 *데우스 엑스 마키나
 고대 그리스와 로마 연극에서 줄거리를 풀어나가고 해결하기 위해 신이 때맞춰 나타나는 것.
 신이 기중기(그리스어로 '메카네')를 이용하여 하늘에서 나타났기 때문에 이 연극 장치를
 '데우스 엑스 마키나'라고 부르게 되었다. 고대 이래로 예기치 않게 나타난 구조자나
 혼란, 혹은 질서를 가져오는 뜻밖의 사건(예를 들면 미국 서부영화에서 결정적 순간에
 기병대가 나타나 비극을 막는 것 따위)을 일컬을 때도 이 용어가 사용되어왔다. 이
 연극장치는 BC 4세기부터 사용되었다. 소포클레스의 〈필록테테스 Philoctetes〉
 연극에서도 여러 번 신이 등장하여 위기를 해결한다.

== 9장 지능 또는 문제해결력 ==
 * 심리적 자세와 거리[http://gpgstudy.com/forum/viewtopic.php?t=23035&postdays=0&postorder=asc&start=0 한참을 고생한 버그]
 {{{#!gcode
for( int i = 0; i < 10; ++i)                                                                                              ; <- 요거
{
      처리..
}
}}}

== 10장 동기 부여와 훈련, 경험 ==

 *동기부여
 문제는 푸는 것보다 발견하는 것이 더 중요하다.
 '나는 무엇을 해결하고 있는가?'
 '지금 이건 누구의 문제인가?'
 '이게 진짜 해결하고 싶은 문제인가?'

== 프로그래밍 직업의 다양성, 개인의 성격 ==
 * 같이 일하기 싫은 프로그래머의 성격? 같이 일해야 한다면 어떻게 해야할까?
  * 책임감 없는 프로그래머
  * 뭔가 다른 동기(짝사랑을 맺어준다던가) 로 우연찮게 친해질 수도 있다
  * 개인 사정으로 인한 성격 변화에 대한 대처
   * 부모님 병 수발 때문에 잠이 부족해져서 짜증이 많아진 직원
    * 개인사 때문에 회사 업무에 지장이 생기면 프로의 자세가 아니다(윌 스미스의 '행복을 찾아서')
  * 개발자끼리 알력이 생겼을 때 중재해 줄 수 있는 대모같은 사람이 팀에 있으면 좋겠다
  * 문제를 자기 맘대로 재정의해서 풀어버리는 개발자
  * 코딩 랩퍼(코딩하면서 중얼중얼 랩으로 불만을 얘기하는 개발자), 우울라이저

 
 * 만화 '바텐더' 에 나오는 얘기 - 스탠다드를 지키면 실수를 막을 수 있다
  * 여친과 헤어진 후 비탄속에서 업데이트 하다가 DB 를 날려먹은 사례가 2-3명이나 있다!

 
 * 버그를 고치는 자세
  * 일단 고친 후 결과를 지켜보자 vs 원인을 제대로 알 때까지 그대로 두자
  * 방어 코드를 넣어서 제품을 보낸 적도 있다
 * 디버깅 - 대박 버그를 잡았을 때의 희열(아무도 안 알아주더라도)
 * 프로그래밍 하다보면 성격이 변하는 듯
  * 다른 직업도 그에 맞게 성격이 바뀌는 것 같다

 
 * 일하는 도중 휴식삼아 하는 일, 스트레스를 풀기 위해 하는 일은?
  * 일주일에 하루 정도 밤새 게임하는 등의 일탈, 잠이 최고, 운동

 
 * 도메인을 잘 아는 프로그래머 vs 공부 안 하는 프로그래머
  * 시게루도 게임 안 한다더라 -> 게임을 안 하면 대화가 안 된다 -> 너무 게임만 하면 베끼기만 한다, 게임 공부한다면서 실제로는 놀기만 하는 개발자가 많다 -> 게임을 싫어하면서 게임 개발하는 사람도 있다

 
 * 다른 부서(예 : QA, CS) 의 이해를 위해 job switch 해 본 적 있나?
  * 신입을 몇 개월 QA 에 보냈는데, 나중에 물어보니 신입들은 하나도 도움 안 되더라고 하더라. 1,2년 개발시킨 후에 보냈어야 하지 않았을까?
  * CS 에서 하루 정도 앉아서 고객 상담을 들어보니, 고객이 내가 생각한 것과는 참 다르구나 는 걸 알게 되었다

 
 * 개발 마인드를 전파할 수 있는 방법은? 불가능한가?

 
 * 신입에게 어떤 업무를 줘야할까?
  * 자사 게임을 한 달간 시킨다
  * 한 달간 코드 리딩만 시킨다(절대 코드를 수정할 수는 없음). 다른 사람의 코드를 읽는 능력이 생기더라
  * 주석이 없는 함수에 주석을 다 달아라고 시킨다
  * UML 이나 다른 문서화를 시킨 후, 발표를 시킨다
  * 그냥 놔 둔후, 나중에 뭐 했는지 물어본다(알아서 일을 찾아서 하는 사람이 되자)
  * 3개월간 알고리즘 문제를 풀게 한 후, drop 시키기도 한다

 
 * 팀에서 사람마다 다른 재능을 효율적으로 활용한 경험이 있는가?
  * 디버깅 잘 하는 사람, 설계 잘 하는 사람, 요구사항 분석 잘 하는 사람
  * 하지만 급한 버그가 났을 때는, 사람마다 다양한 시각에서 버그를 볼 수 있기 때문에 팀원 전체가 버그를 잡는게 중요하다
  * 즉, 너무 성향별로 작업을 나누면 오히려 안 좋을 수 있다
  * 그리고 편애로 보일 수 있기 때문에, 팀장 입장에서는 그냥 '스탠다드'로 하는 게 낫다

 
 * (면접을 볼 때) 이 사람이 정말 프로그래밍을 사랑하는지 알 수 있는 질문은?
  * 자기 개발 여부(공부, 책, 스터디 등), 혹은 오픈소스 참여 등을 얘기하는가?
   * 이런 건 거짓말해도 조금만 캐 내어보면 다 들통난다.
  * 기획서를 주고 어떻게 구현할지 설명해 보라고 한다

 
 * 문제 해결 : 컴퓨터는 거짓말을 하지 않는다
  * 뭔가 잘못 돌아간다면 99.999% 는 사람이 잘 못 한거다
  * 사실 0.0001 % 는 기계 잘못인 경우도 있다.

 
 * 싫어하는 작업을 맡았을 때 재미있게 일할 수 있는 방법은?
  * 반복 작업을 자동화하거나, 문서화해 보자.
  * 이번 기회에 이 작업으로 내가 뭘 할 수 있을지를 고민해 보자
 
 
 * 일은 주어진 시간을 다 채울때까지 늘어난다 - 파킨슨
  * 느슨하게 일정잡은 프로그래머
  * 팀장이 일을 파악하지 못하면 이런 일을 막을 수 없다

 
 * 비자아적 프로그래밍 vs 창조적 프로그래밍(software creativity 2.0)
  * 서로 어울리는 작업이 있지 않을까?

 
 * 목표로 했던 기능을 일정보다 빨리 구현한 상태
  * 다른 일을 더 할 것인가? 이번 일을 더 심화할 것인가?
  * 이건 기획자나 PD 와 상의해야 할 듯
  * 상점을 3 번째 구현중인데, prototype 때 너무 많은 걸 보여줬더니 힘들어졌다
   * 구현하는 도중에 계속 feedback 을 주고 받자

  
 * 피드백을 높이는 방법
  * msn 대신 팀별 IRC 를 열어, 모든 채팅은 전체 채팅으로 만들어 둔다
   * 누가 뭐 하는지 전부 알 수 있게 된다
  * 파트원끼리는 항상 전체 메일
  * 아틀란티카 온라인 팀처럼, 내가 만든 작업물은 전부 인트라넷에 올리고, 다른 팀원은 항상 칭찬만 리플에 달아주기

 
== 동기부여와 훈련 경험, 지능 또는 문제 해결력 ==
 * 동기부여 : 인센티브를 주겠다 vs 이 문제는 당신만 해결가능하다
  * 인센티브를 준다는 건 경영자 입장에서 해 줄 수 있는 최고의 보상
  * 그 약속을 제대로 지키지 않기 때문에 인센티브로 동기부여를 못 하는거지, 개발자가 인센티브를 싫어하는 건 아니다

 
 * 기술을 습득하는 나만의 방법은?
  * 책에 나와있는 코드를 다 일일이 타이핑 해 본다
  * 공책에 손으로 코딩해 본다(예전 포트란때는 그렇게 했다)
  * 쉬운 책(혹은 만화책) 부터 같은 주제의 책을 여러권 동시에 산다

 
 * 다른 도메인의 지식 습득(예 : 미술) 도 큰 도움이 되더라

10회 난상토론회 정리

() 는 제 생각입니다.

1부 : 블로그

발제 :
* 2007 년 이후로 블로그의 성장률이 0% 다. 왜일까?
* 블로그를 통한 수입 모델에는 뭐가 있을까?

토론 :
* 블로그를 운영하다가 비용이 너무 많이 들어서 8개월만에 그만 두었다
* 회사에 관련된 내용을 썼다가, 그 내용이 네이버 -> 전자신문까지 가는 바람에 HR 으로부터 경고전화를 받았다
* 블로그로 돈 벌 수 있는 분야는 IT 가 아니다
 * 요리, 오디오, 사진기, 일부 정치 블로그
 * 특히 요리. 문성실씨, 나물이네(1권이 57쇄까지 찍었더라).
* 블로그로 돈을 벌어야 하는가?
 * 돈(혹은 이득) 이 안 되면 2-3 년을 지속 못하더라
* 컨텐츠는 좋은데 귀찮아서 블로깅 안 하는 친구들이 있다. 아깝다
* 우리 나라는 인터넷 카페 때문에 SN 이 잘 안 된다고 한다
* 트위터(micro blogging) 에서도 스폰서를 받아서 광고하는 경우가 있다
 * 나 XXX 먹어봤다~ 맛있더라 같이...
 * 도덕성이 의심되는 순간 블로거들이 떠나지 않나? vs 블로그 보는 사람들이 알아서 걸러서 본다.
* 해외에서는 블로그를 잘 만들어 양도하는 경우가 있다(최고 100억원)
 * (무슨 캐릭터 육성도 아니고 -.-;;)
* 블로그 수익 내기에는 한국어 인구가 부족하다
* 개인 블로그도 언론 중재가 필요하지 않을까?

2부 : 협업

토론:

* 회사, 조직 내에서의 협업
 * 구글 doc 를 쓰고 있다
  * 구글에서 구글 app 의 자료를 수집한다는 소문이 있다. 회사의 기밀 서류는 구글 app 안 쓰는 게 좋을거다
  * 스프링노트는 왜 안 쓰나?
   * 자료가 날아갈 지 모른다는 불안함이 있다
   * 오픈마루(NCsoft) 의 신뢰도는 구글보다는 떨어진다

* 협업용 app 의 3 종류
 * 엄무 프로세스 : ERP(Enterprise resource planning)
 * 생산성 : CAD(Computer Aided Design), PLM(Product Lifecycle Management)
  * PLM 같은 경우, (저는 잘 모르겠습니다만) 대한항공이나 보잉에서 항공기 개발할 때 전세계 10개국 이상에서 동시에 개발할 수 있도록 도와주는 툴이 있다고 하는군요. 
 * 창의력 : TRIZ
  * (TRIZ 와 더불어 통섭, 학제간 연구도 중요하다)

* 기업에서의 협업 app 는 대부분 실패
 * 그냥 서로 얼굴 보고 얘기하는 게 최고다
  * 작은 조직의 큰 장점
 * 그나마 성공한 건 KB(지식 베이스) : MS 는 80 년대부터 KB 구축해, CS 등에서 활용
 * 인적 network 를 DB 화 하려는 노력
  * 국내 대기업은 이미 그렇게 하고 있다
   * 만날 수 있는 방법, 친한 사람, 좋아하는 것 등등이 기재
  * 프리랜서가 많은 기업에서는 인적 네트워크가 자신의 자산이라고 생각해서 잘 open 하지 않는다
 * 협업은 신뢰 없이는 안 된다
  * 오픈소스 개발, 위키피디아라는 특이한 형태도 있다
  * 오마이뉴스도 아직 꽤 괜찮은 편이다

* 대학원 연구소에서의 협업은 CVS 써서 코드 버전 관리하는 정도가 전부다

* 그림 그리는 협업 문화
 * 누가 그리면 받아서 그리기, 동시에 그리기

* 게임에서의 협업(혈맹, 공성전, 파티 사냥)

* 네이버의 오픈 캐스트도 언론사의 협업이라고 볼 수 있지 않을까?
 * 언론사끼리의 경쟁이다
  * 그래서 서로 좀 더 자극적인 기사를 내 보내고 있다
  * 네이버 내부 직원들도 이런 점에 불만이 많고, 언론사에 경고 공문을 보내고 있다
 * 오픈 캐스트 덕분에 오히려 네이버의 언론 장악력이 커진 느낌이다. (진짜?)
  * 데스크에서 아무리 뭐라고 해도 말 안 듣던 광고팀이, 네이버에서 경고 들어가니까 말 듣더라

* 웹에서의 협력 사례는 뭐가 있을까?
 * 네이버의 지식인
 * 트위터나 미투데이
 * 블로깅 자체가 집단 지성으로서의 협업이 아닐까?
 * P&G 같은 회사에서 open enovation(외부 소비자가 참여하는 혁신) 을 하고 있다고 한다

다른 분들 후기
http://szie.tistory.com/396

소프트웨어 크리에이티비티 2.0 을 읽다가
작년부터 계속 고민해왔던 생각을 떠올라 써 봅니다.

작년 KGC 에서 내가 발표한 내용 중, UnitTest 도입 효과에 대해 설명한 것이 있다.
대략 다음과 같은 그림이었는데...


이 자료는 다음과 같은 방식으로 수집했다.
1. 버그 추적 도구에서 데이터를 XML 로 export 한 후
2. C# 의 XML 파서를 사용해서 디버깅 생산성 측정 프로그램을 만든 후 데이터를 분석

통계는 다음 규칙을 만들었다.
1. 버그가 처음 보고된 시간으로부터 버그를 수정한 시간까지의 평균
1-1. 우선순위가 높은 것부터 확인. 너무 우선순위가 낮은 버그는 통계에서 무시
1-2. 사례보고 같이 몇 년동안 해결되지 못한 버그도 무시
2. 버그가 발생한 횟수를 개발 분기별로 분류

'500% 생산성 증가'란 말에는 약간 과장이 있지만, (특히 레거시 코드에서는) 200% ~ 300% 이상 생산성이 증가한다고 생각한다. 이런 자료 덕분에 막연히 UnitTest 를 도입하면 생산성이 향상되고, 버그가 줄어든다더라가 아니라, 실제로 해 보니 이렇게 생산성이 향상되고 버그가 줄었다고 얘기할 수 있는 근거를 얻게 되었다.

문제는 이제부터인데,
막상 이런 식으로 디버깅 생산성 측정 규칙을 정했더니, 그 규칙에 내가 끌려다니게 되었다.
예를 들자면, 버그 추적에 아직 올라와 있지 않은 긴급한 서버 Crash 가 날 경우, 당연히 Crash 를 다른 무엇보다도 먼저 수정해야 한다. 하지만 Crash 는 버그 추적 도구 대신 개발팀에 직접 이메일로 전달되는 '시급한' 문제다보니, 이걸 고친다고 하루, 이틀 고생해 봐야, 위에서 정한 디버깅 생산성 통계만 놓고 보면 내가 아무 것도 안 한 것이 된다.
마찬가지로, 다른 사람이 버그로 고생하고 있을 때에도, '내꺼부터 빨리 수정해야지, 다른 사람 도와줘봐야 측정도 안 되고...'라는 어이없는 생각에서 벗어날 수가 없게 되었다.
(디버깅 생산성 측정 프로그램은 순전히 UnitTest 를 적용했을 때의 효과를 확인하기 위해서만 썼지, 팀원들의 생산성을 측정하는 용도 등으로는 쓰지 않았는데도 불구하고 말이다)
Crash 수정 횟수라던가 다른 사람을 도와준 횟수도 같이 기록하면 되지 않겠냐고 할 수 있겠지만, 이것 역시 누가 얼마나 공헌했는지를 알기도 어렵고, 이렇게 모든 걸 다 기록하기 시작하면, 어느새 작업량보다 측정을 위한 일이 더 많아지게 된다.

그래서...? 당장 디버깅 생산성 측정 프로그램을 폐기해 버렸다. ㅎㅎ
이렇게 하고 나니, 마음이 편안해지고, 다시 팀에서 가장 중요한 일을 먼저 할 수 있는 마음가짐을 가질 수 있게 되었다.

시간당 LOC(line of code) 를 기록하는 회사도 있다고 하는데, 누가 하루 종일 고민해서 대박 버그를 찾아내 고쳤는데, LOC 만 놓고 보면 시간당 1 라인을 작업했다고 나와서, 관리자가 왜 이리 일을 안 하냐고 다그쳤다는 얘기도 있다.

개발자의 생산성은 어떻게 측정하더라도, 거기에 맞춰 사람들이 최적화되기 때문에, 가능하면 하지 않는게 좋다. 생산성을 측정하겠다면, 그 목적이 사람들을 평가하기 위해서가 아니라, 팀 개발 프로세스 중 어디에서 생산성을 더 높힐 수 있는지를 확인하고, 변경한 프로세스가 이전보다 생산성을 얼마나 높혀주었는지를 확인하는 목적에만 써야 한다. 그렇지 않고, 어떻게든 사람을 평가하기 위해 측정 방법을 도입한다면, 개발자들은 그에 맞춰 배신게임을 할 것이다.

원문

다른 의견 추가하고 싶으신 분은, 위 원문 링크의 위키를 수정해 주세요. :)

 

== 4장 프로그래밍 그룹 ==
CodeReview 과연 괜찮은가?
 CodeReview 를 했을 때 드는 시간을 측정했더니 평소 작업량의 30% 가 더 필요하더라
 이런 부분에 대해 관리자가 우려를 표시하면 어떻게 설득해야 할까?
  관리자에게 이런 얘기를 하면, 개발자를 한 명 더 넣어주는 식으로 해결하려든다
 pair programming 이 비자아적 프로그래밍인 것인가? 실제로 하는 곳이 있나? 어떤 식으로 실천하나?
  몇몇 회사가 있긴 하나 대부분은 하지 않음. 하지만 못 할 것도 없음
 code review 를 하긴 하는데, 맡은 파트가 달라서 코드를 소유한다는 느낌은 들지 않는다
  작업을 돌아가면서 맡아보니 꽤 효과가 있더라.

== 5장 프로그래밍 팀 ==
프로그램팀을 지속적으로 훈련시킬 방법은?
 자기개발 의지가 없는 사람은 어떻게 해도 훈련시키기 힘들더라. 그래서 처음부터 그런 사람은 안 뽑는다

개발자는 꼭 리더가 되어야 하나?
프로그램 능력 말고, 융화능력이 좋은 사람이 PM 역할을 맡으면 좋겠다.
팀장에게 권한이 너무 많이 주어져서, 팀장도 힘들고 팀원도 힘들다
좋은 관리자란 일단 잘 먹여야 한다
 재테크에 대해서는 모르는 게 없으면서, 음료수 살 때도 가위,바위,보 하자는 팀장
강압적인 상하관계 대신 수평관계여야 하지 않을까?
 필요한 순간에 결정을 내릴 수 있는 상급자는 있어야 하지 않을까?

리더나 팀원이 교체될 때 팀이 위기를 맞은 적이 있는가?
 나가는 사람은 그런 걱정을 하지만, 막상 남은 사람들이 잘 해내는 경우가 많더라
 이것저것 할 수 있다고 질러놓고 퇴사하는 사람도 있다
  이건 범죄이지 않을까?

문제가 생겼을 때 잘 모르면 기계 탓을 한 적이 실제로 있다
 QA 하시는 분들도 좀 더 재현방법을 잘 찾아주실 때, 디버깅도 빨리 할 수 있다

자기만의 완전한 시스템을 구현하조자 하는 프로그래머 <-> 끊임없이 바뀌는 개발 스팩(기획서)
 개발 스팩은 당연히 변경될거라는 가정으로 프로그래밍을 해야 한다
 코드를 완벽하게 작성하되 일정을 못 맞추는 프로그래머는 어떻게 해야할까?
  그런 사람의 성향에 맞는 프로그래밍 업무를 맡겨야 하지 않을까?
 Nature Of Order 에서 나온 얘기인데, 팀의 목표를 한 장으로 정리(혹은 시로 만들어서) 해서 매번 읽게 하면 팀의 공통 목표를 잃지 않게 할 수 있다고 한다

배신 게임을 하지 말자
 대신 팀원들을 칭찬하자
 팀에 대한 신뢰는 성과를 통해 쌓인다

팀장이 정보의 비대칭성을 이용하면, 언젠가는 들키게 되고 신뢰를 잃게 된다
 회사가 모든 정보를 다 오픈하지만, 이를 통해서 '지금 우리 회사가 힘들다' 는 것만 강조하려 든다.

한국은 회식도 많고, 서로 끈끈해서, 누가 퇴사해도 궁금한 게 있으면 도움을 요청하기도 쉽고, 누가 뭐 하는지도 더 잘 안다
 감정 상하지 않게 퇴사 잘 하는게 중요하다

언제든 물러날 준비가 되어 있는 리더 <-> 책임감이 있는 리더
 회사랑 맞붙은 후에 나가버리는 리더는 책임감이 없다고도 할 수 있지 않을까?
 
어설픈 보스가 팀원들을 힘들게 한다

제대로 돌아가는 프로세스에 대해 개선을 할 기회를 주는 회사가 있는가?
 과연 제대로 돌아가는 프로세스인지를 항상 의심하고 개선해야 한다
 무엇이든 더 좋아질 수 있다. 예 : 5년 넘게 1시간씩 걸리던 작업을 1주일만에 1분에 끝내도록 고쳤다. 당연하다고 생각되는 것부터 찾아서 고쳐보자

계속 커 나가는 팀을 구성할 때 기존에 있던 사람들이 맡은 역할을 재분배하는 문제가 있다

근태(정시출근)는 기본이다

역량(그 사람의 능력)과 평가(목표 달성 여부)는 분명하게 구분짓자

단기 목표가 무엇인지를 분명하게 알 수 있게 해 주면, 팀장 역할 반은 한 거다

팀장도 피드백을 원한다
 내가 팀원들에게 하고 있는 일에 대해 팀원들이 만족해 하는가?
 마음에 들지 않는 팀장에게 왜 '이건 아닌거 같아요' 라고 말 하지 못하는가?
 그 사람이 나에 대한 평가를 하기 때문. 회사를 나갈 수 있는 사람이 올바를 얘기를 할 수 있다

기본적으로 관리자는 리팩토링을 싫어한다

워크샵에서 심리분석(MBTI 비슷한 거) 를 했더니 서로의 성향을 조금이나마 이해할 수 있는 계기가 되었다

== 6장 프로그래밍 프로젝트 ==
..

분향소...
http://lineage2.plaync.co.kr/board/sshot/view?articleID=74329
http://lineage2.plaync.co.kr/board/sshot/view?articleID=74331
정기점점 후에는 깨끗이 정리될 걸 알면서도 열을 맞춰 리니지2 안에 분향소을 마련해 주신 분들, 수고하셨습니다. 감사합니다.