By Kesus Kim

이건 뭔가요?

서버 프로그래머 로그(Server ProgrammerLog, SPL)는 본인이 서버 개발을 하며 느끼고 알게 된 것들을 정리한 기록이다.

서버에 대한 내용을 주로 기록하겠지만, 사회 초년생인 본인 입장에서 일반적인 개발자의 삶도 기록하지 않을까 생각한다.

서버, 넌 누구냐

정의

서버라는 단어 자체에서 서버가 무엇인지 알 수 있다. serve -er, 즉 ‘제공하는 존재’ 가 서버이다. 무엇을 제공하는가? 에 따라 서버의 명칭이 달라진다.

종류

서버의 종류는 검색해보면 많이 나온다. 당장에 Wikipedia 만 봐도 애플리케이션 서버, 카탈로그 서버(이건 뭐지…?), …~ 웹 서버 까지. 14가지 분류의 서버가 있다.

내가 경험한, 그리고 자주 언급되는 서버들은 다음 정도로 분류되는 것 같다.

  • 애플리케이션 서버
  • 데이터베이스 서버
  • 파일 서버
  • 게임 서버
  • 메일 서버
  • 프록시 서버
  • 웹 서버

위의 7가지 종류의 서버 중 애플리케이션 서버와 웹 서버는 분류가 굉장히 애매한 것 같다. 위키피디아에 따르면 애플리케이션 서버는 응용 프로그램의 ‘로직’을 처리해주는 서버라고 하고, 웹 서버는 주로 HTML 을 반환하는 서버라고 하는데, 그렇게 생각하면 HTTP API 서버는 애플리케이션 서버인가? 특히, Web Application Server(WAS) 라고 부를 수 있는건가? 보통 WAS 는 Java 기반의 서버… Tomcat, Wildfly 를 부르던데. @_@ 이건 나도 모르겠다.

클라이언트

‘서버에게 제공을 받는 존재’ 는 클라이언트 라고 부르며, 이 때 ‘제공받는 것’ 을 서비스 라고 부른다.

프로토콜

서버와 클라이언트 간의 통신은 정해진 규격대로 이루어지며, 이를 ‘프로토콜’ 이라고 한다.

특정한 경우를 제외하고는 거의 모든 통신은 TCP 프로토콜 위에서 이루어진다.

크게 두 종류로 생각할 수 있다.

  • TCP 프로토콜을 이용하여 직접 메세지 송수신 포맷을 정의하여 통신하는 경우
  • TCP 프로토콜 위의 다른 프로토콜(예: HTTP)을 이용하여 통신하는 경우

다른 프로토콜을 이용하면 많은 것들을 다른 사람이 해준 것을 이용할 수 있다. 예를 들어서, HTTPS 프로토콜은 전송 계층에서 암호화를 제공해준다. 그리고 워낙 잘 알려진 국제적 표준이어서 많은 곳(특히 웹)에서 아주 쉽게 사용할 수 있다. 만약 HTTPS 를 직접 TCP 에서 구현한다면, 유쾌한 경험이 아닐 거라 생각한다. (정말 필요한 상황이 아니고서야…)

특성

서버는… ‘안정적’ 이어야 한다. 즉 어떠한 상황에서도 문제 없이 동작을 해야 한다. 만약 문제가 있을 수 있는 상황이라면, 그러한 예외적 상황에 대한 처리가 되어야만 한다.

예를 들어서 인터넷이 잘 되는데 웹 브라우저에서 https://google.com 을 입력했는데, 구글이 안 나온다고 생각해보자. …… 그런 상황은 상상조차 할 수 없다.

사용자의 입장에서는 서버가 오작동을 해버리면 그것은 재앙이다. 사용자 본인에게 피해가 가지 않으면 좀 불편하고 말겠지만, 가령 주식 서버가 오작동해서 1000원씩 보내야 할 걸 1000주씩 보낸다는 둥의 경제적 손실이 발생을 하면, 특히나 이번 상황마냥 사용자의 실수처럼 보이는 일이 아니라 정말 서버가 오작동을 한 문제였다면, 그것은 참으로 재앙이다.

서버가 안정적이 되기 위해서는 많은 노력을 해야 한다. 대표적으로 다음과 같은 노력이 있다.

  • 꼼꼼한 시나리오 기획: 회사 차원의 노력
  • 완벽에 가까운 소프트웨어 설계 및 개발: 팀 / 개인 차원의 노력
  • 테스트 주도형 개발(TDD / BDD): 팀 / 개인 차원의 노력
  • 소프트웨어 품질 관리: 회사 차원의 노력

뭐 제일 중요한건 역시 완벽에 가까운 소프트웨어 설계 및 개발이라고 생각한다. 동작하는 모든 코드 한 줄 한 줄까지 담당자가 이해를 해야만 한다. 담당자가 이해하지 못하는 부분(예를 들어 서드 파티 라이브러리)이 조금이라도 있다면, 제 아무리 시나리오를 꼼꼼하게 기획하고 코드를 완벽하게 작성해도, 문제가 생길 수가 있다.

물론 그렇다고 해서 모든 부분을 0과 1로 만들 필요까지는 없다. 다만 커뮤니티나 회사 내부적으로 검증이 된, 믿고 쓸 수 있는 부분을 가지고 만들자는 것이다. 그래서 모든 서버 프로그래머는 로우 레벨에 익숙해야만 한다. 본인 회사의 선임님은 심지어 Python 처럼 커뮤니티 차원에서 검증이 된 언어라도, 런타임 차원에서 메모리 관리 등을 직접 하기 위해 C/C++ 로 개발을 하신다. Python 의 런타임을 불신하시는 것이다. 본인에게는 신선한 충격이었다. Node, Python 좀 해보고 서버 프로그램 할 줄 안다고 생각했는데, ㅎㅎ..

모듈화

모듈화는 주로 OOP 에서 Object 의 개념을 설명할 때 사용하는 단어이긴 하지만, 내가 이를 적당한 의미로 사용하는 건지는 모르겠다. 나는 모듈화 라고 부르겠다.

기본적으로 서버는 ‘안정적’ 이어야 하고, 그 ‘안정성’ 을 보장하기 위해 담당자는 서버의 동작을 모두 이해해야 하며, 따라서 가급적 서버의 규모를 복잡하게 하지 말자는 생각 이 여기서 하고 싶은 말이다. 그런 의미에서 서비스를 제공하는 전체적인 서버의 시스템은 복잡할 수 있을지언정, 시스템이 제공하는 각각의 기능을 쪼개어 서버를 분리시켜서, 마치 모듈처럼 만들자는 생각이다.

서버를 모듈화 시킬 경우의 장점은, 각각의 서버가 각각의 기능을 수행하니, 특정 기능에서 문제가 생길 경우 어느 서버에서 문제가 생겼는지를 쉽게 파악할 수 있고, 특히나 어느 함수의 어느 지점에서 문제가 생겼는지까지도 큰 어려움 없이 파악할 수 있다. 반면 단점은 서버가 너무 많아질 경우 새로운 담당자가 각 서버를 파악하는 데에 어려움을 겪는다는 점과, 만일 서버 간 통신을 할 경우 실패했을 때의 예외 처리 등을 해주어야 한다는 점이다.

설계 방법론 또는 디자인 패턴 이라고 부를 수 있는 이 모듈화는 내 생각에는 어느 정도 규모 있는 서버 시스템을 만든다면 반드시 고려해야 한다고 생각한다.