2_흐름정리_백엔드란?

fadet 2022. 2. 17. 17:41

* 비유는 접근성을 늘릴지라도 본질을 흐리기 마련입니다.

해당 포스트는 실습 과정 중 학습을 정리하는 글이기에 주관적인 내용이 포함되어 있을 수 있습니다.

잘못된 부분이 있다면 걸러들으시거나 댓글로 남겨주시면 감사하겠습니다.

* CS 카테고리의 흐름 정리 파트는 정확한 개념 파악보단 전체적인 흐름을 이해하는데 초점을 맞춰 진행합니다.

* 예전에 쓴 글이다보니 의욕이 앞섰는지 존댓말이 아닌 반말로 진행되는 점 양해 부탁드립니다. 언제 한 번 수정하겠습니다.

@지금까지 알아본 내용
#API

CS 카테고리에선 프로그래머라면 알고 있어야하는 소양에 대해서 끄적이려고하는데, 그 중 가장 처음 끄적인 것은 API였고 앞으로 단계를 거치며 여러 포스트를 작성하려고한다.

포스트에 앞서 모든 지식을 획득함에 있어서 공통되는 사항은 지식은 선형적이라 학습 단계가 딱딱 나누어진 것이 아니고 파편화되어 있어 여러 개념들이 난립하며 그 깊이는 너무나도 깊기 때문에 한 명의 완벽한 선생님이 알려주지 않는 이상 학습에 있어서 모르는 부분이 나온다면 그것을 참고 다음 스텝에 들어갈 용기가 가장 중요하다고 생각한다.

그렇기에 어떤 분야에 입문할때 가장 중요한 것은 내가 어느 부분을 얼마나 덜 알고 넘어갈 것이냐의 결정이고 이 결정은 내가 그 분야의 전체적인 흐름을 파악하는 시간과 매우 밀접할 것이다. 운영체제에선 프로세스가 어떻게 메모리와 cpu를 사용하는지, RDBMS에서 data를 효율적으로 가져오기 위해 무슨 기술을 사용하는지, 메모리를 GC가 청소하는 과정 같은 지식은 매우 중요하지만 전체 흐름을 알기위해서 이것들을 과감하게 나중에 습득할 것으로 치부하는 게 더 효율적인 학습이 될 수 있다는 얘기다.

Index
0 백엔드란?
1 벡엔드 개발 용어
2 BackEnd? Server?
3 백엔드 개발 과정의 비유
4 정리

백엔드(Back-end)란?

우선 아무것도 모르는 분들을 위해 가장 먼저 백엔드는 과연 무엇인가?에 대해 애기해보고자 한다. 초등학생도 코딩 교육을 받는 요즘 많은 분들이 프론트엔드와 백엔드같은 용어 정도는 많이 들어봤을테지만 막상 정확히 무슨 뜻인지 알지 못하는 경우가 많다.

이 용어들을 알기 위해선 end point를 의미하는 end에 대한 이해가 필요하다. 엔드포인트란 영어 뜻 풀이 그대로 끝 지점을 의미하며 개발자들의 성지인 stackoverflow에 적힌 글은 이렇게 설명한다.

An endpoint is simply one end of a communication channel

앞서 살펴봤던 API처럼 개발 전반에 있어 엔드포인트는 추상화되어 많이 사용되며 우리가 알고있는 디바이스, 포트 등 통신의 최종 목적지로 구현된다. 쉽게 앞서 살펴봤던 API 통신의 목적지가 엔드포인트라고 생각하면 편하다.

대략 이해했다면 좀 더 정확한 개념에서 엔드포인트는 네트워크 통신에서 “한 쪽 끝”을 의미하며, 예시처럼 반드시 “최종 목적지”만을 뜻하진 않는다. API에서의 엔드포인트는 특정 기능을 제공하는 URL(예: /api/users)을 의미하며, 단순히 “목적지”로만 한정하면 오해의 소지가 있으므로 디바이스나 포트 전체를 지칭하기보다는, 프로토콜에 따라 정의된 논리적 접점이 더 정확할 것이다

