by 흥배 2008.03.20 23:21
2005년 10월 29일에 네이버 블로그에 적은 글입니다.


문서의 피드백

문서화 작업의 가장 문제점 중 하나가 피드백이라고 생각합니다. 문서화 라는게 자신이 보는 것도 중요하지만 더 중요한 것은 남이 본다는 것인데 그렇다 보니 만들면서 언제나 이게 잘하고 있는 것인가에 대해 의문의 느끼게 되더군요. 수학문제 처럼 어떻게 답이 나오는 것이 아니니 참 애매 합니다. 그렇다고 주위에서 평가를 해주는 것도 아니고저의 경우도 1차적으로는 제가 주위 개발자에게 열심히 보여주면서 평가를 받아야 되는데 저 자신이 자신이 없다보니 자신 있게 피드백 해주기를 요구 하지 못하고 또 다른 개발자 분들은 자신이 할 일이 있다 보니 남의 것을 평가해 줄 시간도 없고, 또 평가 할 때 잘못하면 사이가 어색해 질 수가 있다고 생각하고 있지 않나 생각합니다.

좋은 개발 문서를 만들기 위해서는 피드백이 상당히 중요한데 현재 상황에서는 피드백 받기가 쉽지 않아서 한동안은 삽질을 하지 않을까 생각도 합니다.

 

꾸준한 문서 작업 방식 개량
일반 개발 프로세스 관련 책에 나오는 문서화 방식은 일반적인 기준이라서 개개인의 성향이나 개발자가 속한 환경에 따라서 그에 맞게 적용해야 된다고 생각합니다. 그래서 자신과 환경에 맞는 문서 작업 방식을 찾고 알맞도록 꾸준히 개량해야 된다고 생각합니다.

 

저도 위에 적었듯이 지금 하는 문서 작업 방식은 이제 3개월이 되어갑니다. 그래서 아직 고칠 점이 많이 있을 거라고 생각합니다. 문제점이 드러날 때 마다 강구책을 세워서 적용해보고 가능한 문서화 작업 방식이나 방법에 대해서 많은 개발자와 상의를 할 수 있다면 아주 좋은 결과가 나오지 않을까 생각합니다.

 

 

저는 아직 프로그래밍도 미숙하고, 문서화에도 미숙한 편입니다. 그래서 이런 이야기를 다른 개발자 분들과 여러 가지 이야기를 나누어 봤으면 합니다. 보통 저 말고도 다른 개발자분들도 기회가 되면 다른 개발자분들과 대화를 나누면서 교류를 하기를 원하는데 그럴 방법이 없었어 아쉬워 하더군요개발자들끼리 정기적으로 오프라인에서 모일 수 있는 모임이 있으면 참 좋을 거라고 생각합니다.

 

제가 글 적는게 약해서 헷갈리게 글을 적지 않았나 생각되고 또 별 도움 안되는 이야기를 적었는지 모르겠습니다.. 이런 이야기를 직접 만나서 하면 좀 쉬울 텐데 이렇게 글로 적어서 표현 할려니 쉽지 않네요많이 부족하지만 이후 저의 문서화 작업 방식에 또 다른 변화가 생기던가 문제점을 발견하면 또 글을 올리겠습니다.^^


* 참고로 2008년 현재 이때 적은 글과 방식이 변경된 부분이 있습니다.
관련해서 글을 올리겠습니다.

신고
by 흥배 2008.03.20 23:20
2005년 10월 29일에 네이버 블로그에 적은 글입니다.


새로운 문서화 작업 방식

8월부터 새로운 회사에서 일을 하게 되면서 저한테 맞는 문서화 방식을 적용해서 작업을 하기로 했습니다.

