Backend-Roadmap

이 글을 쓰고 있는 시점에서 난 0년차 개발자다. 할 줄 아는 것이라고는 Spring Boot를 통해 API 서버 개발하고 부트스트랩으로 View 짜는 게 전부다. 어쨌든 회사를 계속 다녀야 하고 돈을 벌어야 하는 게 개발자의 삶이다. 그러므로 내 지식을 정제해서 더욱

Intro 웹 개발이라는 분야가 생기게 된 가장 큰 이유는 인터넷이 생김으로써라고 할 수 있다. 이번 시간에는 인터넷의 동작 원리에 대해 한번 알아보도록 하자. 인터넷의 시작 과거 인터넷이 군용으로 개발되었다는 글을 본 적이 있다. 처음에 인터넷은 1960년대에 군용

Hyper Text Transfer Protocol, 우리가 흔히들 말하는 HTTP의 풀 네임이다. 영어 그대로 해석 해 보면 Hyper Text를 전달하는 규약(프로토콜) 이다. 주로 HTML 문서를 주고 받는 데 쓰인다. (HTML에 대한 이야기는 추후 올리도록 하

크롬이든 사파리든 우리는 웹 브라우저를 통해 서버에 무언가 요청을 보낸다. 지금 이 글을 읽고있는 사람들도 웹 브라우저에서 요청을 했기에 서버에서 응답 메시지를 보냈을 것이고 별 재미도 없는 글이 출력되었겠지. 이번에는 클라이언트 입장에서 서버에 요청을 보내고 받는 데

Intro 이번에는 DNS에 대한 글을 써 보도록 하겠다. DNS 라는 말, 많이들 들어 보았겠지만 특히나 통신 (학부에 따라 데이터 통신이든 컴퓨터 네트워크든 여튼 그런 이름을 가진 수업에서 꼭 나오는 이야기.) 시간에 많이 들어보게 되는 용어다. Domain N

Hosting 이라는 말은 블로그를 운영해 본 사람이라면 한번씩은 들어봤을 지도 모른다. 나처럼 Velog 같은 플랫폼 위에 자신만의 블로그를 꾸미는 사람도 존재한다. 하지만 어떤 사람들은 자신만의 블로그 페이지를 만들어서 호스팅 업체에 돈을 지불하고 운영하는 경우도

백엔드 개발자도 기본적인 프론트엔드 지식이 있어야한다. 아니 사실 난 이 두 분야를 나누는 것 자체가 의미 없다고 생각한다. 특히나 나 같은 쌩 주니어 무지성에게는 특히나 그렇다. 이번엔 알아두는 게 좋은 기본적인 프론트엔드 개념 중 HTML, CSS, Javascri

이번 포스팅은 CSS에 관한 포스팅이다. HTML에 이어서 프론트엔드의 기초를 다지는 데 몰라서는 안 되는 지식이고 모르면...열심히 공부해야 한다. 정말로.Cascading Style SheetCascade라는 단어는 '종속'이란 의미를 가진다. HTML 문서에 '종

프론트엔드 파트의 마지막. Javascript에 대한 글이다. 필자는 사실 Javascript에 대해 아주 잘 알지는 못 한다. 프론트엔드 개발자로 진출 할 생각이 학부 시절에는 그렇게 크지 않았으니까. 하지만 풀스택이라는 원대한 꿈을 위해서는 공부를 멈출 수 없다.

지난 포스팅에서는 Javascript 문법의 객체 개념 까지는 간단하게 알아 보았다. 이번 포스팅에서는 실제 웹 개발에 있어서 몰라서는 안 되는 문서 객체 모델, 브라우저 객체 모델에 대해 다뤄 보겠다.생각보다 글이 길어져서 매우 피곤하다...ㅋㅋ이래서 언어 문법 같은

Intro 지금까지 내용들은 조금 라이트 했다고 생각한다. 사실 저 정도는 전공자가 아니어도 충분히 알 수 있으니까. OS 부터는 CS 지식이 조금 필요 해 질 수 있다. 프로그램을 잘 짜려면 당연히 OS에 대해서도 잘 알아야 한다. 이번 포스팅에서는 OS의 구조와

오랜만의 기술 포스팅이다....요즘 너무 바쁘다 ㅠ올해 안엔 로드맵 전체를 그래도 완성 해 보자!이번 포스팅에서는 OS에서의 프로세스 관리에 대해 알아보도록 하겠다. 어떤 프로그램을 실행시킨다면, 메모리에 로드되고 프로세스가 된다. 프로세스는 실행 되면서 끊임없이 상태

이번 포스팅에서는 쓰레드와 동시성에 대해 알아보겠다. 쓰레드 그 자체는 아마 JAVA든 C언어로 시스템 프로그래밍을 해 봤든 경험 해 봤을 것이다. 쓰레드라는 단어의 뜻과 비슷하게(?) 프로그램이 가지는 하나의 흐름을 쓰레드라고 부른다. 일반적으로는 하나의 프로그램은

이번 주제는 메모리 관리. 운영체제에서 정말 중요한 영역이고 반드시 알아야하는 파트. RAM 다 익선이라는 말을 들어 보았을 것이다. OS를 통해 프로그램을 실행시키고 작업을 하려면 RAM에 프로세스로 로드 시켜야 한다. 하지만 가면 갈 수록 컴퓨터로 할 수 있는 일이

이번 주제는 IPC 즉 Inter Process Communication. OS 에서 상당히 중요한 파트 중 하나다. 프로세스 간 통신을 의미한다. 프로세스 그 자체는 독립 된 실행 객체라고 할 수 있다. 즉 다른 프로세스의 영향을 받지 않는다. 그러므로 서로간에 통신

이번 포스팅의 주제는 입출력 관리. 전산병으로 근무하던 시절 풀링, 인터럽트 등의 용어들을 정말 많이 들어보았다. 그런 용어들이 왜 나왔는 지 알게 되었 던 주제. 컴퓨터는 소프트웨어로만 이루어 져 있지 않다는 것은 너무나 자명한 사실이다. 우리는 마우스든 키보드든 컴

이번 포스팅은 OS 파트의 마지막 POSIX에 대해 다뤄보도록 하겠다. 서로 다른 UNIX OS의 공통 API를 정리해서 이식성이 높은 애플리케이션을 만들기 위한 목적으로 IEEE에서 책정 한 인터페이스 규격이다. 시스템 콜, 프로세스 환경, 파일과 디렉터리, 시스템

디자인 패턴에 대한 시리즈는 세 파트로 나누기로 하겠다. 생각보다 양도 많고 코드도 많이 들어갈테니까. 글이 길면 쓰는 사람도, 보는 사람도 힘드니까. 학부 시절에 알아 뒀으면 얼마나 좋을까 싶었던 지식들이라 생각한다. 마냥 내가 JAVA로 코딩을 할 줄 아는것과 이걸

Intro 지난 포스팅에서는 크게 Singleton, Factory, Strategy Pattern 에 대해 다뤘다. 디자인 패턴 포스팅은 예고했듯이 3가지 파트로 나뉜다. 그 만큼 내용도 많고 중요한 개념들이고 정말 많이 와닫는 내용들이라 포스팅에 정말 많은 신경

디자인 패턴 파트의 마지막 포스팅이다.이번 포스팅에서는 MVC, MVP, MVVM 에 대해 알아보도록 하겠다. 코드로 표현 할 수 있는 건 지금까지 다 다뤄보았다. 이번 포스팅에서는 코드를 따로 첨부하지는 않겠다. 최대한 예시 위주로. 학부 생활 하면서 정말 많이 다뤄

Intro 첫 실무에서 가장 많이 와 닿았던, 그리고 내가 학부 시절 많이 부족했던 지식 중 하나였다. 객체지향 5대 원칙이라고 부르는 SOLID, 한번 깊게 파 보자. Why? 객체지향 프로그램을 설계 할 때 중요하게 여기는 것들이 여러가지 있다. 결국 시간이 오

KISS, YAGNI, DRY들어 본 적 있는가? 사실 필자는 학부 시절엔 들어 본 적 없다. 실무를 뛰면서 알게 되었던 지식들인데, 구차한 변명이지만 코로나 세대라...내가 이런 지식들을 학부에서 다룰 일이 그렇게 많지 않았다는 걸 글을 쓰면서도 많이 깨닫고있다. 되

네트워크 파트가 백엔드 개발자에게 왜 중요할까? 인프라 자체를 이해하는 데 네트워크 지식을 필요로 한다. 프로그래밍 실력 만큼이나 중요한 건 인프라에 대해 이해하는 것이라 생각한다. 네트워크 파트는 총 세 파트로 나뉜다.Part 1 : 기초 네트워크 지식Part 2 :

이번 포스팅의 주제는 네트워크 계층. 그 중에서 TCP/IP 4계층과 OSI 7계층에 대해 써 보도록 하겠다. 우리가 흔히 사용하는 인터넷 프로토콜의 모음들이다. Application Layer 의 DHCP, FTP, HTTP, IMAP 부터 해서 Transfort L

네트워크 파트의 마지막, IP에 대해 포스팅 해 보도록 하겠다. 벌써 백엔드로드맵을 연재한 지 시간이 꽤 지났다. 막상 글을 많이 쓴 것 같지는 않지만...올해 안에 이 시리즈를 마무리하는 게 목표다. 사실 뭐 컨텐츠라 할 만한 게 없는 내 블로그지만, 이 시리즈를 연

인터넷 파트에서 HTTP의 기본적인 개념은 다루었다. 이번 파트에서는 HTTP 버전 별 차이점에 대해, 그리고 보안 알고리즘에 대한 내용들을 서술 해 보도록 하겠다.가장 단순한 형태의 HTTP. 한 연결 당 하나의 요청을 처리하도록 설계 되었으나 RTT가 증가하는 문제

Intro VCS에 대해 글을 써 볼까 말까 참 많이 고민을 했다만....그래도 쓰긴 써야겠단 생각이 들었다. Git 명령어를 쓸 줄 아는 건 맞지만, 실무를 겪기 전 까지 Git을 제대로 썼다고는 떳떳하게 말 하기 힘들었다. 많은 팀에서는 Git을 사용한다. 아니

대망의 DB 파트다. 상당히 장기 시리즈가 될 것으로 예상 되는 파트. 백엔드 개발자에게 중요한 게 한두가지가 아니겠지만, DB 활용 능력이 중요하다는 사실은 자명하다. 웹 애플리케이션 아키텍쳐 상에서 WAS 는 DBMS에 데이터를 요청하고 그에 맞는 데이터가 전달되어

이번 포스팅의 주제는 ORM이다. 백엔드 애플리케이션을 개발하는 과정에서 ORM을 상당히 많이 사용하게 된다. ORM에 대해 한번 깊게 알아보도록 하자. Entity의 특징이 뭘까? 그냥 편하게 생각해보면 그 자체가 하나의 데이터 형태라고 할 수 있다. 게시판 글이라는

이번 포스팅의 주제는 ACID, Atomicity, Consistency, Isolation, Durability 에 대해 다뤄 보도록 하겠다.데이터베이스 내에서 일어나는 트랜잭션의 안전성을 보장하기 위해 필요한 성질이다. 특히 돈이 오가는 주식, 금융업계에서 이러한

DB를 운용하다 보면 상당히 많이 듣는 개념이고, 실제로 백엔드 상에서 특정한 거래가 진행되었을 때 Transaction Code 등의 값을 통해 해당 Transaction에 대한 로그를 남긴다. 이번 포스팅에서는 Transaction 에 대해 다뤄 보도록 하겠다. 절

Intro ORM 등을 활용하다보면 N+1 문제에 대한 이야기를 반드시 듣게 된다. 이번 포스팅의 주제는 N+1. 서버 프로그래밍을 하는 도중 반드시 겪게 될 문제이므로 해당 지식에 대해 숙지해야 한다. N+1 문제란? ORM을 사용하다보면 발생할 수 있는 문제다.

Intro 프로젝트를 진행하기 전, 엔티티를 설계하는 과정을 거치게 된다. 엔티티를 제대로 설계하려면 정규화에 대해 알아야한다. 이번 포스팅의 주제는 정규화. 데이터베이스 전공 과목 시간에 반드시 언급되는 내용이라 할 수 있다. 정규화를 하는 이유? 한 Relati

Index에 대한 이야기는 학부 시절에는 들어 본 적이 없었다. 백엔드 개발자 업무를 처음 할 때 가장 와닿았던 건 서버사이드 프로그래밍이 이렇게 어렵구나 보단 DB를 어떻게 활용하느냐에 따라 내가 짜야 할 코드의 양이 줄어들 수 있느냐였다. Index 포스팅 시작하도

Intro RESTful API라는 말은 정말 많이도 들어봤을 지 모른다. 누군가는 GraphQL로 RESTful 을 대체 하기도 하겠지만, 웹 기반 시스템에서 RESTful을 아예 배제하고 개발을 진행하기는 쉽지 않다. 이번 포스팅에서는 RESTful API에 대해

Intro 이번 포스팅의 주제는 RESTful API 디자인 방법이다. RESTful 한 API를 설계하기 위해서 알아야 할 지침들에 대해 정리 해 보도록 하겠다. Remind RESTful API 라는 개념은 많은 주니어 웹 개발자들이 알다가도 모를 수 있는 주제라

Intro 필자가 어느 시점부터 회사를 다니고 있어서 로드맵 시리즈가 주간 연재로 바뀌었다. 올해 안에는 어떻게든 마무리 짓고 한번 더 손보고자 하는 게 목표다...

Caching 개념 자체를 몰랐던 건 아니다. 학부 시절에는 다룰 기회가 잘 있지 않아서 개념 상으로만 이해하던 용어였다. 실무에서 Caching 주제로 토론을 하게 되었을 때 왜 Caching을 쓸까? 라는 주제로 깊게 고민 해 본적이 없다는 생각이 들었다. Cach

이번 포스팅의 주제는 Redis다. Redis의 개념, 왜 Caching과 연결되는 지, 어떻게 활용할 수 있는지에 대해 포스팅 해 보도록 하겠다. REmote Dictionary Server 의 약자. 메모리 키 값 데이터 구조 저장소다. 오픈소스고 다양한 인 메모리

Intro HTTP 통신을 위주로 개발하던 백엔드 개발자에게 웹 소켓은 아마 생소할 수도 있다. 서버 개발자라면 웹 소켓에 대해서는 반드시 알아야한다. 학부 시절에 채팅 프로그램, IOT 시스템을 개발하는 과정에서 소켓 프로그래밍(C++, Java) 을 경험 해 보았고

MSA냐 Monolithic이냐...상황에 따라 많은 논란이 될 수도 있는 주제라 생각한다. 어떤 상황에서는 굳이 MSA를 채택한다고 해서 좋을 게 없을 수도 있다. 이번 포스팅에서는 두 구조를 비교 해 보도록 하겠다.우선 두 아키텍쳐에 대해 설명하기 전에 확실한 차이

Intro 이번 주제는 SOA, Service Oriented Architecture에 대해 포스팅 해 보도록 하겠다. Service Oriented Architecture 서비스 지향 구조라는 의미다. 업무상에 일 처리에 해당하는 부분들을 하나의 서비스로 판단해서

서버리스 아키텍쳐 또한 MSA 만큼이나 많이 들어볼 수 있는 아키텍쳐 패턴이다. 서버가 없다고? 이게 무슨 소리야....싶겠지만 실제로는 그런 의미는 아니다. 이번 포스팅의 주제는 서버리스. 시작하겠다.앞서 말했듯 Serverless 는 서버가 없다는 의미가 아니다.