이직을 앞둔 1년차 주니어 백엔드 개발자 회고

개발자 커리어에서 처음 3년이 중요하다는 말을 많이 들었다. 그중 1년을 보냈다.돌이켜보면, 나는 이 1년 동안 “일을 잘하는 법”은 배웠지만 “좋은 개발자가 되는 법”은 아직 시작 단계에 있다.혼자 해결하는 사람이 좋은 개발자라고 생각했다입사 초에는 주어진 업무를 혼자 해결하는 것이 당연하다고 생각했다. 질문을 한다는 건, 준비가 덜 된 상태라고 느껴졌고 괜히 시간을 뺏는 것 같아 망설였다. 그래서 대부분의 문제를 오래 붙들고 있었다. 반나절을 고민하고, 방향이 맞는지 확신 없이 작업을 이어갔다. 지금 생각해보면, 그건 책임감이 아니라 비효율에 가까웠다.기준이 바뀌었다: “내가 잘하는 것” → “팀이 잘 돌아가는 것”1년이 지나면서 가장 크게 바뀐 건 행동이 아니라 기준이었다. 더 이상 “내가 얼마나 ..

• format_list_bulleted 카테고리 없음
• · 2026. 3. 30.
• textsms

6개 소셜 로그인을 하나로: 불확실성 속에서 사용자 식별 정합성을 설계한 기록

0. 비즈니스 컨텍스트6개 소셜 플랫폼 지원 (카카오, 네이버, 구글, 애플, 페이스북, 라인)글로벌 서비스 특성상 국가별 주요 플랫폼 대응 필수기획 변경 가능성이 높은 초기 단계 서비스이 업무의 본질은“6개를 붙이는 것”이 아니라, 사용자 식별 기준을 안정적으로 유지하는 것이었다.1. 요구사항 변화에 따른, 설계 기준 변화초기 요구사항이메일만 수집OIDC 기반 ID Token 검증만으로 충분외부 API 호출 1회이 구조는 단순했다.하지만 곧 요구사항이 변경되었다.변경된 요구사항전화번호, 생년월일, 국가코드 등 추가 수집프로필 조회 API 필수외부 API 호출 2회 필요→ OIDC의 네트워크 비용 이점이 사라졌다.당시 선택지선택장점단점OAuth2만 사용변경 대응 유리초기 요구사항엔 과한 설계OIDC만 사..

• format_list_bulleted Spring
• · 2026. 2. 17.
• textsms

실무에서 JPA 연관관계 대신 ID를 선택한 이유 (그리고 그게 정답일까?)

📍 들어가며: 실무에서 생긴 의문JPA를 처음 배울 때 우리는 @ManyToOne, @OneToMany를 활용한 객체 그래프 탐색에 감탄합니다. 이 방식은 객체 지향적으로도 아름다워 보였고, ORM의 장점을 잘 보여주는 기능이라고 생각했습니다.하지만 여러 상용 프로젝트를 경험하면서 한 가지 패턴을 반복적으로 보게 되었습니다.“JPA 연관관계를 맺지 말고 데이터베이스 ID로 관리합시다.”정말 연관관계는 실무에 적합하지 않은 걸까?아니면 프로젝트 특성에 따른 합리적인 선택일까?트래픽이 높은 플랫폼 회사에서는 또 다른 선택을 할까?단순히 JPA 숙련도의 차이 때문일까요? 아니면 우리가 놓치고 있는 비즈니스 운영의 리스크가 있는 걸까요? 이 글은 그 선택의 이면에 숨겨진 '트레이드오프'에 관한 기록입니다.🔍..

• format_list_bulleted Spring
• · 2026. 2. 16.
• textsms

[Java] JVM 청소부 GC: GC를 어떤 관점으로 봐야하는가, GC 알고리즘

JVM 에서의 메모리 관리JVM 안에는 모두 공유되는 영역인 Heap 부터 각각의 메서드의 작업별로 할당되는 Stack 까지 다양한 영역이 존재한다. 프로그램을 실행하면 메서드를 실행하며 새로운 데이터들이 메모리에 추가될 가능성이 높다. Java로 구성된 프로그램을 작동시켜 놓으면 메모리가 계속 증가하게 되는데, 이런 문제점에 해답을 주는 것이 Garbage Collection, GC이다. GC는 JVM 상에서 더 이상 사용되지 않는 데이터가 할당되어 있는 메모리를 해제시켜 주는 장치이다. JVM에서 자동으로 동작하기 때문에 Java는 특별한 경우가 아니면 메모리 관리를 개발자가 직접 해줄 필요가 없다. GC 가 주로 동작하는 대상은 Heap 영역 내의 객체 중에 참조되지 않은 데이터이다.public c..

• format_list_bulleted Java
• · 2024. 7. 3.
• textsms

[Spring] 이메일 인증 기능 비동기 처리와 주의사항: @Async, @EnableAsync

기존의 코드에서 비동기 처리를 고려한 이유 클라이언트가 ‘이메일 전송 요청’에 대한 기존의 시나리오는 다음과 같습니다. 먼저, 우리의 웹 서버와 DB에서 실행되어야 할 작업들이 실행됩니다. 그리고 외부 서버인 구글 SMTP 서버로 이메일 발송 요청을 한 후, 이메일 발송에 대한 응답이 온 후에야 클라이언트에게 완료했다는 응답을 보내주고 있습니다. 또 다른 시나리오는 푸시 알림 발송을 위한 firebase 서버로 요청하는 경우가 있습니다. 마찬가지로 사용자가 (대) 댓글을 작성했을 때 푸시 알림이 발송 완료될 때까지 응답을 기다리게 해야 하는 상황입니다. 현재는 비동기가 아니기 때문에, 하나의 스레드에서 일련의 작업을 진행하고 있습니다. 그러나 비동기 처리를 도입하게 되면, 작업이 완료되기를 기다리지 않습..

• format_list_bulleted Spring
• · 2024. 4. 10.
• textsms

[Spring] 프록시 방식의 AOP 한계: self-invocation 이슈

Spring AOP 기반의 @Async를 공부하다가, self-invocation(내부 호출)하는 경우에는 AOP가 걸리지 않는 이슈를 마주하게 되었습니다. 왜 내부 호출하는 메서드는 AOP 타겟이 되지 못하는 것인지, 그리고 이 문제를 해결할 수 있는 방법에는 어떤 것들이 있는지 알아보겠습니다. 내부 호출 시 왜 AOP 기능이 수행되지 않을까? 이 문제는 프록시 객체와 관련이 있습니다. 따라서, 먼저 프록시에 대해 간단하게 알아보겠습니다. 프록시 적용 전 실제 객체가 스프링 빈으로 등록됩니다. 빈 객체의 마지막 @x0..은 인스턴스를 의미합니다. 프록시 적용 후 스프링 컨테이너에 프록시 객체가 등록됩니다. 스프링 컨테이너는 이제 실제 객체가 아닌 프록시 객체를 스프링 빈으로 관리합니다. 실제 객체는 스..

• format_list_bulleted Spring
• · 2024. 4. 9.
• textsms