API를 설계하다 보면 아래와 같은 구조로 설계하는 경우가 많았다{ "code": "AUTH_002", "message": "만료된 토큰입니다."}문득 Response를 설계하다가 생각이 들었다. “이미 HTTP Status Code가 있는데, 굳이 body에 또 담아야 할까?” 그래서 해당 고찰을 바탕으로 이 글에서는HTTP Status Code의 본래 역할Body에 status code를 중복해서 담는 패턴의 장단점프로젝트에서의 합리적인 선택 기준을 중심으로 이 질문을 정리해볼까 한다. 1. HTTP Status Code는 왜 ‘고수준’이라고 할까?HTTP Status Code는 의도적으로 고수준(high-level) 으로 설계된 표준이다.HTTP Status Code가 표현하는 것은 딱 하나다..

문제Codetree | Learning to Code with Confidence 알고리즘 [접근 방법]이 문제는 완전탐색 + 부분 조합 최적화 문제로 파악했다내가 처음 접근했을 때는두 도둑이니까 DFS를 두 번 돌려야 하는건가각 도둑의 선택 구간에서 부분집합을 또 만들어야 하는지? 등이런 식으로 고민했는데, 구현 자체는 의외로 단순했다.핵심 포인트는 두 가지다.도둑 A가 고를 수 있는 모든 구간을 탐색도둑 B는 A 구간을 침범하지 않는 곳에서 다시 고르기그리고 각각의 구간에서는“M개의 물건 중 일부를 골라 총 무게 ≤ C 를 만족하면서 가치(무게²) 최대화”라는 배낭문제를 풀어야 하는데,M이 최대 5 수준이라서 굳이 DP를 쓰지 않아도 “정렬 후 그리디”로 해결 가능했다. 사실 정석은 부분집합 전부 탐..

로그인/인증을 구현하다 보면“JWT 쓸까? 세션으로 쓸까?”이 고민을 한 번쯤은 하게 된다.어떤 방법이 더 효율적이고 좋은 방법일지 항상 고민하다막상 구현하고 비교해보니 철학 자체가 다르다는 걸 깨달았다.그래서 이번 2편에서는토큰 기반 인증과 세션 기반 인증을 비교해볼까 한다. 1. 둘의 차이점..?딱 한 문장으로 말하면 자면 음..서버가 인증 상태를 기억하는가 안하는가.세션 기반 인증→ 서버가 나의 로그인 상태를 기억하고 있음 (Stateful)토큰 기반(JWT) 인증→ 서버는 아무것도 기억하지 않음. 클라이언트가 인증 정보 들고 다님 (Stateless)철학부터 달라서, 구조, 운영방식부터 서로 다르다. 2. 세션 기반 인증 흐름세션 기반 인증은 밑과 같이 흘러간다로그인 성공 ↓서버: "해당 유저..

문제https://www.acmicpc.net/problem/15663 알고리즘 [접근 방법]중복 값 입력처리 + 순열각 수를 최대 몇번 사용 가능한지가 관건이였다 첫 번째 접근 visited로 비내림차순을 막으면 되지 않을까? 라 생각했다N과 M(12)는 중복 제거 + 비내림차순이 핵심이라초기에는 TreeMap과 visited 배열을 이용해 다음과 같이 생각했다.입력 수를 정렬하고 중복 제거한다.첫 번째 원소가 같은 수열이 여러 번 나오지 않게 visited로 막자.visited를 적절히 조절하면 비내림차순도 만들 수 있지 않을까?결과는 완전히 실패였다 ㅠ visited로는 비내림차순을 보장할 수 없다비내림차순은 startIndex 기반 DFS가 해결해야 하는데visited로 강제로 막으려고 하다 보..

