공부하자

• 백엔드 데브코스 12기 78일차 오전에는 GitHub Actions로 태그와 릴리즈를 생성하고, Docker 이미지를 빌드해 GHCR에 올리는 과정을 배웠다. Job과 Step의 실행 순서, 출력값과 환경 변수의 전달 범위도 정리했다. 특히 Secrets에 저장한 값이라도 이미지에 복사하면 이미지 안에 남을 수 있다는 점이 기억에 남았다.Mac에서 이미지를 내려받지 못했던 문제는 멀티 플랫폼 빌드 설정을 추가해 해결했다. 이미지를 만들 때 실행할 환경의 CPU 아키텍처도 고려해야 한다는 것을 알게 됐다. 이후 SSM을 통한 EC2 자동 배포를 연결했지만, 정상 동작까지 확인하지 못해 다음 수업에서 이어가기로 했다. 오후에는 최종 프로젝트에서 내가 맡은 티켓 예매 기능을 구체화했다. AI와 대화하면서 MVP 범위와 핵심 사용자 시나리오부.. 2026.11.05
• [Github Actions] GitHub Secrets와 환경 변수의 범위, 비밀 값 관리 자동화를 구성하면서 인증 토큰이나 비밀 파일을 어디에 보관하고 어떻게 전달할지도 다뤘다.가장 중요했던 것은 비밀 값을 안전한 곳에 저장하는 것과, 최종 결과물에 포함하지 않는 것은 별개의 문제라는 점이었다.Secrets와 Variables 구분하기GitHub Actions에서 민감한 값은 Secrets, 일반 설정값은 Variables로 관리할 수 있다. 값적절한 저장 위치외부 서비스 API 키Secrets데이터베이스 비밀번호Secrets이미지 이름 backend-deployVariables워크플로에서는 다음처럼 참조한다.${{ secrets.API_KEY }}${{ vars.IMAGE_NAME }} Repository Secrets는 저장소 설정의 Secrets and variables → Action.. 2026.11.05
• [Github Actions] Docker 이미지 빌드·푸시 자동화와 Mac에서 실행하기 태그와 릴리즈 생성 다음에는 Docker 이미지를 빌드하고 GHCR에 올리는 작업을 연결했다.직접 입력했던 빌드·푸시 명령을 워크플로로 옮기면서, Job 간 의존 관계와 결과 전달 방식을 배웠다.Job 사이의 순서 정하기buildImageAndPush: name: 도커 이미지 빌드와 푸시 needs: makeTagAndRelease runs-on: ubuntu-latest needs는 앞 Job이 성공한 뒤 현재 Job을 실행하도록 연결한다. 태그·릴리즈 생성 성공 ↓이미지 빌드·푸시 앞 Job이 실패하면 기본적으로 뒤 Job은 실행되지 않고 건너뛰어진다.반대로 이미지 빌드가 실패하더라도 이미 생성된 릴리즈가 자동으로 삭제되지는 않는다. 따라서 릴리즈가 보인다는 사실만으로 이미지 빌.. 2026.11.05
• [GitHub Actions] 실행 구조와 태그·릴리즈 자동화 지금까지는 코드를 수정한 뒤 직접 빌드하고 실행했다. GitHub Actions를 사용하면 저장소에서 특정 이벤트가 발생했을 때 필요한 작업을 자동으로 실행할 수 있다.처음에는 간단한 메시지 출력부터 시작하고, 이후 태그와 릴리즈 생성으로 연결했다.워크플로 파일과 실행 조건워크플로는 저장소의 .github/workflows 아래에 YAML 파일로 작성한다. 파일 이름은 원하는 대로 정할 수 있다.name: work-1on: push: branches: - mainjobs: hello1: runs-on: ubuntu-latest steps: - name: sayHi run: echo "Hi" - name: sayMyName run: e.. 2026.11.05
• 백엔드 데브코스 12기 77일차 오전에는 Docker의 빌드·운영 환경 분리와 멀티 스테이지 빌드, Spring Boot의 S3 연동과 EC2 배포를 공부했다.빌드는 CPU와 메모리를 사용하기 때문에 운영 서버에서 함께 수행하면 사용자 요청 처리에 영향을 줄 수 있다. 빌드 환경에서는 JAR를 만들고, 운영 환경에서는 완성된 결과물을 실행하도록 역할을 나누는 이유를 이해했다. 멀티 스테이지 빌드는 이 구분을 Dockerfile 안에 표현하고, 실행에 필요한 결과물만 최종 이미지로 가져오는 방법이었다. AWS에서는 코드와 실행 환경의 관계를 다시 생각하게 됐다. 로컬에서 S3 조회에 성공해도 EC2에서 사용할 인증 정보와 권한이 없다면 실패할 수 있다. 이미지에는 Java와 애플리케이션이 담기지만, EC2의 IAM 역할이나 보안 그룹까지.. 2026.11.04
• [AWS] Spring Boot에서 S3에 접근하고 EC2·Docker로 실행하기 이전에는 Terraform으로 EC2를 만들고 IAM 역할을 연결했다. 이번에는 Spring Boot에서 S3 버킷 목록을 조회한 뒤, 같은 프로그램을 EC2에서 직접 실행하고 Docker 이미지로도 실행했다.코드가 같아도 실행하는 위치에 따라 인증 정보를 얻는 방식이 달라질 수 있다는 점이 중요했다. 이미지에 담기는 실행 환경과 AWS에서 설정하는 권한도 구분해서 이해했다.S3 라이브러리 추가하기프로젝트에 S3를 사용할 의존성을 추가했다.implementation("io.awspring.cloud:spring-cloud-aws-starter-s3:4.2.1") S3 자체를 애플리케이션에 설치하는 것이 아니라, Spring Boot에서 S3에 요청할 수 있도록 라이브러리를 추가하는 것이다.버킷 만들기AW.. 2026.11.04
• [Docker] JAR를 Docker 이미지로 배포하고 멀티 스테이지로 빌드하기 빌드 환경에서 JAR를 만들었다면 이제 운영 환경에서 실행해야 한다. 여기서 궁금했던 것은 JAR만 전달하는 방식과 Docker 이미지로 전달하는 방식의 차이였다.JAR 직접 실행과 이미지 실행의 차이JAR만 운영 서버에 전달한다면 서버에 호환되는 Java 실행 환경을 준비해야 한다.java -jar app.jar 반면 이미지에는 Java 실행 환경과 JAR, 시작 명령을 함께 담을 수 있다. JAR 전달→ 서버에 Java 실행 환경 준비→ JAR 실행이미지 전달→ 컨테이너 실행 환경 준비→ 이미지에 담긴 Java 환경으로 실행 이미지를 사용해도 서버에 아무 준비가 필요 없는 것은 아니다. Docker 같은 컨테이너 실행 환경은 필요하다.대신 서버마다 Java를 따로 설치하는 차이를 줄이고, 프로그램과 .. 2026.11.04
• [Docker] 빌드 환경과 운영 환경을 분리하는 이유 이전에는 컨테이너 안에서 Java 프로그램을 빌드하고 실행했다. 이번에는 프로그램을 만드는 환경과 사용자 요청을 처리하는 환경을 분리하는 이유를 배웠다.빌드를 운영 서버에서 하면 어떤 문제가 생길까?빌드는 소스를 컴파일하고 필요한 의존성을 내려받아 JAR 같은 결과물을 만드는 과정이다. 이때 CPU와 메모리를 사용한다.사용자 요청을 처리하는 서버에서 빌드까지 수행하면 같은 자원을 두고 경쟁하게 된다. 그 결과 응답이 느려지거나 메모리가 부족해질 수 있다.그래서 역할을 나눈다.빌드 환경: 소스 코드를 받아 JAR 생성운영 환경: 완성된 JAR를 실행하고 사용자 요청 처리 컨테이너만 나누고 같은 서버에서 실행한다면 물리적인 자원은 여전히 공유한다. 역할을 구분하는 것과 서버 자원을 분리하는 것은 함께 생각해.. 2026.11.04
• [Docker] 컨테이너에서 Java 프로그램을 빌드하고 실행하기 Docker 이미지는 프로그램뿐 아니라 실행에 필요한 환경도 함께 담을 수 있다. 이를 이해하기 위해 컨테이너 안에서 Java 소스를 컴파일하고, JAR로 묶어 실행하는 과정을 살펴봤다. 이후 같은 과정을 Gradle로 자동화했다.Java 소스와 실행 결과물 구분하기먼저 다음과 같은 Java 코드를 작성한다.public class Main { public static void main(String[] args) { System.out.println("Hello, Rocky Linux!"); }} 파일 이름은 Main.java다. 이 파일을 컴파일하고 실행하는 명령은 다음과 같다. javac Main.javajava Main 처음에는 javac Main.java가 Main.java를.. 2026.11.04