전체 조건

• MySQL 서버에서 InnoDB 스토리지 엔진 사용
• innodb_lock_wait_timeout: 50초(기본값)
• 두 개의 터미널/세션을 사용해 실행

테스트 과정

1. 테스트 테이블 생성

CREATE TABLE accounts (
    id INT PRIMARY KEY,
    balance INT
) ENGINE=InnoDB;

INSERT INTO accounts VALUES (1, 100), (2, 100);

2. Session A: 트랜잭션 시작 후 레코드 잠금

START TRANSACTION;
UPDATE accounts SET balance = balance - 10 WHERE id = 1;
-- 여기서 COMMIT 하지 말고 대기!

• id = 1 행에 쓰기 잠금 (exclusive lock) 이 걸린다.
• 트랜잭션을 커밋하지 않았기 때문에 락은 유지된다.

3. Session B: 같은 레코드에 접근 시도

START TRANSACTION;
UPDATE accounts SET balance = balance + 20 WHERE id = 1;

• id = 1은 이미 Session A에서 락을 걸고 있으므로, Session B는 락 해제를 기다리며 대기 상태에 빠진다.

4. 일정 시간 후 Lock wait timeout exceed 에러 발생

• 기본 설정 기준 50초 이상 대기하면 위와 같은 에러가 발생한다.

문제 발생 원인

원인) Session A가 UPDATE를 실행한 후 트랜잭션을 종료하지 않았기 때문

• 트랜잭션이 종료되지 않으면 락은 계속 유지되며, 다른 트랜잭션은 해당 레코드에 접근할 수 없다.
• Session B는 락을 얻기 위해 기다리다 해당 에러가 발생했다.

해결방법

Session A 에서 빠르게 커밋하기

COMMIT;

커밋 → 락 해제 → Session B는 update 쿼리 실행 가능

🚨 명시적으로 트랜잭션을 시작했을 때(START TRANSACTION)을 사용했을 때는 “트랜잭션의 끝을 명확히 닫아주는 것”이 매우 중요하다. 그렇지 않으면 락이 유지되며 다른 트랜잭션이 블로킹되거나 타임아웃으로 이어질 수 있다.

1부. 취업난 속에서도 살아남는 신입 개발자의 전략: 멘토링 현장에서 찾은 생존 팁

"취업 = 실력 + 태도 + 운" 여기서 실력은 어떻게 기를 수 있을까?

실력은 개발 지식 + 개발 지식의 적용이다. 여기서 말하는 개발 지식은 CS 공부를 말하고 적용은 이를 코드에 적용하는 것이다.

ex. 인덱스 : explain 살펴보기 , 1000만개 이상 데이터 넣고 인덱스 걸기 전/후 파악 AOP: 트랜잭션 update했을때 commit을 하는데 그 전에 다른 호출을 하면 값이 달라짐(어노테이션의 구성, 동작원리 코드로 이해하기)

• 용어와 개념은 제대로 이해하고 이를 정의할 줄 알아야한다.
• 기술을 배울때는 해당 기술이 어떤 목적으로 생겼으며 어떤 과거 기술이 영향을 받았는지 연관지어 공부해야한다.
• 모든 기술에는 장/단점이 있다. 이를 파악해둬야 나중에 어떤 기술을 사용할때 선택의 기준이 된다. → 연구자는 1%라도 개선의 가능성이 있으면 연구하지만 엔지니어는 비용과 효율을 생각해야하기 때문에 장단점을 알고 있어야한다.
• CS 공부에 왕도는 없다. 절대적인 시간을 쏟아부을 수 밖에 없다.

그럼 태도는 무엇인가? 일을 어떻게 대하는가/바라보는가이다.

그렇다면 우리는 태도를 어떻게 면접관에게 알릴 수 있을까?

• 포르폴리오( 깃헙을 첨부하면 코드를 꼭 본다⭐)
• 소규모(10-20명의 유저)서비스를 개발하고 운영해본 경험 이때, 가벼운 배포 / 도메인 구입 / aws 사용 / 홍보 등 적은 비용에 제한된 환경에서 개발해본 경험이 좋다.
• 사용자의 요구사항이나 리뷰를 반영해본 부분을 블로그에 기록하기⭐

2부. 데브코스 현업까지: FE 수료생이 들려주는 실전 취업 사례와 전략

이력서 Tip)

• 본인을 소개하는 3~4 문장은 머릿말에 작성하지 말고 마지막에 작성하자 → 이력서를 쭉 읽고 요약 소개처럼 느껴지는게 point!
• 객관적인 자료를 확인할 수 있는 정략적인 수치와 지표 사용하기
• 성능개선 전/후와 같은 기술 외적으로도 어필 요소가 있다면 작성하기 ex. PR 규칙 적용을 통해 협업 능력 기여 등

회사 지원 Tip)

• 하향 지원 → 상향 지원 → 적정 지원
• 3년차 공고에도 지원해보기 → 신입 지원인 걸 염두하고 질문하니 너무 걱정말고 일단 지원해보자!

면접 준비 Tip)

• AI를 활용해 이력서/포폴 위주 예상 질문에 답변하는 연습하기
• 모집 공고에 작성되어 있는 기술 스택 준비하기
• 질문에 대한 대답 후, 한줄 요약으로 정리해서 다시 말하기
• 비대면 면접이라면 컨닝하지 말자! 눈이 움직이는거 다~~ 보인다.
• 면접 끝나면 꼭! 질문 복기하기

포폴 Tip)

• 블로그에 게시글 작성해 활용하자. 이떄, 기록이 초점이 아니라 자신만의 언어로 남기는게 중요하다 ex. 코테 접근 방식이나 문제풀이 해설, CS 공부, 프로젝트 유지보수한 과정, 회고 등
• 특히, 프로젝트 리팩토링하는 경우 전/후를 문서화해서 성능 개선이나 자동화 적용 등을 하면 좋다.

무엇보다 가장 중요한 건! 취준은 장기전이라 번아웃이 오지 않게 자신의 페이스로 준비하자 + 운동

3부. 현업 개발자가 직접 알려주는 "내가 함께 일하고 싶은 신입 개발자"

1. 호기심을 뿜어내는 동료

분기별, 매년 회고를 통해 나는 어떤일을 하고있는지, 하는일이 어떤 방향성을 갖는지 생각해보는 시간 갖기

2. 주변에 관심를 많이 가지는 동료

주변에 관심이 많으면 결국 자신의 성장으로 돌아온다. 작은 행동이 스노우볼처럼 되돌아올 수 있다.

3. 질문을 잘 하는 동료

이때 동료와의 컨텍스트 중요한데, 내가 말하는 걸 상대가 100% 이해하는 건 힘들다. 신입의 입장에서 선임에게** "자주 질문하는게 낫다. 단, 어느정도 찾아보고 질문해야한다" ** → 혼자 딥하게 찾아보면 나중에는 방향성이 잘못되어 수정하는 데 시간이 더 걸린다. → 여러번 맞은 방향성으로 가고 있는지 질문하는게 Best!

4. 성장에 대한 호기심

시니어가 되어도 계속 공부해야한다. 회사 퇴근하고 나서도 주말에도 추가공부하신다고 한다...

5. 주어진 일만 하는 개발자보다는 일을 만드는 개발자

사소한 거라도 주변 동료에게 도움이 되는것 만들기

6. 현업자가 어떤일을 하는지 들여다보기

기술 블로그, 기술 컨퍼런스 영상 활용하기

✅ 회고) 나의 실천 체크리스트

강의를 듣고 나서 어떤 부분을 보완해야하는지 리스트 형태로 만들었다. 앞으로 하나씩 지워나가면서 해당 내용들을 나에게 적용해봐야겠다👀

• CS 공부한 내용 코드로 적용해서 이해하기
• CS 공부한 내용은 블로그에 작성하고, ChatGPT와 대화하면서 정리하기
• 깃허브(GitHub) 깔끔하게 정리하기
• 기존 프로젝트 'Gymmate' 유지보수 하기
• 이력서/포트폴리오 꾸준히 수정하고 업데이트하기

다시보기 링크🔗

https://youtube.com/@programmerschannel?si=TDmfQd52f-HAmE_s

문제 상황

프론트에서 Swagger UI로 API를 실행할 때 @RequestPart로 JSON을 받는 경우, Swagger는 이를 file로 인식해서 Content-Type: application/octet-stream으로 전송하게 되고, 이로 인해 Content-Type 'application/octet-stream' is not supported 오류가 발생한다.

