그새 이런저런 일도 많았고, 회사도 옮기고, 팀원이 증가해서 뭔가 완성된 하나의 팀이 된 느낌이다. 원래는 웹디자이너(1), 백(1) 이였다가 웹디자니어(1), 백(1), 프론트(1)로 증가되고, 최종으로 현재 인원은 웹디자이너(1), 기획(1), 백(2), 프론트(2)로 뭔가 규모도 커지고 팀이 정해진 느낌이다. 이 후 3번의 회의시간도 갖고 서비스 자체에 퀄리티를 키우면서 뺄꺼 빼고 추가할꺼 추가하면서 서비스가 완성되어 가고 있는 상황이다.

새로들어오신 백엔드분이 정말 똑똑하시고 네스트에 대한 애정이 넘치신다. 너무 감사하다. 실무에서 여러가지 기술들을 배우고 프로젝트에 적용 시키는모습이 멋있으셨다. 페어프로그래밍? 이라는 두명이서 같이 하는데 한명이 코딩을 하고 한명은 옆에서 보면서 피드백해주는 그런 코딩 방법을 알려주시면서 해봤는데, 도움도 많이 되고 그분도 도움이 됐다고 하시면서 훈훈하게 같이 코딩을 했다. 앞으로도 많이 배우고 도움도 드려야 겠다!

부트캠프 수료 후 사이드프로젝트를 하면서 공부도 하고, 구직도 참 열심히 했다. 그래서 간간히 공부와 사이드프로젝트를 하면서 보고 배우는것들로 포트폴리오를 채워가면서 구직에 성공했다. 기쁜 마음으로 회사를 다니면서 부족하거나 배우고 싶은 공부들을 열심히 하면서 만족감에 살고 있었다. 그렇게 회사를 다니던 목요일(23.05.04)에 사건이 발생했다..

18시에 퇴근을 하고 집에 가려고 짐을 싸고 가려고 하는데 대표님께서 잠깐 보자고 하셨다. 무슨일 일까 내가 잘못한게 뭐가 있지 생각하면서 대표님 방으로 들어갔다. 대표님께서 뭔가 미안하신 표정을 짓고 계신 느낌이였는데 그 느낌이 딱 맞았다.

들어가자마자 한숨을 쉬시면서 미안하다고 하는 것이다. 뭐지?.. 생각하다가 바로 말씀해주셨다. 자기는 어떻게 해보려고 했는데 더이상 힘드시다며 회사를 가족끼리만 운영해야 할 것 같다고 얘기하시는거다..(순간 마음이 쿵 하고 떨어진 기분이였다.) 나는 침착하고 일단 얘기를 들었다. 적자가 너무 심하게 나서 월급을 못 줄거 같아서 그냥 본인이 운영하고 가끔 에러 핸들링 해주는대신 알바비를 조금씩 주신다는 것이였다..

이런 상황은 처음이라 당황스러웠다. 뭔가 서류를 꺼내시면서 나한테 보여주셨는데 작년부터 마이너스 였던것이였다.. 그 숫자들을 보면서 감정이 복잡해졌다 ,, 뭐 어떻게 할 상황이 아니다. 빠르게 내일부터 아니 당일부터 구직을 다시 해야 한다는 생각이 들었다. 그렇게 미안하다는 말만 반복하시다가 면담이 끝났고 집에 도착해서 바로 포트폴리오 추가할거 추가하고 공고를 보다가 잠에 들었다.

우선 우리 팀의 상황이 백엔드(본인)1, 웹디자이너(용진님) 이렇게 둘 뿐이였고, 용진님은 피그마로 작업을 하셨고 나는 백엔드 기능 구현을 하고있었다. 그러던 용진님이 슬슬 프론트 구직 글 올려 보겠다 하시고 난 후 2일 만에 3분 한테 연락을 받았다고 했다. 그중 1분이 서울에서 일하시고, 말도 잘 통하는 느낌이라고 하셔서 한번 만나서 회의를 해보기로 했다.

