컴퓨터 네트워크
컴퓨터 네트워크 공부의 복리 이자
대학교 갓 졸업한 친구들을 작년에 뽑아서 회사에서 같이 일을 하고 있다. 전공이 컴퓨터 공학이랑 전기 전자라서 소프트웨어에 대한 기본은 있지만 물론 많이 부족하다. 단순한 일을 시키면 곧잘 하고, 열심히 하려고 하는 의욕도 있어서 즐거울 때도 있지만, 어떤 때는 업무를 시키는 의도를 잘 이해하지 못하거나 전혀 엉뚱한 곳에서 헤매고 있어서 답답할 때도 많다.
요 근래에 몇 번 시켰던 일이, 임베디드 컴퓨터 장비를 네트워크에 연결하고 통신이 잘 되는지를 확인하는 일이었다. 대부분의 경우에는 장비 업체에서 제공하는 매뉴얼대로만 따라 해도 동작이 잘 되는 경우가 있지만, 그렇게 바로 일이 되지 않을 때는 좀 더 깊이 파고들어서 뭐가 문제인지 확인을 해 봐야 하는 경우도 있다.
본격적인 개발일도 아니고, 그 전의 준비 작업이고, 업체에서 제공한 자료도 많은 단순한 업무라고 생각해서 신입 직원에게 일을 맡겼는데, 반나절이면 끝냈어야 할 일을 며칠씩 붙잡고 있길래 뭐가 문제인지를 같이 보다가 이 친구가 컴퓨터 네트워크에 대한 가장 기초적인 이해가 부족하다는 것을 발견했다.
파이썬이나 C++ 언어를 이용해서 인터넷 관련 프로그램이나 임베디드 컴퓨터와 통신하는 소켓 프로그램을 만들라고 하면 곧잘 만들어내던 친구라서 더 실망이 컸는지도 모르겠다. TCP/UDP 라이브러리를 이용해서 서로 다른 컴퓨터끼리 통신하는 프로그램을 만들 수 있는 친구가, 가장 기본적인 네트워크 연결을 확인하지 못해서 며칠째 헤매고 있다는 것이 이해가 가지 않았다.
아마도 이런 것이, 근본적으로 내가 만드는 소프트웨어의 동작 원리를 이해하지 않고, 편하게 만들어져 있는 라이브러리만 갖고 프로그래밍을 배울 경우의 부작용일 것이다. 사실 소프트웨어 라이브러리라는 것이 있는 이유가 어찌 보면 그렇게 가장 아랫단의 동작 원리를 전부 이해하지 못해도 내가 풀고자 하는 문제를 쉽게, 보다 효과적으로 해결하기 위한 것이라고 하면, 이런 부분을 내가 못마땅해하는 것이 비합리적인 반응일지도 모르겠다.
영어로 흔하게 하는 말이 “Don’t reinvent the wheel”이라는 표현이다. 이미 남들이 다 만들어놓은 바퀴라는 발명품을 다시 발명하지 말라는 이야기다. 즉, 남들이 풀어놓은 문제는, 고맙게 그 해결책을 가져다 쓰는 것이 좋다는 뜻이다. 표면적으로는 옳은 말인데, 정말 실력 있는 소프트웨어 엔지니어가 되고 싶다면 이 말을 좀 더 다르게 해석할 필요가 있다고 생각한다. 바퀴를 내가 다시 발명할 필요는 없지만, 그 바퀴가 만들어진 원리를 잘 이해하고 있어야 만들어진 용도대로 잘 사용도 할 수 있고, 혹시 부족한 부분이 있다면 개선을 하는 것도 가능할 것이다.
나는 TCP/IP Illustrated라는 책으로 컴퓨터 네트워크를 공부했었다. 그 분야에서 정말로 유명한 책이었다. 가장 기본적인 컴퓨터 네트워크의 원리부터 실제로 구현된 코드를 한 줄 한 줄 들여다보면서 공부를 하다 보면 시간은 많이 걸리지만 컴퓨터 네트워크의 동작에 대해서 정말 탄탄한 기본기를 갖출 수 있다.
꼭 그 책이 아니더라도, 이더넷으로 이루어진 링크 레이어에서, IP로 이루어진 네트워크 레이어, TCP/UDP로 이루어진 트랜스포트 레이어와, 이메일이나 웹 브라우저를 위한 애플리케이션 레이어를 설명하는 책이나 동영상 혹은 강의를 통해서 이해를 넓힐 방법은 많다.
이런 기본적인 이해를 하게 되면 우리가 자주 쓰는 192.168.0.x로 시작하는 사설 네트워크 주소가 어떤 의미이고 255.255.255.0이라는 서브넷이 왜 필요한지, 그리고 왜 같은 네트워크 허브에 같은 컴퓨터에서 두 개의 서로 다른 네트워크 인터페이스가 연결이 되면 통신이 안되는지, 왜 한쪽 컴퓨터에서는 같은 네트워크 스위치를 통해서 인터넷이 잘 되는데 다른 컴퓨터에서는 라우팅 테이블을 업데이트해 줘야만 인터넷 연결이 되는지를 이해하고 문제에 접근할 수 있다.
물론 이런 기본적인 지식이 없이도, 구글 검색을 통해서 스택 오버플로우에 다른 사람들이 올려놓은 해결책을 찾아볼 수 있고, 이것 저것 명령어를 시도해 보면 그중에 하나가 얻어걸려서 문제가 해결될 수도 있을 것이다. 하지만 그럴 경우, 문제가 해결되었다고 해도 왜 그런 문제가 발생했는지를 모르기 때문에 그게 올바른 해결책이라는 확신도 없고, 추후에 비슷한 문제가 생겼는데 그 해결책으로 해결이 안 될 경우 다시 또 구글 검색과 다른 친절한 엔지니어의 선의에 의존해서 문제를 해결해야만 할 것이다.
소프트웨어를 개발할 때 가끔 나오는, Technical Debt라는 용어가 있다. 업계에서 쓰는 우리말 번역이 따로 있는지는 모르겠는데, 말 그대로 기술적인 빚이라는 뜻이다. 지금 당장 남의 돈을 빌려서 문제를 해결하지만 결국은 갚아야 한다는 면에서 금전적인 빚과 비슷하고, 계속 갚지 않고 놔두면 이자가 발생하며, 나중에 더욱 커다란 문제가 될 소지가 있다는 공통점도 있다.
예를 들어서 일정이 급한 소프트웨어 개발 프로젝트에서, 자잘하게 발생하는 컴파일러의 경고를 무시한다거나, 제대로 된 검증 과정을 생략하고 중요한 부분만 테스트하고 넘어간다거나, 서로 처음에 동의한 코딩 표준이라던가 디자인 원칙을 당장의 급한 개발 일정 때문에 지키지 않고 오로지 빠른 결과물을 만들어내는 데에만 집중하는 것을, 기술적인 빚이 쌓여간다고 한다.
이런 기술적인 빚을 빨리 해결하지 않으면, 아주 중대한 결함이 생기거나, 점점 기능을 수정하거나 추가하는 것이 어려워서 자꾸 누더기 같은 소프트웨어가 되거나, 아니면 결국 이런 것들이 쌓여서, 기존 결과물을 다 갈아엎고 새로 다시 만들어야 하는 경우가 생기기도 한다.
소프트웨어 엔지니어로 성장하는 과정에 있어서도 기본을 무시하고, 남들이 만들어놓은 라이브러리를 제대로 원리도 이해하지 못하고 편리하게 쓰기만 하는 것도 어찌 보면 이런 기술적인 빚을 쌓는 것과 비슷하다고 생각한다. 뭔가 굉장히 어려워 보이고 멋있어 보이는 프로그램을 만들어내니까 겉보기에는 화려해도, 부실한 기초 위에 쌓은 건축물이 계속 크고 높게 올라가기는 어려울 것이다.
내가 평생 해온 분야가 컴퓨터 공학의 가장 기본을 다루는 임베디드 시스템 분야라서 그럴 수도 있도, 또 어느 정도로 소프트웨어에 문제가 생겨도 소셜 네트워크의 사용이 좀 불편해진다거나, 오피스 프로그램이 좀 느려진다거나 하는 정도의 사소한 문제가 아니고, 매우 심각한 재산의 손실 혹은 사람의 생명까지 위험해질 수도 있는 분야의 소프트웨어를 다루다 보니 보다 더 이런 충실한 기본기를 강조하는 것일 수도 있다.
예전에는 이더넷이나 네트워크 프로그래밍을 한다는 것은, 웹사이트와 웹브라우저의 통신을 원활하게 한다거나, 게임에서 데스크탑 쪽 소프트웨어와 게임 서버의 통신, 혹은 서버에 저장된 금융 거래나 기타 정보를 원활하게 다루는 특정 분야를 의미했을 수도 있다. 하지만 지금은 우리가 타는 자동차부터, 비행기, 스마트폰, TV 부터 무인 폭격용 드론이나 핵 발전시설, 심지어 화성에 가 있는 탐사선까지 모두 네트워크로 연결이 된 컴퓨터에 의해서 작동을 하는 세상이다.
우리에게 친숙한 유무선 이더넷도 있지만, 블루투스나 5세대 통신망부터, 위성 통신과 전력선을 통한 통신, 차량에 들어있는 100여 개의 컴퓨터를 연결하는 CAN/LIN/FlexRay나 단순한 문자 메시지를 저속으로 주고받는 직렬 통신까지 정말로 다양한 형태의 컴퓨터 네트워크가 있다. 그리고 이런 다양한 네트워크 시스템을 아우르는 OSI 모델 (Open Systems Interconnection model)이라는 것이 있다.
처음에 이런 네트워크 시스템을 바닥부터 들여다보면 정말 헷갈리고 무슨 소리인지 이해하기 쉽지 않겠지만, 시간을 두고 한 땀 한 땀 공부를 해 보고 실제 바탕이 되는 소프트웨어도 직접 손으로 만들어보면 나중에 큰 도움이 될 것이라고 보장한다. 빚이 오래 쌓이면 그만큼 갚기가 힘들어지듯이, 아주 어렸을 때부터 적금을 들어놓으면 복리로 쌓이는 이자 역시 매우 커지는 것과 같은 원리이다.