2025-04-12T02:10:40.517+09:00  WARN 20456 --- [gymmate] 
[nio-8080-exec-5] .m.m.a.ExceptionHandlerExceptionResolver : 
Resolved [org.springframework.web.HttpMediaTypeNotSupportedException: 
Content-Type 'application/octet-stream' is not supported]

이를 해결하기 위해서는 @RequestPart를 String으로 받고, 컨트롤러 내부에서 직접 JSON을 파싱하는 방식으로 변경해야 한다.

그러면 @Valid 으로 request 에 대해 검증을 진행할 수가 없다. @RequestPart로 JSON을 받는 경우, Swagger에서 등록, 수정, 삭제에 대해서 API 실행을 할 수 없고 조회하는 것만 가능한데 괜찮은 걸까?

chatGPT 답변

실제 운영 환경에서는 대부분 API 테스트를 Postman, Insomnia, 실제 프론트엔드 연동으로 진행해. Swagger는 문서 + 스펙 안내 도구 역할이 더 크고, Swagger에서 실행이 안 된다고 해서 API 자체가 문제 있는 건 아니다.

결론, 지금 구조 유지 + Swagger 설명 강화 + Postman 테스트 제공

문제 발생

FE팀에서 개발 중 Swagger UI에서 API 테스트를 위해 Execute 버튼을 눌렀는데 CORS 오류가 발생했다. 처음엔 Spring Security 설정에 문제가 있는 줄 알고 CORS origin을 추가했지만, 문제가 해결되지 않았다. 원인을 찾아보다가 Swagger 자체 설정도 고려해야 한다는 것을 알게 되었고, 결국 SwaggerConfig와 SecurityConfig를 함께 설정하면서 문제를 해결할 수 있었다.

해결을 위해 참고한 블로그

CORS란?

CORS(Cross-Origin Resource Sharing)는 브라우저의 보안 정책 중 하나로, 다른 origin으로 요청을 보낼 때 이를 제어한다. 여기서 origin은 프로토콜 + 도메인 + 포트 조합을 의미한다.

예를 들어, 클라이언트가 http://localhost:3000에서 실행 중인데 API 서버는 http://localhost:8080이라면, 서로 다른 origin으로 판단되어 브라우저가 보안 상 요청을 차단한다. 이때 서버가 명시적으로 해당 origin을 허용해야만 정상적인 요청이 가능하다.

언제 CORS 설정이 필요 없을까?

Swagger UI가 백엔드 서버와 동일한 origin에서 실행될 경우, 예를 들어 http://localhost:8080/swagger-ui/index.html처럼 Swagger 문서가 백엔드 서버에서 함께 서빙되고 있을 때는 CORS 오류가 발생하지 않는다. 이 경우에는 브라우저 입장에서 동일한 origin으로의 요청이기 때문에 setAllowedOrigins() 설정 없이도 API 요청이 가능하다.

언제 CORS 설정이 필요할까?

반대로, 프론트엔드 개발 중 Swagger UI를 http://localhost:3000 같은 다른 origin에서 띄우는 경우, Swagger가 백엔드 서버(localhost:8080)로 요청을 보내면서 브라우저가 CORS 정책 위반으로 차단한다.

이런 경우에는 Spring Security에서 아래와 같이 CORS 설정을 해줘야 한다.

configuration.setAllowedOrigins(List.of("http://localhost:3000"));

SwaggerConfig도 함께 설정해야 하는 이유

CORS 설정만으로 문제가 해결되지 않는 경우가 있다. Swagger UI는 OpenAPI 문서에 명시된 서버 주소를 기준으로 API 요청을 보내는데, 별도로 서버 주소를 설정하지 않으면 Swagger가 문서를 호스팅하고 있는 origin이 아닌 다른 경로로 요청을 보낼 수도 있다.

이럴 때는 SwaggerConfig에 아래와 같이 서버 주소를 명시적으로 설정해줘야 한다.

@Bean
public OpenAPI openAPI() {
    return new OpenAPI()
        .addServersItem(new Server().url("/"));
}

이 설정은 Swagger가 현재 문서를 띄우고 있는 origin을 기준으로 상대경로로 API 요청을 보내도록 한다.

정리

Swagger를 사용할 때 CORS 문제 없이 API 요청이 잘 되기 위해서는 아래 두 가지 설정이 모두 필요할 수 있다.

