yuchi's Development Home


yuchi의 2000년도 개발사

조회 수 6313 추천 수 94 2002.04.22 21:45:28
(이 글을 쓴 시점은 2001년도 초였음을 밝혀둔다.)

yuchi의 2000년도 개발사.

작년 한해를 이제 와서 되돌아 본다는 게 어찌 보면 때가 너무 늦었단 생각도 든다….음..
이제서야 이런 글을 쓰게 되는 건…무엇보다도 홈페쥐에 게시판 단 게 오늘이기 때문이다. 사실 지난 해 내 머리 속을 지나간 정보량은 어림잡아 100GB이상 될 것으로 생각한다. 정말로 많은 변화가 있었다.
작년도 우리 회사는 합병을 하고 온라인 프로젝트 3개를 시작했다. 어찌 어찌 하여 난 3개 프로젝트의 네트워크 레이어 작업에 관계하게 되었다. 정치적인 얘기라 자세한 내막을 적을 수는 없다. 당시 나는 무협 온라인 팀 서버 프로그래머였고 실질적으로는 학원물 MUG N-AGE의 서버도 같이 맡고 있었다.

당시 나는 하면 된다라는 무대뽀 정신을, 적어도 숙련된 프로그래머보단 많이 가지고 있었고 용감했다.무식했다.(-_-;)
플랫폼은 NT로 잡았다. 어차피 유닉스 프로그래밍 경험이 전무하였으므로 생각할 필요도 없었다. 정확히는 windows 2000을 선택했다.
별 생각없이 전년도 가을에 시험삼아 만들어본 winsock AsyncSelect 방식으로 소켓 레이어를 구성했다. 나름대로 클래스 계층 구조를 잡아서 게임적인 처리를 하는 상위 레이어와 패킷 송수신을 보장하는 하위 레이어를 만들었다. AsyncSelect방식은 윈도우의 메시지큐에 기반한 방식이다. 클라이언트에선 문제가 없었고 서버에서도 일단 문제는 없었다. 얼마 후에 이 방식은 병목이 심하다는 것을 알게 되었다. 메시지 큐를 이용한 싱글 스레드 방식이므로 눈에는 비동기적으로 움직이는 걸로 보이지만 실제로는 메시지큐 에서 완전 serialize되고 동기화 신경 안써도 되는 대신 I/O의 동시 처리가 불가능 했다. 사실 별로 비효율적이란 생각도 못할 정도로 잘 몰랐다. 당시 하이텔 게임 제작 동호회에서 배현직씨(cafe9개발자)로부터 Overlapped I/O가 효율이 좋다는 얘기를 들었다. 어떤 원리인지도 몰랐고 왜 좋은지도 모르고 막연히 퍼포먼스 향상을 위해 Overlapped I/O를 사용해야겠다는 생각이 들었다. 마침 게제동 게시판에 올라온 책 소개를 보고 Network Programming for Windows 라는 책을 구입하였다. 그때까지만 해도 원서를 잘 보지 않았다. 영어실력도 딸리는데다가 소스코드만 보면 금방 따라 할 수 있다는 무대뽀 정신이 투철했기 때문이었다.
그 책을 보면서 winsock에서 사용할 수 있는 I/O방식은 하나씩 다 구현해보았다. 어떻게든최고의 퍼포먼스를 내는 서버를 만들겠단 생각을 하고는 있었으나 회사 일정은 내 이상과는 달랐다. 회사에선 빨리 가시적인 효과를 내주길 바랬고 난 어쨌건 눈에 보이는 결과를 내어야만 했다. 하이콤에서 근무하던 나로서는 합병 후 처음 시행되는 작업일지에 근거한 고과제에 손해를 보았고 도무지 적응할 수 없었다. 스트레스가 쌓이기 시작했다. 소켓 프로그래밍은 나 혼자 하고 있었고 아직 어느 방식을 써야할지도 명확하지 않았을뿐만 아니라 각 방식에 따른 구현 테크닉도 심각하게 부족했다.(물론 그 당시는 얼마나 부족한지도 몰랐다.)
함께 일하던 p씨가 그 무렵 회사를 떠났다. 스트레스가 두배가 되었고 상당히 힘들었다. 작업량이 많아진 것보다도 믿고 일할 사람이 하나 더 없어졌다는, 이제는 혼자서 해결해야한다는, 그 상황에 쉽게 적응이 안되었다. 또한 p씨는 원래 N-AGE팀의 서버 프로그래머였으므로 그쪽팀 업무까지도 나한테 넘어오게 되었다. (나중에 p씨는 불가피한 사정으로 다시 회사에 돌아오게 되었으나 다른 업무를 맡았다.)

