내일배움캠프

내일배움캠프의 첫 시작 "웹 개발 기초" 강의를 통해서 웹, 프론트엔드, 백엔드, HTML, CSS, JavaScript 등에 대해서 학습해보았다.웹 페이지의 구성과 어떻게 만들어지는지 그리고 백엔드와 프론트엔드간의 대화에 대한 기초를 학습해보았다.백엔드 개발자가 되기

오늘은 서버와 HTTP, REST API에 대해서 학습하고 Postman을 사용하여 Mock서버를 생성하고 API를 직접 호출, 응답해보았다.완성된 프론트엔드, 백엔드 프로젝트를 연동하여 완성된 하나의 웹 프로젝트를 실습해보았다.서버는 하드웨어로서의 서버와 소프트웨어로

1.API 식별하기 https://place.map.kakao.com/10332413 2.API 명세서 만들기 3.Mock 서버 구축하기

데이터베이스와 대화하기위한 언어인 SQL 문법을 학습해보았다.select : 데이터를 가져오는 기본 명령어로, 데이터를 조회하는 모든 Query 에 사용됨from : 데이터를 가져올 테이블을 특정해주는 문법where : 전체 데이터 중 원하는 데이터만 필터링을 할 수

replace, substring, concat, if, case 등을 이용해서 데이터 포맷을 다르게 변경해보는 방법을 학습했다.REPLACE : REPLACE 함수는 지정한 컬럼에서 특정 문자열을 다른 문자열로 바꾸어 주는 문자열 치환 함수이다.SUBPTRING :

Git 이란 버전관리시스템으로 2005년에 출시되었다. Git은 분산 버전관리시스템으로 코드를 병렬적으로 수행이 가능해서 협업에 좋은 시스템이다.GitHub는 Git으로 관리하는 프로젝트를 올릴 수 있는 호스팅 사이트이다. 오픈소스를 통해 전 세계에 있는 개발자들과 협

과제 템플릿을 clone과 Pull Request, Merge를 이용해 소개 페이지 내용 완성하기팀장의 레포지토리 코드를 clone하고 개인 branch를 작성하여 개인 작업을 진행한다.작성된 내용을 commit하고 pull request 하고 코드 리뷰와 merge

1. Java의 기초문법 사전캠프에 이어서 Java의 조건문, 반복문 등 기초문법에 대해서 공부해보았다. 2. 조건문 조건을 미리 정의하여 컴퓨터가 조건에 맞게 동작할 수 있게 하는 구문 if, if-else, else-if, switch 등이 있다. 2-1. if

1편에 이어서 Java의 배열, 메서드 등 기초문법에 대해서 공부해보았다.배열은 같은 타입의 데이터를 연속된 공간에 나열하고, 각 데이터에 인덱스(index)를 부여해놓은 자료구조관련된 데이터를 편하게 관리하기 위해서 사용배열에 들어갈 수 있는 데이터의 개수한번 크기를