배포 환경에서는 실제 도메인(https://example.com)도 CORS 허용 목록에 포함해줘야 한다. 프론트엔드 개발 환경(localhost:3000)에서도 Swagger를 통해 API 테스트를 원활하게 하려면 위의 설정을 모두 확인해봐야한다.

Web server failed to start. Port 8080 was already in use. 
Action: Identify and stop the process that's listening on port 8080 
or configure this application to listen on another port.

찾아보니까 대부분 아래와 같은 방식의 해결방법으로 진행하더라

1. cmd를 관리자 모드로 실행
2. netstat -ano | findstr 8080 명렁어 입력
3. taskkill /f 1234 /PID 명령어로 강제 종료
4. 인텔리제이 재실행

근데 찾아본 방법으로 진행했는데도 현재 실행중인 8080포트에 대해서 아무런 값이 나오지 않았다.

그래서 다른 방법으로 포트 충돌을 해결했다.

1. cmd를 관리자 모드로 실행
2. net stop winnat 과net start winnat 명령어 입력
3. 인텔리제이 재실행

net stop winnat 과 net start winnat 명령어

winnat 이란? WinNAT(Windows Network Address Translation)은 Windows에서 NAT(Network Address Translation) 기능을 제공하는 서비스이다. 특히, Windows에서 Docker, WSL2, Hyper-V 등의 가상화 네트워크를 사용할 때 이 서비스가 백그라운드에서 네트워크 주소를 매핑해준다.

• net stop winnat → WinNAT 서비스를 중지해 네트워크 포트 포워딩 설정 등이 해제되는 걸 의미한다

• net start winnat → WinNAT 서비스를 다시 시작

포트 충돌 문제가 해결된 이유?

• 8080 포트를 점유하고 있던 게 일반 프로세스가 아니라, winnat을 통해 설정된 포트 포워딩이었을 가능성이 있다. → 이 경우 netstat로도 안 보이거나 LISTENING 상태가 아니어서 PID가 안 나올 수 있다.

• Docker를 사용한다면 내부적으로 8080 포트를 컨테이너에 포워딩할 수 있고, 이건 WinNAT을 통해 처리된다.

만약 Windows에서 8080 충돌 발생했는데 netstat -ano 해도 안 보인다면?

• WSL2 접속 >> wsl
• 내부에서 포트 확인 >> `sudo netstat -tuln
• 현재 8080 포트를 LISTEN 프로세스가 누군지 파악 >> lsof -i :8080 | grep LISTEN | awk '{print $1, $2}'

1. 3306 포트를 사용 중인 프로세스 ID(PID) 찾기 명령 프롬프트(CMD)를 관리자 권한으로 실행한 후, 아래 명령어를 입력

   netstat -aon | findstr :3306

2. 해당 PID의 프로세스 강제 종료 PID를 확인한 후 아래 명령어로 프로세스를 종료

   taskkill /PID 1234 /F

결과

문제상황

pc가 새롭게 시작될때마다 docker에서 실행중인 mysql에서 포트 충돌이 발생하는데 이유가 있나?

1. 컴퓨터를 종료한 뒤에 아래 명령어를 했을때 실행이 되는지, 문제가 발생하는지 실험

   cmd 에서
   docker exec -it [mysql_container_name] mysql -u root -p

위 명령어로 실행했을때 접속이 제대로 되었다. 그러면 뭐가 문제였을까?

이전에 수업 진행하면서 MySQL Workbench에서 실습을 진행했었는데 여기에서 3306으로 포트가 연결된게 있었나보다..

docker에서도 3306으로 mysql을 실행하다보니 포트 충돌이 발생된 듯 하다. 윈도우에서 mysql 관련된 부분을 제거하니 연결이 잘 됐다. 특히 mysqlServer 부분 제거하니 DBeaver에 연결이 잘 됐다.

🔍 문제를 찾아간 과정

• GitHub Actions에서 실행한 deploy.yml의 Job 수행 과정에서 문제가 발생한 지점을 확인했다.
• 태그(Tag) 생성, 릴리즈(Release) 작업, 도커 이미지 빌드 및 푸시까지는 정상적으로 완료되었다. 그러나 새로운 이미지를 다운로드하고 컨테이너를 실행하는 과정에서 오류가 발생했다. → docker run 명령이 정상적으로 실행되지 않아 컨테이너가 시작되지 않음.

🚨 문제 원인: 잘못된 레지스트리 경로 사용

• GHCR과 Docker Hub는 별개의 레지스트리

• ghcr.io는 GitHub Container Registry(GHCR)*이고, docker.io는 Docker Hub임. 즉, GHCR에서 이미지를 가져오려면 GitHub 사용자명 또는 GitHub 조직명을 사용해야 함.

• GitHub 사용자명과 Docker Hub ID는 다를 수 있음

문제가 발생한 코드

docker pull ghcr.io/[dockerhub 아이디]/${{ env.DOCKER_IMAGE_NAME }}:latest

즉, dockerhub 아이디가 아닌 git 사용자명으로 작성해야한다

해결된 코드 (올바른 경로로 수정)

docker pull ghcr.io/[github 아이디]/${{ env.DOCKER_IMAGE_NAME }}:latest

오류가 발생했는데도 Job이 실패로 표시되지 않는 이유

• GitHub Actions에서 실행된 명령어가 실패했어도 GitHub Actions가 이를 감지하지 못하는 경우가 있음.

  • 특히 외부 실행 환경(AWS SSM, SSH, Docker 내부 실행 등)에서 오류가 발생할 경우, GitHub Actions 자체는 실행 성공(Success)으로 인식할 가능성이 있음.

🔍 오류를 빠르게 찾는 방법

1. GitHub Actions 로그를 확인 : Actions 페이지에서 실행된 로그를 확인하여 오류 메시지를 찾기.

   
   

2. set -e로 명령이 실패하면 즉시 종료하도록 설정

   set -e
   docker pull ghcr.io/[dockerhub아이디]/${{ env.DOCKER_IMAGE_NAME }}:latest

3. echo $?로 Exit Code 확인 : Exit Code가 0이 아니면 오류가 발생한 것을 의미

   docker pull ghcr.io/[dockerhub아이디]/${{ env.DOCKER_IMAGE_NAME }}:latest
   echo "Docker Pull Exit Code: $?"

4. set -x로 실행되는 명령어 로그 출력

   set -x
   docker pull ghcr.io/[dockerhub아이디]/${{ env.DOCKER_IMAGE_NAME }}:latest

정리 및 요약

set -e, echo $?, set -x 모두 GitHub Actions에서 실행되는 deploy.yml 내의 run 단계에서 추가하면, 해당 Job에서 발생하는 오류를 효과적으로 파악할 수 있다.

HAProxy는 로드 밸런서(reverse proxy)로서, 새 버전을 배포하는 동안에도 기존 서비스가 중단되지 않도록 트래픽을 관리한다.

1. 트래픽을 현재 사용 가능한(healthy) 서버로 보낸다.

• 예를 들어, v1이 실행 중일 때 v2를 배포하는 경우, HAProxy는 v2가 준비될 때까지 계속 v1으로 트래픽을 보낸다.

2. Health Check(상태 검사)를 수행하여 정상적인 서버만 사용한다.

• 새 버전(v2)이 정상적으로 실행되는지 지속적으로 확인한다.
• 만약 v2가 아직 준비되지 않았다면, 기존 버전(v1)으로 계속 트래픽을 보낸다.

3. 새 버전(v2)이 완전히 배포되면 트래픽을 전환한다.

• v2가 준비되면, 기존 요청을 끊지 않고 점진적으로 v1 → v2로 트래픽을 전환한다.
• v1이 더 이상 사용되지 않으면 제거할 수 있다.

실습1

localhost:8080 → ha_prox_1(:8090) → nginx_1 : 즉, 8090으로 요청이 들어오면 ha proxy가 8080인 nginx 페이지로 전환한다.

#ha_proxy 설정파일 생성

echo -e "
frontend http_front 
    bind *:80
    default_backend http_back  #80포트 들어온 모든 요청을 http_back으로 보낸다

backend http_back
    server app_server 172.17.0.1:8080
" > volumes/usr/local/etc/haproxy/haproxy.cfg

• frontend와 backend는 HAProxy의 예약어(설정 블록 키워드)
• http_front와 http_back은 사용자가 설정한 변수명임

실습2

8080(nginx_1)과 8081(nginx_2)로 라운드로빈

echo -e "
frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin  #라운드로빈
    server app_server_1 172.17.0.1:8080 check
    server app_server_2 172.17.0.1:8081 check
" > ${PWD}/dockerProjects/ha_proxy_1/volumes/usr/local/etc/haproxy/haproxy.cfg

• localhost:8090으로 요청할 때, 8080(nginx_1)과 8081(nginx_2)이 번갈아가면서 응답

실습3

app1-127-0-0-1.nip.io => ha proxy => nginx_1:80 - 출력 : Web Server 1 app2-127-0-0-1.nip.io => ha proxy => nginx_2:80 - 출력 : Web Server 2

frontend http_front
    bind *:80
    acl host_app1 hdr(host) -i app1-127-0-0-1.nip.io
    acl host_app2 hdr(host) -i app2-127-0-0-1.nip.io

    use_backend http_back_1 if host_app1
    use_backend http_back_2 if host_app2

backend http_back_1
    server app_server_1 nginx_1:80 check

backend http_back_2
    server app_server_2 nginx_2:80 check
" > ${PWD}/dockerProjects/ha_proxy_1/volumes/usr/local/etc/haproxy/haproxy.cfg

• app1-127-0-0-1.nip.io으로 들어오면, host_app1에 넣는다.

실습4

app1-127-0-0-1.nip.io > ha proxy => nginx_1_1:80 > Web Server 1-1 출력 app1-127-0-0-1.nip.io > ha proxy => nginx_1_2:80 > Web Server 1-2 출력 app2-127-0-0-1.nip.io > ha proxy => nginx_2_1:80 > Web Server 2-1 출력 app2-127-0-0-1.nip.io > ha proxy => nginx_2_2:80 > Web Server 2-2 출력

## 설정파일 생성
echo -e "
frontend http_front
    bind *:80
    acl host_app1 hdr(host) -i app1-127-0-0-1.nip.io
    acl host_app2 hdr(host) -i app2-127-0-0-1.nip.io

    use_backend http_back_1 if host_app1
    use_backend http_back_2 if host_app2

backend http_back_1
    balance roundrobin
    server app_server_1_1 nginx_1_1:80 check
    server app_server_1_2 nginx_1_2:80 check

backend http_back_2
    balance roundrobin
    server app_server_2_1 nginx_2_1:80 check
    server app_server_2_2 nginx_2_2:80 check
" > ${PWD}/dockerProjects/ha_proxy_1/volumes/usr/local/etc/haproxy/haproxy.cfg

• server app_server_1_1 nginx_1_1:8081 check에서 app_server_1_1은 변수(X), 그냥 식별자(O)
• server app_server_1_1을 server site_server_1_1처럼 바꿔도 된다! ✔ 그 이유는 app_server_1_1은 변수(X), 단순한 HAProxy 내부 식별자(O)이기 때문이다.

: 하나의 Dockerfile 내에서 여러 개의 FROM을 사용하여 빌드 환경과 실행 환경을 분리하는 기법

📌 왜 멀티스테이지 빌드가 필요할까?

1. 빌드 과정과 실행 과정 분리
   → 빌드용 이미지에는 많은 개발 도구가 필요하지만, 실행용 이미지는 최대한 가벼운 것이 좋음.

2. 컨테이너 크기 최적화
   → 빌드가 끝난 후 불필요한 파일(예: 소스코드, 빌드 도구)을 제외하여 작고 빠른 컨테이너를 만들 수 있음.

Docker 멀티스테이지 빌드 최적화

🔹 빌드 최적화란?

Docker는 레이어(layer) 기반으로 이미지를 빌드하며, 각 RUN, COPY, ADD 등의 명령어가 새로운 레이어를 생성한다.
이미 캐시된 레이어가 있으면 다시 실행하지 않고 그대로 재사용하여 빌드 속도를 단축할 수 있다.

🔹 최적화 원칙

1. 변하지 않는 부분(예: 패키지 설치, 의존성 다운로드)은 최대한 위쪽에 배치하여 캐시를 유지하도록 한다.
2. 자주 변경되는 코드(예: 애플리케이션 소스 코드, 설정 파일)는 아래쪽에 배치하여 변경이 발생해도 최소한의 레이어만 다시 빌드되도록 한다.

⚠ 비효율적인 Dockerfile 예제 (잘못된 순서)

FROM openjdk:23 AS builder

# 1️⃣ 애플리케이션 소스 코드 복사 (자주 변경됨)
COPY . /app
WORKDIR /app

# 2️⃣ 패키지 설치 및 빌드 (자주 변경되지 않음)
RUN ./gradlew build

❌ 문제점
소스 코드(COPY . /app)가 위쪽에 배치되어 있기 때문에, 코드가 변경될 때마다 모든 이후 레이어가 다시 빌드된다.
즉, gradlew build가 매번 실행되어 비효율적이다.

✅ 최적화된 Dockerfile 예제 (캐시 최적화)

FROM openjdk:23 AS builder

# 1️⃣ 의존성 설치 (자주 변경되지 않음)
WORKDIR /app
COPY build.gradle settings.gradle ./
RUN ./gradlew dependencies

# 2️⃣ 애플리케이션 소스 코드 복사 (자주 변경됨)
COPY src ./src
RUN ./gradlew build

🔴 최적화된 이유

✔ gradlew dependencies 실행 결과가 캐시되므로 소스 코드만 변경되었을 때 전체를 다시 빌드하지 않는다.
✔ COPY src ./src가 가장 아래쪽에 위치하여, 코드 변경 시 최소한의 레이어만 다시 빌드된다.

변하지 않는 코드(의존성 설치, 환경 설정)는 위쪽, 자주 변경되는 코드(소스 코드, 설정 파일)는 아래쪽에 배치해야 한다.
이 원칙을 따르면 빌드 속도를 크게 단축할 수 있다. 🚀

이럴땐 EBS(SSD)에스왑파일을 생성해 가상 메모리를 만들어 저장 공간을 늘릴 수 있다

🤷‍♀️ EBS(SSD, Elastic Block Store)?

*AWS에서 제공하는 네트워크 기반의 스토리지 *AWS에서 제공하는 OS 입장에서 보면 하나의 블록 디바이스(디스크)처럼 보이기 때문에, 우리가 직접 Swap 용도로 사용할 "임의의 4GB 파일"을 만들 수 있다.

OS는 실제 RAM (1GB) 사용 → RAM이 부족하면 Swap(SSD/EBS) 사용 : free -h 명령어를 실행하면 RAM + Swap을 합쳐서 총 가용 메모리처럼 표시됨.

1. EBS(SSD) 위에 4GB(128MB X 32) 크기의 빈 파일을 생성

sudo dd if=/dev/zero of=/swapfile bs=128M count=32

2. 스왑 파일의 읽기 및 쓰기 권한을 업데이트

sudo chmod 600 /swapfile

3. Linux 스왑 영역을 설정

sudo mkswap /swapfile

4. 스왑 공간에 스왑 파일을 추가

sudo swapon /swapfile

5. 프로시저가 성공적인지 확인

sudo swapon -s

6. /etc/fstab 파일을 편집하여 부팅 시 스왑 파일을 시작

echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

→ 테라폼으로 작성해두면 일일히 EC2에 해당 내용 작성해서 적용시키지 않아도 된다!

locals {
  ec2_user_data_base = <<-END_OF_FILE
#!/bin/bash
yum install docker -y
systemctl enable docker
systemctl start docker

yum install git -y

sudo dd if=/dev/zero of=/swapfile bs=128M count=32
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo sh -c 'echo "/swapfile swap swap defaults 0 0" >> /etc/fstab'

END_OF_FILE
}

📌 Terraform에서 <<-END_OF_FILE 사용법

cat <<-EOF
    Hello
        World!
EOF

• <<- : 들여쓰기 자동 제거
• EOF 이후의 모든 내용이 EOF(End Of File) 마커를 만날 때까지 하나의 문자열로 처리됨

aws cli가 다운받아져 있고 현재 상황에서 aws configure해서 로그인이 되어 있다면 aws configure list하면 목록이 나온다.

그렇기 때문에 springBoot에서 S3 실행하면 따로 api키를 입력하지 않아도 실행이 된다. 이때, AWS 인증 정보를 찾는 우선순위는 아래와 같다.

1. 환경변수
2. aws configure 명령어로 설정된 list
3. application.yml
4. EC2 IAM ROLE

도커 빌드 과정에서 테스트 실패를 회피하는 방법 2가지

도커 빌드 과정에서 테스트가 실패 원인) 해당 환경에서는 aws 인증정보가 없어서

1. dockerfile > RUN gradle build --no-daemon -x test : -x test 옵션을 추가하면 Gradle 빌드 시 테스트를 실행하지 않음.

2. application-test.yml에서 S3 자동 설정 제외 : src/main/resources/application-test.yml에 아래 내용 추가해 테스트 환경에서 S3 서버 찾는 시도를 하지 않도록 막음

spring:
   autoconfigure:
     exclude: io.awspring.cloud.autoconfigure.s3.S3AutoConfiguration

이때 Test class에 @ActiveProfiles("test") 추가

🙋‍♀️ @ActiveProfiles("test")는 Spring Boot가 application-test.yml을 우선 적용하도록 설정하는 역할을 한다. 일반적으로 테스트 코드에서 특정 프로파일을 강제 적용할 때 사용됨.

만약, application-testing.yml 파일을 참조하려면 @ActiveProfiles("testing")으로 설정해야 한다

docker 이미지 빌드, 푸시 방법

Dockerizing 하는 과정

1) 애플리케이션 코드 준비(git pull) 2) Dockerfile 작성 3) docker build로 Docker 이미지 생성 docker build -t seyoen3/app:8 . : .빼먹으면 안된다!!

4) Docker push로 Docker hub에 업로드 docker push seyoen3/app:8

→ 이후 docker pull로 해당 이미지 다운받아 docker에서 컨테이너로 실행가능 docker pull seyoen3/app:8 docker run -d -p 8080:8080 --name app seyoen3/app:8

docker 이미지 빌드, 푸시 자동화

• .github/workflows/deploy.yml에 job 작성
• GitHub Actions를 통해 Docker 이미지를 자동으로 빌드
• GitHub Packages(Container Registry)에 저장
• 해당 패키지 setting에 들어가서 Private(비공개)로 설정해야함

🙋‍♀️Docker 이미지 내부에 환경 변수, API Key, 민감한 설정 파일이 포함될 가능성이 있어 보안 상 해당 패키지를 Private(비공개)로 설정하는게 좋다

• 비공개 패키지를 EC2에서 다운로드하려면?

1. access Token을 생성
2. 로그인 진행

   docker login ghcr.io -u [github아이디]  //이후, password에 accessToken 입력
   

3. docker pull  ghcr.io/your-org/your-private-image:latest
4. EC2에서 `docker run -d -p 8080:8080 --name app [이미지]` 컨테이너 실행

🙋‍♀️ ghcr.io는 **GitHub Container Registry(GHCR)**의 도메인이며, GitHub Packages에서 제공하는 Docker 이미지 저장소이다. 비공개(Private) 패키지는 EC2에서 다운로드하려면 반드시 **docker login ghcr.io 과정을 거쳐야 한다.**(공개(Public) 패키지는 로그인 없이 다운로드 가능)

---

### 서버 작업 <span style="color:red;">  자동화

+ 자동화 대상 : 기존 새 이미지 다운 → 기존 컨테이너 종료 → 새 이미지 실행 → 기존 도커이미지 삭제
+ GITHUB ACTION 에서 도커 이미지 푸시가 완료되면 운영서버에게 교체하라는 명령어를 전송하여 자동배포 완성

1. 리포지터리 세팅에서 AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY 시크릿 변수 생성

2. .github/workflows/deploy.yml에 step추가
```dockerfile
   deploy:
    runs-on: ubuntu-latest
    needs: [ buildImageAndPush ]
    steps:
      - name: AWS SSM Send-Command
        uses: peterkimzz/aws-ssm-send-command@master
        id: ssm
        with:
          aws-region: ${{ secrets.AWS_REGION }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          instance-ids: "i-015d44766db7d2a9f"
          working-directory: /
          comment: Deploy
          command: |
            docker pull ghcr.io/${{ env.OWNER_LC }}/app20250314:latest
            docker stop app1 2>/dev/null
            docker rm app1 2>/dev/null
            docker run -d --name app1 -p 8080:8080 ghcr.io/${{ env.OWNER_LC }}/app20250314:latest
            docker rmi $(docker images -f "dangling=true" -q)

명령어

nslookup: 특정 DNS(Domain Name System) 조회를 수행하는 명령어 curl : Command-line URL tool의 약자로, 터미널에서 HTTP 요청을 보내고 응답을 확인할 수 있는 명령어

ex. curl https://example.com → 브라우저에서 페이지를 여는 것과 동일한 효과)

• AWS : AWS(Amazon Web Services)는 아마존에서 제공하는 클라우드 컴퓨팅 서비스
• 테라폼 : HashiCorp에서 개발한 인프라스트럭처를 코드로 관리하는 오픈소스 도구 → Terraform의 선언적 구성(Declarative Configuration) 문법을 사용하여 클라우드 리소스를 생성, 관리, 업데이트할 수 있다

// AWS 프로바이더 선언
provider "aws" {
  region = var.region
}

✔️ provider "aws" → AWS를 사용하겠다는 선언
✔️ region = var.region → AWS 리전(예: us-east-1, ap-northeast-2)을 변수로 설정
✔️ 이 코드는 Terraform이 AWS 인프라를 관리하는 데 필요한 기본 설정을 정의하는 부분

✅ EC2 100개 생성 방식 비교: AWS 콘솔 vs Terraform**

결론

✔ AWS 콘솔: 클릭 몇 번으로 간단하게 EC2를 생성할 수 있지만, 100개를 만들려면 매우 비효율적이고 실수 가능성이 큼
✔ Terraform: 선언형 코드로 EC2를 자동화하여 빠르고 일관되게 배포할 수 있으며 유지보수도 훨씬 편리함

즉, 대량의 EC2 인스턴스를 생성하려면 Terraform을 사용하는 것이 훨씬 효율적이고 안정적이다!

2. 루트 계정과 AWS IAM

2-1. 관계

• 루트 계정: 최상위 관리자 계정. 해킹 시 심각한 보안 위험 발생 가능
• IAM 계정 : 보안 강화를 위해 루트 계정의 직접 사용을 피하고, 필요한 권한만 부여하여 관리할 수 있도록 하기 위해 생성한다

ex. admin(사용자)에게 AdministratorAccess 정책 부여

이때, 역할에 부여하는 정책은 하나가 아니라 여러 권한을 모아놓은 묶음이다!! 즉, 정책(policy) = 권한 묶음

2-2. 로그인 방법

• 루트 계정 로그인 : 루트계정 + 비밀번호
• IAM 계정 로그인 : 루트계정 ID or 루트 계정 별칭 IAM계정이름 + 비밀번호

루트계정 ID는 어려우니까 루트 계정 별칭을 만들어주고 사용하는게 좋다

2-3. AWS IAM

• AWS IAM에서 권한을 부여할 수 있는 대상은 크게 사용자(User), 그룹(Group), 역할(Role) 3가지이다.

• 역할(Role)에 권한을 부여한다는 의미 = 특정 AWS 리소스나 외부 사용자가 임시로 사용할 수 있는 권한을 부여한다는 의미

• IAM은 글로벌 서비스로 특정 리전에 귀속되지 않는다.

  🤷‍♀️why? AWS 계정(Account) 단위로 역할(Role)을 생성하고 부여하는 방식이기 때문에 만약 IAM이 특정 리전에 귀속된다면, 각 리전에 대해 동일한 IAM 역할을 중복으로 설정해야 하는 불편함이 생긴다.

3. 여러 용어 설명

• 리전 : 하나 이상의 데이터센터가 모여 하나의 가용영역을 형성하는데, 하나의 리전에는 2개 이상의 가용영역(AZ)으로 구성되어 있다. 가용영역은 물리적으로 떨어져있다.

• VPC((Virtual Private Cloud)) : AWS 클라우드 내 가상 네트워크

  ✅ CIDR 블록(서브넷) 비교: /16 vs /24

🔹 비트 표현

1) 10.0.0.0/16

11111111 11111111 00000000 00000000 (앞의 16비트는 고정, 뒤의 16비트(82) 사용 가능) → IP 대역: 10.0.*0.0** ~ 10.0.255.255

2) 10.0.0.0/24