일단 저에 대해서 말하면 부끄럽지만 저는 아직도 설계에 대한 실력이 미천 합니다. 물론 한번 했던 일에 대해서는 할 자신이 조금 있지만 게임 개발 이라는게 왠만한 경력자가 아니면 했던 일을 또 하는 것은 쉽지 않고 거의 100% 다르지는 않지만 다른 일을 하게 된다고 생각합니다. 이렇다 보니 직접 프로그래밍을 들어가기 전에 구체적이고 체계적인 설계를 하기가 쉽지 않으면(책상에 있어도 잘 떠오리지 않더군요) 만약 설계를 했다고 해도 막상 프로그래밍에 들어가면 무지하게 변경을 하게 되더군요. 그래서 저는 프로그래밍 하기 전에 대략 약간 추상적인 형태의 설계를 잡고 제가 만들어야 되는 것에 대해서 기능별로 분리 후(물론 일단 할 수 있는 것만이라도) 그 기능을 하나 하나 구현해 나가면서 전체를 완성합니다. 물론 이 방법에는 하나의 그 전제가 하나 있습니다. 바로 끊임 없는 리펙토링 입니다.

만든 후 문제가 느껴지면 바로 리펙토링을 하면서 해소해 나가야지 다 만든 후 고쳐겠다는 생각을 했다가는 여러 개발 서적에서 나온 것 처럼 잘못된 설계로 다 엎어야 되는 상황에 빠지게 됩니다.

 

제가 하는 방식을 좀더 구체적으로 이야기 하면 저는 문서는 3 가지를 만듭니다. 유즈케이스 명세서, 시퀸스 다이얼그램, 활동 다이얼 그램  현재는 이 3개의 문서가 프로그래밍에 대한 중심이고(물론 소스의 주석은 기본이고요) 그 외에 사양서나 참고 사항에 대해서 따로 문서를 필요에 따라 만듭니다. 제가 구현해야 될 기능에 대해서 제 머리속에 구체적으로 떠오른다면 유즈케이스 명세서로 기능의 이름, 목적, 기본과정, 선 조건, 후 조건, 확장, 관련문서 등을 기록합니다.
이후 시퀸스 다이얼그램이나 활동 다이얼그램을 작성 합니다. 2개는 둘 다 만들어 질 때도 있고 필요하지 않다고 여겨 질 때는 필요한 것만 만듭니다. 제 개인적인 기준은 클라이언트, 서버 등의 여러 단계를 걸쳐가는 경우는 시퀸스 다이얼그램, 기능에 대한 상세한 흐름을 대한 것은 활동 다이얼그램을 이용합니다. 어떤 경우는 시퀸스 다이얼그램을 만들고 이 중 어떤 부분이 복잡하다고 생각되는 부분은 그 부분만을 따로 활동 다이얼그램을 만듭니다. 이것을 다하면 소스 코딩을 합니다.

물론 위에 같은 순서에 딱 맞추지는 않습니다. 어떤 경우는 먼저 소스 코딩을 하고 위의 문서를 만들기도 합니다. 다만 꼭 지키는 것은 기능의 완성된 시점은 코딩과 문서 작업이 다 끝냈을 때를 기준으로 하고 가능한 한 기능을 다 끝 내고 다음 기능을 구현하는 것을 원칙으로 하고 만약 소스를 수정하여 문서와 달라진다면 꼭 문서도 그 변경에 맞추어 변경해야 된다는 것입니다. 이렇게 하는 이유는 제가 처음에 이야기 했듯이 저의 경우는 아무리 문서화 의지나 시간이 있어도 그 양이 많아지면 너무 버거워져서 엄청나게 하기 싫어진다는 것 때문에 제가 쉽게 할 수 있는 양을 하고 또 소스에 특이한 부분은 그것을 만들 때 문서에 기록을 해야 그 당시의 상황에 대해서 좀더 정확하게 기록이 가능하다는 것이면 특히 문서와 소스가 서로 다르게 되면 문서화의 의미가 없어지게 때문에 꼭 같이 일치화 시키는 것을 중요하게 생각합니다. 


리펙토링

현재 제가 개발하는 방식에서는 리펙토링이 아주 중요합니다. 위에 말했듯이 저는 심사숙고한 설계 후 프로그래밍에 들어가는 것이 아니기 때문에 프로그래밍을 하다 보면 불합리한 구조, 이해 안가는 변수 및 함수 이름 등에 의해 수시로 알맞게 수정해야 됩니다. 다만 제가 의지가 약한 인간이다 보니 아무리 레펙토링에 대한 생각이 있어도 그 양이 제가 처리 할 양을 넘어서면 오히려 포기 하게 되기 때문에 언제나 작은 단위로 수시로 작업을 하는 것을 중요하게 생각합니다. 이러다 보니 때에 따라서는 문서와 코드가 불일치 될 확률이 상당히 높기 때문에 문서의 수정 완료를 전 리펙토링이 끝난 시점으로 보고 있습니다.

