Develop/CS

서론 결국 좋은 품질의 애플리케이션을 개발하기 위해서는 CS지식을 활용하여 성능과 안정성을 최대로 이끌어내야한다. 이 때문에 나도 다시 CS지식을 학습하고 있는데 운영체제를 공부하다보니 이러한 이론들을 실제 개발에 어떻게 접목시켜야 좋을지 감이 오지 않았다. 스레드, 동기화, 스케줄링 부분을 학습하면서 이론들을 어떻게 실제 성능, 안전성, 자원 관리같은 운영품질 향상과 같은 실전에 연결 시킬 수 있는지 정리해보았다.스레드의 본질백엔드 개발 관점에서 스레드를 이해할 때의 핵심은 하나이다.같은 프로세스의 스레드들은 같은 주소 공간(메모리)를 공유한다. 즉, 코드/힙/전역 데이터같은 메모리를 함께 사용한다.대신 각 스레드들은 자신만의 스택을 가진다. 스택은 스택 포인터 레지스터로 관리되기 때문에 스레드별로 분..

왜 쿠키가 필요할까?HTTP는 기본적으로 무상태(stateless)프로토콜이라, 요청 하나하나가 서로 독립적이고 서버는 기본적으로 "이 요청이 누구의 것인지" 모른다. 하지만 우리가 실제 웹 서비스를 돌린다 했을때는 다음과 같은 기능들이 필요할 것이다.로그인 유지(세션 유지)장바구니 상태 유지사용자 설정(언어, 테마 등)분석/광고를 위한 사용자 식별 등이를 위해 서버와 브라우저는 쿠키(Cookie)라는 작은 데이터를 주고받으며, "이 사용자는 이 쿠키를 가진 사용자이다"라는 식으로 상태를 기억하게 된다.쿠키의 기본 동작 흐름서버 → 브라우저: Set-Cookie서버는 HTTP 응답 헤더에 `Set-Cookie`헤더를 넣어 쿠키를 설정할 수 있다.HTTP/1.1 200 OKSet-Cookie: sessio..

1. JWT를 실무에서 어렵게 만드는 것들JWT의 개념 자체는 단순하다.`header.payload.signature` 구조서버 비밀키/공개키로 서명서버가 토큰만 보고 사용자 식별그러나 실무에서 사용할 때 문제가 되는 포인트들이 여럿 존재한다. 설계와 개발 과정에서 신경 쓰고 개발한다면 JWT는 서버 부하를 줄이고, 대규모 서버 확장에 유리하지만 그렇지 않다면 허점이 노출되어 보안 위협을 겪을 가능성이 크다. JWT를 사용할 때 신경써야 할 부분은 다음과 같다.토큰을 언제까지 유효하게 둘것인가(만료 정책)토큰을 어떻게 무효화할 것인가(로그아웃, 탈취 시 대응)여러 기기, 브라우저, 마이크로 서비스에서 일관된 정책을 유지할 것인가.키 유출/탈취/XSS/재사용 공격 등 보안 이슈이를 해결하기 위해 등장한 개..

1. 서론백엔드 서버에서 많이 사용하는 세션 기반 인증과 JWT 기반 인증을 비교해보려 한다. 개인 프로젝트를 진행하면서 세션 방식과 JWT 방식을 모두 구현해보기는 했지만 어떠한 방식이 더 유리한지 구현에 용이한지 어떤 규모의 프로젝트에 적합한지는 고려해본적이 없어 이번 기회에 정리하려 한다.세션 인증서버가 "로그인한 사용자 상태"를 들고 있는 방식이다(stateful).구현이 쉽고, 전통적인 웹 서비스/어드민 페이지에 여전히 적합하다.JWT 인증서버가 사용자 정보를 서명된 토큰(JWT)에 담아서 클라이언트에게 맡기는 방식이다(stateless 지향).마이크로 서비스, 모바일/웹/외부API를 동시에 지웒나느 대규모 서비스에서 유리하지만 설계 난이도가 높다. 처음 만드는 서비스라면 세션으로 시작해도 충분..

1. 멱등성수학 / CS에서의 정의수학에서 멱등 연산은 다음 성질을 만족한다. f(f(x))=f(x) 어떤 값 `x`에 대해 `f`를 여러 번 적용해도 첫 번째 적용 시와 동일하다. 컴퓨터 과학에서 이 개념을 시스템/코드에 가져오면, 보통 이렇게 설명할 수 있다.같은 연산(요청/호출)을 여러 번 수행해도, 시스템의 최종 상태와 관찰되는 결과가 한 번만 수행했을 때와 동일하다.코드 레벨에서 예시멱등한 연산int x = 10;void setZero() { x = 0;}setZero(); // x = 0setZero(); // x = 0 (상태 변화 없음)setZero(); // x = 0 멱등하지 않은 연산int balance = 100;void withdraw10() { balance -= 10..