11111111 11111111 11111111 00000000 → IP 대역: 10.0.0.0 ~ 10.0.0.255 (앞의 24비트는 고정, 뒤의 8비트(8*1) 사용 가능)

• 서브넷 : VPC에 속해있는 하위 네트워크
• 라우팅 테이블: 네트워크 패킷이 어디로 가야 하는지 결정하는 지도 같은 역할
• 인터넷 게이트웨이: 퍼블릭 서브넷에서 인터넷과 통신할 때 사용, 이때 게이트웨이 자체는 아무 역할도 하지 않음. 라우팅 테이블에 연결되어야 인터넷 연결이 가능함
• 보안그룹 : EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽

4. 테라폼 프로젝트

• terraform.tfstate, terraform.tfstate.backup 파일에는 민감한 정보(AWS RDS 비밀번호 등)들이 포함되어 있을 수 있어 리포지토리를 private로 관리해야한다.

✅ 퍼블릭 서브넷을 만들 때 필요한 구성

1. VPC 생성
2. 서브넷 생성 (퍼블릭 서브넷)
3. 인터넷 게이트웨이 생성 및 연결
4. 라우팅 테이블 생성 및 IGW로 경로 추가
5. 퍼블릭 서브넷에 라우팅 테이블 연결
6. EC2 인스턴스에 퍼블릭 IP 할당

             ┌──────────────────────────────────────────────┐
             │              (dev-vpc-1)                 │
             │ CIDR: 10.0.0.0/16                        │
             │                                          │
             │  ┌───────────────────────────────────────┐   │
             │  │   Internet Gateway (dev-igw-1)        │
             │  └────────────────────────────────────────┘  │
             │         │                                 │
             │         ▼                                 │
             │  ┌────────────────────────────────────────┐  │
             │  │   Route Table (dev-rt-1)               │
             │  │   0.0.0.0/0 → IGW                      │
             │  └────────────────────────────────────────┘  │
             │         │            │            │       │
             │         ▼            ▼            ▼       │
             │   ┌──────────┐  ┌──────────┐  ┌──────────┐  │
             │   │ Subnet-1 │  │ Subnet-2 │  │ Subnet-3 │
             │   │ 10.0.1.0 │  │ 10.0.2.0 │  │ 10.0.3.0 │  
             │   └────▲─────┘  └────▲─────┘  └────▲─────┘  │
             │        │            │            │       │
             │   ┌────┴─────┐  ┌────┴─────┐  ┌────┴─────┐  │
             │   │  EC2-1   │  │  EC2-2   │  │  EC2-3   │
             │   │ (Public) │  │ (Public) │  │ (Public) │
             │   └──────────┘  └──────────┘  └──────────┘  │
             └──────────────────────────────────────────────┘

