개발에 AtoZ까지

🚨 API마다 에러 모양이 다 다릅니다안녕하세요 😀REST API를 만들다 보면 어느 순간 이런 상태가 됩니다. 어떤 컨트롤러는 {"message": "..."}를 내려보내고, 어떤 컨트롤러는 {"error": "..."}를 내려보냅니다. 정작 예외를 못 잡은 자리에서는 화이트라벨 에러 페이지가 그대로 나갑니다.그러다 프런트엔드에서 연락이 옵니다. "에러 포맷 좀 통일해 주실 수 있을까요." 그때부터 공통 에러 응답 클래스를 직접 만들기 시작합니다.그런데 그걸 직접 만들 필요가 없습니다. HTTP 에러 응답 본문에는 이미 표준 규격이 있고, Spring은 그걸 프레임워크 안에 넣어 뒀습니다. ProblemDetail이라는 이름입니다.이 글에서 정리하고 갈 것은 네 가지입니다. 상태 코드와 본문을 정하..

8월이 지나면 대개 마음이 놓입니다. 에어컨 켜는 날이 줄어드니 다음 고지서는 당연히 가벼울 거라고 생각하게 됩니다. 그런데 막상 열어 보면 금액이 별로 안 줄었거나, 오히려 늘어 있는 경우가 있습니다.계량기가 고장 난 것도, 한전이 잘못 계산한 것도 아닙니다. 여름에만 넓혀 주던 누진 구간이 8월로 끝나기 때문입니다. 누진제는 쉽게 말하면 많이 쓸수록 뒤에 붙는 전기의 단가가 비싸지는 구조인데, 그 단가가 바뀌는 경계선이 9월에 아래로 내려옵니다. 쓰는 양을 조금 줄여도 경계선이 더 많이 내려오면 요금은 올라갑니다.이 글에서는 세 가지를 정리합니다. 첫째, 여름 할인이 정확히 언제까지인지 확인합니다. 둘째, 9월에 같은 양을 쓰면 얼마가 더 나오는지 공시 단가로 직접 계산해 봅니다. 셋째, 우리 집 고..

😀 개요안녕하세요 😀우리는 매일 HTTPS를 씁니다. 주소창에 자물쇠가 보이면 왠지 안심이 되죠. 그런데 이런 질문에 바로 답하기는 은근히 어렵습니다."SSL이랑 TLS는 뭐가 다른가요?""자물쇠가 있으면 이 사이트는 안전한 건가요?""인증서는 대체 뭘 증명하는 거죠?"미리 결론을 말씀드리면, HTTPS는 HTTP를 TLS라는 보안 계층으로 감싼 것이고, TLS는 전송 구간 암호화·무결성·서버 도메인 확인 이 세 가지를 해 줍니다. 하지만 자물쇠는 "이 도메인과 암호화된 연결" 이라는 뜻이지, "믿을 만한 사이트" 라는 보증은 아닙니다. 피싱 사이트도 버젓이 HTTPS를 씁니다.이 글은 예전에 다룬 Socket 통신과 HTTP 통신에서 한 걸음 더 들어가, 그 HTTP를 안전하게 감싸는 TLS가 실제..

😀 개요안녕하세요 😀자체 회원가입 기능을 만들 때, 비밀번호를 DB에 어떻게 넣을지 검색해 보면 조언이 갈립니다."그냥 저장하면 안 되니까, 암호화해서 저장하면 되죠.""SHA-256으로 해시하고 salt만 붙이면 안전해요."둘 다 그럴듯하지만, 둘 다 오늘날 기준으로는 위험한 방법입니다.결론부터 말하면 두 가지입니다. 첫째, 비밀번호는 암호화(양방향)가 아니라 되돌릴 수 없는 단방향 해시로 저장합니다. 둘째, 그 해시는 SHA-256 같은 빠른 해시가 아니라, 일부러 느리게 만든 전용 해시(bcrypt·Argon2id) 를 salt와 함께 써야 합니다. 이 두 가지가 왜 그런지 짚고, 그다음 무엇을 어떤 값으로 쓸지까지 정리하겠습니다.이 글은 로그인을 만드는 과정에서 세션 vs JWT 인증(상태를 ..

🚨 버전만 올렸는데 컨트롤러가 통째로 죽었습니다안녕하세요 😀버전만 올렸는데 컨트롤러가 통째로 500을 뱉는 경험, 한 번쯤 하셨을 겁니다. Spring Boot를 3.1에서 3.2 이상으로 올린 직후에 특히 자주 나옵니다. 로그를 열어 보면 이런 문장이 찍혀 있습니다.java.lang.IllegalArgumentException:Name for argument of type [java.lang.String] not specified,and parameter name information not available via reflection.Ensure that the compiler uses the '-parameters' flag.황당한 건 컨트롤러 코드에는 파라미터 이름이 멀쩡히 적혀 있다는 점입니..

😀 개요안녕하세요 😀구글·카카오·네이버 로그인을 처음 붙일 때, 검색해 보면 방법이 두 갈래로 갈립니다."access token 받아서 프로필 API 부르면 로그인 끝나요.""그렇게 하면 안 돼요. PKCE 쓰고 OIDC의 id_token을 검증해야 해요."여기에 response_type=code, code_verifier, nonce 같은 파라미터가 쏟아지면, 도대체 뭘 기준으로 붙여야 안전한지 막힙니다.결론부터 말하면, OAuth 2.0은 "로그인(인증) 프로토콜"이 아닙니다. OAuth는 "이 앱이 당신 자원에 접근해도 될까요?"를 다루는 인가(authorization) 규격이고, "이 사람이 누구인가?"를 다루는 인증(authentication) 은 그 위에 얹는 OpenID Connect(O..

😀 개요안녕하세요 😀로그인 기능을 새로 붙일 때, 검색해 보면 조언이 정반대로 갈립니다."요즘은 무조건 JWT죠. 서버 확장도 쉽고요.""아니에요, 세션이 더 안전해요. JWT는 로그아웃도 안 되잖아요."여기에 "토큰은 localStorage에 저장하면 된다"는 글과 "localStorage는 위험하니 쿠키에 넣어라"는 글까지 겹치면, 도대체 뭘 기준으로 골라야 할지 막힙니다.결론부터 말하면, 이건 하나의 승패 싸움이 아니라 사실 두 개의 다른 결정입니다. ① 로그인 상태를 서버에 둘지(세션) 토큰에 둘지(JWT), 그리고 ② 그 자격증명을 브라우저 어디에 저장할지(쿠키 vs localStorage). 이 둘을 섞어서 설명하니까 계속 헷갈리는 것입니다.이 글은 예전 CORS 에러, 왜 나고 어떻게 푸..

😀 개요안녕하세요 😀프론트엔드 개발하다 이 빨간 줄, 다들 한 번쯤 보셨을 겁니다.Access to fetch at 'https://api.example.com/users' from origin'https://myapp.com' has been blocked by CORS policy:No 'Access-Control-Allow-Origin' header is present on the requested resource.분명 URL도 맞고, Postman에서는 200이 잘 떨어지는데, 브라우저에서만 막힙니다. 그래서 fetch 코드를 이리저리 고쳐 보지만 소용이 없습니다.결론부터 말하면, 이건 대부분 내 JavaScript 코드의 버그가 아닙니다. 서버가 "이 출처는 허용한다"는 응답 헤더를 안 보냈..