C++
2006년 1월 11일에 네이버 블로그에 적은 글입니다.


C++의 설계와 진화 라는 책을 보고 있습니다.
( 책 사진은 http://blog.naver.com/jacking75/140009579158   )

이 중 첫 부분의 'C++의 이전의 역사' 챕터를 보았습니다.
1.1 Simula와 분산 시스템
1.2 C와 시스템 프로그래밍
1.3 개인적인 배경


이중에서 1.3에서 나오는 내용을 간추려 보았습니다. 이것을 보면 C++의
특징에 대해서 좀 이해와 C++을 만든 비얀스트롭(맞나 -_-;;)의 사상을
알수 있으리라 생각합니다. 그리고 이전에 자바와 C++의 비교하는 것을
의미 없는 것이라고 이분이 이야기 했는데 그 이유도 알것 같습니다.
자바와 C++의 사상 자체가 틀린것 같더군요.
자바는 OOP가 최선이라고 생각하여 이것을 프로그래머들에게 강제한다면
C++은 개개인의 프로그래머의 생각을 존중하여 개인의 생각을 최대한
존중하여 다양한 방법으로 프로그래밍을 할 수 있게 만들었다고 생각합니다.


아래가 제가 대충 정리한 내용입니다.
------------------------------------------------------

C++의 전체구조는 나의 일반적인 세계관이 반영 되고 있을 것이다.
물론 C++의 개개의 부분은 컴퓨터 과학의 정밀한 개념에 의해 만들어 졌지만

나의 전공은 수학(순수수학과 응용수학)으로 나의 덴마크 박사 칭호의 타이틀은
'수학 및 컴퓨터 과학'으로 되어 있다. 나는 수학의 아름다음도 좋지만 목적 없는
추상적인 진리나 미(美) 보다도 문제 해결을 위한 실용 툴로써의 수학에 마음이 기울어진다.
컴퓨터나 프로그래밍 언어에 대한 나의 관심도 역시 실용적인 관심이다.

나의 장년(25년 이상)의 취미는 역사이다. 또 학생시대 이후부터 철학 공부에 많은 시간을
소비 하였다...세계에는 다양한 사상이 있는 중에서 나에게는 관념론 보다 경험주의가 가장
잘 맞다.

집단의 존중에 그 집단에 속하는 것에 대한 존중이 포함 되지 않는다면 그것은 전혀 존중
할 수 없다. C++ 설계의 많은 부분이 강제에 대한 나의 혐오가 근간이 되고 있다.
인류 역사의 최악의 참사는 '이것이 옳은 것이므로 이것을 해!' 라고 말하는 이상주의자의
강제에서 생겨난다.

나는 프로그래머들에게 선택을 자유를 주고 싶다.

나는 이론이랑 논리만으로 기초를 두는 결정이 싫으므로 그 것은 나의 문학 취미에도 나타나고
있다. 이렇게 말하는 의미는 C++는 마틴 A 한셈, 알베르 카뮤, 죠지오웰 등 컴퓨터를 한번도
본적이 없는 소설가랑 엣세이스트들의 영향을 크게 받고 있다. 또 컴퓨터 과학자 중에서는
David Gries, Don Knuth, Roger Needham 같은 수학자로 있기 이전에 인간으로서 상식인으로 있는 사람들에게 많은 영향을 받고 있다.

나는 나의 기호에 맞지 않는 기능을 C++에서 뺄려고 하는 것에 대해 언제나 그것을 생각하지 않을려고 한다. 왜냐하면 나의 생각을 타인에게 강제 하는 자격이나 권리는 누구에게도 없기 때문이다.
이론만을 순수하게 추구하여 다양한 생각을 '오랜되었다', '안된다', '확실하지 않다'고 말하면서
깔아 뭉게었다면 C++은 훨씬 일찍 완성되었을 것이다. 그러나 시간의 가치 보다도 사람의 가치가
훨씬 높은 경우가 많다. 사람의 다양한 생각을 허용하고 받아들여 하나의 것을 여러가지 방법으로
완성하는 것이 나에게 있었어는 훨씬 가치가 크다.

나는 새로운 기술을 사람들에게 추천해 그 가치를 설득할 때, 무리하지 않고 천천히 하는 것을
좋아한다. 사람들을 세뇌하는 테크닉이 있다는 것을 알고 있지만 그런한 테크닉은 기본적으로
위화감을 느낀다.

나는 문제 해결을 위해서 C++을 설계 하였지 무언가를 실증하기 위해 만든 것이 아니다. C++은
유저에게 봉사 하는 것에 의해서 성장했다. 변화를 조금씩 축적하는 것에 의해 세상을 좋게
하는 것은 가능하다.

나는 사람들에 도움이 된다고 믿는 기술이나 아이디어의 보급에 이제부터라도 힘을 쏟고 싶다.
우리들의 기술이랑 생각에 접근성을 높이고 그것들의 전문가의 도구가 아닌 사회의 도구로
하는 것은 과학자랑 지식인의 의무이다. 물론 사람이 이상의 회생자로 되어서는 안된다. 나는
협소한 프로그래밍 언어에 의한 단 하나의 설계 스타일을 사람들에게 강제하고 있는 것이 아니다.
사람마다 사물의 생각과 일을 하는 방법이 굉장히 다양하므로 '이것이 보통적인 최선'이다고
칭하는 특종의 스타일을 밀어 붙인다면 발생하는 것은 피해이다. C++은 의도적으로 다양한
스타일을 실현 할 수 있는 스타일로 되어 있다. 그것은 '단 하나의 옳은 방법'를 강제하는
언어가 아닌다.

프로그래머에게 있었어 프로그래밍 언어가 가장 중요한 도구이다. 그러나 프로그래밍 언어는
세계의 극히 작은 일부분에 지나지 않으므로 그렇게 요란을 떨 것은 아니다. 이를테면 세계의
전체를 의식하고, 균형 있는 시각을 유지하는 것이다. 그리고 가장 중요한 것은 유머와 센스를
잊지 않는 것이다. 메이져 언어 중에서 가장 많은 호사가들이랑 죠크의 근본이 되고 있는
것이 C++ 이다. 그것은 결코 우연이 아니다.
-------------------------------------------------

이전에 사 놓고 요즘 'Art of UNIX Programmin'를 다 보고 이른바 잠자기 용 책으로
보고 있는데 저의 주력 언어인 C++에 대해 제가 모르고 있던 부분이 나와서
흥미롭네요....그래도 책에 글자만 있었어 잠은 잘 옵니다..^^;;

신고
by 흥배 2008.03.20 23:23
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

티스토리 툴바