(서평) 대체 뭐가 문제야?

일반적으로 네트웍 프로그램을 작성할때 대부분 소켓을 이용합니다.

하지만 소켓을 사용할줄 안다는 것이 TCP/IP를 이해한다는 의미는 아닙니다.

사실상 대부분의 네트웍 프로그래머가 소켓이 왜 그렇게 처리 되고 있는지, 왜 그렇게 해야만 하는지에 대해서 모르는 실정입니다.

이 책에선 좋은 네트웍 프로그램 (효율과, 안정성을 모두 보장하는) 을 만들기 위해선 어떠한 사항들을 신경써야 하는지 잘 정리해주고 있었습니다.

TIME_WAIT 상태에 대한 설명 이라던지, TCP/IP가 연결 닫기 정보를 통보하지 않는다는 점, 데이터 복사 효율, 연결 하기/끊기 과정, Nagle 알고리즘에 대한 썰 등 여러모로 다양한 정보를 담고 있습니다.

스캇 마이어스 씨가 작성하진 않았지만, 역시나 Effective 시리즈 다운 좋은 챕터 구성이었습니다.

그렇다고 이 책이 100점 짜리라고 보긴 뭐한것이, 원서를 보지 않아 번역서의 문제라 단정할 순 없지만 조금 난해한 설명을 들 수 있습니다.

도저히 이해못할 정도는 아니긴했지만, 매끄럽진 못했어요.

아쉬운 점이 있긴했지만 고급 네트웍 프로그래머를 꿈꾸신다면 반드시 읽어야할 도서 1순위로 꼽고 싶은 책이었습니다.

서버 테스트 방법 들

스트레스 테스트

  • 예상한 것보다 훨씬 많은 행동을 시도하는 테스트 클라이언트를 통해서, 많은 부하가 발생했을 시에도 정상동작하는지 확인한다.

접속/해제 테스트

  • 좀비 클라이언트가 남는지 확인한다.
  • 접속/해제시 소켓 재사용 로직이 잘 처리되는지 확인한다. (최대 접속 가능 수가 5000이라고 치면, 5000개 이상의 클라이언트로 접속/해제 테스트를 수행한다)

로그인 / 로그 아웃 테스트

  • 로그인 과정에서 끊길 수 있도록, 난수로 결정된 시간 값으로 클라이언트에서 디스커넥을 시도한다. 좀비가 남지 않는지 확인해야 하는데, 이 좀비는 위의 접속해제와 다른 것이 소켓 풀에서의 좀비가 아니라, 서버 로직상에서의 좀비를 확인해야 한다.

랜덤 (더미) 패킷 테스트

  • 프로토콜에 전혀 맞지 않는 (비암호화) 무작위 생성 패킷을 발송한다.
  • 이 검사를 통해 프로토콜 검사를 통과하는 경우는 생길 수 있지만, 그로 인한 예외처리가 잘 되어있는지를 확인하기 위함이다.

변조 패킷 테스트

  • 프로토콜엔 맞되, 들어있는 값이 다른 패킷을 생성해 발송한다.
  • 예를 들면, 뒤에 붙는 데이터 크기보다 더 큰 크기라고 속여서 발송하는 것이다. (실제 길이는 8byte인데, 헤더에는 64byte라고 속이는 등)
  • header의 값을 참조로만 사용하게끔 서버의 verify 로직이 잘 작성 되어있는지 확인하는 테스트이다.

#부하 테스트

  • 프로토콜을 맞춘 패킷을 매우 많이 쏘아올려, 동시 접속자 몇당, 초당 몇 바이트의 패킷 까지 정상적인 수행 속도를 유지하는지 확인한다.
  • 패킷별로 패킷 처리 속도도 기록하라.

로직 테스트

  • 정상적인 로직이 구현되었는지 확인하는 테스트 클라이언트를 구현하고 확인하라. 잘못된 데이터를 전달 받거나, 패킷이 회신 되지 않거나 했을 때에는 개발자에게 알려주도록 하라.

경계 값 테스트

  • 로직 테스트 시 데이터를 올려보낼때 경계값(아이템 최대치가 10이 제한이면, 10, 11 , 0, -1, -32768 등의 값을 올려보낸다) 과 터무니 없는 값도 입력해서 예상치 못한 행동을 미리 시도해보는 것이 좋다.