그래서 단톡방을 만들어 기본적인 것들 서로 질문하고 대답 하는 시간을 가졌다. 난 나름대로 나쁘지 않은 흐름이라고 생각했다. 이 후 회의장소, 시간을 정하고 설렘반, 떨림반의 마음을 갖고 회의장소로 발걸음을 옮겼다.

드디어 첫 사이드 프로젝트에 첫 회의이다. 용진님은 살짝 늦는다고 하셔서 처음에는 프론트엔드 분이랑 둘이 있었다. (나는 보통 어색한걸 싫어해서 어색한 상황이 연출이 되면 어색함을 적극적으로 깨려고 하는 편이다.) 내가 먼저 말을 걸었다. 저녁은 먹었는지 오는데 얼마나 걸리는지 등의 기본적이면서 아이스브레이킹을 할 수 있는 말들로 시작을 했고, 어느정도 어색한 분위기가 사라진것 같았을 때 프로젝트에 관한 질문들을 했다.

우선 배포하기 전이라 로컬에서 Docker로 서버를 키고 GraphQL DOCKS를 보여드렸다.. 내가 만든 기능들을 보여준다는 것은 오묘한 느낌이 든다. (뭔가 내가 만든 음식을 다른사람한테 보여주는 느낌?) 속으론 엄청 떨렸다. 떨린 이유중에 제일 큰 이유는 프론트엔드분은 실무에서 1년반 정도 하시고 계셨을텐데 그러면 현직 백엔드 개발자의 코드들을 보시다가 내 코드를 보셔서 상당히 떨렸다.

그렇게 보시다가 몇가지 물어보셨고, 아는 상식선에 대답 하고 있을 무렵 용진님이 오셔서 상황은 마무리 되었다. 그렇게 첫 회의가 시작됐고 용진님이 노션으로 회의 기록을 해가면서 회의를 진행하였고, 용진님이 작업하신 피그마를 다같이 보면서 방향성 또는 건의사항들을 서로 말하면서 회의를 계속 진행했다. 진행하는 중간중간에 괜찮은 아이디어도 나오고 기능추가, 삭제도 되가는게 나쁘지않은 느낌이였다. 같은 곳을 바라보고 가는 사람들의 힘은 작지 않다는 것을 느낀 회의였다. 그렇게 2시간이 순식간에 흘렀고 첫 사이드 프로젝트의 첫 회의는 나에겐 성공적으로 끝난 것 같아서 피곤해도 기분좋게 집을 갈 수 있었다.(파도에 휩쓸리다보면 언젠가 파도속에서 내가 방향을 잘 잡을수 있지 않을까라는 생각이 들었다.)

docker-compose build로 빌드부터 해야하는데 처음부터 막혔다.

우선 첫번째 에러 발생 아니 나는 다 잘 맞춰준거 같은데 뭐지 하면서 처음엔 vs 코드 렉 인줄 알았다. 그래서 재부팅해서 했는데 당연히 안됐다. 내가 보기엔 뭔가 16.14버전을 14.21.3버전으로 바꾸라는 말 같아서 구글링을 해봤는데 sudo n 이라는 매우 유용한 명령어를 알았다. sudo n => 활성화 시킬 Node.js 버전 변경 sudo n ls => 현재 설치된 Node.js 버전 확인 sudo n install {버전} => 특정 버전의 Node.js 설치 sudo n rm {버전} => 특정 버전의 Node.js 제거 부트캠프때 배웠던 기억으로는 sudo는 관리자 권한으로 강제적으로 하라는 명령어라고 알고있다. 암튼 여기서 내가 신기했던 점은 노드 버전을 여러개 다운을 받고 프레임워크 라이브러리 버전의 호환성에 따라 버전을 바꿔 가며 쓸 수 있다는 점이였고, 신기하고 유용했다. (개발세계는 파면 팔수록 신기한 것들이 많아서 좋다) 하지만 결국 이것도 답이 아니였고… 문득 떠올랐던게 도커 빌드에러니깐 도커 파일을 확인했다. 유레카!