노션 정리를 하다가 22년도에 한창 '발헤임'이라는 게임이 유행했었을때 GCP를 활용하여 24시간 발헤임 서버를 구축하였었는데 해당 서버를 운영하며 있었던 이슈에 대해 정리해뒀던 기록을 발견하여 추억 회상 겸 올리게 되었습니다 ㅋㅋㅋUbuntu 20.04 LTS 기준으로 작성된 글입니다. 얘들하고 발헤임을 하며 접속 시간이 모두 다 다르다보니 24시간 항상 열려 있는 서버가 있으면 좋을꺼 같다고 생각했다.처음에 대학생용 학습 계정이 있는 Azure로 서버를 구축을 할까 생각했다가 크레딧을 10만원밖에 주지 않아 나중에 진짜 돈이 나갈꺼 같았기에 .. 구성했던 VM를 삭제하고 GCP로 다시 세팅했는데서버를 이틀정도밖에 유지 하지 않았는데도 생각보다 서버에 잔렉이 어우... 그래서 매일 주기적으로 새벽 4시..

프로그래밍을 하다가 문득 생각이 들었다.우리가 단순히 몇가지 단어들(프로그래밍 언어)만 가지고 어떻게 모니터에 표시할 수 있고, 저장장치 속 파일들을 긁어올 수 있는걸까?이 명령들이 어떻게 CPU나 메모리, 디스크와 같은 하드웨어들을 직접 다룰 수 있으며, 제약은 없는걸까..이번 게시물에서는 프로그래밍 언어로 어떻게 하드웨어를 조작할 수 있는건지. 그리고 해당 기능을 왜 사용하고 있는건지에 대해 차근차근 알아가보고자 한다. 1. 우리가 하드웨어를 다룰 수 있는 이유우리가 printf() 함수 하나로 화면에 글자를 띄우고, open() 함수 하나로 디스크의 파일을 조작할 수 있는 이유는 바로 운영체제가 하드웨어 접근을 추상화해주기 때문이다.우리가 Java나 C 같은 언어로 코드를 짜면, 그 코드는 결국 ..

웹 애플리케이션에서 사용자를 식별하고 권한을 관리하는 건 정말 중요한데, 이걸 위해 쿠키, 세션, 토큰이라는 세 가지 방식이 주로 쓰인다. 각각 어떤 특징이 있고 언제 써야 하는지 알아보자. 1. 쿠키(Cookie)란?쿠키는 서버가 사용자의 브라우저에 저장하는 작은 데이터 조각이다. 사용자가 웹사이트를 방문하면 서버는 쿠키를 생성해서 브라우저로 보내고, 브라우저는 이걸 저장해뒀다가 같은 서버에 요청할 때마다 자동으로 함께 보낸다. 쿠키의 주요 특징클라이언트 저장: 사용자의 브라우저에 저장됨자동 전송: 같은 도메인으로 요청할 때 자동으로 포함됨만료 시간: 설정한 기간이 지나면 자동으로 삭제됨용량 제한: 도메인당 약 4KB로 제한됨도메인 제한: 특정 도메인에서만 접근 가능 쿠키의 장단점장점:구현이 간단함서버..

1. 버블 정렬 (Bubble Sort)서로 인접해 있는 요소 간의 대소 비교를 통해 정렬버블 정렬은 정렬 알고리즘 중 가장 단순한 알고리즘으로, 단순한 만큼 비효율적임.동작 방식은 인접한 두 요소간의 대소 비교를 진행함시간 복잡도가 최고, 평균, 최악 모두 O(n^2) 이며 공간복잡도는 하나의 배열만 사용하므로 O(n)을 가짐만약 배열에 n개의 요소가 있을 경우 1번째 원소 vs 2번째 원소를 비교하고 2번째 원소 vs 3번째 원소를 비교하고, ... n-1번째 원소 vs n번째 요소를 비교하면 1회전 비교가 끝난다.1회전이 끝나면 가장 큰 원소는 맨 뒤에 위치하게 되므로 2회전 비교에서는 제외된다.마찬가지로 두 번째로 큰 원소는 가장 큰 원소 앞에 위치하게 되므로 3회전 비교에서는 제외된다.즉, 버블..