무작위 패킷 테스트

  • 정상적인 클라이언트가 올려보내기로한 패킷의 순서를 무시하고 패킷을 올려보낸다.
  • 패킷이 순서가 존재하는 상황이 줄어야겠지만, 거래나 퀘스트 같은 경우가 여러 과정을 거치게끔 되어있는 경우가 많다.
  • 동일한 패킷을 여러번 올려보내도 로직상 문제가 없는지 확인한다. (아이템 보상 패킷, 되팔기 패킷 등이 주 검토 대상.)

(서평) 둠. 컴퓨터 게임의 성공신화. 존 카맥, 존 로메로 - 천재 프로그래머 이야기

천재들은 대부분 영재인 경우가 많다.

해당 분야를 일찍 접하고, 그와 동시에 재능을 발휘해오며 천재 소리를 듣게 되었기 때문일 것.

대부분의 좋은 평가를 받는 프로그래머는 꼼꼼하고 성실해서 일을 잘 하거나, 경험이나 연륜에서 묻어 나오는 판단으로 좋은 결과를 내는 사람들이 대다수다. 하지만 천재들은 그런 경험 없이도 뛰어난 판단력과 통찰력을 갖고 있는 경우가 있다.

고등학교 때 만난 한 친구는 문제의 핵심을 파악하고, 그 문제점을 해결하는 방법을 찾는 능력이 매우 뛰어나, 제가 생각하지 못한 부분까지 생각한 능력을 보여주곤 했다

그 친구는 3개월밖에 안했고, 나는 몇년이나 했는데…나도 열심히 해왔고, 그  생각 때문에 괴로웠고, 이 길이 내길이 아닌가보다 내 자신이 부족한 점만 생각나 몇날 몇일 잠을 못들정도로 힘들기도 했었다. 살리에르의 심정이 이런거였구나 싶었다랄까?

내가 중학교 때 방영된 드라마중 카이스트라는 드라마가 있었다.

카이스트를 보면 살리에르의 슬픔이라는 에피소드가 있는데, 그 에피소드에서 말한다. 천재 모짜르트를 곁에 둔 살리에르가 살 수 있는 방법은 한 가지라고. 바로 모짜르트와 경쟁하지 않는 것.

그래서 생각해보면 꼭 천재와 같은 방법으로 내 자신의 가치를 정할 순 없다는 생각이 들었다. 통찰력이 뛰어난 식으로 일을 잘 할 수도 있는것이고, 커뮤니케이션을 잘하는 방법으로 팀작업을 잘 할 수도 있는 것이고, 꼼꼼하게 많은 걸 검토해 일을 잘 할 수도 있는 것 아닐까?

내가 가질 수 있는 다른 장점을 키운다면, 천재와는 다른 방식으로 잘 할 수 있는 것이기에, 천재와 같은 방식이 아닌 다른 방식으로 경쟁하자고 생각을 해오게 됐다.

박지성이 루니나 호나우도에게 드리블이나 테크닉으로 이기기에는 힘들기에 볼이 없는 순간에 움직임을 통한 기회를 만들어내려는 노력이나, 수비에도 적극 가담하며, 경기 흐름을 깨지 않는 플레이 등 다른 점에서 장점을 갖기 위해 노력해 경쟁력을 가졌다. 

나도 그와 마찬가지로, 평범한 프로그래머로써 일을 잘하는 법을 익히고 실천하고 있다.

나와 같이 평범한 대다수의 프로그래머들이 0.1%도 안되는 천재 프로그래머 때문에 힘들어하고, 괴로워하지 않는게 자신을 위해 좋지 않을까 생각이 드는 책이었다.

(서평) 아키텍트 이야기 - 프로젝트의 성공을 위한 지휘자, 아키텍트가 되자.

사실 프로젝트를 진행해오면서 표준이 필요하다는 생각이 많이 들었습니다.

XP에서도 주장하는 것은 죽은 문서를 만들지 말자는 것이지, 문서를 만들지 말자는 것이 아니듯이, 필요한 문서라면, 자주 참고해야 되는 내용이라면 당연히 문서화 하는 것이 맞습니다.

프로젝트가 오래 진행될 수록 네이밍, 클래스 상관도, 기본 설계 방침과 같은 것들에 대한 필요성이 절실했습니다.