테라폼 명령어

terraform init  : 라이브러리 다운로드
terraform plan : 현재 소스 코드가 실행가능한지 검사
terraform apply : 리소스 생성
terraform destory : 리로스 삭제

→ ** "terraform apply와 terraform destroy 명령어를 사용하면 AWS 콘솔에서 직접 클릭하며 리소스를 생성하거나 삭제할 필요가 없다."**

5. IAM - IAM 인스턴스 프로파일 - EC2 인스턴스 연결

• IAM 역할은 EC2에 직접 연결될 수 없고, IAM 인스턴스 프로파일을 통해 연결됨.
• IAM 인스턴스 프로파일은 하나의 IAM 역할만 포함 가능 → 1:1 관계 → 하나의 인스턴스에 여러 개의 IAM 역할을 부여하면 역할 간의 정책 충돌이 발생할 가능성이 높음.

ex. IAM 역할 A: S3 읽기만 허용 / IAM 역할 B: S3 전체 접근 허용 EC2 인스턴스가 두 역할을 모두 가지면, 어떤 정책이 적용될지 모호해짐.

• IAM 인스턴스 프로파일은 여러 EC2 인스턴스에 적용 가능 → 1:N 관계

• 리팩토링 후 코틀린 마이그레이션 진행하는 방향이 좋다.

• 성공한 경우에는 resultCode를 200으로 단일 처리하는 것이 좋다. (실제로 현업에서도 201, 204 등 따로 처리하는 것이 거의 의미가 없다.)

• 서버의 개수가 늘어나면 Stomp와 SSE에 변화가 필요하다. 중간에 처리하는 외부 브로커를 추가해야 한다. → 외부 브로커를 통해 메시지를 중앙에서 관리하면, 여러 서버가 동시에 클라이언트와 통신할 수 있으며, 데이터의 일관성을 유지할 수 있다.

• 채팅의 경우, 처음부터 Stomp로 시작하기보다는 WebSocket으로 먼저 실습해보는 것이 좋다.

다른 팀이 도입한 기술 구현 및 효과

우리팀, POFO 프로젝트 피드백