클래스 : 객체를 만들기 위한 설계도 (첫 글자는 대문자)객체 : 실제로 존재하는 것 (사물, 논리, 개념, 무형의 것들도 객체가 될 수 있다.)속성 : 특징을 작성하는 곳으로 객체를 생성해야 접근 가능하다, 프로퍼티, 필드 라고도 한다. (예시 : 사람의 나이, 이름

객체 및 이들간의 관계, 상호작용 등을 기반으로 프로그래밍 캡슐화, 상속, 추상화, 다형성 등의 요소가 있다.객체의 정보를 외부에서 직접 접근하지 못하게 보호하는 개념접근제어자를 통해서 구현할 수 있다.접근제어자는 클래스, 변수, 메서드, 생성자의 접근 범위를 제한하는

지금까지 Java 기초문법에서 배운 내용을 활용하여 2가지 정수와 연산자(+,-,\*,/)를 받아서 사칙연산을 하는 계산기 코드를 작성해보았다.양의 정수와 연산자를 받는 기능 작성연산자(+,-,\*,/) 별로 다른 결과값이 나오게 작성예외 상황에 대한 대처(0으로 나누

Step1 에서 작성한 계산기를 토대로 계산기능만 따로 Class 를 만들어서 수행하게 만들고 결과 값을 저장하는 기능까지 추가해보았다.Step1의 기능을 토대로 Calculator 클래스를 만들어 계산기능을 따로 빼주었다.계산된 값을 리스트에 저장하고 출력하는 기능을

프로그램 실행 중 예상하지 못한 상황이 발생하는 것예외를 의도적으로 발생할 수 있음(throw 키워드 사용)예외처리 하지 않으면 프로그램이 중단되므로 try-catch를 통해 예외처리를 해야함컴파일러가 예외 처리를 강제하지 않음컴파일 오류가 발생하지 않고 처리되지 않은

Optional 객체는 null(값이 없음, 참조하지 않음) 을 안전하게 다루게 해주는 객체null을 직접 다루는 대신 Optional을 사용하여 NullPionterException을 방지할 수 있다.if문을 활용하여 null처리를 할 수 있지만 모든 가능성을 예측하

자료구조들을 쉽게 사용할 수 있도록 인터페이스와 구현체를 제동하는 집합.컬렉션을 통해 데이터 저장, 조회. 삭제, 정렬 등 다양한 기능을 구현 가능배열은 크기가 고정되어 있어 한 번 설정하면 변경할 수 없음.컬렉션은 길이를 동적으로 변경 가능하다.요소의 순서를 유지하고

클래스, 메서드 등에서 사용되는 <T>타입 매개변수를 의미한다.타입을 미리 지정하지 않고 유연하게 결정 가능하다.코드의 재사용성 및 타입 안정성을 보장 할 수 있게 된다.코드 재사용성 : 다양한 타입에서 동일한 코드로 재사용이 가능타입 안정성 : 잘못된 타입 사용

익명 클래스를 간결하게 표현하는 문법하나의 추상 메서드만 가져야 하기 때문에 함수영 인터페이스를 통해 구현해야 한다.컴파일 시점에서 람다 표현식을 보고 컴파일러가 익명클래스를 구현한다.이름이 없는 클래스로 별도의 클래스 파일을 만들지 않고 코드 내에서 일회성으로 정의해

Step1 에서는 아래와 같은 기능을 구현 해보았다. 상품 목록 출력 JAVA 프로그램을 실행하면 여러 전자제품을 출력합니다. 제시된 상품 중 입력받은 숫자에 따라 다른 로직을 실행하는 코드를 작성합니다. Product 클래스 생성하기 설명 : 개별 상품을 관리하는 클

CommerceSystem 클래스 생성하기설명: 커머스 플랫폼의 상품을 관리하고 사용자 입력을 처리하는 클래스입니다.Product를 관리하는 리스트가 필드로 존재합니다.main 함수에서 관리하던 입력과 반복문 로직은 이제 start 함수를 만들어 관리합니다.List&l

Category 클래스 생성하기설명 : Product 클래스를 관리하는 클래스입니다.전자제품, 의류, 식품 등 각 카테고리 내에 여러 Product를 만들어 줍니다.List<Product> 은 CommerceSystem 클래스가 관리하기에 적절하지 않으므로 Cat

캡슐화 진행 및 오류사항 수정캡슐화는 처음부터 캡슐화 하여 작업했으므로 생략하였다.음수가 입력될 때의 예외처리는 했지만 양수이지만 리스트의 사이즈보다 큰 숫자를 입력 했을때 IndexOutofBoundsException이 발생하여 처리하는 방법을 찾아보았다.두 문제 다

장바구니 생성 및 관리 기능사용자가 선택한 상품을 장바구니에 추가할 수 있는 기능을 제공합니다.장바구니는 상품명, 수량, 가격 정보를 저장하며, 항목을 동적으로 추가 및 조회할 수 있어야 합니다.사용자가 잘못된 선택을 했을 경우 예외를 처리합니다(예: 유효하지 않은 상

Servlet과 MVC에 대해서 알아보자서블릿(Servlet)이란?server(서버) + -let(작은)의 합성어로 서버에서 실행되어 클라이언트의 요청을 처리하고 그 결과를 동적으로 생성하여 응답하는 자바 프로그램클라이언트가 보낸 데이터를 읽고 해석하며 조회, 계산 등

SPA의 등장 : React-, Vue.js 같은 프레임워크들이 등장하면서 웹 애플리케이션을 하나의 페이지에서 모든 것이 동작하는 것(Single Page Application) 처럼 만들 수 있게 되면서 프론트엔드는 자체적으로 하나의 거대한 개발 영역으로 자리잡게 되

Spring에서 3 Layer Architecture 패턴을 기반으로 Create, Read, Update, Delete 기능을 구현하는 실습을 해보았다. 클라이언트로 부터 요청을 Service로 전달한다.Controller에서 받은 요청으로 Repository에 접근

지난 시간까지 공부했던 CRUD 기능을 기본적으로 구현해보았다.https://github.com/JJK3187/SchedulerAssignmentCreateReadUpdateDeletePostMan 을 통해서 api 가 정상적으로 작동하는지 테스트를 진행해보았

전체 조회 기능 중 작성자 기준으로 전체 조회 기능 및 수정일 기준으로 내림차순 정렬하는 기능 추가수정과 삭제 기능에 비밀번호 입력 을 해야 해당 기능이 작동하도록 하는 기능 추가일정관리 github작성자 기준으로 조회 및 수정일 기준으로 내림차순 정렬Controlle

댓글 생성(댓글 작성하기)일정에 댓글을 작성할 수 있습니다.댓글 생성 시, 포함되어야할 데이터댓글 내용, 작성자명, 비밀번호, 작성/수정일, 일정 고유식별자(ID)를 저장작성/수정일은 날짜와 시간을 모두 포함한 형태각 일정의 고유 식별자(ID)를 자동으로 생성하여 관리

인증(Authentication): 사용자가 누구인지 확인하는 절차인증 = 신원확인 (로그인)스마트포 잠금을 지문이나 얼굴 인식으로 해제하는 것건물 출입구에서 신분증을 제시하여 신원 확인받는 것인가(Authorization): 인증된 사용자가 특정 리소스나 기능에 접근

엔티티를 영속적으로 저장하는 환경JPA에서는 엔티티의 생명주기를 관리하고, 애플리케이션과 데이터베이스 사이에서 수많은 최적화 작업을 해주는 논리적인 공간(메모리 공간)1차 캐시와 동일성 보장영속성 컨텍스트는 일종의 Map형태의 캐시 저장소를 가짐1차 캐시에 엔티티가 저

일정을 생성, 전체 조회, 단건 조회, 수정, 삭제할 수 있습니다.일정은 아래 필드를 가집니다.작성 유저명, 할일 제목, 할일 내용, 작성일, 수정일 필드작성일, 수정일 필드는 JPA Auditing을 활용합니다.일정관리2 github기존 일정관리 앱에서 진행한 일정

연관관계 구현일정은 이제 작성 유저명 필드 대신 유저 고유 식별자 필드를 가집니다.일정관리2 github일정 Entity안에 유저를 생성controllerservice

유저에 비밀번호 필드 추가설명Cookie/Session을 활용해 로그인 기능을 구현조건이메일과 비밀번호를 활용해 로그인 기능을 구현일정관리2 github유저 EntityControllerService처음 비밀번호 확인 중 맞지 않는 경우가 아닌 맞는 경우로 예외처리를

Validation과 @RestControllerAdvice 를 사용한 예외처리PasswordEncoder를 이용한 비밀번호 암호화일정관리2 githubValidation 사용@RestControllerAdvice을 이용해 IllegalStateException을 한번

생성한 일정에 댓글을 남길 수 있습니다.댓글과 일정은 연관관계를 가집니다.댓글을 저장, 전체 조회할 수 있습니다.일정관리2 github댓글을 작성하고 조회하는 과정에서 QueryArgumentException이 발생하여 조회가 되지 않음기존에 작성한 코드중 메서드명(f

@PageableDefault는 페이지네이션을 쉽게 할 수 있게 만드는 어노테이션으로 Pageable 객체를 메서드 파라미터로 받을 때 사용됩니다. @PageableDefault 어노테이션의 속성을 지정하여 페이지네이션 기본 속성값을 세팅할 수 있습니다.size : 한

@RequestParam을 사용한 코드를 PostMan을 통해 테스트 할 때 params값이 없을 경우 에러가 발생@RequestParam에 디폴트 값인 (required = true)로 적용되어 null일 경우 오류가 발생하여 해당 부분을 수정Service 코드nul

이번 프로젝트에서 보안을 담당하며 Spring Security와 JWT를 연동하여 인증 시스템을 구축하였다. 단순히 코드를 복사하는 것이 아니라, 전체적인 데이터 흐름(Request ~ Response)을 파악하기 위해 구조도를 정리해 보았다.Spring Securit

이커머스 백오피스 프로젝트를 진행하며 모든 API 응답을 일정한 양식으로 반환하도록 구현하는 중 로그아웃 기능에서만 우리가 설정한 공통 응답 객체가 전달되지 않고, 응답 바디가 null로 반환되는 문제가 발생.기존 로직: 로그아웃 성공 시 별도의 반환 데이터가 필요 없

이 세 가지는 실행되는 시점과 관리되는 영역(Context)에서 가장 큰 차이가 남.인터셉터는 DispatcherServlet과 Controller 사이에서 요청을 가로채는 역할을 함.주요 메서드preHandle(): 컨트롤러 실행 전. 리턴값이 false이면 요청을

N+1 문제는 연관 관계가 설정된 엔티티를 조회할 때, 의도하지 않은 추가 쿼리가 발생하는 현상.1 (조회 쿼리): 처음에 대상 엔티티를 조회하기 위한 쿼리 1번.N (추가 쿼리): 조회된 결과가 N개일 때, 연관된 데이터를 가져오기 위해 각 결과마다 추가 쿼리가 N번

Spring Boot 애플리케이션을 AWS EC2(t4g.small) 환경에 Docker Compose를 활용하여 배포함. 특히 로컬 환경과 서버 환경의 CPU 아키텍처 차이(x86 vs ARM64)로 인한 문제를 해결하며 멀티 플랫폼 빌드의 중요성을 학습함.1\. V

AWS Systems Manager (SSM) Parameter Store를 활용한 환경 변수 관리application.yml에 외부 설정값(S3 버킷명, DB 정보 등) 주입보안 강화: GitHub에 직접 노출하기 위험한 Access Key, Secret Key, D

프로필 이미지를 서버가 아닌 AWS S3에 저장하고, 보안상 안전하게 접근하기 위해 Presigned URL을 발급하는 기능을 구현함. 개념: AWS 자격 증명을 가진 서버가 특정 객체에 대해 일정 시간 동안만 접근을 허용하는 임시 URL을 서명하여 발급하는 방식.장점

VPC (Virtual Private Cloud): AWS 클라우드 내에 논리적으로 격리된 사용자만의 가상 네트워크 공간.Subnet (서브넷): VPC를 다시 작은 단위로 쪼갠 네트워크 망. (Public/Private으로 구분)IGW (Internet Gateway

데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위를 의미. "전부 성공하거나, 아니면 아예 실패하거나(All or Nothing)"라는 원칙을 통해 데이터의 정합성을 보장.ACID 원칙Atomicity(원자성): 한 트랜잭션 내의 모든 작업은 하나의 단위로 처

커머스 시스템을 설계하던 중, "상품 가격이 변동되면 과거의 주문 내역은 어떻게 유지되는가?"라는 문제에 직면함. 이를 해결하기 위한 데이터 보존 방식인 스냅샷 패턴을 학습함.데이터베이스 설계에서 특정 시점의 상태를 그대로 복사하여 저장하는 방식을 의미함. 보통 DB

실제 서블릿 컨테이너(Tomcat 등)를 띄우지 않고, 스프링 MVC의 동작을 재현하여 컨트롤러 레이어를 테스트할 수 있게 해주는 프레임워크.장점: 서버를 구동하지 않으므로 테스트 속도가 매우 빠르고, HTTP 요청과 응답을 모킹(Mocking)하여 세밀하게 검증할 수

결제 확인(confirm) API를 호출했을 때, 포인트가 차감되어야 함에도 차감되지 않는 현상이 발생했다. 흐름: PaymentService.confirmPayment() └─► OrderService.completePayment() ← 포인트 차감

QueryDSL은 JPQL의 한계를 넘어서 타입 안전하게 작성하기 위한 라이브러리다.JPQL의 한계 : 문자열 기반으로 자동완성, 리팩토링 불가 / 컴파일 시 검증 불가 / 가독성 저하QueryDSL의 장점타입 안정성 : 자바 코드로 쿼리를 작성하므로 컴파일 시점에서

사용자가 입력한 조건에 따라 유연하게 쿼리를 생성하는 방식예시: 이름만 입력할 경우 이름으로 검색, 이메일만 입력하면 이메일로 검색, 둘 다 입력하면 둘 다 조건으로 검색동적 쿼리가 필요한 이유기존 방식의 한계 : 조건이 조금만 바뀌어도 메서드가 늘어나거나, 코드가 중

모든 데이터를 도서관(DB)에서 찾아오기엔 너무 머니까, 자주 보는 책은 내 책상(Cache)에 미리 꺼내두는 것. 책상이 꽉 차면? 안 보는 책부터 치워야 함 데이터베이스(DB)데이터를 영구적으로 저장하며 항상 정확성과 정합성을 유지하는 시스템.디스크 기반이라 안정적

Redis는 “Remote Dictionary Server”의 약자로,데이터를 메모리(RAM)에 저장하는 초고속 Key-Value 데이터베이스입니다.Redis의 특징Spring이 제공하는 Redis용 클라이언트Java코드로 Redis 명령어를 대신 실행해주는 도구흐름도

팀 프로젝트인 배달 커머스 백엔드 프로젝트의 핵심 도메인인 결제(Payment) 시스템을 설계하고 포트원(PortOne) API 연동 흐름을 학습했다.단순히 API 문서를 보고 따라 치는 것이 아니라, "결제 요청의 주체는 누구인가?", "웹훅은 정확히 어느 타이밍에

결제 시스템에서 결제를 검증하는 트랜잭션과 웹훅을 저장하는 트랜잭션을 분리했을 때, 웹훅 저장 트랜잭션이 실패할 경우 보상 트랜잭션이 필요한가?웹훅 저장은 결제 완료의 핵심 로직이 아니라 결제 사실을 기록하는 로그성 작업이기 때문에, 보상 트랜잭션이 아닌 재시도 로직으

실제로 PortOne과 연동하여 테스트 결제를 진행하는 중 결제는 진행되었으나 결제 검증은 실패하는 상황이 발생v2를 이용해서 결제 테스트를 진행하였으나 백엔드 코드는 v1 버전을 기준으로 작성되었음txId로 /payments/{txId} 조회 → 404 발생dbPay

스프링 커머스 백엔드를 공부하면서 결제/환불 시스템에서 발생할 수 있는 동시성 문제와그 해결 방법들을 정리했다.두 요청이 거의 동시에 재고를 읽으면 둘 다 "재고 있음"으로 판단하고 차감할 수 있다.결과적으로 재고가 음수가 되거나 포인트가 두 번 차감되는 문제가 생긴다

결제/환불 시스템에서 동시성 이슈(중복 결제, 중복 환불, 잔액 불일치 등)를 방어하기 위해 JPA의 비관적 락(Pessimistic Lock) 을 적용했다.그런데 내가 작성한 Mockito 기반 테스트에서는 기대했던 “락 대기/차단” 동작이 전혀 나타나지 않았고, 마

프로젝트의 핵심 도메인인 결제/환불(Payment/Refund) 과 쿠폰(Coupon) 시스템에 적용된 동시성 제어(락) 방식을 리뷰하고,현재 아키텍처의 정합성 평가, 잠재적 문제점, 개선 방안을 정리했다.결제/환불은 ‘돈’이 오가는 도메인으로 처리량보다 완벽한 데이터

다중 인스턴스 환경에서 커피숍 주문 시스템의 포인트 결제/충전 기능 구현다수의 요청이 동시에 발생할 때 나타나는 데이터 정합성(Lost Update) 문제 해결동일한 사용자가 동시에 포인트를 충전하거나 여러 번 결제를 시도할 때,DB의 포인트 잔액(balance)을 읽

여러 명이 하나의 프로젝트를 진행하다 보면, 각자의 코딩 스타일과 선호하는 단어가 다르기 마련이다.이번 프로젝트에서는 "마치 한 사람이 짠 코드처럼 보이게 만드는 것" 을 목표로 삼았고, 이를 위해 개발 시작 전 팀원들과 함께 규칙들을 정리했다.단순히 변수명을 맞추는

Product 도메인 Entity를 구현하다가 @Table의 indexes 속성을 마주쳤다. 인덱스가 성능에 좋다는 건 알고 있었지만, 막상 어떤 컬럼에 걸어야 하는지, 걸면 무조건 빠른 건지 명확하게 정리된 적이 없었다. 그래서 이번에 인덱스에 대해서 찾아보았다.책의

상품 등록 API를 구현하면서 모든 상품에 공통으로 들어가는 텍스트가 있었다.배송 안내 (deliveryInfo)환불 정책 (refundPolicy)처음에는 서비스 코드나 엔티티 생성 로직에 문자열을 직접 넣는 방식도 고려했다. 하지만 정책 문구는 운영 중 바뀔 가능성

상품 이미지를 S3에 저장할 때, 아래 두 가지 방식 중 어떤 것을 선택할지 고민했다.❌ 서버를 통해 S3에 업로드하는 방식✅ 클라이언트가 S3에 직접 업로드 (Presigned URL) 하는 방식이미지 파일이 서버를 경유하므로 네트워크/메모리 부담 발생파일 크기가 클

한 도메인에 많은 API를 구현하다 보니 Service 클래스의 코드가 지나치게 길어졌다.기능별로 코드를 찾기 어렵고, 가독성이 크게 떨어졌다.CQRS (Command Query Responsibility Segregation) 란, 명령(Command) 과 조회(Qu

한정판 드랍(Drops) 도메인에서 재고 차감 및 상태 전이 로직에 낙관적 락(Optimistic Lock)을 도입했다.초기에는 단일 인스턴스 환경이고 충돌이 잦지 않을 것이라 예상하여, 성능상 이점이 있는 낙관적 락을 선택했다. 하지만 서비스 오픈 시점에 트래픽이 몰

드랍 조회수는 애플리케이션 메모리 카운팅 대신 Redis 중복 방지 키(SETNX + TTL) 와 DB 원자 증가 쿼리를 결합해, 고트래픽에서도 중복 카운트를 억제하고 DB 업데이트 부하를 줄였다.드랍 상세 페이지는 오픈 직전/직후 트래픽이 몰리며, 같은 사용자의 반복

같은 사용자가 동일한 드랍을 반복 조회할 때마다 DB 조회수가 증가해 과집계가 발생하고, DB UPDATE 부하도 높았습니다.DropsQueryService에서 Redis SETNX로 중복 방문을 선점한 뒤 DB를 증가시킵니다.📋 처리 흐름💡 rollbackView

상품 목록·상세 API는 트래픽이 높아 동일 요청이 반복되는데, 매번 DB를 조회하면 부하가 빠르게 누적됩니다.반대로 TTL을 길게 잡으면 변경사항 반영이 늦어 오래된 데이터(stale data) 노출 위험이 커집니다.CacheConfig에 캐시 영역을 분리하고, 조회