아키텍처가 없을 때 같은 일을 하는 메소드가 중복 되고, 어떤 클래스는 크고 어떤 클래스는 작고, 어설픈 패턴적용으로 클래스 간의 관계가 모호하거나 복잡하고, 기능별 처리 주체 불분명해지는 등의 많은 문제를 안게 됩니다.

이런 문제를 책임지고 해결해줄 사람이 바로 아키텍트였습니다. 이 책에서는 아키텍트를 책임 설계자라고도 칭했는데, 아키텍처와 프레임 워크를 통해 성공적인 프로젝트를 위한 가이드라인을 제시하는 역할을 하는 것이죠.

책에서도 말했듯이 프레임 워크는 표현력을 감소 시키는 악영향과, 프레임 워크가 제공하는 범위를 벗어났을 때 기술적인 문제, 설계적인 문제가 동시에 발생하기도 합니다.

그렇지만 전반적으로 프레임 워크가 생산성 향상이나, 유지보수에 이득을 가져다 준다는 점에서 상황에 따라 적절히 활용하면 좋겠다는 생각이 들었습니다.

아키텍트는 이런 기술적인 문제만이 아니라, 팀원들을 리드하는 리더쉽, 비 기술자와 기술자 사이의 절충과 같은 다양한 역할을 맡고 있었습니다.

우리나라에서 일반적인 관리자로써 불리는 직책에 계신 분들이 하는 일과 다른점은, 기술적으로 좀 더 관여한다는 점인데 이 부분이 매력적인 직책이란 생각이 들었습니다.

이 책을 읽고 프로젝트의 성공을 위해 프로그래머보다 좀 더 많은 기여를 할 수 있는 아키텍트가 되고 싶단 생각이 들었습니다. 물론 그러기 위해서는 우선 다양한 경험을 통해 좋은 프로그래머가 되어야겠지만 말이죠.

(서평) 익스트림 프로그래밍 - 소프트웨어 개발도 결국 사람에 달려있다.

사실 소프트웨어 개발에서 자바를 사용할 것인가, C++을 사용할 것인가, 윈도우를 사용할 것인가, 리눅스를 사용할 것인가, DBMS는 어떤 것을 사용할 것인가와 같은 기술적인 이슈는 빠질 수 없는 요소입니다.

그렇지만 기술적인 요소들에 대한 이해도가 높고, 능숙한 기술들로 소프트웨어를 개발한다고 했을 때에도 여전히 소프트웨어 개발은 쉽지 않습니다.

제가 천재가 아니라 확실하진 않지만, 천재도 실수를 하더군요. 당연한 것 아니겠습니까? 사람은 불완전한 존재니까요.

그렇다보니 익스트림 프로그래밍(eXtream Programming, 이하 XP)에서는 그런 실수를 줄이기 위해 테스트를 먼저 작성하고 프로그램에 포함 시키는 테스트 우선 프로그래밍(Test First Programming)을 하자고 주장하고 있습니다.

테스트가 힘들면 그만큼 테스트가 싫어지고, 프로그램 수정과 확인에 대한 스트레스를 받는 다는 말이 너무나 와닿았기에 테스트 우선 프로그래밍의 필요성에 대해 크게 공감할 수 있었습니다.

그 외에 의사소통 문제를 해결하자는 이야기나, 과업별로 스토리를 작성하고 우선 순위를 정해 작업하자는 이야기등도 다 좋았지만, 품질을 낮춘다고 작업 효율이 좋아지지 않는다는 말에서 고개를 끄덕이지 않을 수 없었는데, 높은 품질을 요구 받고 그에 부합하려는 노력을 할 때 더 즐겁고 성취감도 얻을 수 있었기 때문입니다.

사용자 스토리, 테스트 우선 프로그래밍이나, 페어 프로그래밍이나 아직 실무에 제대로 적용하진 못했습니다. 테스트를 프로그램에 포함시키진 못했지만 코드 테스트는 하고 있고, 페어 프로그래밍을 해보진 못했지만 코드에 대한 논의 횟수나 방법을 개선해가며 나아지고 있다고 생각합니다. 물론 아직 멀었지만요.

XP에서 반복적으로 주장한 내용은, 실천하라, 반복하라, 테스트하라. 일찍, 자주, 자동화해서 였습니다. XP에서 주장하는 것들은 사실 사람관계 개선을 위한 방법들이 많고, 그 것을 위해 극복해야 할 것이 많겠지만 시도해보고, 좋은 결과를 얻도록 노력해봐야겠습니다.