이것을 이해했다면 다음으로 개발 전반의 역사를 잠깐 살펴봐야한다. 과거 웹사이트를 런칭하고 서비스하는데 개발자들은 현재 개발자들의 주 업무라 볼 수 있는 사용자들이 보는 화면, 사용자들의 요청을 서버로 보내는 API 통신, 사용자들의 요청을 받아 처리하는 비즈니스 로직이 담긴 서버 뿐만아니라 뒤에서 설명하겠지만 DB 통신부터 네트워크 구축, 보안까지 모든 과정에 관여했기에 한명 한명 정말 많은 지식이 필요했고 이 점이 과거 컴공의 인식이 그리 좋지 않았던 큰 이유 중 하나였다고 생각한다.

하지만 IT 산업이 크게 확대되고 기술의 눈부신 발전으로 인해 IT 산업의 각 분야마다 이루고 있는 요소들이 매우 고도화됨에 따라 IT 직종이 세밀하게 분화되었다. 그 중 현재는 주로 개발의 영역에서 프론트엔드와 백엔드 두 개로 구분하여 업무를 처리하는데 프론트엔드는 사용자 영역의 비즈니스 로직과 인터페이스를 백엔드는 DB와 서버 API 개발을 주로 담당한다. 그렇기에 백엔드 개발자로 업무를 하기 위해선 프로그래밍, DB, 웹 서버, 인프라 등에 관한 지식을 갖춰야한다.

벡엔드 개발 용어

개발의 타임라인은 지구의 시간을 미세하게 쪼개어 마지막에 위치한 부분인 인류의 시간 중 기록된 시간, 즉 역사에서도 그리 길지 않다. 하지만 그 생태계는 앞서 살펴봤듯 그렇게 짧은 시간 발전해 온 것에 비해 너무나도 방대하기에 개발자가 알아야할 지식 중 백엔드 관련만 해도 프로그래밍, DB, 웹 서버, 인프라 등이 있으며 백엔드 개발자라 해도 기본적으로 프론트엔드에 대한 기본 지식을 갖춰야하며 이뿐 아니라 OS, 네트워크 등 CS(Computer Science 컴퓨터 공학)까지 익혀야한다. 이를 하나하나 깊게 이해하는 것은 불가능하다 생각하기에 앞으로 전체적인 흐름을 살펴보는 선에서 이 지식들을 하나하나 살펴보려 한다.

BackEnd? Server?

백엔드 개발자의 업무를 조금 살펴보자면 우리가 스마트폰을 켜서 인스타그램에 포스팅을 하면 포스트가 올라간다. 그 때 check버튼을 누른 순간부터 포스트가 생성되는 과정까지 생기는 API 통신과 사용자 페이지에서 뚜렷하게 보이지 않는 개체들간 관계를 정립하는 과정을 서버가 했다고 생각하면 쉬울 것이다. client-server사이에서 서버는 저장된 페이지만 client에게 제공하는 단순 WEB서버부터 요청을 받아 로직을 처리하여 동적인 결과를 제공할 수 있는 Tomcat 등 WAS(Web Application Server)라는 것까지를 의미하고 실제로 서버는

이런 커다란 컴퓨터 본체들을 의미한다. 지금도 이런 서버 컴퓨터들이 모여 있는 서버실을 운영 중인 대규모 기업들도 있지만 AWS같은 클라우딩 서비스 기업의 대두로 이런 서버 컴퓨터가 직접 없더라도 웹 구축이 가능하며 최근엔 대부분의 기업이 클라우드를 이용한다.

보통 백엔드와 서버 개발자를 보통 동의어로 사용하곤 하는데, 사실 따지자면 스프링 웹프레임워크를 써서 개발하는 사람이라면 '웹 백엔드 개발자'가 정확할 것이다. 서버 관련 업무는 무수히 많다 뒤에서 알아보겠지만 일반적으로 불리는 서버의 로직을 개발하는 백엔드 개발자, DB를 중점적으로 관리하는 DBA(Database Administration), 실제 서버를 관리하는 서버 엔지니어, 개발 관련 인프라를 구축하는 시스템 엔지니어 등 이해하기 쉬운 직무만 봐도 꽤나 복잡하고 아직 설명하지 않은 개념들때문에 소개는 못하지만 더 많은 직군이 존재한다. 실제로 옛날에 이런 직무 분리가 존재하지 않을때는 모든 업무를 개발자 한명이 도맡아했다. 개발자들이 개발할 시스템 환경을 구축하고 비즈니스 로직을 개발하며 DB, 서버도 직접 관리하고 사용자에게 보여줄 View도 만들었다. 이 때문에 할 일이 태산이었고 항상 호출이 있을 수 있으며 뒤에 설명할 배포도 하루 잡고 밤에 모여서 서로 만든 코드를 합쳐서 직접 해야했다.