이부분이 문제 였다.. 도커에게 “난 노드 14버전을 쓸거야!” 라고 말하고 16이나 19버전에서 삽질중이였다.. 저기 FROM node:14 를 => FROM node:16으로 바꾸니깐 성공했다… 오늘도 이렇게 하나 배워간다…

라고 생각하자마자 두번째 에러

이건 딱봐도 디비버에서 GOW라는 데이터베이스를 만들면 될거 같아서 만들고 리빌딩 , docker-compose up 하니깐 잘 되었다. 난 개발을 하면서 디비 연결이랑 그래프큐엘 연결 성공 할때가 기분이 제일 좋다.

뭔가 에러가 났을 때 핸들링하는 방법중 누군가의 도움을 받기 보단 내가 직접 이것 저것 먼저 수정해보는게 기억에 더 잘 남고 나중에 비슷한 에러가 생겼을때 처리하기 쉬운 것 같다.

예를들면 import를 바꿔본다던가, 변수명 앞에 타입을 바꿔준다던가, (), {}, ; 같은 것들을 체크해주는 행동들이 기억에 잘남고 에러를 캐치 했을 때 기분이 정말좋다.

아.. 어제 일어나자마자 두통이랑 목이 좀 아프고 몸살기운이 있는거 같아서 출근하자마자 병원 좀 가야 할 것 같다고 하고 병원에 갔는데 감기 환자는 코로나 검사를 해야한다고 해서 바로 했다.. 근데 왠걸 여태 잘 버티고 있던 내 몸의 면역 체계가 무너진 것이다.. 유행할 때 막 돌아다니고 해도 절대 안걸렸었는데 유행 다 지나니깐 코로나가 뒷북을 친다. 실장님께 말씀드렸더니 놀라시면서(창문을 여시면서) 집에 가라고 하셔서 집에 바로 왔다. 뭔가 자바 강의를 듣고 싶었는데 두통이 너무 심해서 누워만 있었다. 오늘은 그나마 괜찮아서 강의를 조금 듣고 블로그도 쓰고있다.

코드에서나 현실에서나 방심은 금물이다!!!

지하철로 30분 거리에 위치하고 있다. 30분 정도면 가깝진 않지만 멀지도 않은 위치 라고 생각한다. 다만 1호선이라는 변수 때문에 나는 1시간전에 나왔다… 그래도 잠이 깨고 정신을 맑게 하기 위한 워밍업 시간이라고 자기위로를 하니 그렇게 억울하지만은 않았다. 회사의 문앞에서 한숨을 가다듬고 들어갔다. 사무실 배치를 스캔 한 후 자리가 남는곳을 보고 ‘저 자리들중 하나 겠구나’ 라고 마음속으로 생각하고 있을 때 실장님께서 오셔서 자리 안내를 해주셨다. 자리에 앉고 사수와 간단한 통성명을 한 후, 인수인계 할 것들을 알려주었고, 대망의 첫 업무들에 대한 인수인계를 받기 시작했다.

집 가면서 자바쪽을 공부해야겠다는 생각도 했다. (채용공고를 보는데 10중 8은 자바 / 스프링이였음) 그렇게 출근전에 챙길것을 챙기면서 이미지 트레이닝을 하고 있었는데 갑자기 합격한 회사에서 전화가 왔다. 뭔가 쌔~ 한 느낌을 받으면서 전화도 받았다. 인간의 감각이란… 부서이동으로 인해 해당부서의 막내가 내가 하려던 사무보조 업무를 맡아서 한다는것이였다.. 절망적이였다. 불안감은 다시 나를 찾아왔고, 자바가 점령한 채용공고를 다시 보면서 불안의 한숨을 내쉬었다.