• 사용자가 작성한 글을 삭제한 경우, DB에 남겨놓는게 더 좋다. → 정책에 따라 DB에 남겨놓지 않을수도 있는데 탈퇴 시 완전 삭제를 진행시키는 방향이 더 좋을 것 같다.

• 소셜 로그인 계정 통합 및 관리자 대시보드 기능이 잘 구현되어 있으며, 실제 서비스에서도 기본적으로 해당 기능들이 구현된 경우가 많다. → 다만, 이메일 인증의 경우 개인정보 보호 방침 때문에 강사님은 이메일과 같은 개인정보를 최대한 받지 않는 방식을 선호하지만 해당 프로젝트는 토이 프로젝트이므로, 해당 내용은 참고하기

추후 프로젝트를 어떻게 고도화하면 좋을까?

아래와 같이 요청하신 내용을 표에 추가하였습니다.

cf) 코틀린으로 마이그레이션 시 라인 수 변화 : 스프링 부트로 혜택을 보고 있기 때문에 코틀린으로 마이그레이션 시 3040% 감소는 어렵고, `5%10%가 이상적임` → 만약, 스프링부트로 게임 개발을 한다면 코틀린으로 마이그레이션 시 코드라인 수가 많이 감소한다는 걸 체감할 수 있을 것이다. → 줄어든 라인수에 집착하기 보다는 코드가 코틀린스러운지를 파악하는게 더 좋을듯!

• Gemmni AI활용한 PR리뷰 써보기 : Gmmini API key env 파일에 넣기
• 로그저장

추가 공부해야하는 개념

• 동시성 이슈 : Redisson Lock
• webSocket : RabbitMQ
• JPQL → QeuryDSL 변환: kept, Qclass
• 페이징 방식 성능 최적화 : 데이터가 많을 수록 offset이 아닌 no-offset 활용해 부하를 줄일 수 있다.
• 현재 Hibernate lazyloading 문제 발생 중.. JPQL 오류와 관련이 있을 수 있음..

• github에서 확인하기

1. github > repository > branch > 해당 파일을 선택한다.
2. history에서 commit 내역을 확인하여 누가 수정했는지 파악한다.

• CLI로 확인하기

1. git blame 파일명 명령어를 사용하면 해당 파일의 각 줄을 마지막으로 수정한 사람을 알 수 있다.
2. git log --follow -- 파일명 명령어를 실행하면 파일의 변경 이력을 추적할 수 있다.

2. PR을 남긴 사람을 필터링하는 방법

1. PR 목록에서 특정 사용자의 이름을 클릭한다.
2. 해당 사용자의 PR만 필터링되어 표시된다.
3. GitHub에서는 is:pr author:사용자명 형식의 검색어를 활용하면 특정 사용자가 생성한 PR을 쉽게 찾을 수 있다.
4. git log --author="사용자명" 명령어를 사용하면 해당 사용자의 commit 내역을 확인할 수 있다.

3.issue 생성 및 branch 생성

1. 작업할 내용을 GitHub Issues에 등록한다.
2. develop 브랜치를 pull받는다.
3. local에서 새로운 branch를 만들고 add → commit → push한다.
4. PR 내용 작성 시 #[issue번호]로 해당 Issues를 언급한다.
5. 해당 브랜치를 merge한다.
6. 모든 Issue 작업이 끝나면 마지막 branch에서 closes #[issue번호]를 붙여 해당 Issue를 close한다. 또는 Issue 탭에서 수동으로 close할 수도 있다.
   ### 4. merge commit

• merge 시 마지막에 commit하는데, 이 부분의 내용이나 제목은 크게 신경 쓰지 않아도 된다.
• 다만, 정상적으로 merge한 것이 아니라 close하는 경우에는 명확한 사유를 남겨야 한다.
  • 예: "기능 불필요로 인해 PR close", "다른 PR과 중복되어 close"
• close한 PR이 나중에 다시 필요할 수도 있으므로, 관련 내용을 이슈나 댓글로 남겨두면 좋다.

• 자바와 코틀린은 호환되므로 점진적으로 변환 가능
• 코틀린은 널포인트익셉션(NPE) 발생이 적음
• 확장 함수를 활용하여 기존 클래스에 기능 추가 가능
• 자바보다 간결한 코드 작성 가능 → but, 요즘은 java 버전이 ↑ 거의 개선됨
• 코루틴 등 다양한 기능 제공

✅ 코루틴이 뭐지? : 코틀린에서 제공하는 비동기 프로그래밍을 위한 경량 스레드임.

🚀 예제 2: 네트워크 요청 (API 1000개 호출) - Java vs Kotlin Coroutine

API를 1000번 호출하는 상황을 가정하고 Java와 Kotlin에서 각각 구현했을 때 성능을 비교해본다.
Java에서는 ExecutorService를 사용하여 멀티스레딩을 구현하고, Kotlin에서는 Coroutine을 사용하여 비동기적으로 실행한다.

💥 Java (ExecutorService 사용)

import java.util.concurrent.*;

public class JavaApiRequest {
    public static void main(String[] args) throws InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(100);
        long startTime = System.currentTimeMillis();

        for (int i = 0; i < 1000; i++) {
            executor.execute(() -> {
                try {
                    Thread.sleep(500); // API 요청을 시뮬레이션
                    System.out.println("API 요청 완료 (Thread: " + Thread.currentThread().getName() + ")");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }

        executor.shutdown();
        executor.awaitTermination(10, TimeUnit.SECONDS);
        long endTime = System.currentTimeMillis();
        System.out.println("Total execution time: " + (endTime - startTime) + "ms");
    }
}

🔹 문제점

• 스레드 풀 크기(100개) 제한으로 인해 동시 요청이 제한적이다.
• 스레드 컨텍스트 스위칭 비용이 발생하여 속도가 느려진다.
• Thread.sleep(500)을 사용하여 스레드가 불필요하게 블로킹된다.

💡 Kotlin (Coroutine 사용)

import kotlinx.coroutines.*
import kotlin.system.measureTimeMillis

fun main() = runBlocking {
    val time = measureTimeMillis {
        val jobs = List(1000) {
            launch(Dispatchers.IO) {
                delay(500L) // API 요청을 시뮬레이션
                println("API 요청 완료 (Coroutine: ${Thread.currentThread().name})")
            }
        }
        jobs.forEach { it.join() }
    }
    println("Total execution time: ${time}ms")
}

🔹 장점

• Dispatchers.IO를 사용하여 비동기적으로 실행되므로 스레드 제한 없이 많은 요청을 처리할 수 있다.
• delay(500L)을 사용하여 스레드를 차단하지 않고 효율적으로 실행한다.
• 코루틴 컨텍스트 스위칭 비용이 적어 성능이 향상된다.

🔥 Java vs Kotlin Coroutine 성능 비교

Q. 실무에서 코틀린과 자바 혼용해서 쓰기도 하나? A. 일부 기업에서는 혼용 가능 멘토님 회사의 경우도 스칼라→ 코틀린으로 전환함( 코틀린이 레퍼런스가 더 많아서 )

2. 코틀린으로 전환하는 방식

• 서비스 단위로 변경 가능
• DTO도 단계적으로 변환 가능
• 데이터 클래스 활용 추천 Tip) AI를 활용한 PR리뷰를 통해 코틀린스러운 코드인지 질문해보기! Tip) IDE에서 제미나이(Gemini) 활용 추천 다운 링크

3. 사이드 프로젝트 및 실무 경험

• 실제 현업에서도 업무량에 따라 사이드 프로젝트 진행 가능 개인 프로젝트가 물경력이 되는 것을 방지하기 위해 노력 필요 성공 사례: 사이드 프로젝트(소개팅 앱)로 높은 수익을 올려 퇴사 후 창업한 사례 존재 단, 앱 개발 시 약관 동의, 개인정보 처리 등 민감 정보 처리 경험 필요

4. 배포 관련 비용 문제

• 프로젝트 규모에 따라 비용 발생 가능 초기에는 무료 프리티어 활용 가능
• 오라클 클라우드 프리티어(VM 2개 제공) → 사이드 프로젝트로 사용(오라클 VM에 DB 올려서 사용) 추천!!! * MySQL은 무료가 없지만 MongoDB 무료 버전 존재

5. MongoDB와 Redis 비교 🌟

• Redis : 휘발성 메모리 기반, 영속성 없음, single 쓰레드 기반이라 사용 시 주의 → DB가 아니다!!!!!
• MongoDB : 디스크 저장, 데이터 처리 및 집계 기능 제공, 트랜잭션 및 ACID 중 몇가지 지킴