가까스로 게임적인 부분(이동,채팅 등)도 진행해가며 초기에 AsyncSelect방식으로 코딩되었던 네트워크 모듈을 갈아엎기 시작했다. 처음엔 overlapped방식으로, 그 다음엔 eventselect방식으로, 최종적으로 overlapped i/o와 completion i/o port를 이용한 방식으로 결정했다. 무지했던 나로서는 completion i/o가 사실 어떤건지도 잘 몰랐다. I/O입출력음 감시하는건가 보다…라고 생각할뿐 그게 스레드 풀링 api인줄은 몰랐다. 스레드 풀링이 무엇인지 조차 잘 몰랐던 시기였다. 대충 구현은 되었고 게임은 계속 진행해나갔지만 멀티 스레드 모드 프로그래밍 경험이 없었고 기본이 너무 부족했기 때문에 연일 스레드 동기화 문제로 머리를 뽀갰다. Cbzgame을 진행하던 웹팀에서도 네트워크 모듈을 요구했고 무협,학원 온라인 팀에서도 네트워크 모듈은 필요했으므로 내가 시험적으로 작성하고 있던 코드들은 모두 실전에 쓰여졌다. 버그는 많았지만 간단히 잡을 수 없는 것들이 많았다. 데드락도 처음 경험하는 것이었고 아주 간발의 시간차에 의해 동기화에 문제가 생기는건 도무지 알 수가 없었다.설계를 뒤집어야겠단 생각만 하고 몇번이나 설계를 바꿨다. 석달간 5번이 넘게 바꾼 것 같다. 대량의 코드가 휴지통으로 들어갔고 버려진 코드만큼 스트레스도 심해졌다.
모듈의 인터페이스가 자주 바뀌었기 때문에 내가 설계를 뒤엎을때마다 각 팀 프로그래머들의 표정은 일그러졌다. 그 열받는 심정은 알지만 당시 어쩔수가 없었다.

여전히 이동처리등의 게임적인 요소도 내가 맡고 있었고 네트웍 모듈은 계속 어딘가에서 문제를 일으켰다. 스레드 동기화에 미묘한 문제가 있어서 10명 접속,100명 접속,150명 접속 모두 상황이 다르게 나왔다. 다른 팀에선 네트워크 모듈의 버그로 계속 날 찾아왔고 나도 뾰족한 수가 없었기 때문에 설계를 뒤집는 횟수만 늘어갈 뿐이었다. 정말 난감했다. 얼마나 기본이 부족했는지 얼마나 무지했는지 여실히 실감했다. 나름대로 빠르게 실력을 쌓았다고 자부했으나 그 무렵 난 아무것도 아니었다. 기본없는 풋내기 프로그래머였을 뿐이었다. 스스로 무력하다고 느끼면서 그래도 극복해볼 생각으로 자료를 찾아다녔고 Jeffrey Richter의 Application Programming for windows 4th란 책을 구입하여 보게 되었다. 일반적인 win32프로그래밍 책과는 달리 os론의 관점에서 바라본, 또한 windows NT계열의 내부적인 처리에 초점이 맞춰진 책이었다. 정말로..정말로 그 때 광명을 보았다. 저자의 막강한 실력에도 놀랐지만 내가 궁금해하던것들이 상당수 해결되었다. 스레드 동기화 문제에 대해서도 해결책이 보였다. 어셈블리 코딩에 대해서도 관심을 갖게 되었는데 어셈블리 코드를 보면서 상당수의 버그를 잡았고 멀티스레드 상황에서 코드 간섭이 어셈블리 명령 하나 차이로 일어난다는 것을 그때서야 알았기 때문이다. 이때부터 원서를 사모으는 버릇이 생겼고 컴파일러에는 disassembly 윈도우를 항상 띄워놓았다. 이런 결론도 내렸다.
“네트워크 프로그래밍을 하려면 OS부터 확실히 알아라”