그러던 와중에 신입환영이라는 반가운 채용공고를 보고 바로 지원했다. 채용공고에는 웹 프로그래머구인 이라는 단어외에 기술스택이라던가, 담당업무 같은 것들이 안나와있었다. 하지만 나는 일단 들어가서 배운다는 마인드로 바로 지원을 하게 되었고, 면접을 보러 오라는 전화를 받았다. 자세하게 표기되어 있지 않은 것들을 면접에서 질문했고, 해소가 되었다. 오히려 사무보조에 떨어진게 좋을 정도로 나한테 좋은 기회인 회사였다. 바쁘진 않지만 개인 공부를 할 수 있는 시간을 주는 신입에게는 적절한 회사. 만약 들어가면 나는 자바, 스프링(부트)를 공부한다는 생각으로 소식을 기다렸다.

다음날에 바로 전화가 왔고 이번에도 붙었다는 소식을 들었다. 정말정말정말 기분이 좋았다. 여태 불안했던 내마음을 단 한순간에 진정시켰고 나는 어떤 상황이던 열심히 하고 환경에 잘 적응해야겠단 두가지 생각으로 잠에 들었다.

: 오토스케일은 인스턴스의 부하를 모니터링해서 특정 이벤트에 대해 인스턴스를 추가,삭제하는 기능을 제공한다. 예를 들어, 갑작스러운 서비스 트래픽의 증가 상황에서 운영자의 개입없이 자동으로 인스턴스를 추가한다던가, 부하 상황이 해제되면 추가된 인스턴스를 삭제하는것이 가능하다. 이처럼 탄력적인 서비스 인프라 운영이 가능해지고, 이를 통해 인프라 비용 및 운영 비용 절감이 가능해진다.

지정가능속성

1. 이미지
2. 인스턴스 타입
3. 디스크 사이즈 (추가볼륨 지정 가능)
4. 키페어
5. 연결될 네트워크
6. 플로팅 IP 연결 여부
7. 부팅 스크립트

: 기술 블로깅이 아닌 코드캠프 생활을 하면서 그동안 개발자로 성장하기 위해 노력한 나를 되돌아 보세요.

코드캠프에서의 마지막 블로깅이 될 것이다. 살면서 블로그를 이렇게 많이 쓰는 것도 처음이지만, 블로깅만으로 이정도 공부가 된다는 사실을 알아서 후회는 하지 않는다. 아직 많이 미숙하고 볼품 없지만 점점 더 나아지리라고 믿는다.

우선 나는 비전공자에 학창시절에 운동을 한 덕분에 공부도 잘 안했다. 하지만 큰 결심을 하고 개발자의 길을 선택해서 결국 여기까지 왔다. 그런 내가 코드캠프의 커리큘럼을 보니 큰 벽과 마주하는것 같았다. 처음엔 두려움으로 가득했지만 곧 그 두려움들이 궁금증으로 변하고, 결국엔 벽 안을 들여다 보기로해서 백엔드코스를 선택했다. 베이스 캠프때부터 정말 쉽지않았다. 내가 게임을 좋아해서 컴퓨터랑 많이 친해서 내가 구매한 맥북이 싫지는 않았지만 뭔가 맥북이 나랑 친해지기 싫은 것 처럼 영어타자도 느리고 답답했다. 하지만 나는 친해지려고 타자연습도 많이 하고 강의를 들으면서 안보고 치는 연습을 하니깐 지금은 많이 늘었고, 최근 강의는 여유까지 있었다. 이런 소소한 경험을 돌아봤을때 기분은 좋았다. 하지만 이제부터가 시작이였고, 백엔드의 커리큘럼은 난이도가 상당했다. 항상 머리로는 이해가 되지만 혼자하려면 생각처럼 잘 안되고 과제들도 나를 더욱 괴롭혔다. 그래도 나에겐 구세주같은 멘토님들과 같이 강의를 듣는 몇몇 똑똑하신분들이 있어서 여기까지 올 수 있었던 것같다. 백엔드는 어렵지만 궁금한, 힘들지만 오기가 생기는 분야인 것 같다. 이제 막 걷기 시작했지만 코드캠프를 첫 발걸음으로 앞으로 많은 곳을 다니고 언젠간 내 식대로 라이브코딩을 할 수 있는 날이 올 수있게 더 노력할 것이다.

