1. 자기소개(Ice Breaking)
학과/학년
컴퓨터공학부 소프트웨어전공 17학번, 3학년 2학기 재학 중입니다.
닉네임
제트
닉네임을 지은 이유
뭐로 할지 고민하다 책상 위의 '제트'스트림이 눈에 들어왔습니다.
배우고 싶은 것, 들어온 목적, 되고 싶은 모습 / 진로 등
개발을 할 땐 항상 배우게 됩니다. 저는 배운 내용을 바로 활용해서 무언가를 만들 때 정말 재미있다고 느껴왔기에 제가 배웠던 내용들을 활용할 수 있는 좋은 기회의 장이 될 것 같아 UMC에 지원하게 되었습니다.
진로는 현재 백엔드 개발자를 목표로 공부하는 중입니다.
좋은 서비스를 기획해서 멋지게 만들어 이 서비스를 정말 필요로 하는 사람들의 니즈를 충족시켜 주는 개발자가 되고 싶습니다.
활동지역?
서울 동작구 상도동 (집), 경기 성남시 분당구 이매동 (회사)
아침형/올빼미형?
아침형.. 00시 넘으면 집중이 잘 안되는 사망년입니다..
운동하는 거, 게임하는 거 좋아합니다. 요즘은 인턴 생활이랑 같이 병행하다 보니 학기 중 수업을 들을 때보다 덜 하긴 하지만 짬짬이 시간 내서 취미 생활을 이어가고 있습니다.
대학 입학 후부터 계속 미식축구부 활동을 하고 있습니다. 혹시 궁금하거나 관심 있으신 분들은 편하게 물어보세요!
2. 학습 목표
- 서버의 정의와 역할을 이해한다.
- 서버의 구성요소과 각 요소와의 관계를 이해한다.
- 서버가 어떻게 구축되는지 이해한다.
- 서버와 관련된 개념들을 이해한다.
3. 실습
1️⃣ 실습1. 비트나미를 통해 본인의 컴퓨터에 서버(APM) 구축해보기
https://opentutorials.org/course/3084/18893
생활 코딩 튜토리얼을 따라 하나씩 따라해봤습니다.
WAMP Stack 설치 화면입니다.
어떤 컴포넌트를 설치할 것인지 묻는 화면입니다. 저는 APM 환경만을 구축할 것이기에 다른 컴포넌트들을 체크 해제하여 설치하였습니다.
WAMP Stack의 설치 경로를 지정한 다음, WAMP의 M에 해당하는 MySQL 루트 계정 정보를 입력해줍니다.
WAMP Stack을 클라우드로 런칭할 것인지 묻는 화면입니다. 체크 해제를 한 후 넘어갔습니다.
localhost로 접속해보니 bitnami WAMP 스택이 잘 구동되고 있는 모습입니다. 기본 포트는 80이었습니다.
2️⃣ (과제) 실습2. 리눅스 개발환경 위에 APM 패키지 설치로 서버 구축해보기
과제의 목적
- 서버 개발자의 개발환경(CLI)인 리눅스에 익숙해지기 위함.
(리눅스 명령어, APM과 관련된 리눅스 파일구조 파악)
- 문제해결하는 방법에 대해 터득하는 것
(구글링, 공식문서, 블로그를 활용하여 원하는 것을 만들어본다.)
Tip
가장 좋은 것은 공식문서를 통해 구현하는 것. 하지만, 블로그나 구글링을 통해서 구현해도 좋다.
→ 모든 과정을 암기하는 것이 아닌 이해하고, 스스로 할 수 있는 것이 중요.
UMC Server Session 1주차 실습영상
📝 실습 체크리스트
4. 개념 키워드
핵심 개념 키워드
- 서버와 서비스
- 서비스 : 저는 서비스가 서비스 요청자(requester)가 비용(cost)이나 위험부담(risk) 없이 가치의 재생산을 하는 것이라고 생각합니다. 제가 카페에 가서 아메리카노를 한 잔 사먹는 행위를 예시로 들어보겠습니다. 이 행위에서 서비스 요청자인 저는 커피 원두를 기르고, 수확한 후 원두를 볶아낸 다음 커피 한 잔을 내리기까지의 과정에 해당하는 비용이나 위험부담에 대한 대가를 현금으로 지불한 것이 됩니다.
- 서버 : 서버는 서비스 요청자와는 정반대의 주체인 서비스 제공자라고 생각합니다. 서버는 요청자가 원하는 가치를 생산하기 위해 다른 가치들을 투입합니다. 카페의 예시를 들자면 커피 원두와 커피 기계를 사는 비용이 있을 수 있고, 커피를 내리는 노동력에 대한 비용, 카페 자체를 운영하기 위해 드는 임대료 등의 비용이 해당 가치입니다.
- 클라이언트 - 서버 관계
- 클라이언트 - 서버 관계는 요청을 보내는 주체가 누구인지에 따라 나뉩니다. 요청을 보내는 존재는 클라이언트, 요청을 받아 처리하고 응답을 다시 보내는 존재가 서버입니다. 이렇게 클라이언트 - 서버 방식을 사용하게 되면 몇 가지 장점이 있습니다.
- 하나의 서버가 요청을 처리하기 위한 모든 정보를 제어하기 때문에 데이터의 보호가 용이합니다. 따라서 사용자 인증에 있어서 강점이 있습니다.
- 클라이언트와 서버가 서로 밀접한 접근성을 가지지 않아도 데이터의 접근이 가능해집니다.
- 네트워크 세그먼트, 서버, 컴퓨터와 같은 자원들이 큰 제한 없이 추가될 수 있습니다.
- 서버의 동작 방식과 순서(요청이 들어왔을 때 서비스가 어떻게 처리되는가?)
- 서버는 크게 세 가지 구성요소로 이루어져 있습니다.
- 첫째는 클라이언트로부터 요청이 들어오면 이를 잘 정리해서 전달해 줄 웨이터 역할을 하는 서버 프로그램(서버 어플리케이션)입니다. 잘 알려져 있는 서버 프로그램에는 Tomcat, Nginx, Jetty 등이 있습니다.
- 둘째는 서버 프로그램으로부터 요청을 받으면 비즈니스 로직에 따라 요청에 알맞는 데이터를 잘 조합하고 가공해주는 요리사 역할을 하는 백엔드 랭귀지입니다. 현대에 와서는 목적과 필요에 따라 다양한 언어로 이 부분을 구성할 수 있습니다.
- 셋째는 서버 프로그램이 필요한 재료인 데이터를 그 때 그 때 제공해주는 냉장고, 창고 역할을 하는 데이터베이스입니다. 백엔드 랭귀지와 마찬가지로 다양한 솔루션을 사용하여 구성할 수 있습니다.
-
서버의 구조
-
Server Program
-
Back-end Language
- java - spring, spring boot
- javascript - node.js, express
- python - django, flask
-
DB, DBMS
-
SQL : 전통적으로 DB!하면 떠오르는 RDBMS입니다. 관계형 데이터베이스로, 구성된 테이블이 다른 테이블들과 관계를(RDBMS의 Relational) 맺고 있다는 점이 특징입니다.
-
NoSQL : 처리해야 하는 데이터의 규모가 점점 감당할 수 없을 정도로 커져서 등장하게 된 새로운 종류의 DB입니다. No라는 단어에서 느낄 수 있듯 테이블 간의 관계를 정의하지 않습니다. 따라서 테이블 간 Join도 할 수 없지만 성능 향상을 위해 분산 서비스에 적합한 Scale-Out에 강점이 있습니다.
- MongoDB : 많이 들어봤던 NoSQL DBMS입니다. 이름은 친숙하지만 정작 사용해본 적이 없어서 추후에 이 놈을 사용해서 프로젝트를 구성해보고 싶습니다.
- redis : 게임 랭킹과 같은 실시간으로 상대적으로 가벼운 데이터를 처리할 때 용이합니다. 거대한 캐시로 이루어진 DBMS와 같아서 고속으로 입출력이 가능하지만 결국 캐시 서버이기 때문에 in-memory 관리에 유의해서 사용해야 합니다.
- Cassandra : CQL이라는 쿼리 언어를 사용하는 NoSQL DBMS입니다.. 처음 들어봐서 추후에 또 공부가 필요할 것 같습니다.
- APM : Apache, PHP, MySQL를 묶어 부르는 말입니다. Apache는 웹 서버로 앞서 설명했던 서버 프로그램에 해당합니다. PHP는 서버 사이드 언어로 백엔드 랭귀지에 해당됩니다. 같은 맥락으로 MySQL은 RDBMS 중 하나로, 데이터베이스에 해당합니다. APM은 수십 년 동안 인기 있는 웹 개발 기술 스택이었고, 현재는 전보다 인기가 덜 하지만 여전히 전 세계에서 많이 사용 중입니다.
- 비트나미 : 비트나미는 어플리케이션을 설치할 때 귀찮은 과정들을 생략하고 바로 서비스를 이용할 수 있도록 이용자가 쉽게 어플리케이션을 설치하게 도와주는 프로그램입니다.
- 로컬호스트(localhost) : 네트워크에서 자기 자신을 지칭하는 호스트명입니다. IPv4에서는 127.0.0.1, IPv6에서는 ::1(0:0:0:0:0:0:0:1) 입니다.
-
가상머신(Virtual Machine) : 물리적인 컴퓨터 위에서 프로그램을 돌리는 대신 가상의 컴퓨터인척하는 프로그램 위에서 운영체제를 포함한 프로그램들을 구동하는 환경입니다.
-
Linux, Ubuntu : 리눅스는 리누스 토르발즈가 개발한 리눅스 커널을 기반으로 하는 운영체제입니다. GNU 라이센스 하에 오픈소스로 공개되었기 때문에 여러모로 널리 사용되는 운영체제 중 하나입니다. 우분투는 데비안, 페도라와 같은 유명한 리눅스의 배포판 중 하나입니다.
-
리눅스 디렉토리 구조 : 리눅스는 트리 형태의 파일 시스템 구조를 가집니다. 간략하게 자주 접했던 디렉토리들은 다음과 같습니다.
- /: 루트 디렉토리입니다. 트리의 루트 노드라고 생각하시면 될 것 같습니다.
- /boot: 리눅스의 부트로더가 있는 디렉토리입니다.
- /bin: mv, ls, rm 등 기본적인 명령어들이 들어있는 디렉토리입니다.
- /usr/local: MySQL과 같은 서비스들이 설치되어 있던 디렉토리였던 것 같습니다. 찾아보니 어플리케이션들이 소스로 컴파일 설치될 때 사용되는 곳이라고 합니다.
- /etc: 시스템 설정 파일들이 있는 디렉토리입니다. /etc/init.d에는 커널 초기화 이후 가장 처음으로 실행되는 프로세스인 init이 서비스를 조작할 수 있는 쉘 스크립트들이 위치해 있습니다.
- 리눅스 명령어, vi(vim) 편집기 사용법 : 추후 포스팅에서 더 자세히 다루겠습니다.
추가 개념 키워드
-
Web Server(WS)와 Web Application Server(WAS) : 검색하던 중 좋은 포스팅이 있어 공유합니다. https://victorydntmd.tistory.com/121
- 요약을 해보자면, WS와 WAS는 제공하는 컨텐츠가 다르다는 점이 둘을 구분합니다. nginx와 같은 WS는 정적 컨텐츠 (html + css + js)를 제공하고, tomcat과 같은 WAS는 동적 컨텐츠 (DB CRUD 및 관련 비즈니스 로직)을 제공합니다.
그동안 tomcat을 사용하면서 WAS가 정적 컨텐츠를 제공함에 있어 당연한 것이라고 생각해오고 있었는데, 대부분의 WAS가 정적 컨텐츠 또한 제공하기 때문이라는 비하인드가 있었다는 점이 신기했습니다.
-
운영체제(OS)
- 초창기 컴퓨터는 현대의 컴퓨터에 비해 굉장히 한정된 리소스를 가지고 있었습니다. 메모리도, CPU도 한정되어 있고 사용에 따른 비용도 발생했기 때문에 사람들이 '어떻게 하면 주어진 리소스를 잘 활용할 수 있을까?' 라는 고민에서 시작된 것이 운영체제입니다.
- 운영체제는 따라서 컴퓨터의 모든 것을 관리하는 시스템 소프트웨어입니다. 하드웨어인 CPU, 메모리, 각종 입출력 장치와 저장장치 뿐만 아니라 프로세스들을 잘 스케줄링해서 마치 동시에 수행되는 것처럼 느끼게 해줍니다.
- 현대에 와서는 소프트웨어들이 이전과는 비교할 수도 없을 정도로 복잡해졌습니다. 이런 요구를 만족시키기 위해 운영체제는 소프트웨어를 따라 고도화된 하드웨어를 최적화하여 수백, 수천만원의 장비를 좀 더 효율적으로 사용하게 해줍니다. CUDA와 같은 소프트웨어를 사용하여 딥러닝 연산을 처리하는 것이 예시라고 할 수 있습니다.
- Windows, MacOS : 운영체제의 한 종류입니다. Windows는 Microsoft 사의, MacOS는 Apple 사의 OS입니다.
-
CLI와 GUI
- 인터페이스 : 인터페이스는 컴퓨터 시스템에서 서로 다른 여러 구성체들이 모여 데이터를 교환하기 위한 만남의 광장입니다. 컴퓨터 안팎에는 굉장히 많은 구성 요소들이 존재하기 때문에 만나서 정보를 교환하려면 미리 약속을 정해놓는 겁니다.
'이번 주 토요일 13시에 강남역 11번 출구 앞에서 만나자!' 라고 약속해 놓으면 길을 잃어버리거나 약속 상대가 어디있는지 전화를 하는 번거로움이 없는 것과 비슷합니다.
- GUI : Graphic User Interface입니다. 대부분의 사용자는 컴퓨터에 대한 전문적인 지식이 없기 때문에, 사전지식이 필요없어도 아이콘이나 버튼과 같은 요소를 통해 컴퓨터를 다룰 수 있게 그래픽으로 데이터들을 약속해 준 것입니다.
- CLI : Command Line Interface입니다. 초창기부터 컴퓨터를 다룰 때 사용해왔던 약속으로 터미널과 명령어들을 사용하여 데이터를 다룹니다.
-
HTTP : HyperText Transfer Protocol입니다. MDN Docs에 잘 설명되어 있었습니다. https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
-
패키지 설치와 컴파일 설치
- 패키지 매니저 : apm, yum과 같은 툴들이 예시입니다. wikipedia에서는 컴퓨터의 프로그램의 설치, 업그레이드, 구성, 제거를 자동화하는 도구의 집합체라고 설명하고 있습니다. 자바스크립트 패키지 매니저로 널리 사용되는 npm도 Node Package Manager입니다.
- 컴파일 설치 : 소스 코드를 컴파일 및 빌드하여 소프트웨어를 설치하는 방법을 말합니다. 모든 소프트웨어는 소스 코드를 바탕으로 빌드 된 결과물인 바이너리 프로그램을 기동하는 식으로 동작합니다. 패키지 매니저를 사용하는 경우에는 이 과정이 자동화되어 있기 때문에 굉장히 쉽게 이루어지는 것'처럼' 보입니다. 소프트웨어를 컴파일 설치하는 경우는 패키지 매니저를 사용하는 것에 비해서 세부적으로 옵션을 가하여 설치할 수 있다는 장점이 있습니다. 또 많은 회사에서는 보안 상의 이유로 패키지 매니저를 사용할 수 없기 때문에 컴파일 설치의 방법은 항상 숙지하고 있어야 한다고 배웠습니다.
cmake
와 make
같은 툴들을 사용해서 이루어집니다.
5. 논의해보면 좋은 것들
Warming Up
- 소통과 개발의 중요성
- 라이트한 프로젝트라면 모르겠지만, 대부분의 프로젝트는 개인이 혼자 할 수 있는 규모가 아닙니다. 적게는 3~5명, 많게는 수 백명, 잘 알려진 오픈소스 프로젝트 같은 경우에는 몇 천명이 동시에 프로젝트를 진행하기도 합니다. 예시로 tensorflow의 github contributor 수는 2021년 9월 말 기준 3000명입니다. Tensorflow Github
- 따라서 개발을 '잘'하기 위해서는 협업을 '매우 잘'해야 한다고 생각합니다. 협업을 잘하기 위해서는 협업을 하는 타인과의 소통이 매우 중요합니다. 대학교 조별과제는 기껏해야 3학점 정도만 걸려있지만, 개발을 생업으로 최전선에서 코드를 작성하고 배포하는 개발자라면 오히려 개발 스킬보다, CS 지식보다, 소통이 잘 되는 사람이 더 도움이 될 수 있겠다는 생각을 요즘하고 있습니다.
- 스스로를 소통이 잘되는 사람이라고 생각하는가? 이유는?
- 자기객관화를 잘 못하는 저는 대체로 소통을 잘한다고 생각하지만 문득 돌이켜보면 그동안 아쉬움이 있었던 부분이 문득 떠오릅니다. 저는 일에 답답한 부분이 생기면 제가 혼자 많은 부분을 떠맡고 처리하려고 하는 나쁜 습관이 있습니다. 이런 습관은 잠깐 하고 말 프로젝트라면 상관 없었지만 지속적으로 소통하며 어려운 부분이 생겼을 때 내가 그룹 내에 도움을 처하려 할 때 꺼려지게 했던 경험이 있습니다. 이는 그룹의 성장을 저해하는 소모적인 습관입니다. 스스로도 의식하며 소통을 막는 나쁜 버릇을 고치려고 노력 중입니다.
- 추가로 함께 일하고 싶은 개발자/사람의 특성은 무엇이 있을까요?
- 소통이 잘 되는 것이 함께 일하고 싶은 사람의 가장 중요한 특성이라면 그 다음은 공동 문화에 잘 스며드는 것이라고 생각합니다. 개인의 개성을 해치지 않는 선에서 조직의 공통적인 규칙을 잘 지키고, 건설적인 문화를 만드는데 일조하는 사람이라면 내가 상급자여도, 하급자여도 믿고 같이 업무를 할 수 있는 사람이라고 생각하기 때문입니다.
Server
- 세상에는 어떤 종류의 서버스들이 있고 거기에 서버란 어떠한 것을 제공해줄까요?
- 요즘엔 이전보다 상당히 세분화된 사용자층을 겨냥한 서비스들이 생겨나고 있습니다. OTT 서비스가 그 예시라고 생각합니다. 국내에만 하더라도 왓챠, 넷플릭스, 티빙, 씨즌 등등 굉장히 많은 양질의 영상 스트리밍 서비스들이 운영중입니다. 흥미로운 점은 각 서비스들이 지향하는 바가 조금씩 다르기 때문에 각자가 서비스하는 컨텐츠 또한 달라지고, 다양해진 컨텐츠 풀, 곧 다양해진 서비스가 다시 신규 사용자를 유도한다는 점이었습니다. 이러한 서비스들에서 서버는 서비스를 제공하는 주체입니다. 서비스 자체도 SaaS, PaaS등 종류가 다양해지고 있기 때문에 앞으로 좋은 서버 개발의 수요는 점점 더 늘어날 것이라는 개인적인 견해입니다.
- 본인이 만들고 싶은 서비스와 서버가 있나요? 있다면 무엇인가요?
- 본인이 생각하는 좋은 서버란? 좋은 서버가 갖추어야 하는 조건은 무엇인가요?
- 제가 생각하는 좋은 서버는 서비스를 잘 제공하는 서버입니다. 잘 제공한다는 것에는 여러가지 의미가 있겠지만 3가지 정도로 추려 볼 수 있을 것 같습니다.
- 서비스를 안정적으로 제공하는 서버
- 서비스를 빠르게 제공하는 서버
- 서비스를 안전하게 제공하는 서버
인턴 활동을 하면서 계속 느끼는 거지만, 개인적으로 3->2->1로 갈 수록 구현하기 더 어려워지는 것 같습니다. 세 가지 조건을 모두 충족하는 서버를 만드는 것이 절대로 쉬운 일이 아니라는 것을 알아가고 있기 때문에 공부를 더 열심히 하게 되는 계기가 됩니다.
- 실습 과제를 수행하면서 배운 것들, 공유하면 좋은 것들
- 실습 과제를 수행하며 배운 것들을 이 velog에 공유하려고 합니다. 이외에도 개인적으로 공부를 하며 느끼거나 배운 것들을 적어 추후에 비슷한 어려움에 부딪혔을 때 self reference가 되는 것이 가장 좋으니까요!