리펙토링은 코드의 수정 및 문서의 수정이 용이할 만큼 쌓였을 때 처리를 해야지, 이후 자꾸 수정이 있을 것 이라고 생각하여 모아서 하려고 하면 많은 양은 시간 부족에 의해 하지 못하니 자신의 성향에 맞게 잘 조절 해야 된다고 생각합니다.

 

문서화 툴

저는 문서화 툴은 따로 특별한 건 사용하지 않고 MS Office의 엑셀이나 파워포인트를 사용합니다. 다른 좋은 툴이 있지만 비싸고 사용 방법을 익혀야 되기 때문에 오히려 번잡하고 주위에 쉽게 있는 엑셀이나 파워포인트가 저한테는 딱 맞더군요. 특히 저 처럼 클래스 다이얼그램을 사용하지 않는 경우는 더 그렇다고 생각합니다. 다만 이후 Visual Studio .NET 2005가 출시되면 그 툴에 있는 것을 사용하면 좋지 않을까 해서 기대 중입니다.

참고로 저는 파워 포인트로 주로 상세 문서나 유즈케이스 명세서를 만들고, 엑셀로는 시퀸스 다이얼그램이나 활동 다이얼 그램을 만들고 있습니다.


신고
by 흥배 2008.03.20 23:18
2005년 10월 29일에 네이버 블로그에 적은 글입니다.



< 게임프로그래머 최흥배의 문서 작업 방식 >


여러 프로그래머들과 만나서 문서화에 대해서 이야기를 나누어 보고 싶었지만 그럴 기회가 되지 못해 이렇게 블로그를 통해 저의 생각을 알리려고 합니다. 혹시 글을 보시고 토론을 원하는 시는 분은 언제라도 연락주세요^^

문서화는 꼭 필요한가 ?

프로그래밍의 문서화라는 것은 프로그래머 분들은 거의 다들 아실 겁니다. 개발 프로세스 관련 책을 보면 아직도 빠지지 않는 부분이 문서화 부분이라고 생각합니다. 그런데 한국의 게임 개발 회사(타 분야나 외국에 대해서는 자세히는 모르겠네요)에서는 문서화 작업을 하는 곳이 별로 없는 것으로 압니다. 이유는 여러 가지 있지만 제가 생각하기에는 부족한 개발 시간, 문서화의 필요성을 못 느낌, 문서화에 자신 없음 등으로 하지 않고 있지 않나 생각합니다.

문서화라는 꼭 필요한 것은 아닐 수 있으면 문서화 안 한다고 해서 게임이 안 만들어지는 것도 아니고 이게 진짜 필요한가에 대한 의문도 가지기 쉽다고 생각합니다. 그리고 이때까지 안 해도 잘 개발 되었는데 재미 있지 않은 일을 하는데 쓸데 없이 시간을 소비 한다고 생각되어 아깝게 생각 하시지 않나 생각합니다(또 하나 현재 팀장 되시는 분들이 문서화 작업을 해보지 않았기 때문에 막상 팀장이 되었을 때 문서화 작업을 하려니 어떻게 해야 될지 몰라서 팀원들에게 하자고 하기 힘들고, 아니면 문서화 필요성을 느끼지 않기 때문에 영향력 있는 팀장님들이 문서화 작업을 개발에 포함 시키지 않지 않나 생각합니다).

 

제 개인적으로는 문서화에 대한 기준은 개발의 성향이나 환경에 꽤 영향을 받는 다고 생각합니다. 그래서 문서화를 안 한다고 해서 비난 할 수도 없고, 문서화를 한다고 쓸데 없는 짓 한다고 비난 할 수도 없다고 생각합니다.

잠시 저에 대해서 이야기 하면 제가 문서화에 집착하는 이유는 대충 다음과 같습니다. 일단 전 컴퓨터 공학과 출신이다 보니 개발 할 때 가능한 개발 프로세스가 정돈된 상태에서 하기를 원하고 기억력이 좋지 않다 보니 제가 만든 거라고 장시간 지나면 헷갈릴 때가 있더군요.

