개요 이번 글에서는 성능테스트 도중 발생한 DeadLock 문제에 대해, 개념부터 해결 과정까지 정리해보려고 한다. 기능 개발 단계에서 진행한 간단한 테스트에서는 데드락의 위험성이 존재했음에도 불구하고 실제로 발생하지 않았다. 왜 그런 일이 가능했는지에 대해서도 함께

개요 이번 2차 고도화는 지난 1차 고도화에서 발견된 문제를 해결, 실제 운영 환경에서도 안정적으로 동작할 수 있는 구조로 개선을 최우선 목표로 진행되었다. SSE 구조의 한계를 극복하기 위해 WebSocket 기반 구조로 전환 정답 제출 시 GitHub 저장소로 자

개요 이전 글에서 정리했던 기존의 채점 시스템은 동시 처리 부재로 여러 사용자를 동시에 처리하지 못하고 다중 제출 시 불필요한 서버 리소스 낭비와 일관된 결과 제공이 되지 않는 한계를 가지고 있었다. 2주간의 고도화 과정을 통해 비동기 병렬 처리로 여러 제출을 순차

개요 이번 프로젝트에서 우리는 팀원 모두가 새로운 기술과 도메인에 도전해볼 수 있는 서비스 개발을 목표로 삼았다. 다양한 아이디어를 논의한 끝에, 최종 후보로 다음 세 가지 주제가 거론되었다 그룹웨어 음성 채팅 애플리케이션 코딩 테스트 사이트 1. 그룹웨어 그룹웨

개요 백엔드 개발자에게 데이터 정합성은 선택이 아닌 필수다. 트래픽이 몰리는 상황에서 하나의 자원을 동시에 여러 사용자가 요청할 경우, 정합성이 깨지면 곧바로 운영 리스크로 이어진다. 이번 글에서는 동시성 문제란 무엇인지, 이를 해결하기 위해 어떤 방식들이 존재하는지

개요 프로젝트에서 XML 파싱 로직을 만들면서 리팩토링을 거듭하다 보니, 유틸리티 클래스를 통해 static 메서드 중심으로 구현하게 되었다. 처음엔 간단해서 좋아 보였지만, 확장이 어려워지고 굉장히 객체지향적이지 못 하다는 느낌을 받았다. 더 나은 구조를 고민하다가

현재 진행하고 있는 사이드 프로젝트에는 책 정보가 필요하다.크롤링해서 DB에 직접 저장해두기엔 세상에 책이 너무 많아 효율도 안 나오고 무리다. 입맛에 맞게 재가공한 책 데이터만 내 DB에 따로 보관하고 싶은데.. 라고 생각하던 찰나알라딘과 같은 대형 서점들은 Open

소프트웨어를 만들다 보면 이런 경험을 하게 된다.코드는 잘 돌아가는데, 비즈니스 로직은 점점 이해하기 어려워진다.특히 시스템이 커질수록,"이 버튼이 왜 이렇게 동작하는 거야?""이 데이터는 어디서 관리돼?""왜 주문 취소가 이렇게 복잡하지?"같은 질문들이 생길 수 있다

배달 앱을 구현하는 팀 프로젝트에서 메뉴, 장바구니, 주문 API를 맡게 되었다.JPA를 사용해 구현해야 한다는 기본 요구사항이 있었는데, 쿼리문을 직접 쓰지 않고 구현해보자! 라는 것이 개인적으로 가진 추가 목표였다.왜 굳이 쿼리를 통해 그룹핑하지 않고 비즈니스 로직

이미 만들어진 프로젝트를 리팩토링하는 과제를 하는 중이다.어드민 사용자만 접근할 수 있는 특정 API에 대해 접근 로그를 기록하라는 요구사항이 주어졌다.처음엔 로그 코드를 직접 넣는 방식도 괜찮지만, API가 많아질수록 같은 코드가 반복되고 유지보수가 어려워진다. 이런

개요 팀 프로젝트로 진행한 소셜 네트워크 서비스(SNS)와 유사한 뉴스피드 API 서버 구현에서, 회원 기능과 인증/인가 로직을 담당했다. 초기에는 세션 기반 인증으로 구성했지만, 이후 JWT 기반 인증 방식으로 리팩토링 하는 과정에서 문제를 마주하게 됐다. JWT에

– 런타임에 결정되는 구조를 이해해야 객체지향의 본질이 보인다 –Java나 Kotlin 같은 객체지향 언어에서 왜 인터페이스나 추상 클래스를 자주 쓸까?바로 다형성(polymorphism) 때문이다.이 코드에서 animal.speak()가 어떤 메서드를 호출할지는 컴파

"Frameworks are details. UI is a detail. Databases are details."— Robert C. Martin (Uncle Bob)클린 아키텍처(Clean Architecture)는 시스템의 핵심 규칙과 비즈니스 로직을 외부로부터

지난 번에 구현했던 일정 관리 API 과제의 심화 버전이다.이전과 다른 요구 사항 중 큰 것들만 나열한다면 다음과 같다.JPA 사용Filter 사용댓글 게시판 추가쿠키/세션을 활용한 로그인 로직 구현Bcrypt를 활용한 비밀번호 암호화 구현이번 구현에서는 여러 관점에서

가비지 컬렉터는 메모리 관리 기법 중의 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제하는 기능이다. 힙(heap) 메모리에서 더 이상 참조되지 않는 객체가 차지하는 메모리를 자동으로 수집하고 해제하는 방식으로 메모리 관리를 수행하는

DTO와 VO의 개념은 Java와 Spring 애플리케이션에서 자주 혼동되는 부분이다. 나 또한 두 객체의 차이점을 구별하기 힘들어 이 글을 작성하면서 공부해보려고 한다. 여러 자료를 찾아보니 나처럼 헷갈려하는 사람들이 많더라.. 더 이상 헷갈려하지 않기 위해 DTO

이번 과제는 일정 관리 기능을 제공하는 API를 Postman을 사용해 테스트하며 구현하는 것이 목표다. 일정 조회, 생성, 수정, 삭제 기능을 제공하며, 3계층 구조(3 Layer Architecture)를 적용하고, JDBC를 통해 MySQL 데이터베이스와 연동하는

최근 마트 카운터 아르바이트를 시작하면서, 적절한 예외 처리가 되지 않아 시스템이 멈추는 문제를 경험했다. 편의점이 아닌 일반 마트의 포스(POS) 프로그램은 오래전에 개발된 경우가 많고, 이후 추가된 기능이 기존 시스템에 억지로 덧붙여지는 경우도 많다.예를 들어,

웹 서버(Web Server)와 WAS(Web Application Server)는 웹 애플리케이션을 운영하는 데 핵심적인 역할을 한다. 하지만 둘은 완전히 다른 기능을 수행한다.이 글에서 웹 서버와 WAS의 차이점, 역할, 장단점을 쉽고 명확하게 정리하려고 한다.

HTTP는 클라이언트와 서버 간에 이루어지는 요청/응답(request/response) 프로토콜이다. TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송된다.HTTP에는 여러 버전이 존재하며, 현재 가장 널리 사용되는