: 깃의 저장소를 여러개로 나눠서 안전하게 저장, 확장할 수 있는 시스템이다. 브랜치 모델은 feature - develop(dev) - release - hotfix - master으로 나뉘며 각 기능에 맞게 관리 해주면 팀이 편안하게 코드를 짤 수 있다.

Branches

1. master : 기준이 되는 브랜치로 제품을 배포하는 브랜치다.
2. develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합친다(Merge).
3. feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다.
4. release : 배포를 위해 master 브랜치로 보내기 전에 먼저 에러검사를 하기위한 브랜치다.
5. hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치다.

workflow

: 작업 절차를 통한 정보 또는 업무의 이동을 의미하며, 이름 그대로 작업의 흐름이라고 부른다.

: 객체지향 언어에서 this_는 클래스로 생성한 인스턴스 객체를 의미한다. 하지만 **_JS에서의 **this는 어디서든 사용할 수 있다.

전역공간

:전역 공간에서의 this는 객체를 가리킨다. 말그대로 전역에서의 this이기 때문에 전역객체인것 이다.

1. global => Node.js 에서의 전역객체
2. window => 브라우저 환경에서의 전역객체

메서드 내부

: 당연히 매서드를 호출한 객체와 바인딩 된다.

생성자 함수 내부

: 생성자 함수가 생성할 인스턴스와 바인딩된다.

위와 같이 this는 함수 호출방식에 따라 바인딩이 결정된다.

: 로그아웃은 컴퓨터 시스템 또는 웹 사이트에 대한 액세스를 종료하는 것을 의미한다. 로그아웃을 하면 컴퓨터 또는 웹 사이트에 현재 사용자가 로그인 세션을 종료한다고 알리는 것이다. 로그아웃을 하면 자격증명을 확인하지 않고 다른 사용자가 시스템에 액세스하지 못하게 할 수 있다. 또한 현재 로그인 세션에서 현재 사용자의 액세스를 보호하거나 무단작업을 방지하는데 도움이 되므로 보안의 중요한 부분이다.

: Jest란 페이스북에서 만든 자바스크립트 테스팅 라이브러리다. 쉽게 말해서 본인이 작성한 코드를 테스트 하는데 쓰인다고 생각하면 될 것 같다. 규모가 커질수록 테스트해야 할 코드가 많아지는데, 그 때 Jest를 사용하면 편리하게 코드를 테스팅 할 수 있다.

기능

1. describe() 여러 개의 test() 코드를 하나의 테스트 작업 단위로 묶어주는 API. 하나의 테스트 케이스를 test()라고 한다면 describe()는 여러 개의 테스트 케이스를 하나의 그룹으로 묶어주는 역할을 한다.
2. test() 테스트 코드를 돌리기 위한 API. 하나의 테스트 케이스를 의미하며 it()과 같은 역할을 한다.
3. expect() 테스트할 대상을 넣는 API. expect()에는 주로 테스트 입력 값 또는 기대 값을 넣는다.
4. beforeEach() 테스트 파일의 각 테스트 코드가 돌기 전에 수행할 로직을 넣는 API. 테스트 케이스마다 반복되는 로직을 넣기에 적합하다.
5. afterEach() 각 test들이 실행된 이후 실행되는 부븐을 의미한다.
6. beforeAll() 모든 test들이 시작하기 전에 실행되는 부븐을 의미한다.
7. afterAll() 모든 test들이 시작항 후 실행되는 부분이다.