그리고 제가 이때까지 맡은 일이 남이 만들어 놓은 것을 물려 받아 다시 개발 할 때가 있다보니 남의 소스를 보고 분석을 하고 활용을 하는데 제가 만든 것이 아니라서 때에 따라서 분석에 어려움을 겪고 사용을 쉽게 하지 못하니 그런 것에 시간을 소비 해야 되는 것이 너무 아깝고, 또 내가 만든 것을 남이 볼 때 나와 같은 골치 아픈 짓을 할 것이라 생각하니 쓸데 없는 시간을 낭비한다고 생각되더군요. 그리고 문서화 등을 안 하면 회사에서 만든 소스들은 개발자가 떠나 버리면 무 의미 하게 될 때가 있는데(즉 분석을 제대로 못하면), 회사의 입장에서 볼 때는 개발을 많이 할수록 회사의 기술이 쌓여야 되는데 문서화를 하지 않으면 그것을 만든 사람이 떠나버리면 회사에는 제대로 남지 않아 회사에 기술력이 제대로 쌓이지 못한다고 생각됩니다.

이런 생각에 의해 전 문서화에 대해서 예전부터 생각을 해왔고 나름대로 어떻게 하면 잘 할까에 대해서 고민도 해왔습니다.

그렇지만 신규 개발만 전문적으로 해오신 분들은 문서화의 중요성에 큰 의미를 두지 않는게 자신이 개발한 것이니 장시간 기간이 지나도 약간 헷갈리지는 정도지 소스를 보면서 조금 노력하면 바로 이해가 되니 궂이 문서화의 필요성도 못느끼고, 막상 할려니 어떻게 해야 될지도 막막하고, 또 어떤 경우는 개발자를 뭐 같이 보는 경영자나들이 개발자를 무 자르듯이 잘라 버릴 때 방어 하기 위한 방어의 수단으로도 사용하기도 하고, 개발을 할 시간도 부족하기 때문에 문서화는 엄두도 못내고 있지 않나 생각합니다.

 

문서화 할 때에 문제는 없었나 ?

저는 현재 경력이 4년 차가 되어 가는데 문서화를 제가 자발적으로 하려고 한건 얼마 되지 않았습니다. 제일 처음 한 것이 2003년 말에 이직을 하여 새로운 회사에서 이미 서비스 중인 게임을 제가 물려 받게 되어 소스 분석을 할 때 그냥 하려니 잠만 와서 뭔가 하면서 하면 좋지 않을까 하게 생각이 되어 문서화 작업을 하기 시작하다가 2004년 중순쯤에 일본 마작을 만들면서 처음으로 UML을 실 제작에 도입해보았습니다. 그러다 이번 6월에 다니던 회사를 그만 두면서 문서화 작업을 하면서 나름대로 문서화 방식에 대해서 생각을 가지게 되었습니다. 다른 개발자 분들처럼 저도 그 때까지는 개발 시간에 문서화 시간은 포함 시켜 보지도 못했고 문서는 개발이 완전이 완료가 된 이후에 해야 된다고 생각했습니다. 그래서 6월에 이직 할 때 시간이 넉넉하게 남아서 문서화 작업을 하려고 했는데 꽤 골치 아픈 문제에 직면 했습니다. 문서화 작업이 너무 너무 재미가 없었어 도저히 집중이 되지 않았습니다.  코딩을 하는 것에 비해 보람감도 별로 들지 않고, 하면서도 이게 제대로 하는 건지 자꾸 의문스럽더군요. 그리고 어떤 소스의 경우는 그것을 코딩 할 때의 심정이나 상황이 잘 떠오르지 않으니 좋은 글이 생각이 나지 않더군요. 그러다 보니 결국은 시간이 있음에도 불구하고 제가 생각한 것의 반도 완성을 못 시킨 상태에서 퇴직을 하게 되었습니다.

이렇게 되면서 저 자신에 대해서 다시 생각하게 되었습니다. 저 자신이나 제가 있는 곳의 상황에 맞게 문서화 작업을 하지 않으면 아무리 생각이 있어도 못하고 시간이 있어도 제대로 못한다는 것을 느꼈습니다(의지의 문제겠죠-_-;;).
그래서 최대한 현실적으로 문서화 작업을 하자고 생각했습니다.


