무턱대고 네트워크 프로그래밍에 관심을 갖게 되면서 네트워크 기반 지식들 쉽게 배울 만한 수단이 뭐가 있을까.. 찾는 중에 발견하게 된 책이 '후니의 시스코 네트워킹' 이란 책입니다.
이 책은 주로 네트워크 장비, 그 중에서도 스위치, 라우터를 여러가지 상항(네트워크 물리적인 구성)을 예시로 들면서 설명하고 물리 계층에서 네트워크 계층 까지 적용되는 프로토콜을 설명합니다. 이해를 돕기 위한 이미지가 많고 '자문 자답' 형식으로 말하듯 설명합니다.
챕터 중간에 실제로 네트워크 configuration을 콘솔에서 지정하고 확인하는 내용이 있는데, 저는 '네트워크 장치 관리를 실제로 어떻게 관리' 하는지 보단 '네트워크의 물리적인 단계에서의 대략적인 흐름'을 알고 싶었기 때문에 실습예제는 세세하게 읽진 않습니다. 게다가 스토리텔링 하듯 설명하기 때문에 책을 읽고 나면 이야기 책을 본듯한 느낌이 납니다. (중간에 가려울 법한 부분은 별도로 보충 설명을 하는 등의 노력을 많이 한 점이 보입니다.) 때문에 1,2권을 합치면 600page가 넘는 분량이지만 생각보다 빨리 읽을 수 있었네요.
이 책은 전반적으로 네트워크 장치(스위치, 라우터)를 기준으로 네트워크 설명을 하기 때문에 게임 서버 프로그래밍과는 직접적인 관련이 있진 않습니다. (물론 네트워크 계층 프로토콜, IP 체계에 대한 설명은 매우 유용하다고 생각합니다.) 그래도 가독성이 좋은 책이기 때문에 네트워크 계층 아래 프로토콜들의 원리가 궁금하시다면 가볍게 읽고 네트워크에 대한 인사이트를 확장 시켜보는 것도 좋을 것 같습니다 :D
[인프런 rookiss 님의 C++ 서버 강의]를 듣고 [윤성우 tcp/ip 소켓] 책을 보게 됐습니다.
tcp/ip 가 무엇이고 실제로 windows에서 소켓 프로그래밍을 어떻게 작성하는 대략적으로 알고 있는 상태에서 이 책을 읽었습니다.
프로그래밍 입문 당시 프로그래밍 기초 문법을 살펴보고 좀 더 심도 있는 공부를 원하던 때 윤성우님의 c/c++ 책은 제게 심화 학습을 위한 중간 다리와도 같은 느낌이 였습니다. 자칫 초심자에게 어려울 수 있는 내용은 굉장히 친절하게 전달하려고 노력한다고 느꼈기 때문입니다.
단순히 프로그래밍 기본 문법을 전달하는 한국서적을 읽고 좀더 레벨(?)을 올리기 위해 새로운 책들은 찾아 보면 대부분의 고급주제를 다루는 책들이 영문버전이 많고 해석본 마저 부자연스러운 번역들이 많이 이런 부분들은 더 많은 경험치를 쌓고자 하는 초심자인 저를 가로 맞는 큰 벽과 같았습니다.
처음 c/c++을 배울 때 이런 상황에서 윤성우님의 책은 제게 [초심자-중급자]의 중간 다리 역할을 하는 책이라 생각합니다. 윤성우님의 책은 조금 더 심화된 내용을 독자들로 하여금 이해하기 쉽게 설명하고 더 나아가 힘조절(?)을 하면서 앞으로 공부 방향성에서 자연스럽게 유도합니다.
이런 좋은 기억을 되새겨 서버프로그래밍을 시작한 지 얼마 안된 뉴비인 저에게 윤성우님의 tcp/ip 소켓 프로그래밍 책은 후회 없는 선택이였습니다.
이 책의 장단점과 다루는 주제에 대해 간략히 요약하겠습니다.
장점
- 문장 하나하나에 굉장히 심혈을 기울였다고 생각합니다. 기술서적의 경우 한가지 개념을 설명하기 위해서 여러가지 개념의 수반되는 됩니다. 그리고 이때 모든 개념을 다루다 보면 서적의 난이도는 굉장히 올라가게 됩니다. 이 책은 이 밸런스를 잘 조절 했다고 생각합니다. 이해를 쉽게 하기 위해 중요한 기반지식을 생략하지도, 최대한 자세하게 설명하기 위해 가독성을 포기하지도 않았습니다.
- 모든 챕터의 진행이 [개념->샘플 소스코드] 구성입니다. 모든 개념을 설명한 뒤에 적절한 타이밍(?)에 샘플코드가 나옵니다.
- 챕터 중간중간 소켓프로그래밍 지식을 전달하며 수반되는 필요성에 대한 언급도 자주 합니다. 책 마지막에는 향후 학습 책도 추천합니다. 주니어 프로그래머에게는 단순히 주제에 대한 지식 전달 뿐만 아니라 앞으로 공부 방향성에 대한 조언은 굉장히 유익한 부분이라고 생각합니다.
- 리눅스, 윈도우 두 OS를 대상으로 설명하고 샘플코드를 첨부합니다. 때문에 설령 Window Socket 프로그래밍이 관심 있는 분이라고 할지라도 이 책을 통해 공부한다면 리눅스에서의 소켓프로그래밍의 공통점과 차이점을 이해하는 것은 되려 윈도우에서의 소켓프로그래밍을 제대로 이해하는데 도움이 될 거라고 생각합니다.
- 윈도우, 리눅스에서 소켓 프로그래밍에 사용되는 함수들 매개변수, 반환형 단위로 상세하게 설명합니다. 어떤 분야든 처음 공부할 때는 거시적은 설계보다는 세세한 사용법에 신경 쓰게 됩니다. 지극히 자연스러운 부분이고 세세한 사용법을 알아가는 과정도 거시적인 안목을 기르는 자연스러운 기본기가 되는 부분이라 생각합니다. 이점에서 이책은 함수 단위로 상세하게 설명하면서 초심자들의 가려운 부분을 시원하게 긁어주고 있지 않나 생각합니다.
- 동영상 강의도 책을 구입한 독자들 대상으로 12개월 무료로 제공됩니다. 아직 동영상 강의를 보지 않았지만 개인적으로 다양한 형태의 input이 중요하다고 생각하기 때문에 이점은 무조건 장점이라고 생각하는 부분입니다.
단점
- 제가 책을 읽은 2022 기준 샘플코드가 복붙으로 간단하게 실행되진 않습니다. 전 간단한 소켓 프로그래밍을 이미 작성 해본 경험이 있고 해당 책은 눈으로만 읽었기 때문에 이런 부분이 문제가 되진 않습니다. 하지만 샘플소스코드를 꼭 실행해보고 싶은 사람들에게는 조금은 불친절한 책이 될 수도 있을 것 같습니다. 하지만.. 대부분의 프로그래밍 책들이.. 책이 쓰인 시점과 책을 읽는 시점의 환경이 많아 달라진 탓에 제대로 돌아가지 않긴 합니다..
- 다루는 주제 범위가 굉장히 넓거나 굉장히 심도 있진 않습니다. 저 같은 경우에는 그래도 두세번은 더 읽은 만한 가치가 있다고 생각해서 책으로 소장하는 것에 대한 후회는 없지만, 어느정도 소켓프로그래밍 수준이 높은 분들은 서너번 읽게 될 책은 아닐 것 같습니다. 이건 독자들의 수준에 따라 다를 것 같습니다.
814p. 코드 최적화는 일반적으로 아키텍처, 알고리즘 선택과 같이 극적인 향상을 제공하지도 않고, 성능을 향상시키기 가장 쉬운 방법도 아니다. 하지만 진정한 프로그래머가 되는 통과 의례이다. 여러분과 다른 프로그래머들을 제외한 어느 누구도 일반적으로 여러분의 코드가 얼마나 엄격한지에 대해서 신경 쓰지 않는다. 그럼에도 불구하고 프로그래밍 문화에서는 아주 미세하게 효율적인 코드를 작성하는 것은 여러분이 훌륭한 프로그래머라는 것을 증명한다.
818p. 코드를 작성하면서 최적화해야 한다! - 거짓! : 세부적인 최적화를 하느라 너무 바빠서 중요한 전역적인 최적화를 뭇히나는 경우가 생긴다.
820p. 최적화 시기 : 고급 설계를 사용하라. 프로그램을 올바로 만들어라. 나중에 작업하기 쉽도록 모듈화하고 변경이 쉽도록 만들어라. 정확하게 완성되었을 때, 성능 검사하라. 만약 프로그램을 못 쓰게 하고 싶다면, 빠르고 작게 만들어라. 최적화가 필요하다는 것을 알게 될 때까지 최적화를 하지 않는다.
823p. 비효율성의 공통적인 원인 : 입/출력 연산, 메모리 페이징(page), 시스템호출(컨텍스트 스위칭 발생), 인터프리트 언어, 오류
831p. 만약 보다 효율적인지를 알기 위해서 측정할 가치가 없다면, 성능 도박을 위해서 명료함을 제물로 바칠만한 가치도 없다.
827p. 공통적인 연산의 상대적인 성능 비용
Chapter26 코드 최적화
논리구조
답을 알고 있을 때에는 테스트를 중단하라
- break문 사용
빈도에 따른 테스트 정렬
- 거의 항상 참인경우가 가장 먼저 수행되도록 정렬한다.
유사한 논리 구조의 성능을 비교해라
- case문과 switch문의 경우 언어보다 성능의 우위가 다르다. 간단히 말해서 결과를 측정할만한 신뢰할 수 있는 방법이 없다.
복잡한 표현식을 테이블 참조로 대체하라
- 테이블 참조가 복잡한 논리 구조를 따지는 것보다 더 빠른 경우가 있다.
소극적인 평가를 사용하라
루프
언스위칭
- 루프 검사를 밖에서 하는 것을 고려해라
재밍
- 결합가능한 루프를 하나로 묶어라
언롤링
- 루프의 보조 수단 코드의 양을 줄이는 것이다. 하지만 전체 코드량이 늘어나고 가독성이 떨어지는 단점이있다. 또한 코드 최적화에 대한 보증이 없다. 언어나 컴파일러에 따라 상이하기 떄문이다.
루프 내부 작업의 최소화
감시값
- 루프의 지속 중단 여부를 결정 짓는 감시값을 외부에서 정의해서 사용해라
가장 빈번한 루프를 안쪽에 작성해라
강도감소
- 곱셉과 같이 시간이 많이 걸리는 연산을 덧셈과 같이 시간이 적게 걸리는 연산으로 대체해라
666p. 어떤 방법을 사용하든지 간에, 모든 협력적인 구현 기법은 오류를 해결하기 위한 목적으로 여러분의 작업을 다른 사람에게 보여주는 것을 형식적으로 만들기 위한 시도이다.
667p. 협력적인 개발 방법의 개요 - 서로 간에 차이가 있을지라도 모든 협력적인 구현 기법은 개발자들이 자신의 작업에 있는 문제점들을 제대로 파악하지 못한다는 점과 다른 사람들은 제대로 파악할 수 있다는 점, 그리고 다른 프로그래머가 자신의 작업을 지켜보면 도움이 된다는 기본 개념에 기초하고 있다.
671p. 짝 프로그래밍 성공 요건 - 짝 프로그래밍을 강요하지 마라 : 매우 복잡한 코드를 작성할 때 짝 프로그래밍을 사용했던 한 그룹은 15분 동안 칠판에 상세 설계를 한 다음 혼자서 프로그램을 작성하는 것이 더 적절하다는 것을 발견 했다.
675p. 정밀 검사에 경영자가 참가하는 것은 일반적으로 좋은 생각이 아니다. 사람들은 검토를 하는 대신 평가를 받고 있다고 느낀다.
679p. 정밀 검사에서의 자존심 - 정밀 검사 자체의 핵심은 설계나 코드에 있는 결함을 발견하는 것이다. 다른 대안을 찾거나 누가 옳고 누가 그른지에 대해서 논쟁하는 것이 아니다.
680p. 정밀 검사에서의 자존심 - 그럼에도 불구하고, 작성자는 언급된 모든 결함을 인정하고 계속 진행해야 한다. 비평을 인정한다고 해서 작성자가 비평의 내용에 동의한다는 것을 의미하지는 않는다. 작성자는 검토중에 자신이 한 작업에 대해서 방어를 하려고 해서는 안된다. 각 검토자는 오류를 어떻게 해결할 것인지에 대한 작성자의 최종 결정권을 존중해 주어야 한다.
779p. 구현중에 변경하는 것은 일반적으로 원래의 개발자가 수행하고, 보통 프로그램이 완전히 잊혀지기 전에 수행된다. 시스템이 아직 외부에 공개되지 않았기 때문에, 변경 사항을 끝내야 한다는 압박도 일정상의 압박일 뿐이지 시스템이 다운된 이유를 궁금해 하는 500명의 사용자가 아니다. 같은 이유로 구현중의 변경사항은 자유로울 수 있다.
787p. 전문가들은 미래의 요구 사항을 준비하는 가장 바람직한 방법은 이론적인 코드를 작성하지 않는 것이라고 말한다. 현재 필요한 코드를 분명하고 직관적으로 작성하여, 미래의 프로그래머가 그 코드가 무엇을 하고 무엇을 하지 않는지 대해서 알 수 있도록 하고 그에 따라 변경할 수 있도록 하는 것이다.
790p 데이터 수준 리펙토링 - 컬렉션을 캡슐화 한다 : 만약 클래스가 컬렉션을 리턴할 때, 고정되지 않는 여러 개의 컬렉션을 갖고 있다면 동기화 처리를 어렵게 할 수 있다. 클래스가 읽기만 가능한 컬렉션을 리턴하도록 하고, 컬렉션에 요소를 추가/제거하기 위한 루틴을 제공하도록 한다.
791p 명령문 수준 리펙토링 - 조건문을 다형성으로 대체 한다.
792p 루틴 수준 리팩토링 - 다운캐스팅을 캡슐화 한다 : 만약 루틴이 객체를 리턴하고 있다면, 일반적으로 루틴이 알고 있는 가장 구체적인 객체의 타입을 리턴해야 한다. 이러한 리팩토링은 특히 반복자(iterator), 컬랙션(collection), 컬렉션의 요소 등을 리턴하는 루틴에도 적용이 가능하다.
799p 안전한 리팩토링 - 주차장을 만든다 : 여러분이 리팩토링을 수행하고 있을 때, 때로는 다른 리팩토링을 해야 할 필요가 있을 것이다. 또한 새로운 리팩토링을 수행하고 있을 때, 또 다른 리팩토링이 도움이 된다는 것을 발견하게 될 것이다. 지금 당장 필요하지 않는 변경을 위해서 "주차장"을 만들어 놓는다. 즉, 지금 당장은 변경해야 할 필요가 없지만 어느 시점에서 변경해야 하는 변경사항에 대한 목록을 만들어둔다.
799p 안전한 리팩토링 - 빈번하게 체크 포인트를 설정한다 : 리팩토링을 하다보면 코드가 갑자기 엉뚱한 방향으로 가기 쉽다. 여러분이 시작한 코드를 저장하는 것뿐만 아니라, 리팩토링을 하면서 여러 곳에 체크 포인트를 저장하여 막다른 골목에 갔을 때, 작동하는 프로그램으로 돌아올 수 있도록 한다.
800p 안전한 리팩토링 - 컴파일러의 경고를 활용한다 : 컴파일러의 경고 수준을 가장 까다롭게 설정하면 많은 오류들을 즉시 잡는 데 도움이 될 것이다.
800p 안전한 리팩토링 - 변경 사항을 검토한다 : 작은 변경이 큰 변경보다 오류를 발생시킬 가능성이 더 높은 경향이 있다.