6. 취업 시 자바, 코틀린 vs Node.js, Python

• 한국에서는 자바 & 스프링이 대세
• Python은 데이터 처리 및 AI 관련 분야에서 사용
• Node.js는 풀스택 역할 요구하는 경우 많음 → 풀스택 바라는 곳은 가지마...
• 그래도 가고 싶은 특정 기업이 요구하는 기술이 있다면 학습 필요

ex. 한국에서는 코볼(COBOL)거의 사용 안하지만, 미국에서는 시니어 개발자 부족으로 높은 연봉으로 모셔가는 사례가 생김

7. 사이드 프로젝트 경험

• 꾸준한 사이드 프로젝트 진행 추천
• Task 관리의 경우, 트렐로(Trello) 추천
• WebSocket 을 활용한 프로젝트도 해보면 좋다!

ex. 멘토님의 경우, 게임 관련 앱을 개발해 6개월간 광고 수익 450만 원 달성 경험O → 애드센스 적극 활용하길 추천!

프로젝트 상세 조회 API를 호출한 후, 응답 데이터가 정상적으로 반환되고 setProject(res.data);를 통해 상태를 업데이트했지만, 화면(UI)에는 데이터가 표시되지 않는 문제가 발생하였다.

2. 문제 원인 분석

• API 응답을 확인한 결과, res.data의 구조는 다음과 같았다.

  {
    "resultCode": "200",
    "message": "프로젝트 단건 조회가 완료되었습니다.",
    "data": {
      "projectId": 36,
      "name": "이세연",
      "startDate": "2025-03-04",
      "endDate": "2025-03-05",
      "memberCount": 1
    }
  }

• 기존 코드에서 setProject(res.data);로 상태를 설정했기 때문에, project의 상태 구조가 다음과 같아졌다.

  {
    resultCode: "200",
    message: "프로젝트 단건 조회가 완료되었습니다.",
    data: {
      projectId: 36,
      name: "이세연",
      startDate: "2025-03-04",
      endDate: "2025-03-05",
      memberCount: 1
    }
  }

• 그러나, UI에서는 project.name, project.startDate와 같은 방식으로 데이터를 출력하려고 하였고, 실제로 name 값은 project.data.name에 존재하였다.
• 즉, project.name을 참조하려 했으나 undefined가 반환되었기 때문에 화면에 아무것도 출력되지 않았다.

3. 해결 방법

• setProject(res.data.data);로 변경하여 data 내부의 객체만 저장하도록 수정하였다.

  setProject(res.data.data);

• 이렇게 변경한 후, project의 상태 구조는 다음과 같이 변경되었다.

  {
    projectId: 36,
    name: "이세연",
    startDate: "2025-03-04",
    endDate: "2025-03-05",
    memberCount: 1
  }

• 이제 project.name, project.startDate 등 UI에서 참조하는 속성들이 올바르게 매칭되었고, 정상적으로 화면에 표시되었다.

4. 결론

• API 응답에서 불필요한 resultCode, message까지 포함하여 상태를 저장하면, UI에서 데이터를 참조할 때 예상치 못한 문제가 발생할 수 있다.
• setProject(res.data.data);와 같이 API 응답에서 실제 필요한 데이터만 상태에 저장해야 한다.
• 이를 통해 project.name, project.startDate 등의 속성을 UI에서 바로 사용할 수 있게 되었고, 정상적으로 데이터가 렌더링되었다. 🚀

프로젝트 수정 시, 다음과 같은 세 가지 경우가 존재한다.

1. 썸네일 첨부파일만 수정하는 경우 → Content-Type 'application/octet-stream' is not supported.
2. 썸네일 첨부파일과 프로젝트 내용(JSON)도 수정하는 경우 → Content-Type 'application/json' is not supported.
3. 프로젝트 내용(JSON)만 수정하는 경우 → Content-Type 'application/octet-stream' is not supported.

각각의 경우에서 415 Unsupported Media Type 오류가 발생했다

문제 원인

Spring Boot에서 415 Unsupported Media Type 오류가 발생한 이유는 Postman에서 deleteThumbnail 값을 Text로 보내지 않았을 가능성이 크다.

원인) Boolean 타입을 @RequestPart로 받을 경우 발생하는 문제

@RequestPart(value = "deleteThumbnail", required = false) Boolean deleteThumbnail,

위와 같이 Boolean을 @RequestPart로 받을 경우, Spring Boot는 multipart/form-data에서 Boolean 값을 직접 처리하지 못한다.

• Boolean 값은 true 또는 false 값을 기대하지만, multipart/form-data는 기본적으로 String 또는 File 형태로 전달된다.
• Postman에서 false를 입력해도 내부적으로 application/octet-stream으로 인식될 수 있다.
• Spring Boot는 multipart/form-data 내에서 Boolean 값을 직접 변환하지 못해 오류가 발생한다.

💡 즉, Postman이 Boolean 값을 Text가 아닌 application/octet-stream 타입으로 보내면서 Spring Boot가 이를 지원하지 못한 것이다.

문제 해결 방법: String으로 수신 후 Boolean 변환

deleteThumbnail을 String으로 받고 Boolean으로 변환하여 사용하는 방식으로 해결했다.

@RequestPart(value = "deleteThumbnail", required = false) String deleteThumbnailStr, // ✅ String으로 받기

이제 deleteThumbnail을 String으로 받으면서 Postman이 데이터를 반드시 Text 형식으로 보내도록 강제할 수 있다.

• Postman에서 "false"를 Text로 보내면, Spring Boot는 이를 String으로 처리할 수 있다.
• 이후 Boolean으로 변환하여 사용하면 된다.

Boolean deleteThumbnail = deleteThumbnailStr != null && deleteThumbnailStr.equalsIgnoreCase("true");

이 방식은 Spring이 multipart/form-data를 더 자연스럽게 처리할 수 있도록 도와준다.

추가 학습

1. multipart/form-data와 JSON을 함께 처리하기 위한 원리

• multipart/form-data는 여러 개의 데이터를 각각의 파트로 분리하여 전송하는 방식이다.
• JSON과 파일을 함께 전송하려면 각각의 Content-Type을 적절하게 설정해야 한다.
• Spring에서는 @RequestPart를 활용하여 JSON과 파일을 동시에 받을 수 있다.

2. @RequestParam vs @RequestPart

@RequestParam

• 쿼리 파라미터, form 데이터, multipart/form-data 등의 요청 파라미터를 처리할 수 있다.
• 메소드 인수가 String이나 multipart/form-data가 아닐 경우 등록된 Converter 또는 PropertyEditor를 통한 형식 변환에 의존한다.
• Key/Value form 필드와 함께 사용된다.

@RequestPart

• multipart/form-data에 특화되어 있으며 여러 복잡한 값을 처리할 때 사용할 수 있다.
• 메소드 파라미터 타입이 String 또는 MultipartFile/Part가 아닐 경우, 요청 부분의 Content-Type 헤더를 고려하는 HttpMessageConverters에 의존한다.
• JSON, XML 등을 포함하는 복잡한 Content를 포함하는 경우에 적합하다.

3. Spring의 Multipart 처리 방식

• CommonsMultipartResolver vs StandardServletMultipartResolver 비교 → CommonsMultipartResolver는 Apache Commons FileUpload를 기반으로 동작하며, StandardServletMultipartResolver는 Servlet 3.0의 기본 Multipart 기능을 활용한다.
• spring.servlet.multipart.enabled 설정 옵션 → true로 설정하면 Spring Boot에서 Multipart 요청을 자동으로 처리할 수 있다.
  #### 4. **Postman에서 multipart/form-data 전송 시 고려해야 할 사항**
• 파일 전송 시 form-data 방식으로 설정하는 방법 → Postman에서 Body 탭에서 form-data 선택 후 Key에 파일명을 지정하고 Type을 File로 설정해야 한다.
• Boolean 값 전달 시 Text로 설정해야 하는 이유 → multipart/form-data에서는 Boolean 값이 기본적으로 지원되지 않으므로 String으로 변환 후 처리해야 한다.
  #### 5. **Spring에서 JSON을 처리하는 방법**
• @RequestBody vs @RequestPart 차이점 → @RequestBody는 JSON 전체 요청을 변환하고, @RequestPart는 Multipart 요청의 일부로 JSON을 처리한다.
• HttpMessageConverter를 활용한 커스텀 변환 적용 방법 → Spring의 MappingJackson2HttpMessageConverter를 사용하면 JSON을 원하는 객체로 변환할 수 있다.
  #### 6. **파일 업로드 관련 보안 이슈**
