한발 한발 나아가기

2023년 초에 원하던 기업에 원하는 백엔드 직무로 입사를 할 수 있었다. 그동안 동기들이나 팀원들과 스터디를 하거나, 프로젝트를 새로 시작하는 등의 경험을 쌓으며 수습기간을 마쳤다.

앞으로는 개발자라 이직이 잦다는 것을 감안하더라도, 최소한 2 ~ 3년 이상은 현재 회사에서 몸 담을 생각이다. 그러면 어떻게 성장해야 할까.

나는 현재 신입이다. 사방에는 모르는 지식들이 너무 많아서 초조함을 느끼곤 한다. 하지만 단기간에 모든 것을 학습하기란 불가능에 가깝기 때문에, 우선순위를 두고 공부해야 한다. 그래서 백엔드 개발자 로드맵과 같은 자료나 유튜브 영상들을 찾아보면서, 다음과 같이 고민을 해 보았다. 물론 학습을 진행하면서 변동이 있을 듯하다.

2023년과 24년은 아래에 집중한다.

• 개발 언어와 프레임워크
  • kotlin, java
  • spring, jpa
  • typescript, vue for admin
• 버전 관리
  • git
  • github
• 네트워크
  • 인터넷, HTTP 등의 기본 지식
  • REST, GraphQL, gRPC 등 api 관련
  • 쿠키/세션, OAuth, JWT 등의 인증 관련
• 운영체제
  • 기본 지식
  • linux, 명령어 등
• 데이터베이스
  • ORM, 트랜잭션 등의 기본 지식
  • MySQL, PostgreSQL, H2 등의 RDB
  • MongoDB, Redis 등의 NoSQL
  • 인덱스, 레플리카, 샤딩, CAP 등의 scaling 지식
• 테스트
  • 통합/단위/기능 테스트
  • JUnit, Kotest, mockk 등
• CI/CD
  • jenkins, sonarQube 등
• 리팩토링
• 캐싱
  • client side
  • server side - redis, memcached 등
  • cdn
• 웹 보안
  • HTTPS, CORS, SSL/TLS, 해싱 알고리즘 등

그 이후는 대략적으로 다음과 같다.

• 개발 방법론
• 아키텍처 패턴
• 메시지 브로커
• 컨테이너화, 가상화 기술
• 웹소켓, SSE
• 웹서버
• ...

참고로 해당 연도에 벗어나있다고 관련 기술을 아예 배제하는 것이 아니다. 가령 도커와 쿠버네티스와 같은 기술들은, 업무 중에서 흔히 접하기 때문에 일정 부분의 지식이 필요하다. 단지 깊이 있게 학습하는 것을 25년 이후로 미뤘을 뿐이다.

캐시

캐시가 없다면 데이터가 변경되지 않더라도 매번 네트워크를 통해서 데이터를 다운로드 받아야 한다.

하지만 네트워크는 매우 느리고 비싸기 때문에 브라우저 로딩 속도에 영향을 준다. 이러한 이유로 캐시를 사용하는 것이 좋다.

헤더 종류

캐시 제어 헤더

• Cache-Control: 캐시 제어
  • 오리진 서버뿐만 아니라 프록시 캐시 서버도 제어할 수 있다.
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

검증 헤더

• 캐시 유효시간이 초과하더라도, 캐시 데이터와 서버 데이터가 동일한지 검증하는 용도
  • 동일한 경우 메세지 바디 없이 304로 응답
• 응답 시 사용
• 종류
  
  • ETag : 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠. ex) ETag: "v1.0"
  • Last-Modified : 마지막으로 수정된 날짜와 시간이 명시된다. ex) 2023년 4월 9일 10:00:00

ETag vs Last Modified

날짜 기반의 Last Modified는 다음의 단점을 가지고 있다.

1. 1초 미만 단위로 캐시 조정이 불가능

2. 날짜 기반의 로직이 사용되며, 서버가 별도의 캐시 로직을 관리하지 않음.

• 수정된 결과가 이전 버전과 동일하더라도, 서로 다른 데이터로 인식된다. 이때 서버는 캐시 로직을 관리하지 않기 때문에 아무것도 할 수 없다.

이와 달리 ETag는 캐시 제어 로직을 서버 측에서 관리할 수 있다.

캐시 무효화

확실하게 캐시를 무효화하기 위해서는 다음과 같이 작성한다.

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache

• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
  • 원 서버 접근 실패 시 설정에 따라서 캐시 데이터를 반환할 수 있음.(Error or 200 OK)
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장 X
 (메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: must-revalidate
  • 캐시 만료후 최초 조회 시 원 서버에 검증해야 함
    • 캐시 유효시간이라면 캐시 사용
  • 원 서버 접근 실패 시 반드시 오류가 발생해야 함(504 Gateway Timeout)
• Pragma: no-cache
  • HTTP 1.0 하위 호환

표현

• 표현은 요청이나 응답에서 전달할 실제 데이터를 의미한다. 
  • 데이터는 html이나 json 등의 형태로 표현될 수 있기 때문에 표현이라는 이름으로 지어졌다.
• 표현은 표현 메타데이터와 표현 데이터로 구성된다.
  • 표현 메타데이터 : 표현 데이터를 해석할 수 있는 정보 제공

HTTP 헤더

• HTTP 전송에 필요한 모든 부가정보를 의미한다.
• field-name : field-value 형태를 가진다.
• 다양한 표준 헤더가 존재하며, 필요시 임의의 헤더 추가가 가능하다.

표현 헤더 - 요청, 응답 둘 다 사용

• Content-Type : 표현 데이터의 형식 
  • ex) text/html: charset=utf-8, application/json 등
• Content-Encoding: 표현 데이터의 압축 방식
  • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
  • ex) gzip, deflate, identy
• Content-Language: 표현 데이터의 자연 언어
  • ex) ko, en 등
• Content-Length: 표현 데이터의 길이
  • 바이트 단위

협상 - 요청만 사용

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

선호하는 값이 여러 개인 경우, 다음의 규칙에 따라 우선순위가 결정된다.

1. Quality Values(q)가 클수록 높은 우선순위를 가진다.(기본값 1)
2. 구체적인 것이 우선한다.
   • ex) Accept: text/*, text/plain -> text/plain > text/*

전송 방식에 따른 구분

1. 단순 전송 -> Content-Length만 사용하면 된다.
2. 압축 전송 -> 압축 후 Content-Encoding을 추가한다.
3. 분할 전송 -> Transfer-Encoding을 사용한다. 바디에 길이가 명시되므로, Content-Length는 사용하지 않는다.
4. 범위 전송 
   • 요청 시 : Range: bytes=1001-2000과 같은 형태로 요청한다.
   • 응답 시 : Content-Range: bytes 1001-2000 / 2000과 같은 형태로 응답한다.

일반 정보

• From: 유저 에이전트의 이메일 정보
  • 검색 엔진과 같은 곳에서 주로 사용하며, 그 외에는 잘 사용하지 않는다.
• Referer: 이전 웹 페이지 주소
  • 유입 경로 분석을 가능하게 한다.
• User-Agent: 유저 에이전트 애플리케이션 정보
  • 클라이언트의 애플리케이션 정보
  • 어떤 종류의 브라우저에서 장애가 발생했는지 파악 가능
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
  • 프록시가 아닌, 실제 요청을 처리하는 서버를 의미
• Date: 메시지가 생성된 날짜와 시간

특별한 정보

참고하면 좋을 자료

- How do we control web page caching, across all browsers?