어쨌든 곧 전면적으로 설계를 수정하기 시작했다. 새로운 버전은 이전보다 훨씬 말끔하게 돌아갔고 100여개 클라이언트를 접속시켜 과부하 테스트를 했을때도 별 문제없이 작동했다.다시 약간씩 자신감을 찾아가기 시작했다. 시스템 프로그래밍, OS,하드웨어등 하드한 분야에 관심이 더해갔고 이런 분야가 기초되어야만 제대로된 프로그래밍을 할 수 있다는 생각도 갖게 되었다.

어떠한 계기로..(이 또한 정치적인 문제이므로 밝힐 수 없다) 2000년 7월경에 서버개발팀(이하 서버팀)이 발족되었다. 팀장은 p씨.팀원은 나. 단 둘의 단촐한 팀이었다. 주 업무는 각 팀에 네트워크 및 서버 솔루션을 개발 공급하는 것. 바라던 바가 이루어진 것이다. 일단은 맘 편하게 작업할 수 있었다. 프로젝트 팀에서 일정에 쫓기며 하위 레이어와 상위 레이어를 모두 만들어야 했던 그 시절에 비하면 천국 같았다. 이전에 작업했던 네트워크 모듈에 대해서도 다시 한번 검토를 할 여유가 생겼다. 좀 더 안정적이고 성능이 개선된 버전을 만들어야겠단 생각에 정말로 ‘제대로 된’ 설계에 들어갔다.

서버팀 발족 후 얼마 후 나는 예전 네트워크 모듈에도 문제가 꽤 많다는 것을 알았다. 사실 퍼포먼스 문제에 대해서 자신하진 않았다.부분적으로 퍼포먼스 저하의 요인이 있다는 것은 알고 있었지만 프로젝트 진행상 도저히 시간이 없었기 때문에 접어두고 있었다. 안정성 면에선 큰 문제가 없을것으로 생각했는데 안정성 면에서도 문제가 있다는 것을 알게 되었다.
당장 프로젝트 진행에는 큰 문제가 없었으므로 ‘제대로 된’ 모듈을 만들기로 했다. 사실 보내고 받는거 자체는 별 일 아니지만 하드웨어 자원을 최대한 활용해서 낭비없이, 또 게임적인 처리를 담당하는 상위 레이어를 작업해야하는 프로그래머 입장에서 스레드 동기화나 기타 문제에 개의치 않고 사용해도 문제가 없도록 만드는건 쉽지 않은 일이었다.

이제야 제대로 된 프로그램을 짤 환경이 되었다는 사실이 기뻤고 즐거운 맘에 설계에 들어갔다. 종이 한장 꺼내놓고 코드 한줄도 못짠 채 하루를 보내는 날이 많았고 삼성동에서 집까지 걸어가면서(약 50-60분) 내내 머릿속으로 설계만 했다. CPU가 여러 개 있고 클럭이 아무리 놓아도 메모리 버스에서 병목이 생기는데는 장사가 없었으므로 최우선적으로 메모리 카피를 없애는데 퍼포먼스의 주안점을 두었다. 그러다보니 나름대로의 데이터구조, 메모리 메니져가 필요했다. NT의 I/O관련 api와 intel CPU에 최적화한 구조를 잡기 위해 꽤 고심했다. 스레드 동기화 때문에 병목현상이 생길만한 부분들은 대부분 어셈블리와 자체제작한 스핀락이 사용되었다. 테스트 결과 병목현상은 꽤 많이 피해갈 수 있었다. 그렇게 하여 기초 설계상으론 마지막 버전인 네트워크 모듈이 완성되었다. 2000년 9월 경이었던 것 같다.