신고
by 흥배 2008.03.20 23:16

행사명 : 마이크로소프트 2008 신제품 발표회바로{당신}이 주인공입니다.”

http://www.microsoft.com/korea/heroeshappenhere/events/default.mspx

 

가서 2개의 세션을 들었습니다.

 

1. 새로운 서버 관리 패러다임, Windows Server 2008 서버 코어

발표자분이 NC Soft에서 근무하시는 분이라서 게임 서버쪽 운영과 관계된 말을 들을 있을까 싶어서 들었는데 결과적으로는 거의 없었습니다.

들은 이야기를 대충 요약하면

 

 

서버 코어는 버전에 비해 가벼워졌다( 디스크 용량이 버전은 6.5기가 코어는 1.5기가 ).

 

버전에 비해서 업데이트 비율이 50% 정도로 줄어 들게 된다.

 

WinRS, wmic, 스크립트언어(, 파이썬) 지원한다.

 

Native Win32 코드 프로그램이 실행된다.
) 서버코어 + IIS7 + NySQL + PHP   된다고

 

코어에 실행 프로그램은 .NET 플랫폼이 아니고 그래픽 UI 있으면 된다.

 

가상화를 이용할 때 가상화를 운용할 주 OS를 코어버전을 설치하고 가상화 시킬 OS는 풀 버전을 설치 하는 것도 좋다(이건 다른 세션에서 김정근님이 듣고 알려주셨습니다).

 

OS가 가벼워지고 보안 및 가용성이 개선되었고 GUI가 없어도 다양한 관리 방안이 있음.



2. Just Try AMD

별 기대를 하지 않은 세션이지만 쿨한 이름답게 내용이 아주 좋았습니다.

제가 AMD CPU를 사용해보지 않았고 기본 지식이 별로 없었는데 짧은 시간 안에 잘 정리 되었습니다.

 

 

현재 AMD 이용률은 25%.

 

AMD의 혁신

-       최초로 1GHz의 벽을 넘었다.

-       최초로 32/64 비트 지원 프로세스를 만들었다.

-       최초로 듀얼 코어 프로세스를 출시했다(인텔이 듀얼코어라는 이름 사용으로 일반 사람들은 인텔이 먼저인지 알고 있다고 함).

-       AMD는 코어는 다이 하나에 들어가 있어야 한다는 기조 때문에 쿼드 코어 출시가 늦게 되었음. 지금 출시되어 완벽한 테스트를 받아서 완전 무결함.

 
발열량이 낮음. 사례로 PC방 주인들에게서 여름에 에어컨 비용이 작게 들었다는 말을 들었다고 함. (발열량이 높으면 주위가 더워져서 그만큼 에어컨 가동이 증가됨)

 

현재 55나노 공정으로 45를 진행 중이고, 2011년에는 22나도 예정.

 

인텔의 경우 코어가 새로 나올 때마다 메인보드까지 교체 해야 되지만 AMD는 그렇지 않음.
) 듀얼 코어가 설치 되는 근래의 보드는 쿼드코어도 CPU만 바꾸면 됨.

 

AMD의 쿼드 코어는 각 코어의 CPU 사용만큼 전력을 소비함.

현재의 듀얼코어나 인텔의 쿼드코어의 경우 하나의 코어는 75% 사용, 나머지는 30% 사용이라면 사용량과 상관없이 모든 코어의 전력 소비는 75%와 같다고 함.

 

AMD도 단점으로 발열을 지적하는데 그것은 옛날 이야기이다. 애슬론부터는 아니다.

지금은 인텔보다도 좋다,

 

전력 소비 발표 시 인텔은 평균을 발표하고, AMD는 최고치를 발표하기 때문에 AMD가 높은 것으로 잘못 전달 되었다고 함.

 

AMD를 사용하기를 원하면 어떤 회사의 PC라도 대여 해 줄 용의가 있다고 함.

그러니 먼저 사용해 보고 판단해 주기를 바란다고 함.


    

강연자 연락처 : Bogyu.kim@amd.com

    

신고
by 흥배 2008.03.20 23:11