잡다한기술블로그

가상화 기술

• 클라우드가 전 세계적으로 인기를 끌 수 있었던 건 바로 가상화 기술 덕분
• 컴퓨터의 운영체제는 하드웨어 자원(CPU, 메모리)을 100% 잘 활용하지 못하므로 자원을 효율적으로 사용할 수 있는 기술에 대한 연구가 활발하게 진행 됨 -> 가상화 기술의 원천
• 가상화 기술은 하드웨어 자원(CPU, 메모리, 디스크 등)을 효율적으로 사용하기 위해 추상화라는 소프트웨어 기법을 통해 여러 개로 쪼개는 기술

• 도커,컨테이너는 수많은 가상화 기술 중 최근 가장 인기를 끌고 있는 기술로 최근 들어 컨테이너를 활용해서 클라우드에 서비스를 배포하는 경우가 많아짐
• 가상화 기술을 거치면 우리의 컴퓨터 자원을 효율적으로 사용할 수 있음
  • 여러 개의 운영체제를 이용해서 한 대의 컴퓨터로도 여러 사용자들이 동시에 이용할 수 있게 됨
  • 실제로 클라우드를 사용하는 사람들은 본인만의 컴퓨터 자원을 할당받아서 사용하는 것 같지만 사실은 하나의 컴퓨터 중에서도 일부 가상화된 자원을 할당받아서 사용함

Iaas, Paas, SaaS

• 클라우드를 제공하는 회사(Amazon, Microsoft, Google 등)에서는 데이터 센터에 보유하고 있는 수많은 컴퓨터들을 통해서 컴퓨팅 파워, 특정 프로그램 설치 및 실행, 소프트웨어 등을 제공

Iaas (Infrastructure as a Service)

• 컴퓨팅 파워 일부를 고객들에게 제공하는 서비스
  
  • 운영체제와 컴퓨팅 자원을 돈을 받고 빌려줌
  • 대표적으로 AWS의 EC2가 존재하며 많은 개발자들이 이를 이용해 OS, 자원(CPU, 메모리) 성능 등을 선택함
  • 비쌀수록 더 좋은 성능의 컴퓨팅 파워를 빌릴 수 있음

• 개발자들이 IaaS를 이용한다는 것은 컴퓨터를 가상으로 빌리는 것이 전부이고, 이 외에는 개발자가 전부 관리를 해야 하며 여기서 관리라는 것은 아래와 같은 것들이 존재
  • 프로그램을 실행하기 위한 환경 설치 
    • 결국 개발한 프로그램을 실행하기 위해선 실행할 수 있는 환경이 컴퓨터에 설치되어야 함
    • 예를 들어 java라는 프로그래밍 언어로 개발한 프로그램을 돌리기 위해선 이 프로그램을 실행할 수 있는 java 런타임이 설치되어 있어야 함
  • 컴퓨터의 상태를 모니터링해야 함
    • 웹 서비스같이 사용자들이 이용하는 웹 서버(컴퓨터)는 네트워크 트래픽에 예민하게 반응해야 함
    • 이벤트나 다른 특별한 이슈가 있을 때 트래픽이 갑자기 늘어난다면 컴퓨터의 자원이 부족해지고 성능은 저하되는데 이 때 모니터링을 하면서 컴퓨터를 스케일링하거나 다른 조치를 취해야 함
    • 네트워크 트래픽뿐만 아니라 자원을 많이 사용하게 되는 컴퓨터는 지속적인 모니터링 및 대처가 필요

PaaS (Platform as a Service)

• IaaS에서 나아가 특정 프로그램들을 설치하고 실행시킨 후 관리까지 해주는 것
  • 개발자들이 어플리케이션(프로그램) 개발에만 집중할 수 있게 해주고 컴퓨터 관리까지 제공
  • PaaS에서 자동으로 실행되는 프로그램을 업데이트하고 자원의 사용 정도에 따라 자동으로 스케일링 작업 진행
  • 대표적인 PaaS로는 AWS의 Elastic Beanstalk, Labmda 그리고 Google의 App Engine 등이 존재
• 대부분의 스타트업에서는 개발자가 부족하기 때문에 Paas를 사용
  • 보통 프로그램(웹, 앱, 서버 등)을 개발하는 작업을 제외하고는 대부분을 클라우드 PaaS에 맡기는 방식으로 진행

SaaS (Software as a Service)

• 위에서 다룬 IaaS, PaaS는 개발자들이 사용하는 서비스
  • IaaS, Paas를 이용해서 개발자들이 만든 소프트웨어를 실행시키고 이를 통해 새로운 서비스를 창출하는 형태
• SaaS(Software as a Service)는 클라우드 환경에서 제공되는 소프트웨어를 총칭함
  • IaaS, PaaS와는 다르게 아예 다른 개발자들이 만든 어플리케이션까지 함께 제공되는 서비스의 형태

• 대표적 SaaS인 Google Drive 사용을 생각해보면 컴퓨터의 성능을 전혀 신경 쓰지 않아도 되고 편하게 어플리케이션 기능(파일 업로드)를 사용 할 수 있음
  • SaaS를 잘 이용하면 개발자가 없이도 목적에 맞는 소프트웨어를 활용할 수 있음
• SaaS는 크게 2가지 유형 B2B SaaS와 B2C SaaS로 나눌 수 있음
  • 일반 사용자들이 사용하는 B2C 형태의 SaaS로는 구글 스프레드시트, MS 오피스 365 같은 소프트웨어 등이 있음
  • 기업이 사용하는 B2B SaaS로는 업무 협업툴 Slack, 쇼핑몰 구축 솔루션 Shopify, 모바일 앱의 채팅용 솔루션을 제공하는 SendBird 등이 있음
•  SaaS는 꼭 클라우드를 제공하는 대형 IT 회사들만 제공할 수 있는게 아니며, 작은 IT 회사들도 클라우드에서 컴퓨팅 파워(IaaS, PaaS 등)을 빌려서 새롭게 소프트웨어를 판매한다면 이는 모두 SaaS라고 볼 수 있음

Reference

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

개발자가 안된다고 하는 이유

• 개발자에게 어떤 특정 요구를 하거나 가능하냐고 물어봤을 때 안된다고 하는 경우가 많음

• 여러명의 개발자들이 한 프로젝트를 관리하다 보면 코드들이 점점 많아지고 읽기 어려워짐
• 배포까지 코드 빌드, 테스트, 리뷰, 통합 등의 프로세스를 거쳐야 함
• 바로 고쳐야 하는 오류(핫픽스) 등의 디버깅에 우선순위가 있음
• 위와 같은 이유들을 고려하여 개발자에게 요청해야 함

커뮤니케이션 TIP

• 개발의 프로세스에 대한 이해 없이 본인의 요구사항만 얘기하면 개발자는 답답할 수 있음
  • 긴밀한 협업을 위해서는 프로세스의 이해가 필요
• 무엇을 만들지 뚜렷해야 개발자가 설계하고 개발 공수(소요시간, 난이도 등)를 산정할 수 있으므로 요구는 최대한 구체적으로 해야 함
• 개발자가 왜 만들어야 되는지 이유를 납득해야 더 나은 개발을 할 수 있고 더 좋은 제품을 만들 수 있음

커뮤니케이션 예시

• 나쁜 예시
  • 구체적이지 않고 모호한 요청
• 좋은 예시
  • 정확한 상황 설명
  • 구체적인 필요 이유 설명
  • 개발 프로세스를 고려한 의사소통

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

인프라

• 인프라는 폭넓은 의미로 프로그램을 실행시키기 위한 환경을 의미
  • 프로그램을 실행시키기 위해선 하드웨어, 운영체제, 네트워크 등의 인프라(환경)이 필요.
  • 일반적으로 인프라 환경을 클라우드에서 많이 제공

코딩 컨벤션

• 코드를 관리하고 읽기 쉽게 만들기 위한 규칙