평소 분산객체모델에 관심이 많았던 p씨는 이 기회에 네트워크 모듈을 COM으로 만드는 것이 어떻겠냐는 제의를 했다. 사실 그 동안 내 코드가 바뀔때마다 각 팀 서버 담당 프로그래머들은 인상이 팍팍 일그러졌고 문제가 있어도 기존 버전을 쓰려고 했다. 남의 코드 갖다 붙이는게 쉽지 않을뿐더러 코드가 바뀔때마다 함수의 프로토타입도 계속 바뀌어왔기 때문이었다. 만약 네트웍 모듈이 COM으로 제공된다면 프로젝트 팀 프로그래머들은 단지 파일 한 개를 카피하는 것으로 코어를 업데이트 할 수 있게 된다.
그리하여 네트워크 모듈은 COM으로 작업되었다.파일명 Inetwork.dll, 코드명 (내 맘대로 지은)I4DyuchiNET이라 명명되었다.MS의 .NET플랫폼에서 따온 이름이었다. 별 문제없이 COM으로 포팅되었다. 다만 한가지 마음에 걸리는 일이 있었다. COM은 바이너리 형태로 배포되기 때문에 받아 쓰기엔 편하지만 내부를 알기 어렵기 때문에 자칫하면 받는 사람은 자존심이 상할 수 있는, 기술적인 것과는 거리가 먼 또다른 문제가 있었다.(이 글을 읽는 사람이 코드를 작성하는 사람이라면 그 기분을 알 것이다.) 망설였지만 어쩔수 없는 일이었으므로 COM으로 작성된 Inetwork.dll을 배포하였다. 예상대로 한 팀에서 거센 반발을 하였고 새로운 버전 사용하기를 거부했다. 기존 버전에 문제가 있음을 밝혔음에도 완강하게 거부의사를 밝혔다.

새로운 모듈은 cbzgame,무협 온라인 ‘묵향’ 그리고 드래곤 라자에 쓰여졌다. 사소한 버그들이 몇 개 있었지만 설계상 특별한 문제는 없었다. 퍼포먼스, 안정성 모두 이전보다 훨씬 좋았다. 충분히 생각을 하며 설계를 한 것이 역시 좋았다. 무엇보다도 성공이라 할 수 있었던 것은 유지보수가 쉬워졌다는 것이다. 내가 모듈의 버그를 잡거나 성능을 개선시켜도 다른 팀에선 전혀 코드를 수정할 필요가 없었다. COM버전의 네트웍 모듈을 받아들인 팀에선 그런 점에서 굉장히 좋아했다.
COM버전의 네트웍 모듈을 릴리즈 한 것이 내가 훈련소 들어가기 몇주 전이었다.10월 말이었다. 1년 후딱 간것이다.
1년간 참 공부 많이 했단 생각이 들었다. 연초에 비해 비싼 원서들이 10권 이상이나 늘어있었고 어셈블리 코딩에도 어느 정도 익숙해져있었으며, 스레드 동기화 문제에 대해선 자신감도 붙어있었다. OS에서 무슨 짓을 하는지도 웬만큼 알게 되었다. 1년간 가장 크게 깨달은건 ‘무대뽀 정신땜에 망한다’였다. 1년간 별짓을 다해봤지만 컴파일러나 OS버그로 문제가 된적은 단한번도 없었다. 프로그래머들이여…자신의 코드를 의심해보라. 잘못이 없다 생각되거든 디스어셈블 해서 어떻게 동작하는지 확인하라. 그럴 능력이 없거들랑 컴파일러 버그나 OS의 버그라고 단정짓지 말라.