하지만 최근에는 이런 배포 작업(보통 CI/CD[Continuous Integration/Deploy]라 함)이 자동화되고 서버나 DB 관리도 AWS의 등장으로 추상화되어 개발자들의 관리 부담이 확 줄었으며 소규모 회사에선 함께 처리하기도 하지만 일정 규모 이상이 되면 직무 분리가 전문화되어 일반적으로 코드를 짜는 우리들은 웹 백엔드 개발자라고 칭해야 할 것이며 딱 정해진 것은 아니지만 서버 개발자는 인프라, 네트워크, 시스템 관리까지 포함하는 경우가 있고, 백엔드 개발자는 주로 비즈니스 로직, 데이터 처리, API 개발에 집중하는 경우가 많다 . 물론 백엔드 개발자 역시 서버 인프라 지식 전반에 대해서 알아야한다. 하지만 아는 것과 실제로 관리하는 것은 매우 큰 차이다.

각설하고 백엔드 코딩을 시작하려는 나는 백엔드에서 무엇을 해야하는지 아는 것이 가장 먼저일 것이다. 앞으로 백엔드에서 이뤄지는 처리는 여러가지다. 이 중 우리가 우선적으로 알아야하는 개념은 다음과 같다. 당연히 실제 개발 단계는 이보다 복잡하며 여기선 단순화하여 설명할 것이다.

#프로그래밍 #라이브러리 #프레임워크 #컴파일 #빌드 #배포

백엔드 개발 과정의 비유

프로그래밍을 내가 집을 짓는 과정 전반으로 비유하겠다. 이 과정을 프로그래머가 할 일에 mapping해 볼 것이다.

#프로그래밍 : 특정 목적을 달성하기 위해 설계된 알고리즘(algorithm)을 프로그래밍 언어를 사용하여
구체적인 프로그램으로 작성하는 과정, 쉽게 말해 프로그램을 만드는 모든 작업
#프로그램(program) : 어떤 문제를 해결하기 위해 컴퓨터에게 주어지는 처리 방법과 순서를 기술한 일련의 명령문의 집합체.
일반적으론 무언가의 진행 목록이나 순서를 뜻하며 과거 공연의 순서를 프로그램이라고 했었는데 
현대에 이르러 방송에 정착되고 컴퓨터 용어로 파생되어 위와같은 뜻을 지닌다.

우리가 집을 짓는 회사의 사장이라고 생각하자. 건축에 대한 전문지식을 다루는 것이 아니기에 전문적인 것은 되도록 배제하고 이 회사는 집을 짓는 것부터 분양, 유지보수까지 모든 것을 하는 회사라고 가정한다. 그렇다면 당신이 집을 지을 때 해야할 일은 다음과 같다.

1 집을 짓기 위한 예산을 가늠한다 - 2 건물을 지을 인력을 뽑는다 - 3 집을 짓는다 - 4 다 지은 뒤 안전점검 등 완공 준비를 한다 - 5 집을 분양한다

1 집을 짓기 위한 예산을 가늠한다

- 일단 집을 짓기 전에 어떤 집을 지을지, 시공 방식은 무엇으로 할지, 어떻게 지어야 수지가 맞는지 확인한 뒤 설계도를 그릴 것이다.

* 이 과정에서 지을 집의 종류는 내가 웹, 모바일 중 어떤 플랫폼에서 구축할 것인가, 시공 방식은 내가 어떤 프로그래밍 언어를 기반으로 코드를 작성할 것인가, 수지 계산은 내가 구축하는 어플리케이션의 규모와 성능이 client에게 맞는지, 개발을 하는데 걸리는 시간 등에 매핑될 것이다.

2 건물을 지을 인력을 뽑는다 > 개발 환경을 세팅한다.

- 당신이 직접 공사판에 뛰어들 수는 없다. 마찬가지로 앱을 개발하는 것도 당신이 아닌 컴퓨터가 한다. 인력을 뽑을 때 일용직을 뽑고 이를 관리할 관리직을 뽑고 모든 관리를 문서화 하고 보고할 사무직을 뽑을 것이다. 일용직인 컴퓨터를 갖추고 관리직인 os, 개발 언어, IDE를 설치한 뒤 사무직인 터미널을 통해 상황을 전달한다.

