백엔드는 Query 날리고(실행하고) 결과만 던져주는 것만 알면 된다?

제목만 보고도 머리가 어질어질 하실 분들이 계실 겁니다. 반대로 "사실이잖아?"라고 말하실 분들도 계실 겁니다. 물론 저야 머리가 어질어질 해지는 쪽이긴 합니다만...

어쩌다 백엔드(Back-end, 예전엔 서버개발자라고도 했죠)는 이런 얘기를 듣고 있는 걸까요?

 

그럼 일반적인 웹사이트 개발에 대한 프로세스를 간단하게 생각해봅시다.

먼저, 고객(클라이언트)라는 존재가 있습니다. 서비스 회사에서는 일반 사용자(Customer)가 될 수도 있고, 용역이나 도급을 받아서 한다면 발주처가 될 수도 있을 겁니다. 어쨌든 고객은 요구 사항을 제시할 겁니다.

개발 조직에 포함해야 하느냐는 의견이 갈릴 수 있겠지만, 저는 개발조직으로 "기획자(디자인), 그래픽, 프로그래머"까지 넣는 편입니다.

한국에서는 기획자라고 부르는데 외국에선 디자인이라고 부릅니다. 저는 편의상 기획자를 디자인 파트라고 얘기하고, 한국에서 흔히 디자이너라고 부르는 분들을 그래픽 파트의 담당자라고 부르겠습니다.

개발자 중에는 기획자가 있습니다. 고객의 요구사항을 분석하고 개발할 내용을 기획 문서에 정리합니다. 그리고 필요에 따라 그래픽 담당자가 실제 화면을 만들어내기 위한 문서도 작성합니다.

그래픽 담당자는 이 문서를 토대로 포토샵이나 제플린, 피그마 등의 툴을 이용하여 화면을 그려냅니다.

퍼블리싱 담당자(퍼블리셔)는 화면을 보고 HTML이라는 문자로 구성하고, 필요한 이미지들을 잘라내서 배치를 시킵니다. CSS나 Javascript와 같은 기술을 이용해서 브라우저 크기나 특성 등을 감안해 만들어내야 하는데, 생각보다 쉬운 작업은 아닙니다. 퍼블리셔는 그래픽이나 프로그래밍 양쪽 모두에 속하기에는 좀 애매한 부분이 있는 영역인데, 그렇다고 중요하지 않다는 의미는 아닙니다. 이들도 개발조직의 당당한 일원입니다.

프론트엔드 개발자부터는 프로그래머의 영역이라고 볼 수 있습니다. 예전에는 백엔드 내에 HTML 코드들이 포함되어 있고 HTML 중간중간에 백엔드 코드가 포함되어 있어서 프론트엔드 개발자들이 작업하는데 애로 사항이 많았지만, 지금은 프론트엔드와 백엔드는 통신을 통해서만 데이터를 주고 받는 형태로 분리되어 개발되는 추세이기 때문에 프론트엔드 개발자들은 독립적인 영역을 다루는 중요한 개발직군이 되었습니다.

백엔드 개발자는 화면에 데이터를 표시하기 위해 프론트엔드가 요청하는 것을 응답하는 프로그램을 만듭니다. 사실 제가 처음 이 일을 시작했을 때에는 그래픽 담당자가 준 PSD 파일을 이미지레디 같은 프로그램으로 자르고 acroedit나 editplus 같은 프로그램으로 HTML을 직접 구성했는데, 이제는 퍼블리싱이나 프론트엔드 개발자도 생기고 RESTful이라는 개념이 생겨서 약간은 표준화된 방식으로 요청을 받고 프론트엔드에서 필요로하는 데이터면 규정에 맞게 보내주기만 하면 됩니다. 물론 후술하는 서버 관련된 일들도 다 했지만, 지금은 그럴 필요가 거의 없죠.

이 외에도 이런 프로그램이 동작하기 위한 서버들을 관리하는 인프라 담당, 개발한 프로그램을 특정 역할을 하는 서버로 배포하는 것을 자동화하기 위한 프로그램들을 구축/관리해주는 데브옵스(DevOps) 담당, 인터넷 세상에서 서비스하기 위한 네트워크 설정들을 해주는 네트워크 등 많은 조직들이 한데 어울려서 개발을 하고 있습니다.

 