지금도 나 자신이 프로그래머로서 기본 부족이라고 생각한다. 전산과 출신도 아니고 무대뽀로 프로그래밍을 익힌 탓이다. 그래서 기본을 지금이라도 쌓으려고 많이 노력한다. 그런데 나보다 기본이 더 없으면서도 도무지 알려고 하질 않는 사람들을 보면 참 답답하다.
이 말을 해주고 싶다.
“이제는 프로그래머다운 삶을 살아야 할게 아닌가?”

* 여치님에 의해서 게시물 이동되었습니다 (2004-01-09 01:20)

댓글 '2'

여치

2004.01.09 01:30:41
*.212.99.117

감회가 새롭군요.

바하무트

2004.01.09 03:27:27
*.134.57.99

흠 제가 그렇게 스트레스 쌓이면 정말 "회사 불질러버리고 시간을 벌자(물론 내가 불질른걸 걸리면 안되고...)" 라는 생각으로 머리가 가득찼을것 같은데요 -_-;;
파일 첨부

여기에 파일을 끌어 놓거나 파일 첨부 버튼을 클릭하세요.

파일 크기 제한 : 0MB (허용 확장자 : *.*)

0개 첨부 됨 ( / )
List of Articles
번호 제목 글쓴이 날짜sort 조회 수
天安門大屠殺 六四天安門事件 反右派鬥爭 大躍進政策 文化大革命 六四天安門事件 The Tiananmen Square protests of 1989 天安門大屠殺 The Tiananmen Square Massacre 反右派鬥爭 The Anti-Rightist Struggle 大躍進政策 The Great Leap Forward 文化大革命 The Great Proletarian Cultural Revolution 人權 Human Rights 民運 Democratization 自由 Freedom 獨立 Independence 多黨制 Multi-party system 民主 言論 思想 反共 反革命 抗議 運動 騷亂 暴亂 騷擾 擾亂 抗暴 平反 維權 示威游行 法輪功 Falun Dafa 李洪志 法輪大法 大法弟子 強制斷種 強制堕胎 民族淨化 人體實驗 胡耀邦 趙紫陽 魏京生 王丹 還政於民 和平演變 激流中國 北京之春 大紀元時報 九評論共産黨 獨裁 專制 壓制 統一 監視 鎮壓 迫害 侵略 掠奪 破壞 拷問 屠殺 肅清 活摘器官 障テ社會 誘拐 買賣人口 遊進 走私 毒品 賣淫 春畫 賭博 六合彩 台灣 臺灣 Taiwan Formosa 中華民國 Republic of China 西藏 土伯特 唐古特 Tibet 達償ワ喇嘛 Dalai Lama 新疆維吾爾自治區 The Xinjiang Uyghur Autonomous Region free tibet



XE Login

天安門大屠殺 六四天安門事件 反右派鬥爭 大躍進政策 文化大革命 六四天安門事件 The Tiananmen Square protests of 1989 天安門大屠殺 The Tiananmen Square Massacre 反右派鬥爭 The Anti-Rightist Struggle 大躍進政策 The Great Leap Forward 文化大革命 The Great Proletarian Cultural Revolution 人權 Human Rights 民運 Democratization 自由 Freedom 獨立 Independence 多黨制 Multi-party system 民主 言論 思想 反共 反革命 抗議 運動 騷亂 暴亂 騷擾 擾亂 抗暴 平反 維權 示威游行 法輪功 Falun Dafa 李洪志 法輪大法 大法弟子 強制斷種 強制堕胎 民族淨化 人體實驗 胡耀邦 趙紫陽 魏京生 王丹 還政於民 和平演變 激流中國 北京之春 大紀元時報 九評論共産黨 獨裁 專制 壓制 統一 監視 鎮壓 迫害 侵略 掠奪 破壞 拷問 屠殺 肅清 活摘器官 障テ社會 誘拐 買賣人口 遊進 走私 毒品 賣淫 春畫 賭博 六合彩 台灣 臺灣 Taiwan Formosa 中華民國 Republic of China 西藏 土伯特 唐古特 Tibet 達償ワ喇嘛 Dalai Lama 新疆維吾爾自治區 The Xinjiang Uyghur Autonomous Region free tibet