여기서 이해를 돕기 위해 모든 인부들을 영국인이라고 가정해보자. 그들에게 일을 지시하기 위해선 모든 사항을 영어로 번역해야할 것이다. 그러기 위해 나는 번역가를 모집해서 건축에 필요한 언어를 문서화한 뒤 영어로 번역했다.

* 이 과정에서 건축에 필요한 언어는 프로그래밍 언어, 문서화한 것을 소스코드, 번역가는 컴파일러, 번역을 하는 일은 컴파일이라고 한다.

#컴파일(compile) : 어떤 프로그래밍 언어로 쓰인 소드코드를 다른 언어로 바꿔주는 과정.
일반적으로 흔히 아는 JAVA, C++ 등을 기계가 이해하는 어셈블리어로 바꿔주는 걸 컴파일이라고 한다.

3 집을 짓는다.

- 집을 지을때 아무 모래나 쇠붙이를 가지고 지을 수 있을까? 지을 수 있다! 초가집이나 기와집이면 된다. 하지만 쇠붙이를 가공하여 철근콘크리트, H빔 등을, 석회와 모래를 가공하여 시멘트로 만들면 더욱 좋은 집을 만들 수 있다. 또한 인부들에게 이 재료를 그냥 주고 집을 지으라고 하면 될 것인가? 당연히 어떻게든 완성이 될 수도 있겠지만 시간이 얼마나 걸릴지 장담할 수 없다. 하지만 1차 시공사를 선정하여 그 시공사에게 건물 뼈대 제작을 맡긴 뒤 뼈대위에 자재를 입혀 완성한다면 시간은 더욱 빠르고 난이도 역시 엄청나게 내려갈 것이다.

* 이 과정에서 모래나 쇠붙이는 어플리케이션을 만들때 사용되는 다양한 프로그램들, 철근이나 시멘트는 라이브러리, 건물 뼈대는 프레임워크로 매핑될 것이다.

#라이브러리 :  소프트웨어를 개발할 때 컴퓨터 프로그램이 사용하는 비휘발성 자원의 모임이다. 
여기에는 구성 데이터, 문서, 미리 작성된 코드, 함수, 클래스, 값 등의 사양을 포함할 수 있다.
우리가 모든 기능들을 코딩하기엔 너무나 오래 걸리기 때문에 공통으로 사용되는 특정 기능을 모듈화.
예를 들어 우리가 계산에 관련된 어플리케이션을 만들고 있다면 수학 관련 라이브러리를 불러와 사용하면 된다.

#프레임워크 : 어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조이다.
프레임워크는 여러 기능을 가진 api, 클래스, 라이브러리를 함쳐서 하나의 툴처럼 개발자에게 제공.
웹 프레임워크는 우리에게 기본적인 웹의 개발 환경을 제공하고 우리가 코드로 커스텀한다고 생각하면 쉽다.
단, 그 목적이 정해진 채로 제공되기 때문에 커스텀에는 한계가 있고 다른 목적으론 사용이 힘들다.

앞서 api 포스트에서 다뤘었지만 제어 흐름의 주도권이 누구에게 있냐가 둘을 가르는 핵심 요소이다. 하지만 여기선 쉽게 비유를 하고 있기 때문에 정확한 것과는 조금 거리가 있다. 조금 더 이해를 쉽게하기위해 우리가 시계를 만든다고 가정해보자.

- 시계바늘부터 렌즈까지 부품만 덩그러니 놓여 있다면 조립하는데 애를 먹겠지만 어떤 간단한 시계 모형을 주고 부품들만 바꿔 끼워넣으면 난이도가 훨씬 낮아질 것이다. 이 때 이 시계 모형이 프레임워크이다.

- 시계바늘과 렌즈 역시 내가 직접 재료를 가지고 만드려면 엄청나게 복잡하다. 이 때 전문가들이 렌즈 제작 도구, 시계바늘 제작 도구를 준다면 이 역시 엄청나게 편할 것이다. 이런 제작 도구들이 라이브러리이다.

- 단점은 주어진 시계 모형이 아날로그 시계라면 디지털 시계를 만들진 못한다. 마찬가지로 프레임워크는 같은 방식의 재사용성을 높인 구조이기에 커스텀에 한계가 있다. 또한 렌즈 제작 도구로 시계 바늘을 못 만들듯 라이브러리는 기능이 비슷한 자원들의 모임이기에 모든 분야에 쓸 수 있는 만능 도구가 아니다.