그런데 말입니다...위에서 서술했듯이 예전에 한 사람이 하던 일들을 여러 조직들이 나누어서 가져갔기 때문에 할 일이 없어졌다고 볼 수도 있습니다. 그래서 데이터를 저장하는 곳, 대표적인 곳인 RDBMS(오라클, MySQL, MariaDB, SQL Server 등)에 저장하고 그 값을 불러와서 그냥 프론트에만 던져주는게 백엔드 개발이 할 일이다...그러니 할 일도 없고 고만고만한 일이고, 아무나 뽑아서 1년만 굴려도 다 할 수 있는 일이다...이렇게 얘기하는 분들이 있는 겁니다.

 

세상 어떤 일도 다 그렇겠지만, 일의 범위를 축소시키고 그 일만 집중적으로 하게 한다면 어떤 일이든 대부분의 사람들이 다 할 수 있는 일이 됩니다. 예를 들면 일의 특수성 때문에 사회적으로도 대접받고 임금도 타 직종에 비해 높은 의사라는 일에 대해서도, 한 사람이 감기에 대해서만 일을 한정시켜 놓으면 대부분의 경우 감기약 타주고 쉬면서 몸 좀 추스려라...이것만 하면 됩니다. 아니, 될 겁니다. 그런데 그렇게 하나요? 감기는 치료약이 없고 자연치유로 약 5일 정도의 시간이 지나면 우리 몸이 알아서 문제를 해결하지만, 사람마다 증상이 다르고 그에 따른 처방이 달라져야 하고, 경우에 따라서는 그게 감기가 아니라 다른 질병일 수도 있는데 그냥 감기만 판단할 줄 알아서 감기약만 처방하고 있으면...무슨 일이 벌어질지 상상도 안됩니다.

 

백엔드도 마찬가지입니다. 사실 대부분의 일은 RDBMS에 값을 넣고 빼온 뒤 프론트로 보내기만 하면 끝날 수 있습니다. 이런 건 정말 1년 동안 반복만 시키면 숙달될 수 있습니다. 그런데, 세상 일이란게 그렇게 쉬울 리가 없죠. 고객은 좀 더 나은 것들을 요구할 것이고, 그걸 만족시키기 위해서는 다른 꼼수(?)를 동원해야할 필요성이 항상 대두됩니다.

대표적인 경우가 No-SQL입니다. RDBMS에 데이터를 넣고 꺼내오는 방법으로 가장 널리 사용되는 방법이 SQL이라는 표준 문법을 이용해 질의(Query)를 실행하는 것입니다. No-SQL은 결국 이런 질의를 하지 않고 데이터를 처리하는 방법 혹은 제품 정도로 생각하시면 됩니다. 왜 이런 제품이 나왔을까요? 만능에 가깝다고는 하지만, 사용자의 이용 특성에 따라서는 부족한 면이 당연히 있을 수 밖에 없고, 부족한 RDBMS를 대체하기 위해 특정 부분에 있어서 더 나은 성능이나 기능을 제공하기 위해 나온 제품입니다. 당연히 고객이 이런 것을 원한다면 No-SQL 제품을 선정하고 배워서 도입해야 합니다. 현재 자신이 개발하는 분야에서 No-SQL을 전혀 사용하지 않고, 사용할 계획도 없다면...의심을 먼저 해봐야 합니다.

우린 고인물인가?

이런 것 외에도 많습니다. 명절만 되면 우리를 괴롭혔던 철도예약 시스템은 언젠가부터 욕을 덜하게 되는 시스템이 되었습니다. 지금이야 시간에 맞춰 접속하기 위해 새벽에 일어나서 두근두근 대면서 초침에 눈을 떼지 못하다가 광클(빛의 속도로 마우스를 클릭한다는 의미)을 해서 좋은 대기순서를 받는게 스트레스라고 하지만, 예전에는 아예 웹페이지 자체가 안떴습니다. 계속 브라우져 로딩이 되다가 Timeout 처리가 되어서 브라우져의 오류를 보아야 했고, 수십 개의 웹사이트를 띄웠다가 성공하는거 하나 나오면 그걸로 예약을 했습니다. 이런 예약시스템의 변경은 WebSocket을 포함한 Long Polling과 같은 기법이 나왔기 때문입니다. 그럼 이런 통신 방법은 RDBMS에서 값을 꺼내와서 사용자에게 보내주기만 하면 해결될까요?

 

그냥 까놓고 얘기하겠습니다. 백앤드 프로그래밍...그거 뭐 있냐구요?

말하는 당신이야말로 정말 뭐가 없네요