프로젝트를 할 때 테스트를 하려면 제스트를 쓰면 좋을 것 같다.

: 제네릭은 선언 시점이 아니라 생성 시점에 타입을 명시하여 하나의 타입만이 아닌 다양한 타입을 사용할 수 있도록 하는 기법이다. 한번의 선언으로 다양한 타입에 재사용이 가능하다는 장점이 있다.

제네릭을 선언할 때 사용되는 식별자는 타입 파라미터라고 한다. 함수에도 제네릭을 사용할 수 있으며, 제네릭을 사용하면 하나의 타입만이 아닌 다양한 타입의 매개변수와 리턴값을 사용할 수 있다.

Typescript는 정적 타입의 언어이기 때문에 함수 또는 클래스를 정의하는 시점에 매개변수나 반환값에 타입을 선언해야한다. 함수 또는 클래스를 정의하는 시점에 매개변수나 반환값의 타입을 선언하기 어려운 경우가 있다. 이럴때 제네릭을 적용시키면 된다.

: Schema-first 방식은 GraphQL 서비스에 대한 스키마를 먼저 정의한 다음 스키마의 정의를 일치시켜 코드를 구현하는 방법을 뜻한다.

Schema-first의 장단점

장점

1. 커뮤니케이션에서 비교적 적은 장애물
2. SDL을 제외한 document가 필요 없으므로 상대적으로 낮은 러닝커브
3. 빠른 mocking으로 인해 개발 속도 증가
4. 종속성 반전 원칙(DIP)을 따르면 더 추상적이고 덜 의존적

단점

1. 스키마 정의가 Resolver와 계속적으로 동기화되어야 한다.
2. lint time에 에러 발견 불가 따라서 코드량이 증가할수록 실수 확률이 증가한다.
3. 위 단점을 다양한 라이브러리로 해결하려고 하지만, 근본적인 해결책은 아니다.

Code-first

: Code-first 방식은 resolver를 먼저 작성하여 코드로부터 스키마를 생성하는 방법을 뜻한다. 스키마는 우리가 작성한 resolver을 기반으로 자동으로 생성해준다.

Code-first의 장단점

장점

1. schema와 resolver 사이에서 type 안정성이 보장된다.
2. 다른 여러 라이브러리를 사용하지 않더라도 Schema-first가 많은 라이브러리로 해결하는 문제들을 쉽게 해결 할 수 있다.
3. 코드 중복이 적어진다. (+ NestJS를 사용하기 때문에 boilerplate 조차 작성할 필요가없다.)

단점

1. 둘다 처음 접하는 입장에서는 SDL과 비교해서 직관적이지 못해 비교적 러닝 커브가 높다. (하지만, 다른 방면으로 생각해보면 자신이 원하는 언어 내에서 코드를 작성하므로 조금 더 러닝커브가 낮다고 생각할 수 있다.)
2. 구현과 스키마가 동시에 포함돼있기 때문에, 가독성이 많이 떨어진다.

: Es(ECMA Script) => Javascript + Lint(소스 코드를 분석하여 프로그램 오류, 버그, 스타일오류, 읽기 애매한 부분에 표시를 달아놓기 위한 도구들을 가리킨다.) 쉽게 말해서 코딩하다가 오타나 오류가 있으면 잡아준다고 생각하면 될 것 같다.

Prettier

: 코드 포맷터라고 불리며, 개발자들에게 일관적인 코딩 스타일을 유지할 수 있게 도와준다. (자동줄바꿈등..)

eslint는 문법에러를 잡아주거나, 더 좋은 문법을 사용하게 해주는 도구지만, prettier는 코드의 퀄리티가 아닌 스타일을 교정해주는 것이다.