• 업로드 파일의 Content-Type 검증 → 파일 확장자만 검증하는 것이 아니라 실제 Content-Type을 검사해야 한다.
• 파일 크기 제한 설정 (spring.servlet.multipart.max-file-size) → 너무 큰 파일이 업로드되지 않도록 적절한 크기 제한을 설정해야 한다.
• 업로드된 파일의 저장 위치 및 접근 제어 전략 → 업로드된 파일을 서버 내부에 저장하는 경우 접근 권한을 제한해야 한다.

정리

Spring Boot에서 multipart/form-data와 JSON을 함께 처리할 때는 @RequestPart를 사용해야 하며, Boolean 값을 @RequestPart로 받을 경우 String으로 변환한 후 처리하는 것이 안전하다.

Postman에서 데이터를 전송할 때는 반드시 Text 형식으로 보내야 하며, multipart/form-data를 사용할 경우 각 필드의 타입을 정확하게 지정하는 것이 중요하다.

+nginx가 없다면, 포트를 다 다르게 해서 매핑해줘야한다. a.com:8080 → site1 b.com:8081 → site2 c.com:8082 → site3

+nginx가 있다면, 같은 포트로 요청이 들어와도 nginx가 분배?를 해준다. a.com:80 → nginx → site1 b.com:80 → nginx → site2 c.com:80 → nginx → site3

브라우저와 nginx가 주고받는 정보는 암호화되어 있다. (http: 암호화X , htpps : 암호화O)

포트로 구분 / 도메인으로 구분하는건 nginx에게는 쉽지만 사람에게는 도메인으로 구분하는게 편하다 → nginx를 사용해야한다!!

리버스 프록시

: 가장 먼저 nginx 가 정적파일캐시, SSL관련처리를 한 후 요청을 앱서버에게 토스하는 방식

스프링부트(app-1)를 먼저 띄우고 그 이후에 nginx(my-nginx-1)를 띄워야 한다. 초기 nginx가 시작할 때 http://app-1:8090 이 없다면 오류가 발생하기 때문이다. 이후 만약, 스프링부트(app-1) 업데이트를 위해 잠시 stop해 놓는다고 nginx는 꺼지지 않는다 → 다만 502 Bad Gateway 오류가 발생할 수 있음. 그렇기 때문에 처음에 nginx 컨테이너를 만들때만 순서를 유의해주면 된다.

=========67강, 68강 실습 docker build -t myname/app-1 . 명령어를 사용하는 이유는 Dockerfile을 기반으로 커스텀 도커 이미지를 만든 후, 이 이미지를 이용하여 컨테이너를 실행하기 위함이다

1. Dockerfile 작성

   • 원하는 설정과 애플리케이션을 포함한 커스텀 이미지를 정의

2. docker build 명령어 실행

   • Dockerfile을 기반으로 이미지를 생성

3. docker run 명령어로 컨테이너 실행

   • 생성한 이미지를 기반으로 컨테이너를 실행

문제1

도커 컴포즈로 구성 http://app1-127-0-0-1.nip.io => app-1 스프링부트(proxy pass) http://app2-127-0-0-1.nip.io => my-nginx-1:/web/site2/index.html

문제2

• 도커 컴포즈로 구성 http://app1-127-0-0-1.nip.io => app-1 스프링부트(proxy pass) http://app1new-127-0-0-1.nip.io => app-1 스프링부트(proxy pass) http://app2-127-0-0-1.nip.io => app-2 스프링부트(proxy pass) http://app2new-127-0-0-1.nip.io => app-2 스프링부트(proxy pass) http://app1-127-0-0-1.nip.io 와 http://app1new-127-0-0-1.nip.io (은)는 같은 스프링 부트로 연결됩니다. http://app2-127-0-0-1.nip.io 와 http://app2new-127-0-0-1.nip.io (은)는 같은 스프링 부트로 연결됩니다. app-2 는 기존 app-1 의 소스코드를 가지고 만들어주세요.

RUN 명령어를 쓴다는것이 layer를 추가하는거고 , 이때 layer는 immuatable하다 그렇기떄문에 싱글이 아닌 멀티 스테이지 빌드를 사용하는 것이 용량 측면에서도 사용하기 좋다!

도메인

A레코드(like 메모)

abc.com(도메인) : 특정 IP 이름?

nslookup 명령어

nplookup abc.com(도메인) : A레코드를 알 수 있다.

1️⃣ 빌드(Build)란?

• 빌드(Build)는 .java 파일을 컴파일하여 .class(바이트코드) 파일로 변환하는 과정이다.
• javac(Java Compiler)를 사용하여 .java 파일을 .class 파일로 변환한다.

컴파일 예시

javac Test.java

• 위 명령을 실행하면 Test.class 파일이 생성된다.

2️⃣ 실행 파일(JAR, Java Archive)

• JAR(Java ARchive) 파일은 여러 개의 .class 파일과 라이브러리를 하나의 압축 파일로 패키징한 것이다.
• .class 파일만으로 실행하기 불편하기 때문에, JAR 파일로 패키징하여 실행을 쉽게 만든다.

JAR 파일 생성 예시

jar cf Test.jar Test.class

또는 특정 디렉터리(build/) 안의 파일들을 JAR로 묶는 경우:

jar cf Test.jar -C build/ .

• 위 명령을 실행하면 Test.jar 파일이 생성된다.

3️⃣ JAR 파일 실행

• JAR 파일을 실행하려면 java -jar 명령어를 사용해야 한다.

JAR 실행 예시

java -jar Test.jar

📝 요약

즉, 빌드는 .java 파일을 .class 파일로 변환하는 과정이며, JAR 파일은 실행 가능한 형태로 패키징한 것이다.

2. 바인드 마운트(Bind Mount)와 볼륨(Volume)의 차이

Docker에서는 컨테이너와 호스트 간 데이터 공유를 위해 바인드 마운트(Bind Mount)와 볼륨(Volume) 두 가지 방식을 제공한다.
둘 다 데이터를 컨테이너와 공유할 수 있도록 하지만, 동작 방식과 사용 목적이 다르다.

✅ 1. 바인드 마운트(Bind Mount)

개념

• 바인드 마운트는 호스트의 특정 디렉터리를 컨테이너 내부로 연결하는 방식이다.
• 컨테이너가 호스트의 파일 시스템을 직접 접근하여 읽고 쓸 수 있다.
• 컨테이너가 종료되어도 호스트의 원본 파일은 그대로 유지된다.
• 컨테이너와 호스트 간 파일 동기화가 즉시 이루어진다.

사용 예시

docker run -d --name bind-container \
  -v /home/user/app:/app \
  nginx

• 호스트의 /home/user/app 디렉터리를 컨테이너의 /app에 마운트한다.
• 컨테이너 내부에서 /app 경로를 수정하면 호스트의 /home/user/app도 함께 변경된다.

✅ 2. 볼륨(Volume)

개념

• 볼륨은 Docker가 자체적으로 관리하는 저장소를 사용한다.
• 컨테이너와 독립적으로 데이터가 저장되며, 여러 컨테이너 간에 공유할 수 있다.
• Docker가 /var/lib/docker/volumes/ 디렉터리에서 데이터를 관리한다.
• 컨테이너가 삭제되어도 볼륨은 유지되며, 데이터가 보존된다.

사용 예시

docker volume create my-volume

docker run -d --name volume-container \
  -v my-volume:/app \
  nginx

• my-volume이라는 Docker 볼륨을 생성하고 컨테이너의 /app에 마운트한다.

• 컨테이너가 종료되더라도 볼륨 데이터는 유지된다.

• 볼륨을 삭제하려면 명시적으로 삭제해야 한다:

  docker volume rm my-volume

✅ 3. 바인드 마운트 vs 볼륨 비교

✅ 4. 바인드 마운트와 볼륨의 사용 사례

바인드 마운트를 사용할 경우

• 개발 환경에서 호스트 파일을 컨테이너와 동기화해야 할 때
• 호스트의 소스 코드 변경 사항이 컨테이너에 즉시 반영된다.
• 호스트의 특정 파일을 컨테이너에서 직접 사용해야 할 때

볼륨을 사용할 경우

• 데이터베이스 컨테이너에서 데이터를 영구 저장해야 할 때
• 컨테이너가 삭제되더라도 데이터를 유지하고 싶은 경우
• 여러 컨테이너에서 같은 데이터를 공유해야 할 경우

운영 환경에서는 일반적으로 볼륨을 사용하며,
개발 환경에서는 바인드 마운트를 활용하는 것이 편리하다.