본문 바로가기

분류 전체보기11

백엔드 리액티브 프로그래밍이 대체 뭔가 — 정통 방식의 한계에서 WebFlux까지 리액티브(Reactive)라는 말은 스프링을 조금만 다뤄 봐도 자주 마주친다. WebFlux, Reactor, Mono, Flux 같은 단어가 따라붙는다. "논블로킹이다", "비동기다", "스트림이다" 같은 말이 뒤섞여 나오는데, 이 단어들이 서로 어떤 관계인지는 흐릿하다. 이번 기회에 이 개념을 처음부터 차근차근 공부해 보도록 하자.이 글은 그 흐릿한 부분을 순서대로 잡아 간다. 순서가 중요하다. 리액티브부터 정의하면 왜 이런 게 필요한지 감이 안 잡힌다. 그래서 거꾸로, 지금 대부분의 서버가 쓰고 있는 정통 방식이 뭐가 문제인지부터 본다. 그다음 블로킹과 논블로킹이라는, 자주 섞여 쓰이지만 다른 개념을 정리한다. 이 둘이 잡히면 리액티브 프로그래밍이 무엇을 하려는 것인지 자연스럽게 보인다. 마지막으로.. 2026. 8. 6.
인프라 · 데브옵스 Socket이 대체 뭔가 "소켓" Socket 이라는 개념 완벽 파헤치기 소켓(Socket)은 이름이 익숙한 개념이다. 개발을 시작한 지 얼마 안 됐어도 어디선가 한 번은 듣는다. 채팅을 만든다고 하면 소켓 이야기가 나오고, 실시간 알림을 붙인다고 하면 또 나온다.그런데 "소켓이 뭐냐"고 물으면 답이 잘 나오지 않는다. 단어는 익숙한데 정확히 설명하려면 막힌다. 그래서 이 글에서는 소켓이라는 개념을 끝까지 파헤쳐서 완전히 잡아 두려고 한다. 어디까지가 소켓이고 어디부터는 소켓이 아닌지, 그 선을 정확히 긋는 것이 목표다.가장 흔히 도는 설명은 이것이다. HTTP는 요청하고 응답받으면 연결이 끊기는데, 소켓은 연결을 계속 유지해 준다. 그러니까 소켓은 실시간 통신을 위한 것이다.이 설명은 틀렸다. 소켓이 하는 일과 그 위에 얹힌 프로토콜이 하는 일을 한 덩어리로 뭉쳐 놓은 문장.. 2026. 8. 5.
개발 일지 · 팁 JPA 연관관계를 안 쓰면 조회는 어떻게 하나 — FK 참조, QueryDSL on 조인, 애플리케이션 조립 지난 글(JPA 연관관계, 쓸까 말까 — @ManyToMany도 써도 될까?)에서 우리 팀이 객체 매핑을 거의 쓰지 않는 쪽으로 흘러왔다는 이야기를 했다. 그 글을 쓰고 나서 스스로 찜찜했던 부분이 하나 있었다. "안 쓴다"까지는 말했는데, "그럼 조회는 어떻게 하느냐"에 대한 답을 안 했다는 것이다.연관관계를 걷어내면 문제가 하나 생긴다. order.getCustomer().getName() 한 줄이면 끝나던 게 안 된다. 주문에서 고객 이름을 가져오려면 고객을 따로 조회해서 붙여야 한다. 이게 매번 불편하다면 그 컨벤션은 오래 못 간다. 실제로는 안 불편했으니 몇 년째 유지되고 있는 건데, 그 "안 불편한 방법"이 뭔지를 정리해 두려고 한다.이번에는 감이 아니라 코드를 직접 세어 봤다. 우리 팀이 운.. 2026. 8. 2.
개발 일지 · 팁 1400개의 경력직 백엔드 이력서를 읽으며 좋게 읽혔던 이력서의 5가지 공통점 (2편) 들어가기 전에 — 1편의 반대편 이야기지난 글에서 1400개의 경력직 백엔드 이력서를 검토하면서 반복적으로 아쉬웠던 점들을 정리했다. 1400개의 경력직 백엔드 이력서를 읽으며 반복해서 보였던 아쉬운 점들 (1편)그 글의 마지막을 이렇게 마무리했었다. "다음 글에서는 반대로 잘 읽혔던 이력서들은 어떤 특징이 있었는지, 그리고 내 이력서가 지향하는 방향은 무엇인지를 정리해보려고 한다." 이번 글이 그 내용이다.전제는 1편과 같다. 채용에는 정답이 없고, 나는 1차 서류를 검토하는 검토자 중 한 명일 뿐이다. 최종 결정은 여러 사람의 의견과 팀 상황, 채용 인원이 함께 얽혀서 난다. 그래서 이 글도 "이렇게 쓰면 합격한다"가 아니라 "내가 검토하면서 이런 이력서는 확실히 좋게 읽혔다" 정도로 읽어주면 좋겠다.. 2026. 8. 2.
개발 일지 · 팁 1400개의 경력직 백엔드 이력서를 읽으며 반복해서 보였던 아쉬운 점들 (1편) 들어가기 전에 — 이 글은 합격과 불합격의 기준이 아니다채용에는 정답이 없다. 회사마다 기준이 다르고, 같은 회사 안에서도 면접관마다 보는 포인트가 다르다. 그래서 이 글은 "이렇게 쓰면 탈락한다"는 기준을 이야기하려는 글이 아니다. 내가 약 1400개의 경력직 백엔드 개발자 이력서를 검토하면서 반복적으로 자주 보였던 사례들을 정리한 회고에 가깝다.먼저 내 위치를 정확히 밝혀두고 싶다. 나는 1차 서류를 검토하는 검토자 중 한 명이다. 내가 혼자 합격을 결정하는 자리가 아니다. 1차 검토 결과는 여러 사람의 의견과 함께 취합되고, 거기에 팀의 현재 상황, 채용 인원, 필요한 포지션의 성격이 더해져 최종 결정이 난다. 그래서 이 글에 나오는 이야기들은 "이런 이력서는 떨어진다"가 아니라 "내가 1차 검토를.. 2026. 8. 1.
인프라 · 데브옵스 메시징·스트리밍 인프라 비교 — Amazon SQS·SNS, Apache Kafka, Amazon MSK, RabbitMQ 이 문서의 모든 정의와 특성은 각 제품의 공식 문서에 근거한다. 근거가 없는 주장은 싣지 않으며, 인용한 출처는 마지막 참고 절에 정리한다.먼저 큰 그림부터. 다섯 기술은 크게 두 계열로 나뉘고, 이 구분이 나머지 모든 차이의 출발점이다.큐·메시지 브로커 계열 — 메시지를 소비자에게 전달하고, 정상 처리(ack)되면 흘려보낸다. SQS, RabbitMQ가 여기 속한다.로그(이벤트 스트리밍) 계열 — 이벤트를 로그에 append해 보존 기간 동안 남기고, 소비자가 offset으로 반복해 읽는다. Kafka, Amazon MSK가 여기 속한다.SNS는 위 둘과 결이 다른 pub/sub 알림으로, 발행한 메시지를 여러 구독 대상에 팬아웃한다.[ 큐·브로커 계열 ] [ 로그(스트리밍.. 2026. 7. 26.
백엔드 JPA 연관관계, 쓸까 말까 — @ManyToMany도 써도 될까? 우리 팀의 컨벤션은 객체 매핑(Object Mapping)을 거의 쓰지 않는 쪽으로 흘러왔다.@ManyToMany는 물론이고, 양방향 @OneToMany도 잘 쓰지 않는다. 심할 때는 "연관관계 매핑 자체를 최소화하자"는 분위기까지 간다.그래서 한 번 정리해두고 싶었다. JPA의 연관관계 매핑, 도대체 쓰는 게 맞을까 안 쓰는 게 맞을까?먼저 한 가지 사례부터 짚고 싶다. 우리 회사는 개발자 채용 사전 과제를 검토할 때, @ManyToMany를 그대로 쓴 코드에 감점을 주는 경우가 많다. 오해는 말자. 모든 회사가 그렇다는 이야기는 아니다. 세상엔 @ManyToMany를 자연스럽게 쓰는 팀도 많다. 다만 우리 팀 기준에서는, 실무에서 반복적으로 문제를 일으켜 온 매핑을 아무 고민 없이 썼다는 신호로 보기.. 2026. 7. 26.
개발 일지 · 팁 내가 겪은 AI를 도입했을 때 생겼던 문제들 AI가 업무 방식을 빠르게 바꾸고 있다. 기획서를 쓰고, 코드를 만들고, 문서를 정리하는 일까지 이제는 몇 분이면 끝난다. 예전에는 하루가 걸리던 일이 몇 시간, 때로는 몇 분으로 줄었다. 생산성은 분명 올라갔다.그런데 여러 프로젝트에서 AI 도입을 지켜보면서 한 가지 공통된 현상을 발견했다.AI를 잘 쓰자 보다, AI에게 일을 맡기자 하는 조직이 점점 많아지고 있다.겉으로는 둘 다 AI를 쓰는 것처럼 보인다. 하지만 결과는 전혀 다르다.AI는 뛰어난 도구다. Skill, Agent, MCP, Workflow 같은 기술도 계속 좋아지고 있다.그런데 내 생각에는 그보다 더 중요한 원칙 하나가 빠져 있다. 그 원칙이 없다면, 차라리 AI를 쓰지 않는 편이 조직에는 더 나을 수도 있다고 생각이 들었다.이 글에.. 2026. 7. 19.
인증 · 보안 Keycloak SPI 정석 가이드 - 빌드·배포까지 앞의 두 글(소셜 로그인 원리, Keycloak SSO 구축기)에서 예고한 SPI 이야기다.Keycloak SPI는 한마디로, Keycloak이 제공하는 인터페이스를 오버라이드(override)해서 나만의 커스텀 기능을 만들거나 기존 기능을 확장하는 것이다. 로그인 검증, 토큰에 담기는 정보, 사용자 조회 방식 같은 걸 Keycloak 기본 동작 대신 내가 만든 코드로 바꾸는 방식이라고 보면 된다.이 글은 설명을 길게 늘어놓기보다, 개념 → 구조 → SPI별 코드와 콘솔 설정 → 빌드·배포 → 주의사항 순서로 실제 만들 때 필요한 것만 정리한다. 공식 문서는 Keycloak Server Development를 같이 보면 좋다.코드·경로·이름은 모두 예시(com.example, custom-*)로 바꿔 뒀.. 2026. 7. 19.
인증 · 보안 Keycloak으로 SSO 구축한 이야기 회사에는 서비스가 여러 개 있었고, 각 서비스마다 회원 정보와 로그인이 따로 놀고 있었다. 같은 사람이 서비스마다 다른 계정을 만들고, 서비스를 옮길 때마다 다시 로그인하는 상황이었다. 이걸 하나의 통합 인증 체계로 묶는 일을 맡게 되면서, 어떤 기술을 골랐고 왜 그렇게 정했는지를 정리해 두려고 한다.이 글은 앞 글(구글·카카오 로그인은 실제로 어떻게 동작할까)에서 다룬 OIDC와 OAuth 2.0 원리를 이미 안다는 전제로 쓴다. 로그인 흐름이 아직 낯설다면 그 글을 먼저 읽고 오길 권한다. 핵심만 다시 말하면, 소셜 로그인은 인증 전담 서버(IdP)가 세션을 들고 있고, 표준 프로토콜로 신원을 주고받는 구조였다. 이번 글의 주인공인 Keycloak은 그 "인증 전담 서버"를 우리가 직접 운영하는 버전.. 2026. 7. 18.
인증 · 보안 소셜 로그인은 어떻게 동작할까? 쿠키·세션부터 OIDC까지 쉽게 정리 구글·카카오 로그인은 실제로 어떻게 동작할까? 쿠키·세션부터 OIDC까지회사에서 여러 플랫폼을 하나로 합쳐 웹 SSO 를 만드는 테스크를 진행하였다. 그 과정에서 웹에서 SSO 기술 분석을 하는 과정에서 "구글로 로그인" 버튼 하나 뒤에 얼마나 많은 약속이 숨어 있는지 처음부터 다시 뜯어보게 됐다. 막상 열어 보니 소셜 로그인은 특별한 마법이 아니라, 쿠키와 세션이라는 오래된 개념 위에 표준 프로토콜 하나를 얹은 구조였다.이 글은 그 구조를 최대한 쉬운 말로 정리한 것이다. 소셜 로그인을 직접 붙여 본 적이 있어도 "안에서 정확히 무슨 일이 일어나는지"는 흐릿한 경우가 많은데, 이 글을 읽고 나면 그 흐름이 눈에 그려졌으면 한다. 다음 글에서 다룰 Keycloak SSO도 결국 여기서 설명하는 원리를 그.. 2026. 7. 18.

티스토리툴바