• 코딩은 어떻게 짜냐에 따라 형태가 다양할 수 있음
  • 위 이미지의 1번, 2번 컨벤션은 모두 똑같은 기능을 하지만 들여쓰기를 어떻게 하고 { 를 어떻게 배치하냐는 등은 개발자에 따라 다름
  • 개발자들이 점점 늘어날수록 코드의 통일성이 떨어지게 되므로 코딩컨벤션을 통해 코드를 어떤 형식으로 짜야하는지 정리함
  • 실제로 코딩 컨벤션은 위 예시처럼 뛰어쓰기, 들여쓰기 등의 짧은 코드의 마이너한 규칙부터 시작해서, 파일을 어떻게 배치하고 역할을 나눌지 등도 해당됨
• 린트(Lint): 코딩 컨벤션을 지키는데 도움을 주는 프로그램 툴
  • 코딩 컨벤션을 미리 설정해두면 개발자들이 코드를 짤 때 해당 컨벤션에 맞게 코드를 짜도록 도와줌

레거시 코드

• 개발자들은 현재 가장 나은 방향으로 코드를 짜지만 시간이 지나면서 개발 트렌드가 변화하거나 회사에서 새로운 방식으로 코드를 짜게 되면 이전에 짰던 코드는 구식의 코드인 레거시 코드가 됨
  • 실제로 에러가 나는 코드는 아니지만 비효율적이고 가독성이 떨어지는 코드일 수 있음
  • 이때 이 코드들을 현재 목적과 방향에 맞게 수정하는 것을 리팩토링한다고 함
• IT 회사에서는 현재 새로운 기능을 위해서 코드를 짜야하는 동시에, 기존에 있는 레거시 코드들을 어떻게 새로운 코드로 바꿔야 할지를 고민함

리팩토링

• 코드를 현재 방향에 맞게 코드를 새로 짜는 것을 의미
  • 과거 코딩 컨벤션 사용, 현재 트렌드와 맞지 않은 라이브러리 사용 등의 과거 레거시 코드를 현재 방향에 맞게 수정 하는 것을 뜻함
  • 리팩토링을 하는 코드들은 외부에서 봤을 때는 큰 문제가 없지만 동작이 제대로 되지 않는다는 것을 의미함
    • 시간이 지나면서 점점 수정하기 어렵고, 코드를 몇줄 바꾸려고 해도 쉽게 고치지 못하는 사태가 발생함

디버깅

• 개발된 코드에서 문제를 찾는 전체 과정을 의미
  • 코딩을 하다보면 에러(버그)가 나는 경우가 많고, 어떤 코드가 문제가 있는지 확인을 하고 수정해야함
  • 리팩토링이 코드를 현재 목적과 트렌드에 맞게 수정하는게 주목적이라면 디버깅은 있어서는 안될 오류들을 발견해서 수정하는 것이 주목적

의존성

• 개발된 코드들이 얼마나 서로 의존하고 있는지를 의미
  • 영어로는 dependency

• 일반적으로 로그인을 구현하기 위해서는 개발자들이 만든 로그인 라이브러리를 사용하게 되는데 이때, 로그인 동작 코드는 로그인 라이브러리 코드를 꼭 사용하게 되므로 의존성이 굉장히 높게 됨
  • 로그인 라이브러리가 만약에 에러가 나서 동작하지 않는다면로그인 코드는 마찬가지로 문제가 생기게 됨
• 의존성이 높다는 것은 그만큼 한 쪽이 문제가 생기면 다른 쪽도 문제가 생긴다는 걸 의미
  • 기본적으로 좋은 코드를 짜기 위해서는 의존성이 낮은 방향으로 코드를 짜야함

Json

• 데이터를 서로 주고받을 때 쓰이는 형식
  • 네트워크 통신에서 안에 데이터를 넣어서 보낼 때 데이터를 주고받기 위한 형식이 존재
  • JSON은 대표적으로 많이 쓰이는 데이터 형식
  • 사람이 읽기에 용이하다는 장점
  • JSON 이외에도 유명한 데이터 포맷으로 XML 존재

• 클라이언트는 API 서버에 정보를 요청하게 되고, 정보를 받아서 처리하기 위해선 API에서 어떤 데이터 형식으로 받게 될지 알고 있어야 함
  • JSON인지 XML인지에 따라 정보를 받은 클라이언트에서 데이터 처리를 다르게 해줘야 하기 때문
• 요새는 네트워크 통신을 통해 데이터를 주고받을 때 JSON 형식을 가장 많이 사용

SQL

• 데이터베이스에게 명령을 내릴 때 필요한 언어
  • 데이터베이스를 이용한다는 것은 필요한 데이터를 저장 or 삭제, 필요시 조회 등의 행위를 하는 것을 뜻함

• SQL은 폭넓은 의미로는 데이터베이스를 사용할 때 쓰이는 언어를 의미
  • 하지만 기술적으로 정확한 의미는 관계형 데이터베이스에서 사용되는 프로그래밍 언어임
  • 비관계형 데이터베이스(NoSQL)의 경우 해당 프로그램의 자체적인 프로그래밍 언어를 사용함
• 관계형 데이터베이스가 대중적으로 많이 사용되기 때문에 데이터를 다루는 직군들은 SQL을 알아야할 필요가 있음

관계형 데이터베이스 & 비관계형 데이터베이스

• 기본적으로 데이터베이스의 유형은 크게 관계형 데이터베이스와 비관계형 데이터베이스으로 나뉨

관계형 데이터베이스(RDB)

• 관계형 데이터베이스는 데이터들을 논리적으로 구분
  • 테이블은 각자의 역할을 가지며 동시에 다른 테이블들과 관계를 가지며 연결됨
  • 스키마를 통해 테이블에 어떤 값(필드)이 들어갈지 미리 정의
  • 스키마를 처음에 설계한 후 그 뒤에 테이블에 데이터를 추가

• 결제 테이블에는 결제 데이터(어떤 유저가 결제했는지, 어떤 상품을 결제했는지 등의 정보)가 들어가는데, 만일 결제 테이블에 유저 데이터, 상품 데이터 등을 전부 담는다면 테이블에 많은 데이터가 들어가게 되고 관리하기 힘듬
• 관계형 데이터베이스는 유저의 테이블에는 유저들의 정보, 상품 테이블에는 상품들의 정보만 저장하고 결제 테이블에서 어떤 유저와 상품이 연결되어 있는지 간단한 ID를 통해서 연결(관계) 정보를 저장함

비관계형 데이터베이스

• 비관계형 데이터베이스(NOSQL)는 관계형 데이터베이스와 다르게 스키마가 따로 존재하지 않음
  • 형식이 따로 정해져있지 않기에 형식에 얽메이지 않게 자유롭게 데이터를 추가할 수 있음

• RDB와 다르게 하나의 컬렉션(테이블)에 자유롭게 데이터를 넣을 수 있음
  • 예를 들어 결제 컬렉션의 데이터에 유저 데이터, 상품 데이터들도 자유롭게 넣을 수 있음
• 장단점 존재
  
  • 유연하게 데이터를 넣을 수 있다는 장점
  • 데이터들이 많아질 수록 형식이 다르다면 관리하기 어렵다는 단점
• RDB와 NoSQL은 데이터를 다루는 형식이 다르기에 어떤 데이터들을 주로 다루냐에 따라 선택이 달라짐
  • 실제로 회사에서는 상황에 맞게 두 데이터베이스 형식을 섞어서 사용

ERD

• 테이블간 관련성을 나타내고 동시에 테이블이 무슨 필드를 가지고 있는지를 알려주는 다이어그램
  • 보통 개발자들이 진행한 데이터베이스 모델링을 한눈에 보기 위해 ERD를 만듬

• 데이터베이스를 설계한다는 것은 보통 테이블을 설계하는 작업으로, 데이터 모델링을 하는 걸 의미
  • 데이터 모델링을 하면 결국 테이블의 개념 정의가 되고 동시에 서로 관련성이 생기게 됨

매니지드 서비스

• 개발자들을 대신해서 서버 관리를 해주는 것
• 일반적으로 서버를 관리한다는 것은 아래의 작업들이 필요
  • 환경 설정 서버를 실행하면서 필요한 설정(서버를 실행시키기 위한 코드, 연관된 다른 서버와 연결 작업)을 세팅
  • 안정성 서버에게 정보를 요청하는 횟수가 갑자기 느는 등의 갑작스러운 상황에서도 안정적으로 서버가 동작
• 과거에는 개발자들이 서버를 직접 관리해야 했던 반면, 기술이 발전하면서 이 관리를 직접 해주는 매니지드 서비스가 생겨나기 시작함
  • 개발자는 공수를 다른 곳에 쓸 수 있음
  • 대신 그만큼의 비용을 지출하게 됨
  • 적은 개발자 인력으로 많은 기능들을 제공하기 위해선 매니지드 서비스를 통해 효과적으로 개발하는 방식이 필요
• 요새는 많은 IT 스타트업에서 매니지드 서비스를 사용

크롤링

• 웹 사이트에 보이는 정보들을 데이터화 하는 것
  • 정보들은 HTML과 CSS로 보여짐
  • 크롤링을 이용하여 HTML에 있는 값, 이미, 텍스트 등을 데이터로 추출

노코드 툴

• 코드 없이 프로그램을 개발하도록 도와주는 툴

• 기술이 발전하며 개발자가 아니고, 프로그래밍 언어를 사용하지 않더라도 웹, 앱 등을 만들 수 있게 도와주는 기술이 많이 나오고 있음
• 앱의 완성도는 직접 코드를 작성하는 것보다 떨어지지만 간단한 웹사이트나 간단한 목적의 앱을 만드는 것은 가능

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

서비스 배포과정

• QA까지 정상적으로 마쳤다면 이제 사용자들이 사용하는 실제 환경에 적용하는 배포과정만 남음
• 일반적으로 개발자가 코드를 짜서 프로젝트에 코드를 합치는 작업들은 전부 개발환경에서 진행됨
  • 개인 컴퓨터를 통해서 프로그램을 실행시키고 코드를 작성하므로 실제 사용자들에게 영향 x
• 개발환경에서 짠 코드들이 실제 사용자들이 사용하는 운영환경에 업데이트가 되어야 하는데 이를 배포라 함
  • 운영환경: 웹 서버, API 서버, 앱 스토어 등 실제 사용자들이 사용하게 되는 환경(서버)
  • 배포: 개발환경의 코드를 운영환경에 프로그램을 실행시키는 일련의 작업

Example

• 프론트엔드 개발자가 웹을 개발한 후 웹 서버에 배포하는 작업 필요
• 백엔드 개발자가 API 서버를 개발한 후 API 서버에 배포하는 작업 필요
• 모바일 개발자는 모바일 앱을 개발한 후 앱 스토어에 배포(+심사)하는 작업 필요

CD (Continuous Deployment)

• 과거에 서비스를 배포하기 위한 프로세스는 다음과 같음

1. 원격으로 운영환경(서버)에 접속
2. 운영환경에서 실행되고 있는 서버 프로그램을 종료시킴
3. 원격 코드 저장소에서 프로젝트를 다운받음
4. 프로젝트를 빌드해서 서버를 실행시킴

• 위 방식은 수동적인 방식으로 운영환경의 컴퓨터들이 많다면 일일이 하나씩 접근해야 하며, 문제가 생기면 일일히 들어가서 수정해야 함
• 이를 해결하기 위해 배포 과정을 자동화하는 방식이 많이 나옴

• CD(Continous Deployment): 서비스를 자동화 및 연속적으로 배포 할 수 있게 해주는 것
  • CD툴 사용시 개발자들이 소스코드를 원격 저장소(github 등)에 올려놓기만 하면 자동으로 운영 환경에 배포까지 진행해줌
  • 보통 CI를 통해 코드가 정상적으로 원격 저장소에 합쳐지고, CD를 통해 원격저장소에 있는 소스코드를 운영환경 컴퓨터에 최종적으로 실행시키는 일련의 과정으로 CI/CD 라고 부름

배포 주기

• 보통 배포는 코드가 원격저장소에 합쳐질 때마다 하지 않음
• 회사마다 정해놓은 주기, 정책에 따라 배포함
  • 일반적으로 하루에 한번씩 배포
  • 에러가 생기면 빠르게 수정해서 바로 배포 -> 핫픽스(HotFix)

배포 후

• 프로덕트가 최종적으로 개발되고 배포된 다음 개발자들이 심어 놓은 로그 코드를 통해서 로그들이 쌓임
  • 로그 데이터를 바탕으로 마케팅, 데이터 분석, 버그 수정 및 디벨롭 등을 진행

 DevOps

• DevOps: 코드 작성, 통합, 배포하는 프로세스를 자동화하고 클라우드 환경에서 문제가 없도록 관리 해주는 직군
  • 실제로 위의 전체적인 프로세스를 자동화하기 위해선 개발 환경을 구축해줘야 하고 꽤 많은 리소스들이 듬
  • 개발자들이 더 좋은 환경에서 개발할 수 있도록 코드 작성 외에 전반적인 프로세스 자동화 및 클라우드 관리 작업을 DevOps가 도와줌

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

개발 코드 통합하기

• 개발자들이 제품 개발을 위해 코드를 다 작성한 후, 프로젝트에 코드를 통합하는 과정 필요
  • 웹, 앱, 서버 등 특정 목적을 수행하는 프로그램을 위한 소스코드들이 모여있는 공간을 프로젝트라고 하며 여러명의 개발자들이 하나의 프로젝트를 바라보고 코딩을 하게 됨
  • 최종적으로 코드가 합쳐져야 프로젝트에 제대로 개발자들이 짠 코드가 반영됐다고 할 수 있음

• 소스코드 빌드 & 테스트 실행, 코드 리뷰를 안(못)하는 기업들도 많음 -> 코드를 합치려면 코드 충돌만 해결해도 가능

프로젝트 빌드 & 테스트 실행

• 개발자가 짠 코드가 최종적으로 원격 프로젝트 저장소에 저장되기 전에 프로젝트 빌드와 테스트 실행이 먼저 실행됨
• 프로젝트 빌드: 개발자들이 짠 코드를 바탕으로 실행가능한 프로그램을 만드는 것을 의미
  • 개발자가 개발한 프로젝트는 사용자들이 이용하는 서버(웹, API 등)에서 제대로 실행되어야 함
  • 만약 프로젝트에 문제가 생기면 사용자들은 해당 서버를 이용할 수 없게 되어 큰 타격을 입을 수 있음
  • 따라서 업데이트된 프로젝트가 실제 유저가 이용하는 서버(운영환경)에 배포되기 전에 미리 가상 컴퓨터 공간에서 프로젝트를 빌드해서 실행시켜 보는 것이 중요
  • 이렇게 되면 문제가 생길 경우 미리 개발자들이 문제를 해결할 수 있게 되어 실제 서비스에 영향을 미치는 사태를 방지할 수 있음

• 프로젝트 빌드가 진행되면서 동시에 개발자들이 짜놨던 테스트 코드가 실행
  • 테스트 코드를 실행해서 통과되지 못한 테스트가 있다면 개발자들이 미리 확인해서 코드를 수정할 수 있음

CI (Continuous Integration)

• CI 툴: 프로젝트를 가상 환경에서 빌드(실행)해주고 테스트 코드도 실행시켜주는 자동화 툴
  • CI 툴은 내부 컴퓨터 환경에서 프로젝트 소스코드를 통해 프로그램을 실행시켜주는 프로젝트 빌드를 알아서 해줌
  • 프로젝트 빌드와 함께 테스트 코드 동작을 시켜 보며 문제가 없는지를 같이 확인해줌
  • 대표적인 CI 툴로 CircleCI, Travis CI 등이 있음
• CI 아래의 프로세스를 가짐
  • 코드를 짜고
  • 프로젝트를 빌드하고 테스트를 실행한 후
  • 프로젝트 저장소에 코드를 합침

코드 리뷰하기

• 보통 개발자들은 본인의 코드를 최종적으로 프로젝트에 반영하기 전에 코드리뷰를 거침
• 코드리뷰: 다른 개발자들이 직접 본인의 코드를 확인하는 과정
  • 코드를 보면서 에러가 날 수 있는 부분들, 회사의 코딩 컨벤션을 잘 지켰는지 등을 확인하고 리뷰를 남김
  • 리뷰 후 해당 리뷰를 코드에 적용하고 다시 리뷰를 요청하는 방식으로 진행
  • 보통 코드리뷰는 github이나 bitbucket 같이 소스코드를 저장하고 관리해주는 서비스에서 진행
• 개발자가 혼자거나 초기 스타트업은 코드리뷰를 하지 않고 빠르게 코드를 병합하기도 함

코드 충돌 해결하기

• 코드 충돌은 두 명 이상의 작업자가 동일한 파일을 작업했을 때 주로 발생
  • 하나의 프로젝트를 여러명의 개발자들이 개발하다 보면 같은 파일을 동시에 수정하는 경우가 많음
  • 보통 Git에서는 동일한 파일을 수정하더라도 알아서 코드를 병합해줌
  • 그러나 특정한 상황에서는 병합 과정에서 코드 충돌이 발생함
  • 그 때는 개발자가 직접 수정을 해서 코드를 병합해야 함
• 코드 충돌이 해결되면 업로드 후 코드 빌드, 테스트, 리뷰를 다시 거쳐 코드 충돌이 없는지 확인 후 코드 통합

QA

• QA: 최종적으로 개발자들이 열심히 짠 코드가 프로젝트에 적용되면 해당 제품이 잘 동작하는지 확인하는 작업
  • 보통 큰 기업에서는 QA 엔지니어 가 QA를 체계적으로 진행
  • 반면 규모가 작은 스타트업에서는 제품 팀에서 직접 사용해보며 문제를 찾음
  • QA를 하면서 기존 디자인에 맞게 잘 만들어졌는지, 버튼이나 API가 잘 동작하는지 등 개발된 제품을 전반적으로 확인
• 개발자들이 테스트 코드를 작성하는 것도 일종의 QA이긴 하지만 테스트 코드만으로 제품의 완성도를 평가하기는 어렵기 때문에 사람이 보통 추가로 QA 작업을 진행함
• 요새는 HBSmith 같이 QA를 자동으로 해주는 서비스들도 나오고 있음
• QA 작업을 해서 문제가 있는지 없는지를 확인하고 문제가 생기면 다시 코드를 고쳐 코드 통합 과정을 반복함

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

제품 개발하기

• IT 제품은 IT 서비스를 제공하기 위해서 만들어야 하는 웹, 앱, 서버 등 폭넓은 의미로 사용되므로 IT 회사에서는 서비스를 개발할 때 제품을 개발한다고 이야기 함

제품팀은 어떻게 구성될까

• 일반적으로 제품팀은 PM 혹은 PO, 기획자, 디자이너, 개발자가 한 팀이 되어 활동함

• PM은 Project Manager로 제품을 개발할 때 전반적으로 일정, 역할, 태스크 관리 등을 주도
• 기획자는 서비스 기획을 담당
  • 예를 들어 친구초대 이벤트를 진행하기로 했다면 기획자는 간단한 화면 구성(프로토타입)을 그려보는 동시에 친구 초대의 정책도 같이 기획함
• 디자이너는 UI/UX를 담당
  • 우리가 사용하는 모든 웹, 앱은 디자이너가 디자인한 화면을 개발자가 구현해놓은 결과물
• 개발자는 제품팀에서 나온 기획과 디자인을 바탕으로 실제 제품을 구현

• 요새 스타트업에서는 기획자 대신 PO, 디자이너, 개발자로 팀을 구성해 기획에 제품팀 모두가 참여하면서 각자의 역할을 주체적으로 부여하는 애자일 방식으로 진행
• 보통 기획자, 디자이너는 개발자와 커뮤니케이션을 잘 하기 위해서는 개발용어를 아는 것 뿐만 아니라 배경지식들을 잘 이해하고 있어야 함

비즈니스 로직 개발하기

• 기획자가 친구초대 정책을 기획하고, 디자이너가 그에 맞춰 디자인을 작업

개발자가 개발하는 과정 1

• 기획과 디자인이 어느정도 윤곽이 나오면 개발자도 코딩을 시작

• 프론트엔드 개발자는 프로토타입을 보면서 화면의 전체적인 구성을 미리 설계
  • 프로토타입에서 "A페이지, B페이지 추가" 등의 정보들이 들어있으면 프론트엔드 개발자는 디자인이 나오기 전에 화면 구성, 간단한 기능들 구현을 먼저 진행
• 백엔드 개발자는 기획을 토대로 데이터베이스와 API 서버를 개발
  • 친구 초대의 기능의 경우 회원가입한 유저는 어떤 친구를 통해 초대되었는지 데이터를 가지고 있어야 하므로 데이터베이스를 수정해야 함
  • 초대받은 친구가 가입했을 때 보상을 줘야 하므로 회원가입 관련 API 코드에 친구 초대관련 코드가 추가되야 함

• 프로토타입은 실제로 디자인 결과물이 나오기 전에 미리 전체적인 그림을 그려주는 역할
• 위 사진처럼 실제 페이지 구성이 어떻게 되는지, 버튼을 누르면 어떻게 가는지 등 프로세스를 담고 있음

개발자가 개발하는 과정 2

• 프론트엔드 개발자는 최종 디자인을 받아 구체적인 화면 구성 진행
  • 버튼, 텍스트, 이미지 등의 배치와 크기를 정하는 작업을 하고 백엔드 개발자가 개발한 API 정보를 받아서 사용
• 백엔드 개발자는 개발한 API를 직접 사용하면서 문제가 없나 직접 테스트
  • 기획과 다른 방향으로 API 코드가 동작하는지 등을 확인
• 실제로 회사마다 제품을 개발하는 프로세스가 조금씩 다를 수 있음

로그 수집

• 보통 IT 제품에서 로그를 수집
  • 로그를 통해 이번 제품 개발이 성과가 있는지 측정할 수 있음
• 프론트엔드 개발자는 '친구 초대 링크에 얼마 들어왔는지', '버튼을 얼마나 클릭했는지' 등의 유저 로그 수집
  • 유저 로그를 이용하여 유저들의 행동을 분석해서 더 나은 제품을 개발할 수 있음
• 백엔드 개발자는 서버 관련 로그 수집 
  • 서버 로그를 이용하여 모니터링 할 수 있음

데이터 트래킹

• 데이터 트래킹은 데이터를 추적하는 것을 의미
  • 사용자의 행동 데이터를 수치로 나타내기 위해서 구글 애널리틱스를 이용해 데이터를 수집하여 데이터베이스에 저장하는 것 
  • 일반적으로 유저들이 웹, 앱에서 행동하는 것을 로그 데이터 형태로 수집한 후 로그를 다루는 서버로 전송
  • 그래서 보통 제품 개발을 진행한 후 버튼 클릭, 페이지 진입 등 유저가 사용하는 특정 행동 리스트에 유저 로그를 수집할 수 있는 코드를 추가함

테스트 코드 작성

• 테스트 코드 작성 이유
  • 이 버튼이 눌렸을 때 API 호출을 잘 하는지, API 서버에서는 제대로 동작을 하는지 등 사람이 직접 사용하면서 문제점을 찾음
  • 이런 과정을 코드로 짜서 자동화 해놓으면 사람의 테스트 시간도 아낄 수 있고, 동시에 휴먼 에러(사람이 낼 수 있는 실수)도 줄일 수 있으므로 개발자들이 테스트 코드를 작성
  • 위 예시와 같이 친구 초대의 경우 "초대 링크로 가입을 했을 때 초대자가 무사히 포인트를 발급받았는지" 를 테스트 코드로 작성함
  • 테스트를 통과하면 친구 초대의 기능이 잘 동작한다는 것이고, 실패한다면 문제가 있다는 것이니 코드를 수정해야 함
• 테스트 코드 종류
  • 기능 테스트 or E2E 테스트: 위와 같이 사용자의 관점에서 기능이 잘 작동하는지 확인하는 테스트
  • 단위 테스트: 개발자들이 짜놓은 코드의 작은 부분들(함수, 클래스 등)을 테스트하는 것
  • 테스트 커버리지: 테스트 코드가 얼마나 적용되어 있는지를 이야기하는 것

TDD

• 테스트를 최우선으로 하는 개발 프로세스로 테스트를 먼저 작성해서 테스트를 통과하는 코드 위주로 개발하는 방법
  • 테스트가 있으므로 코드가 안정성이 있지만 개발하는 기간이 그만큼 길어지는 단점 존재

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

백엔드 개발자

• 백엔드 개발자는 IT 서비스에 필수적인 데이터들과 관련된 모든 프로그램을 관리하는 직군
  • 데이터를 저장하는 데이터베이스, 데이터를 처리하기 위한 API 서버, 파일들을 저장하는 스토리지 등

• 백엔드라는 영역은 실제로 굉장히 넓음
  • 작은 스타트업에서는 소수의 백엔드 개발자가 매니지드 서비스을 활용해서 백엔드 서버들의 환경을 구축함
  • 서비스의 규모가 커지면 방대한 양의 데이터와 데이터 요청을 다루기 위해서 많은 백엔드 개발자들이 필요해지며, 백엔드 개발자의 역할이 전문적으로 나뉘게 됨
• 백엔드 개발자는 다양한 역할을 하며 큰 회사일수록 그 안에서 전문 분야를 나눠서 맡음
  • API를 개발하는 API 개발자
  • 데이터베이스를 전문으로 맡는 DBA(데이터베이스 관리자)
  • 클라우드를 전문적으로 맡는 클라우드 엔지니어 등

API 개발

• API 서버는 클라이언트에게 요청을 받아 데이터베이스에서 적절한 데이터를 넘겨주는 역할

• 백엔드 개발자는 API 서버에서 클라이언트의 요청에 응답할 수 있도록 API를 개발함
  • 로그인, 회원가입, 상품 리스트 받기, 결제하기 등 IT 제품에서 사용하는 많은 기능들은  API 서버에서 나옴
• 서비스 규모가 커질 수록 API서버를 여럿 두어서 역할 별로 나누기도 함
  • 예를 들면 로그인, 회원가입 등 유저를 담당하는 API 서버와 결제를 담당하는 API 서버로 나눔
  • 이렇게 API 서버를 유형별로 잘개 쪼개서 관리하는 방식으로 마이크로 서비스라는 개념이 존재

데이터베이스 관리

• 데이터베이스에는 서비스에 필요한 모든 데이터들이 들어 있음
  • 당근마켓을 예로 들면 당근마켓 서비스는 유저, 상품, 결제 등의 데이터를 바탕으로 동작하게 됨
  • 이때 백엔드 개발자는 해당 데이터들을 개념적으로 구분해서 넣을 수 있는 테이블(공간)을 설계하게 하고 테이블 안에는 필드를 통해 데이터를 구분하게 됨

• 상품이라는 테이블을 만들 때는 이메일, 닉네임, 성별 등의 정보들을 저장할 수 있는 필드를 설계하며 이를 데이터 모델링 한다고도 함
  • 데이터베이스를 설계할 때 ER 다이어그램 을 이용해서 시각화를 할 수 있음
• 만약 나중에 상품의 할인 기능이 들어가게 된다면 백엔드 개발자는 할인 기능 관련 데이터도 들어갈 수 있도록 테이블에 새로운 필드를 추가해야 함
  • 서비스가 발전할수록 동시에 백엔드 개발자도 데이터베이스를 계속 수정하고 확장해 나가는 걸 의미
• 데이터베이스에 쌓이는 많은 데이터들은 API 서버를 통해서 이뤄짐
  • 유저의 회원가입, 상품 찜하기, 결제 등의 모든 데이터는 API 서버를 거쳐 데이터베이스에 쌓이게 됨
  • 이 때 API 서버에서 데이터베이스와 통신을 더 빠르고 쉽게 도와주는 ORM 이라는 것이 존재

서버 & 클라우드 관리

• 웹을 제공하기 위해서는 웹 서버가 필요하고, 데이터를 제공하기 위해선 데이터베이스 서버가 필요하며 클라이언트와 데이터 통신을 하기 위해선 API 서버 가 필요함
  • 이렇게 IT 서비스를 제공하기 위해선 결국 서버들을 관리해야 함
  • 요새는 서버를 쉽게 구축할 수 있는 클라우드를 대부분 사용

• 백엔드 개발자들은 클라우드를 이용해서 서버들을 구축함
  • 서버를 구축한다는 것은 컴퓨터에 클라이언트에게 정보를 줄 수 있는 서버 프로그램을 설치하는 것을 의미
  • 아무 것도 없는 컴퓨터에서 서버 프로그램을 설치하고 그 안에 개발된 코드를 실행시키는 것
• IT 서비스의 규모가 커지면 관리해야 하는 서버들이 늘어남
  • 수많은 클라이언트의 요청을 처리하는 API 서버를 돕기 위한 캐시 서버, 수많은 클라이언트 로그를 효율적으로 처리하기 위한 분산 처리 서버 등 목적에 맞는 서버들이 나오게 됨
  • 백엔드 개발자는 서버를 구축하는 것 뿐만 아니라 효율적으로 관리하기 위해 노력함

• 클라이언트가 많아질 수록 API 서버는 처리해야 하는 요청량이 점점 많아지게 되고 서버가 바빠지면서 응답하는 속도가 느려지게 되어 결국 유저에게 불편함을 주게 됨
  • 이를 방지하기 위해 백엔드 개발자는 로드밸런싱 방식을 적용해서 API 서버 환경을 개선할 수 있음(클라우드에서 쉽게 적용 가능)
• 백엔드 개발자는 서버를 효율적으로 관리하기 위해 노력함
  • 최소한의 비용으로 최대한의 효율을 내기 위함
  • 서버들을 효율적으로 잘 관리하기 위해서 백엔드 개발자들은 아키텍처 공부가 필요
  • 클라이언트 입장에서는 같은 데이터를 내려주는 건 변함이 없지만 아키텍처에 따라 응답 속도, 백엔드 개발자가 개발하는 속도 그리고 비용 등 많은 부분이 결정됨

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

프론트엔드 개발자

• 프론트엔드 개발자는 우리가 사용하는 웹 서비스를 개발
• 모든 웹은 HTML, CSS, Javascript 언어로 구성
  • HTML, CSS는 시각적으로 볼 수 있게 화면을 보여주는 역할(화면은 고정)
  • Javascript는 사용자들이 버튼을 클릭하거나 로그인, 결제하기 등의 동적인 기능을 사용하기 위한 역할
• 웹서버를 관리하는 건 보통 백엔드 개발자가 하지만 작은 기업같은 경우는 웹서버도 프론트엔드 개발자가 같이 관리

프로덕트 디자이너와 협업

• 프론트엔드 개발자는 보통 프로덕트 디자이너와 협업을 많이 하게 됨
  • 웹에 새로운 페이지를 만들거나, 페이지 디자인이 변경될 때 프로덕트 디자이너가 선행 작업을 함
  • 디자이너가 작업을 완료하면 프론트엔드 개발자는 이를 통해 간격, 색상, 크기 등의 수치를 확인하고 코드로 적용
• 대분의 IT 기업에서는 Zeplin , Figma 같은 협업용 UI 툴을 통해 프로덕트 디자이너와 프론트엔드 개발자가 협업하며, 프론트엔드 개발자는 UI 툴을 보면서 작업을 진행
  • Zeplin은 웹 디자인의 간격, 색상, 크기 등의 수치를 확인할 수 있으며, 코드로 바꿔주는 기능까지 제공

프론트엔드 개발자의 역할

• 실제로 웹 개발은 화면만 개발하면 되는 것이 아니며, 프론트엔드 개발자는 화면 작업과 더불어 웹에서 벌어지는 모든 일들을 도맡아 함
  
  • 사용자 관점과 다르게 소스 코드 관점에서는 페이지들이 코드로 연결되어 있기 때문
  • 예를 들어 로그인 기능은 로그인 페이지에서만 작업해야 하는게 아니라 다른 페이지들도 처리를 해야함
  • 즉, 프론트엔드 개발자가 화면을 HTML, CSS로 개발하는 것은 많은 태스크 중 하나
• 웹 퍼블리셔 직군의 경우 HTML, CSS 그리고 약간의 Javascript를 사용해서 화면 구성에 중점을 두고 작업을 하는 반면 프론트엔드 개발자는 화면 구성과 함께 웹의 전체적인 동작(로그인, url 처리 등)을 전부 관리

디자인 시스템 구축

• 서비스의 규모가 커지면 자연스럽게 화면이 많아지고, 화면이 디자인되어 나올 때 통일된 규칙이 있다면 더 빠르게 프로덕트 디자이너와 프론트엔드 개발자가 일할 수 있는데 이를 위해 나온게 디자인 시스템
  • 프로덕트 디자이너는 디자인 시스템에 자주 쓰이는 컴포넌트(버튼, 모달, 텍스트) 등의 간격, 크기 등을 종류별로 정리하여 페이지마다 새롭게 디자인을 하는 것이 아닌 디자인 시스템에 있는 것을 가져다 쓸 수 있음
  • 디자인 시스템에 맞게 프론트엔드 개발자는 재사용할 수 있는 컴포넌트를 미리 개발해두고, 디자인 시스템을 바탕으로 디자인이 나와도 손쉽게 개발된 코드를 사용함

웹 빌드 환경 관리

• 프론트엔드 개발자는 복잡한 웹 빌드 환경을 관리함
  • 프론트엔드 개발자들은 프레임워크를 많이 사용하며, 대표적인 프레임워크로 React, Vue, Angular가 있음
  • 프레임워크를 이용해서 짠 코드가 웹에 보여지기 전에 빌드 작업을 거치고, 나온 결과물을 웹서버에 올려서 브라우저로 전달
  • 빌드 과정을 거칠 때 Babel, Webpack 같은 특정 툴 사용
• 웹의 변화는 빠른 반면, 브라우저는 항상 통일되어 있고 결과적으로 똑같은 화면을 보여줘야 하기 때문에 빌드 환경이 복잡해질 수 밖에 없으며 프론트엔드 개발자는 이 복잡한 빌드환경 또한 관리해줘야 함

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

서버 스케일링

• 많은 사용자가 서비스를 이용할수록 서버에게 많은 요청이 가게 됨 -> 트래픽이 높아짐
  • 트래픽이 높아질수록 서버는 바빠지므로 요청에 응답하기 위해 해당 컴퓨터의 CPU, 메모리를 사용하게 되고 점점 자원이 남지 않아 결국 응답을 바로 못해주고 밀리게 되는 병목현상이 발생

• 이런 문제를 해결하기 위한 방법으로 스케일 업과 스케일 아웃, 크게 두가지 방법이 존재
  • 스케일 업: 해당 서버의 컴퓨터 성능을 높이는 것으로 CPU나 메모리의 성능을 높여 더 많은 요청에 대응할 수 있게 함
  • 스케일 아웃: 서버를 여러대로 늘리는 것으로 트래픽을 분산시켜 하나의 서버가 일하는 양을 줄여줌
  • 클라이언트에서 요청이 많아지면 자연스럽게 API 서버가 바빠지고 이와 맞물려있는 데이터베이스, 스토리지 등도 바빠지게 되므로 이들도 같이 스케일링 작업을 해줘야 함

• 클라우드는 자동으로 스케일링을 해주는데 이를 오토 스케일링이라고 함
  • 덕분에 서버 개발자들은 새벽에도 서버를 계속 모니터링(관찰)하지 않을수 있게 됨

• 로드(Load): 서버 입장에서 처리해야할 일
• 로드밸런싱: 스케일 아웃을 통해 로드를 분산시키는 과정
• 서버 스케일링 작업 외에도 캐시 서버를 사용해서 서버의 계산작업을 줄여줄 수 있음
• 실제로 IT 서비스에서는 서버의 부하를 줄이기 위해 여러 가지의 테크닉들을 사용

모니터링

• 모니터링: 서버의 컴퓨터 성능을 관찰하는 것을 의미
  • 서버가 높은 트래픽으로 인해 장애가 발생한다면 클라이언트(웹, 앱)도 정상적으로 사용이 불가능
  • 서버 컴퓨터의 상태를 지속적으로 점검할 수 있는 장치로 모니터링 장치가 필요
• 보통 트래픽이 많은 API(WAS)서버, 데이터베이스 등에 모니터링 도구를 붙여서 사용

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

클라우드란?

• 백엔드의 구성인 데이터베이스 서버, API 서버, 스토리지 서버 등은 전부 서버이고 하나의 프로그램이므로 전부 컴퓨터 안에서 동작함
  • 과거 웹 서비스 제공을 위해 웹/API/DB 서버 구축 및 네트워크 설정이 필수적이였음
• 현재 가상화 기술 기반의 클라우드 서비스를 제공하며 위의 모든 요소를 손쉽게 구축할 수 있게됨
  • 기존에 회사에서 관리해야 했던 컴퓨터들을 클라우드 회사에서 직접 관리
  • 사용자들은 본인의 컴퓨터에서 네트워크 접속을 통해 클라우드의 컴퓨터들을 사용

클라우드 특징

1. 사용자가 몇 번의 클릭만으로 온라인을 통해 서버 컴퓨터를 빌릴 수 있음

• 온라인으로 손쉽게 서버 컴퓨터를 빌리는 것을 서버 호스팅이라고 함
• 데이터베이스 같은 특정 프로그램이 미리 설치되어 있는 컴퓨터도 제공 가능
  • 개발자들이 프로그램을 설치하고 설정하는 시간을 줄일 수 있음

2. 컴퓨터 간의 네트워크 설정을 손쉽게 할 수 있음

• 기존에는 직접 네트워크 설정과 방화벽 설정을 작업해야 했던 반면, 클라우드 환경 내에서는 네트워크 설정들을 전부 작업할 수 있음
  • 기존에는 서버 컴퓨터들의 네트워크 관련 작업을 진행하는 네트워크 엔지니어가 필요
  • 클라우드는 컴퓨터에 일일히 직접 접근하지 않아도 됨
    • 데이터베이스는 API 서버나 관리자를 제외하고 접근할 수 없게 해야하는데 이런 작업들을 클라우드에서 손쉽게 설정 가능

3. 컴퓨터의 성능을 자유롭게 설정할 수 있음

• 클라우드에서는 자신이 원하는 옵션에 맞게 컴퓨터를 빌릴 수 있음
  • 서버는 클라이언트의 요청에 응답을 해주고, 보통 서버는 수백의 클라이언트 많게는 수천의 클라이언트를 상대하므로 수많은 클라이언트의 요청에 응답하기 위해 열심히 일을 함
  • 네트워크 관점에서 클라이언트의 요청량을 트래픽이라고 하는데 트래픽이 점점 많아지면 서버 컴퓨터가 할 일이 점점 밀리게 되고, 그러면 자연스럽게 성능이 저하되고 응답하는 시간이 길어지게 됨
  • 결국 더 많은 컴퓨팅 자원(높은 CPU, 메모리)이 있어야 안정적인 서버 운영이 가능해짐
• 클라우드에서 트래픽에 대응해 컴퓨팅 자원을 줄이거나 늘리는 스케일링 작업을 손쉽게 해줌
  • 쉽게 얘기하면 서버 컴퓨터를 늘려주거나, 성능을 높여줌

백엔드와 클라우드

• 대부분의 IT 기업들은 백엔드 서버들을 전부 클라우드 환경에서 관리
  
  • 웹을 제공해주는 웹서버, 데이터 통신을 위한 API 서버, 이미지 등의 파일을 관리하는 스토리지 서버, 로그들을 관리하는 로그 서버, 빅데이터를 저장하는 빅데이터 저장소(DB) 등 모든 서버를 전부 클라우드에서 쉽게 사용할 수 있도록 제공
• 대표적으로 많이 쓰이는 클라우드는 아마존의 AWS, 구글의 GCP, 마이크로소프트의 Azure, 네이버의 네이버 클라우드 등이 존재
  • IT 기업들이 가장 많이 사용하는 클라우드는 AWS
• 백엔드 개발자가 보통 클라우드 환경을 관리함
  • 보통 백엔드 개발자를 채용할 때 기업의 자격 요건을 보면 AWS를 잘 다루는 것도 포함됨

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

백엔드란?

• 프론트엔드는 폭넓은 의미로는 사용자가 서비스를 이용할 때 쓰게 되는 웹, 앱 등을 의미
• 백엔드는 서비스에 필요한 모든 데이터를 저장하고 다루는 공간

• 많이 사용하는 서비스들을 이용한 예
  • 네이버 - 회원가입한 유저들 데이터, 웹툰 데이터들, 카페 데이터들, 블로그 데이터들 등 수많은 데이터
  • 카카오톡 - 유저 데이터, 유저가 들어간 채팅방 데이터, 유저의 친구들 데이터 등 서비스에 필요한 많은 데이터
• 백엔드는 서비스에 필요한 데이터들을 저장하고 클라이언트(사용자, 관리자 등)에게 알맞게 데이터를 가공하는 역할

• 데이터를 가공한다는 것은 원형의 데이터들을 목적에 맞게 가공하는 걸 의미
  • 데이터들을 바탕으로 목적에 맞게 데이터들을 끌어와서 필요없는 건 빼고 필요한 건 살리는 작업

백엔드의 구성

• 프론트엔드는 보통 웹, 앱 등 특정한 프로그램을 하나 개발하면 되는 반면 백엔드는 여러가지 서버 프로그램들이 유기적으로 연결되어 있음

데이터베이스

• 데이터베이스는 서비스에 필요한 데이터를 저장하는 역할
  • 온라인 클래스를 제공하는 서비스라면 데이터 중에 클래스 관련 정보들을 저장하는 데이터베이스가 존재
• 데이터베이스도 데이터를 제공하는 서버이므로 즉, 하나의 서버 프로그램이고 운영체제(OS) 위에서 동작함

• 데이터베이스는 서비스에 필요한 중요한 정보들이 전부 들어으므로 철저하게 보안 유지 필요
  • IT 회사에서 데이터베이스가 해킹 당하는 경우, 회사의 모든 중요한 정보가 유출 됨
  • 데이터베이스에서 직접 정보를 가져올 수 있는 주체 제한 필요

API 서버

• 기본적으로 데이터베이스는 웹, 앱을 사용하는 클라이언트는 접근을 막는 대신에 클라이언트에게 대신 데이터를 전달해주는 API 서버에게는 연결을 허용해줌
  • 보통 데이터베이스는 외부 클라이언트의 네트워크 연결을 하지 못하도록 방화벽을 설정
  • 보안을 위해서 데이터베이스에 접근할 수 있는 건 API 서버(WAS 서버), 서비스 관리자 등으로 한정함
  • 이 때 보통 특정 IP주소를 허용하는 방식으로 데이터베이스 연결을 관리

• 위 사진처럼 API 서버는 데이터베이스의 데이터들을 가공해서 클라이언트에게 전달하는 역할을 함

• API 서버에는 다양한 API 요청을 처리하도록 개발됨
  • 위 사진처럼 로그인, 상품 정보 받아오기 등 다양한 요청을 처리할 수 있도록 백엔드 개발자가 API 서버 개발을 함
• 프론트엔드(웹, 앱)에게 데이터를 제공하는 API 서버를 WAS(Web Application Server)라고 하며, API 서버가 조금 더 넓은 개념이고 WAS는 프론트엔드에게 데이터를 건네주는 서버를 한정지어서 얘기함

파일 스토리지

• 스토리지 서버: 이미지 등의 파일들을 전문적으로 저장하는 서버로 파일들을 저장한 후 URL 주소를 통해 다운을 받는 방식
  • 대표적으로 우리가 사용하는 웹에서 이미지의 경우 웹 서버, API 서버를 통해 URL 주소를 전달받고 URL 주소를 통해 파일 스토리지에 접근해서 이미지를 다운받고 보여줌(이미지 자체를 받기에는 용량이 큼)
  • 실제로 데이터베이스에도 파일을 저장할 수 있지만 데이터베이스는 서비스에 필요한 핵심 데이터들, 즉 텍스트 위주로 이루어진 내용들을 다루는데 최적화되어 있음

캐시

• 캐시: 자주 쓰이는 정보를 저장해 놓는다는 개념
  • 보통 API 서버에서는 데이터베이스에서 정보를 꺼내고, 가공을 하는 작업을 하는데 이 때 API 서버에서 항상 동일한 결과를 제공해준다면 매번 데이터베이스, API 서버가 작업할 필요가 없음
  • 캐시 서버를 이용하면 API 서버와 데이터베이스가 일을 따로 하지 않고 바로 저장된 데이터를 제공해줄 수 있음

• 캐시 서버는 사용자와 가까운 곳에 임시 데이터를 캐시 형태로 저장하여 빠르게 제공
  • 정적 컨텐츠에 대해 활용도가 높음

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

모바일 앱 기본 지식

• 거의 모든 스마트폰의 OS는 android와 ios로 나뉘고, OS가 다르기 때문에 기본적으로 앱을 개발하는 방식이 다름
  • android는 java 혹은 kotlin 이라는 프로그래밍 언어로 개발
  • ios는 swift 혹은 objective c 프로그래밍 언어로 개발

• 웹은 HTML, CSS 코드로 화면을 그리는 반면, 모바일 앱을 개발할 때는 GUI 환경에서 화면을 짤 수 있음(프로그래밍 언어로도 화면을 구성할 수 있음)

• 스토어에 올라가기 전에 정상적인 앱인지 심사를 거치게 됨
• 심사는 사람이 직접 하게 되며 심사를 통과하고 나면 정상적으로 플레이스토어에 올릴 수 있게 됨

• 보통 앱 서비스를 내기 위해선 안드로이드는 구글 플레이스토어 , ios는 앱 스토어에 심사를 맡기게 됨
  • 구글 플레이스토어는 심사 시간이 빠르고 엄격하지 않음
  • ios 앱스토어는 심사 규격도 엄격하고 한 번 리뷰를 해주는데도 2~3일이 걸림
• 만들어진 앱은 공식적인 스토어(구글 플레이스토어, 애플 앱스토어 등)에서만 다운받을 수 있음
  • 애플은 ios 앱을 오로지 앱 스토어에서만 다운받을 수 있게 독점
  • 안드로이드는 오픈소스 OS로서 다른 스토어들에서도 앱을 다운받을 수 있음

IT 서비스에서 앱이 동작하는 과정

• 앱은 웹과 다르게 이미 모든 페이지와 코드들이 앱 내부에 들어가있으므로 웹처럼 웹서버에서 페이지와 코드들을 계속해서 다운받을 필요 x
• 앱에서 페이지가 로드된 이후 로그인, 찜하기, 프로필 정보 요청 등은 웹과 마찬가지로 API 서버가 필요
  • 앱과 API 서버의 통신과정을 자세하게 알고 싶을때, 스마트폰의 네트워크를 끄면 데이터를 받지 못한 상태의 앱을 볼 수 있음

• 위 상황은 API 서버에서 데이터를 받기 전 화면

1. 화면이 로드되면서 API 서버에게 마이페이지 관련 정보를 달라고 요청, 이 때 앱에 미리 저장되어 있는 로그인 관련된 데이터를 같이 담아서 요청
2. API 서버는 마이페이지 정보 요청을 확인하고, 요청에 해당하는 데이터를 응답으로 넘겨줌
3. 마이페이지 데이터를 받은 앱은 이를 바탕으로 코드가 실행되고, 결과적으로 완성된 화면을 보게 됨

• 보통 웹과 앱이 같은 서비스를 목적으로 만들어졌다면 하나의 API 서버와 통신해도 됨
  • 예를 들면 웹에서 찜하기 요청을 할 때 API와 앱에서 찜하기 요청을 할 때 API는 동일하다는 의미
  • '찜을 한다', '로그인을 한다' 는 동작은 동일하기 때문
  • 클라이언트(웹, 앱)은 API 서버가 무슨 일을 하는지 모르고 단순히 요청을 통해 결과를 받아오는 작업을 할 뿐임

웹 뷰

• 웹뷰는 앱에서 웹을 보여줄 수 있는 기능 (안드로이드, ios 모두 가능)

• 웹뷰를 사용하면 앱에서 웹을 띄울 수 있고, 웹뷰를 사용해 웹 서버와 계속 통신하여 계속 페이지를 변경할 수 있음
  • 웹은 기본적으로 웹서버에서 계속 다운을 받아서 사용할 수 있는 반면, 앱은 앱스토어에서 따로 업데이트 하지 않는 이상 내부 앱의 코드는 변경되지 않음
  • 특정 페이지에 웹뷰를 이용하게 되면 그 페이지는 웹 서버와 계속 통신 함
  • 웹 서버에서 웹을 업데이트한다면 변경된 웹을 앱에서도 사용할 수 있게 됨
  • 앱에서 웹뷰를 잘 활용한다면 정보를 더 효율적으로 보여줄 수 있게 됨
• 같은 서비스의 웹을 앱에서 웹뷰로 보여주는 경우 뿐만 아니라 앱에서 특정 웹을 참고해야할 때도 웹뷰를 많이 사용함(ex. 네이버 지도 기능, 구글 지도 기능 등)
• 스타트업에서는 앱에서 웹뷰를 많이 이용함
  • 웹 하나를 개발해두면 브라우저에서도 이용이 가능하고, 앱에서도 웹뷰를 통해 보여줄 수 있기 때문
  • 다만 웹이 앱에 비해 렌더링(화면을 보여주는) 속도가 느리기 때문에 유저가 불편함을 겪을 수 있다는 문제 존재

네이티브 & 하이브리드 & 크로스 플랫폼 앱 & 웹 앱 용어 정리

네이티브

• 네이티브 앱은 순수하게 Android, ios로 개발된 앱으로 개발자가 각각 프로그래밍 언어로 개발을 진행해야 함
  • 장점: 네이티브는 아래에 나오는 방식들(하이브리드, 크로스 플랫폼) 중 가장 성능이 좋음
  • 단점: 각각 다른 플랫폼이므로 따로 개발을 해야해 안드로이드, ios 개발자를 각각 구해야해서 리소스가 많이 듬,빠른 실행을 추구하는 스타트업에서는 선호하진 않음

웹 앱

• 웹앱은 실제로 모바일 앱이 아닌 웹으로, 앱 스토어에 올라가는 게 아니라 브라우저에서 접근할 수 있음
  • 즉, 그냥 웹인데 마치 앱처럼 꾸며놓은 웹
  • android, ios 관련 코드가 들어가는 게 아니라 HTML, CSS, Javascript(웹 개발 언어)가 사용됨

하이브리드 앱

• 하이브리드 앱은 네이티브 앱에 웹이 적용된 앱으로 쉽게 이야기하면 네이티브앱에 웹뷰 기술을 적용한 것
• 개발자들이 정의한 하이브리드 앱은 크게 2가지로 나뉨
• 1. 네이티브 앱을 개발하면서 웹뷰를 직점 심어놓은 형태
  • 네이티브 앱에 웹뷰를 사용해서 네이티브 + 웹의 장점을 골고루 살려서 만들어놓은 앱

• 2. 웹 기술(HTML, CSS, Javascript)를 기반으로 코딩을 하면 앱으로 만들어주는 기술
  • 웹을 개발할 줄 알면 앱을 만들어주는 기술로 아이오닉 프레임워크가 대표적
  • 아이오닉은 HTML, CSS, Javascript로 코드를 작성하면 네이티브 앱을 기반으로 웹뷰까지 자동으로 만듬

• ionic 프레임워크는 HTML,CSS,Javascript를 코딩하면 웹, 모바일 앱, 데스크탑 앱까지 한번에 만들어줌
  • 많은 앱을 만들어주는게 좋은 성능의 앱을 만들어주는 것과는 별개임
  • IT 기업은 웹, 모바일 앱을 한번에 만들 수 있기 때문에 초창기에 하이브리드 앱을 선호하지만 어느정도 규모가 커지면 하이브리드 앱에서 네이티브 앱으로 새롭게 넘어가는 추세
• 하이브리드 앱은 부르는 사람 마음
  • 네이티브 앱에다가 웹뷰를 조금 적용해도 하이브리드 앱이라고 할 수 있음
  • 앱의 대부분이 웹뷰로 구성되어 있어도 하이브리드 앱이라고 할 수 있음

크로스 플랫폼

• 크로스 플랫폼은 하나의 코드를 android, ios 네이티브 코드로 변환시켜주는 기술
  • 하이브리드 앱은 기본적으로 HTML, CSS, Javascript로 만들어진 웹을 웹뷰를 통해 사용하지만 크로스 플랫폼은 사용되는 언어가 네이티브 코드(android, ios 코드)로 변환되므로 웹과는 아예 무관한 기술
• 대표적인 크로스 플랫폼 프레임워크로 React Native, Flutter가 있음
  • React Native는 하이브리드 앱과 유사하게 HTML, CSS, Javascript로 코딩함(React 프레임워크 기반), 하지만 이 코드는 네이티브 코드로 바뀌게 되므로 하이브리드와는 다름
  • Flutter는 Dart라는 언어로 개발됨
• 크로스 플랫폼 앱은 결과적으로 네이티브 앱과 동일하게 만들어지므로 성능이 네이티브 앱과 큰 차이가 없음
  • 다만 크로스 플랫폼의 경우 Android, Ios에 대해 어느정도 기본적인 지식을 가지고 있어야 함

• 대표적인 크로스플랫폼 앱으로 인스타그램, 페이스북, 테슬라 등이 있음
• 크로스 플랫폼 시장에서는 React Native가 독보적
  • 웹 프레임워크인 React를 기반으로 개발이 가능하기 때문에 모바일 개발에 진입장벽이 상대적으로 낮은 편

웹과 앱의 차이

변경사항이 바로 반영되는가

• 웹: 브라우저에서 웹을 이용할 때는 계속해서 웹서버와 통신하면서 소스코드를 다운받으므로 프론트엔드 개발자가 웹을 업데이트한 후 웹서버에 적용시킨다면 웹을 이용하는 사람은 바로 업데이트 된 웹을 받아볼 수 있음
• 앱: 모바일 개발자가 앱을 업데이트한 후 앱 스토어에 올리기 위해서는 심사를 거치며, 심사가 통과하기 까지는 어느정도 시간이 소요됨

• 심사가 통과됐다고 하더라도 앱을 업데이트 하는건 사용자의 몫이므로 사용자가 반드시 최신 버전으로 업데이트해주지는 않음, 따라서 버전별로 사용자를 대응해줘야 함

• 앱 안에서 앱 업데이트를 유도하거나 강제할 수도 있음
• 하이브리드 앱에서는 웹뷰이기 때문에 빠르게 반영사항을 적용할 수 있지만 네이티브 앱, 크로스 플랫폼 앱에서는 변경을 적용하는데 시간이 걸림
  • 크로스 플랫폼 프레임워크인 React native에는 실시간으로 코드를 업데이트할 수 있는 Code Push 라는 기술이 있으므로 모든 코드를 다 업데이트할 수 있는 건 아니지만 좋은 기능임

스마트폰의 기능들을 얼마나 사용할 수 있는가

• 웹: 웹은 기본적으로 브라우저에서 동작하므로 브라우저의 환경에 종속적이여서 브라우저에서 제공해주는 기술만 사용할 수 있음
  • 파일 시스템 접근(스마트폰의 앨범, 음악 파일), GPS 같은 필수적인 기능들은 사용할 수 있지만 푸시 알림, 접근 권한 설정, 스마트폰의 센서 등 제한이 생김
• 앱: 앱은 기본적으로 모바일 OS 환경에서 동작되므로 스마트폰의 기능들을 전부 이용할 수 있음
  • 푸시 알림, 스마트폰 센서 등 전부 이용이 가능

• 앱과 앱끼리 서로 상호작용이 가능, 대표적으로 공유하기 기능
• 웹에서도 푸시 알림을 가능하게 하는 방법이 존재
  • PWA(Progressive Web App): 웹을 앱처럼 사용할 수 있게 도와주는 기술

• 앱은 웹과 다르게 스마트폰의 많은 기능들을 이용할 수 있어 앱에서 사용자의 정보를 몰래 접근해서 가져가는 보안 문제가 많이 발생하므로 안드로이드, ios에 대해서는 중요한 기능들(사진 앨범, GPS, 카메라 등)에 대해서는 사용자가 권한을 설정할 수 있게 강제하고 있는 추세
• 실제로 앱을 개발할 때 사용자가 어떤 권한(항상 허용, 한 번 허용, 거부)을 가지고 있냐에 따라 다르게 대응해줘야 함

딥링크

• 딥링크: 특정 페이지로 도달할 수 있는 링크를 뜻합니다.
  • 웹 혹은 앱을 사용하다가 링크를 클릭하면 앱이 실행되는 경험
•  모바일 딥링크: 앱의 특정 페이지로 도달하는 링크
  • 실제로 앱은 웹처럼 페이지의 주소가 따로 존재하지 않지만 딥링크를 이용하면 사용자가 보유하고 있는 앱으로 연결할 수 있음(앱이 없다면 앱 스토어로 연결시킬 수 있음)

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304