비유를 들어 설명했지만 앞서 말했듯 비유가 담지 못하는 제어의 흐름이 둘을 결정하는 주 개념이기에 더 자세한 내용은 앞선 포스트나 관련 글들을 참고하면 좋을 것 같다.

4. 다 지은 뒤 안전점검 등 완공 준비를 한다

- 집을 거의 다 지었고 외관이 완성되었다면 이 집이 설게대로 잘 지어졌는지 안전점검을 하고 완공을 한 뒤 시구청에 등록을 할 것이다.

* 집에 대한 안전 점검이 빌드 테스트 과정이고 집을 짓는 준비부터 실제 부동산으로 등록하는 과정까지를 빌드에 매핑할 수 있다.

#빌드(Build) : 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일.
컴파일 과정 역시 빌드에 포함된다. 우리가 흔히 보는 jar, exe파일 등은 소스코드를 빌드한 결과물의 예시이다.
실제론 빌드는 컴파일, 테스트, 패키징, 배포 등의 단계들을 모두 포괄하나 우선 위처럼 이해하자

5. 집을 분양한다

- 집을 다 지었으면 이 집에 사람이 살도록 분양을 해야한다.

* 건축 관련 인원이 아닌 실제 상품의 수요자인 주거인들을 client로 그 사람들이 집을 가질 수 있도록 분양하는 작업이 배포로 매핑할 수 있다.

#배포 : 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일.
배포에는 deploy, release, distribute가 있으며 deploy는 시스템에 소프트웨어를 설치/배포하는 과정,
release는 새로운 버전을 사용자에게 제공, distribute는 exe파일 등을 여러 사용자에게 배포하는 것이다.
일반적으로 웹 개발자에게 배포란 deploy가 된다.

이렇게 용어들을 살펴봤는데, 이 용어들을 알면 런타임, 컴파일타임에 대해서도 알 수 있다.

컴파일타임(compiletime) : 소스코드가 기계어로 변환되어 실행가능한 상태가 되는 과정
런타임(runtime) : 사용자가 프로그램을 실행하여 동작하는 과정

우리가 흔히 코드를 잘못 작성하여 컴파일 중 IDE에서 검출되는 에러의 경우 보통은 컴파일에러이며, 프로그램 실행 중에 예상치 못한 충돌이 발생하는 경우를 런타임에러라고 한다.

여기서 exception, error, bug, leg이 다 비슷하게 들리는 초심자를 위하여 간단히 정리하면

에러(Error) : 시스템적 문제(메모리 부족 등)로 발생한 오류. 
예외(Excepction) : 프로그래머가 예측하여 코드로 개선할 수 있는 오류. 
버그(bug) : 프로그램이 설계에 의해 의도치 않은 동작을 하는 오류.
랙(lag) : 일반적으론 정상 속도보다 떨어지는 경우를 말하지만 컴퓨터 용어론 latency(지연시간)와 혼용해서 쓰임.
네트워크 지연, 성능 저하시에도 사용됨

다시 본문으로 돌아가서 모든 작업이 끝난 뒤 유지보수하는 과정은 굳이 비유를 하지 않아도 될 것 같다. 차이가 있다면 집에 사는 사람들의 일거수일투족을 모니터링하고 모든 민원을 받는 역할까지 포함해야 server가 하는 유지보수의 영역이라고 할 수 있을 것 같다. 단순히 기능 추가나 버그 픽스뿐만 아니라 트래픽 관리, 보안 유지 등 해야할 업무는 빌드, 배포 과정만큼이나 녹록치 않다.

정리

지금까지 비유를 들어 백엔드 개발 과정의 일부를 설명했지만 앞서 언급했듯 이 과정은 정말 큰 윤곽에 불과하다. 실제 백엔드 개발과정은 API 요청이 들어오면 어떤 로직이 돌아서 무슨 응답을 해주며 그 과정에서 패킷, 라우터 등 웹 계층에 대한 이해와 HTTPS 통신 등 웹 통신 전반에 대한 지식을 동원하여 발생할 수 있는 버그를 고민해야 한다. 그렇기 때문에 다음 포스트는 백엔드에 대한 정보를 더 살펴보기에 앞서 웹 지식에 대해 살펴보겠다.