: Graphical User Interface라는 약자로 그래픽 사용자 인터페이스라는 뜻이다. 사용자가 편리하게 사용할 수 있도록 입출력 등의 기능을 알기 쉬운 아이콘 따위의 그래픽으로 나타낸 것이다. 쉽게 말하면 마우스로 아이콘을 클릭하여 프로그램을 작동시키는 컴퓨팅 환경이라고 생각하면 된다. 요즘은 GUI(구이)를 안쓰는 컴퓨터는 없다고 보면 될 정도로 다 GUI(구이)를 쓰는 추세이다.

CLI

: Command-Line Interface의 약자로 GUI(구이)의 반대말이며, 키보드로 명령어를 타이핑하여 프로그램을 사용하는 원시적인 방식이다. 요즘은 쓰는 사람이 없지만 전문가들한테는 더 편리할 수도 있다.

GUI/CLI의 차이점

--------CLI--------GUI-------- 빠르기 - 빠름------상대적으로느림 리소스 - 적음-------많음 자동화 - 편리-------복잡 편리성 - 낮음-------높음

: Continuous Integration의 약자로 빌드와 테스트의 자동화 라고 할 수 있다. CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다. 이를 구현할 경우 어플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되므로 여러 명의 개발자가 동시에 어플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CD

: Continuous Deployment의 약자로 배포를 자동으로 하는 것이라고 볼 수있다. CD는 지속적인 서비스 제공(Continuous Delivery)또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두가지 의미 모두 파이프 라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

CI/CD의 종류

1. Jenkins => 규모 큼
2. GithubActions => 규모 보통
3. CloudBuild => GCP
4. CodePipline => AWS

CI/CD는 git를 통해 이루어진다!!!

: 사용자가 서버를 직접 관리할 필요가 없다는 뜻을 담고 있다. 앞서 말한 서버를 관리할 필요가 없다는 뜻은 트래픽에 따라 사용자가 직접 서버의 가용량을 증감 시킬 필요가 없다는 뜻이다. 서버리스의 이름만 보고 서버가 없다고 생각할 수도있지만 서버가 없을 순 없다. 그말은 저장할 공간이 없다는 뜻이니깐...

서버리스 컴퓨팅

: 서버리스 컴퓨팅은 사용량에 따라 백엔드 서비스를 제공하는 방법이다. 서버리스 아키텍처로 사용자는 기본 인프라를 걱정하지 않고 코드를 작성하고 배포할 수 있다. 서버리스를 운영하는 업체로부터 백엔드 서비스를 받은 사용자는 사용량에 다라 비용을 부과받고 서비스 규모가 자동으로 결정되기 때문에 고정 대역폭이나 서버 개수를 유지하거나 그에 대한 비용을 지불하지 않아도 된다. 네임 서버리스에도 불구하고 물리적 서버는 여전히 사용되지만 사용자는 인식할 필요가 없다.

서버리스컴퓨팅의 장점

1. 낮은 비용 - 기존 클라우드 제공 업체의 백엔드 서비스(서버 할당)는 사용자에게 사용하지 않은 공간이나 CPU 대기 시간에 대해 비용을 종종 청구하기 때문에 서버리스 컴퓨팅은 일반적으로 매우 비용 효과적입니다.

2. 간편한 확장성 - 서버리스 아키텍처를 사용하는 개발자는 코드 확장을 위한 정책을 걱정하지 않아도 됩니다. 서버리스 업체가 요청에 따라 확장을 모두 처리합니다.

3. 간단한 백엔드 코드 - 개발자는 FaaS를 사용하여 API 호출 같은 단일 목적을 독립적으로 실행하는 간단한 기능을 만들 수 있습니다.

4. 시간 단축 - 서버리스 아키텍처는 시장 진출 시간을 크게 줄일 수 있습니다. 복잡한 배포 프로세스를 이용하여 버그 수정과 새로운 기능을 배포하는 대신 개발자는 필요에 따라 코드를 추가하고 수정할 수 있습니다.