프로젝트 목적이 '트래픽 스파이크 처리', '서버리스 지향', '운영 부담 최소화' 그래서 당연히 EC2보다 관리가 편한 AWS App Runner를 쓰기로 결정했고, Role 권한 부여하고 인프라 설계를 어느정도 한상태였는데... 막상 APP runner를 사용해서 배포하려니까 서울 리전(ap-northeast-2)에는 App Runner가 출시조차 안 되어 있었음.........

AI말을 너무 신뢰하지말자

를 다시금 새기게됌

제미나이 응답

1. 도쿄 리전(ap-northeast-1) 사용하기 (적극 추천) ⭐
아시아에서 App Runner를 지원하는장 가까운 리전이 바로 도쿄입니다.

한국(서울)과 도쿄는 지리적으로 가까워서 네트워크 지연 시간(Latency) 차이가 거의 느껴지지 않습니다. 동아리 프로젝트나 테스트용 API 서버로는 전혀 지장이 없습니다.

2. ECS Fargate
프로젝트 목적(트래픽 스파이크 처리, 서버리스 지향, 운영 부담 최소화)에 제일 부합
App Runner가 내부적으로 ECS Fargate 기반이라 사실상 같은 기술을 직접 쓰는 것

우리의 선택 -> 2번

왜 ECS Fargate?

사실 App Runner도 내부적으로는 ECS Fargate 기반으로 돌아감

• 서버 관리 전무: EC2처럼 OS 패치나 인프라 관리에 리소스를 쏟을 필요 없이 컨테이너만 관리하면 됌
• Auto Scaling & VPC 연동: CPU/메모리 기반 확장이 자유롭고 VPC 연동이 기본이라 ElastiCache 연동이 자연스러움
• 기존 자산 유지: App Runner를 위해 빌드해 둔 Dockerfile → ECR → Task Definition → Service 파이프라인과 GitHub Actions CI/CD 구조를 거의 그대로 가져갈 수 있었음

다시 한번 생각해야할것

AI를 너무 신뢰하지는 말자

문제 상황 (Symptom)

• 새로운 기능을 구현하고 ECR(Elastic Container Registry)에서 최신 도커 이미지를 받아 배포하려 했으나, "No space left on device" 에러와 함께 배포가 무한 실패함.
• EC2 쉘(Shell)에 접속해 df -h와 docker images를 확인한 결과, AI 모델이 포함된 도커 이미지 용량이 너무 커서 남은 용량이 거의 없었음.

원인 분석 (Cause)

• AI 이미지의 비대화: Python AI 서버 이미지가 딥러닝 라이브러리와 모델 파일을 포함하면서 수 GB 단위로 커짐.
• 인스턴스 자원 한계: 기존 t3.micro 인스턴스는 디스크 용량뿐만 아니라 메모리(1GB)도 부족하여, 무거운 도커 이미지를 압축 해제하고 실행하는 과정을 버티지 못함.

해결 방법 (Solution)

1. 인스턴스 타입 업그레이드: CPU와 메모리 사양을 높이기 위해 인스턴스를 t3.micro에서 t3.small로 스케일 업(Scale-up)함.
2. 도커 환경 정리: docker system prune -a 명령어를 통해 사용하지 않는 오래된 이미지와 컨테이너를 삭제하여 가용 공간을 확보함.
3. EBS 볼륨 최적화: 인스턴스 타입 변경과 함께 루트 볼륨(EBS) 크기를 증설하여 향후 이미지 업데이트에 대비함.

Issue 2. AI 퀴즈 생성 데이터의 DB 저장 정합성 오류

문제 상황 (Symptom)

• Python AI 서버에서 퀴즈 생성 로직은 정상적으로 동작하여 응답을 보내주지만, Spring Boot 서버에서 이를 받아 DB(Content, Question 테이블 등)에 저장할 때 데이터가 누락되거나 저장되지 않는 현상 발생.

원인 분석 (Cause)

1. API 데이터 정합성 불일치: Python 서버가 보내주는 JSON 필드 구조와 Spring Boot의 DTO 구조가 미세하게 달러 역직렬화(Deserialization) 과정에서 데이터가 유실됨.
2. 트랜잭션 관리 실패: 퀴즈 생성 요청은 성공했으나, 연관된 여러 테이블(Step -> Content -> Choice)에 데이터를 넣는 과정에서 하나라도 실패할 경우 전체가 롤백(Rollback)되어야 하는데, 이 처리가 미흡하여 데이터가 꼬임.
3. 영속성 컨텍스트 이슈: 부모 엔티티가 저장되기 전에 자식 엔티티를 저장하려다 외래 키(FK) 제약 조건 위반이 발생함.

해결 방법 (Solution)

1. DTO 및 검증 로직 강화: Python 서버와의 규약을 재정의하고, @Valid를 통해 들어오는 데이터의 정합성을 최우선으로 검증함.
2. Cascade 옵션 및 연관관계 편의 메서드 활용: JPA CascadeType.ALL 설정을 통해 부모 엔티티(Step) 저장 시 자식 엔티티들이 한 번에 안전하게 저장되도록 구조를 개선함.
3. 트랜잭션 원자성 확보: 퀴즈 저장 서비스 로직에 @Transactional을 적용하여 전체 프로세스가 "All or Nothing"으로 동작하게 하여 데이터 무결성을 보장함.

회고를 마치며

"인프라는 한 번 구축하면 끝나는 것이 아니라, 서비스 규모와 데이터 크기에 따라 지속적으로 모니터링하고 스케일링해야 한다는 것을 배웠습니다. 또한, 서로 다른 언어(Spring-Python)로 구성된 서버 간 통신에서는 데이터 정합성을 맞추는 것이 시스템 안정성의 핵심임을 깨달았습니다...어렵다 ㅠㅠㅠ"

• 문제 상황: 여러 명의 팀원이 채팅방에서 동시에 AI 요약(@mates)을 호출하거나 상충하는 데이터를 입력할 때, AI 서버로 중복 요청이 가거나 DB의 요약 데이터가 덮어씌워지는(Lost Update) 데이터 정합성 파괴 현상 발생.

• 해결 과정:

  1. 입구 통제 (Redis 분산 락): AI 호출 시 projectId를 Key로 Redis 분산 락(Distributed Lock)을 걸어, 누군가 요약을 진행 중일 때는 다른 팀원의 중복 호출을 차단함.
  2. 출구 방어 (JPA 낙관적 락): AI 요약본을 DB에 최종 업데이트할 때 @Version을 활용한 낙관적 락(Optimistic Lock)을 적용. 읽은 시점과 쓰는 시점의 버전이 다르면 예외를 발생시키고 안전하게 롤백하여 데이터 오염 방지.

• 결과: 100%의 데이터 정합성을 보장하는 안전한 실시간 협업 환경 구축 완료.

  // 1. 엔티티에 낙관적 락 적용 (출구 방어)
  @Entity
  public class ProjectSummary {
    @Id @GeneratedValue
    private Long id;
    private String content;
  
    @Version // JPA Optimistic Lock
    private Long version; 
  }
  

// 2. 분산 락을 활용한 AI 호출 로직 (입구 방어) @Service @RequiredArgsConstructor public class AISummaryService { private final RedissonClient redissonClient; private final SummaryRepository summaryRepository;

public void requestAiSummary(Long projectId) {
    RLock lock = redissonClient.getLock("AI_LOCK:" + projectId);
    try {
        // 락 획득 시도 (대기 시간 0초, 락 유지 10초)
        boolean isLocked = lock.tryLock(0, 10, TimeUnit.SECONDS);
        if (!isLocked) {
            throw new CustomException("이미 AI가 요약을 진행 중입니다.");
        }

        // AI 호출 및 DB 업데이트 로직 (낙관적 락 충돌 시 ObjectOptimisticLockingFailureException 발생)
        updateSummaryWithAI(projectId);

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock(); // 작업 완료 후 락 해제
        }
    }
}

}

#### 2. 다중 서버(Scale-out) 환경에서의 WebSocket 세션 동기화 문제
* **문제 상황:** 단일 서버에서는 STOMP 기반 채팅이 잘 동작했으나, 트래픽 분산을 위해 백엔드 서버를 여러 대(Scale-out)로 늘렸을 때 서로 다른 서버에 접속한 유저 간에 메시지가 전달되지 않는 브로드캐스팅 단절 문제 발생.
* **해결 과정:** * **Redis Pub/Sub 도입:** 기존에 세션 관리용으로 쓰던 Redis의 Pub/Sub(발행/구독) 기능을 메세지 브로커로 확장 활용.
    * A서버의 유저가 메시지를 보내면 Redis로 Publish하고, Redis가 연결된 모든 서버(B, C 등)로 메시지를 브로드캐스팅하여, 어떤 서버에 붙어있든 실시간 통신이 끊기지 않도록 분산 웹소켓 아키텍처 재설계.
* **결과:** 대규모 접속 시에도 안정적인 채팅이 가능한 확장성(Scalability) 확보.

```java
// 1. 메시지 발행 (Publish)
@MessageMapping("/chat/message")
public void sendMessage(ChatMessage message) {
    // DB에 메시지 선 저장 (단일 진실 공급원)
    chatService.saveMessage(message);
    // Redis의 채팅 채널로 메시지 발행
    redisTemplate.convertAndSend("CHAT_ROOM:" + message.getProjectId(), message);
}

// 2. 메시지 구독 (Subscribe) - RedisMessageListenerContainer 설정
@Service
public class RedisSubscriber implements MessageListener {
    private final SimpMessageSendingOperations messagingTemplate;

    @Override
    public void onMessage(Message message, byte[] pattern) {
        // Redis에서 메시지를 수신하면, 자신(서버)에게 연결된 웹소켓 클라이언트들에게 브로드캐스팅
        ChatMessage chatMessage = objectMapper.readValue(message.getBody(), ChatMessage.class);
        messagingTemplate.convertAndSend("/sub/chat/room/" + chatMessage.getProjectId(), chatMessage);
    }
}

3. 외부 API(Notion) Rate Limit(호출 제한) 및 트랜잭션 병목 대응

• 문제 상황: 프로젝트 완료 후 Notion으로 템플릿을 내보낼 때, 다수의 팀이 동시에 요청할 경우 Notion API의 엄격한 호출 횟수 제한(429 Too Many Requests)에 걸려 실패. 게다가 동기식으로 API를 기다리다가 우리 DB 커넥션 풀까지 고갈될 위험 감지.
• 해결 과정:
  1. 트랜잭션 분리: 우리 DB에 데이터를 안전하게 커밋(Commit)하여 완전히 저장한 이후에만 외부 API(Notion)를 호출하도록 설계하여, 외부 장애가 내부 시스템으로 번지지 않도록 격리.
  2. 비동기 큐 및 백오프: Redis 작업 큐(Task Queue)를 도입해 쏟아지는 노션 생성 요청을 담아두고, 워커(Worker)가 속도를 조절하며 순차 처리. API 에러 발생 시 대기 시간을 점진적으로 늘리는 '지수 백오프(Exponential Backoff)' 적용 및 실패 시 사용자 재시도(Retry) 로직 구현.
• 결과: 외부 API 장애로부터 내결함성(Fault Tolerance)을 갖춘 견고한 시스템 완성.

  // 1. DB 트랜잭션과 외부 API 분리 (@TransactionalEventListener 활용)
  @Service
  public class ProjectService {
    @Transactional
    public void finishProject(Long projectId) {
        projectRepository.updateStatus(projectId, "COMPLETED");
        // DB 커밋이 완료된 후 이벤트 발행
        eventPublisher.publishEvent(new ProjectCompletedEvent(projectId));
    }
  }
  

// 2. 이벤트 리스너에서 비동기로 Notion API 호출 및 재시도 로직 적용 @Component public class NotionApiEventListener {

// 트랜잭션이 성공적으로 커밋된 후에만 실행됨
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Async // 비동기 워커로 넘김 (API 병목 방지)
// 429 에러 발생 시 1초, 2초, 4초 대기하며 최대 3번 재시도
@Retryable(value = {RateLimitException.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2))
public void handleProjectCompletedEvent(ProjectCompletedEvent event) {
    notionApiClient.exportToNotion(event.getProjectId());
}

// 최종 실패 시 처리 (Fallback)
@Recover
public void recoverNotionExport(RateLimitException e, ProjectCompletedEvent event) {
    log.error("Notion API 최대 재시도 횟수 초과. 프로젝트 ID: {}", event.getProjectId());
    // DB에 상태를 'FAILED'로 기록하고 사용자에게 '재시도 버튼' 노출 유도
    projectRepository.updateExportStatus(event.getProjectId(), "FAILED");
}

}

#### 4. AI 환각(Hallucination) 및 비정형 JSON 응답에 대한 서버 생존성 확보
* **문제 상황:** 프롬프트로 JSON 형식을 강제했음에도, AI가 가끔 규격에 맞지 않는 엉뚱한 응답을 보내거나 정의되지 않은 Key를 던질 때 백엔드 서버에서 파싱 에러(Mapping Exception)가 발생하며 프로세스가 중단됨.
* **해결 과정:**
    * **방어적 프로그래밍과 Fallback:** Spring Boot 단에서 철저한 객체 검증(DTO Validation) 및 Try-Catch 예외 처리 적용. 에러 포착 시 서버를 멈추지 않고(Graceful Degradation), 사용자에게 알림을 보낸 뒤 **'가장 최근에 검증된 성공 데이터(Last Known Good State)'를 DB에 유지(Fallback)**하여 데이터 유실 방지.
* **결과:** AI의 실수에도 시스템이 무너지지 않고 사용자 데이터를 100% 보호하는 안전장치 마련.

```java
@Service
public class AiResponseHandler {

    // JSON에 정의되지 않은 필드가 들어와도 무시하도록 ObjectMapper 설정
    private final ObjectMapper objectMapper = new ObjectMapper()
            .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

    @Transactional
    public void processAiResponse(Long projectId, String aiRawResponse) {
        ProjectSummary currentSummary = summaryRepository.findByProjectId(projectId);

        try {
            // AI 응답 파싱 시도
            AiSummaryDto dto = objectMapper.readValue(aiRawResponse, AiSummaryDto.class);

            // 검증 성공 시에만 데이터 업데이트
            currentSummary.updateContent(dto.getContent());

        } catch (JsonProcessingException e) {
            // 파싱 실패 시 서버를 죽이지 않고 로그만 남김 (Graceful Degradation)
            log.error("AI 응답 JSON 파싱 실패. Raw Data: {}", aiRawResponse, e);

            // TODO: 슬랙 등 모니터링 채널로 알림 발송

            // 기존 데이터(currentSummary)는 롤백하지 않고 그대로 유지됨 (안전한 Fallback)
        }
    }
}

• 데이터베이스(DB) 구조화된 정보 또는 데이터의 조직화된 모음이며, 일반적으로 DBMS에 의해 제어됨
• 관계형 데이터베이스(Relational DB) 구조화된 데이터를 테이블 형태로 저장 엄격한 스키마를 따르며 SQL(Structured Query Language)을 사용하여 데이터를 조작
• 비관계형 데이터베이스(Non-Relational DB) 비정형 데이터를 저장하며 고정된 스키마가 없음 대량의 분산 데이터 저장 및 다양한 형태의 데이터를 빠르게 처리하는 데 적합함

RDS의 배포 방식 비교

• On-Premise: 사용자가 직접 물리적 서버를 구축하고 데이터베이스를 설치 및 관리
• AWS EC2: AWS 가상 서버(EC2) 위에 사용자가 직접 DB 소프트웨어를 설치하고 운영 체제부터 DB까지 관리
• AWS RDS: AWS에서 제공하는 완전 관리형 관계형 데이터베이스 서비스로, 관리 부담이 가장 낮음

AWS RDS (Relational Database Service)

• 개요: AWS 클라우드에서 관계형 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있도록 지원하는 웹 서비스
• 주요 장점:
  • 간편한 관리: 패치, 백업 등 운영 자동화
  • 가용성 및 안정성: 자동 백업 및 스냅샷 기능을 제공하며 Multi-AZ를 통한 장애 복구 지원
  • 보안성: AWS 네트워크 보안 기능(VPC) 및 암호화 적용 가능
  • 확장성: Read Replica를 통한 읽기 성능 확장 및 스토리지 유연성 확보
  • 비용 효율성: 사용한 만큼만 비용을 지불하는 구조

가용성 및 성능 확장 기술

• Multi-AZ (다중 가용 영역):
  • 다른 가용 영역(AZ)에 데이터베이스 복사본(Standby)을 생성하고 데이터를 동기화함
  • 장애 감지 시 자동으로 대기 인스턴스로 대체(Failover)되어 서비스 연속성을 보장함
• Read Replica (읽기 전용 복제본):
  • 읽기(Read) 쿼리의 성능 향상과 부하 분산을 목적으로 생성함
  • 주 인스턴스로부터 비동기 방식으로 데이터를 복제함
  • 읽기 중심 워크로드에서 Scale-Out을 통해 처리량을 향상시킴

SAA (Solutions Architect Associate) 실무 사례

• 문제 상황: RDS 사용 중 통계용 데이터를 읽어올 때 성능 저하가 발생하는 경우
• 해결책: RDS Read Replica를 생성하여 운영 DB의 부하를 줄이고, 읽기 전용 쿼리를 복제본에서 처리하도록 구성!!

SQL 및 관계형 데이터베이스(RDBMS)

• 관계형 데이터베이스에서 데이터를 저장, 조회, 수정, 삭제하기 위해 사용하는 언어
• 특징:
  • 정해진 구조(Schema)에 따라 테이블에 데이터를 저장
  • 행(Row)과 열(Column)이 있는 표 형태의 구조를 가짐
• Oracle, MySQL, PostgreSQL 등

NoSQL 및 비관계형 데이터베이스

• 비관계형 데이터베이스 환경에서 데이터를 관리하는 방식임
• 특징:
  • 정형화되지 않은 유연한 구조를 사용하여 가용성과 확장성이 높음
  • 고성능 처리에 최적화되어 있으며 SNS(Instagram, Facebook) 등에서 주로 사용됨
• MongoDB, AWS DynamoDB 등

AWS DynamoDB 개요

• AWS에서 제공하는 서버리스 기반의 완전관리형 NoSQL 데이터베이스 서비스
• 주요 특성:
  • 완전관리형: 장비 운영부터 솔루션 설치 및 운영까지 모든 인프라를 AWS에서 담당
  • 고성능: 10ms 미만의 지연 시간으로 데이터를 처리할 만큼 매우 빠름
  • 내구성: SSD에 저장되며 리전 내 여러 가용 영역(AZ)에 걸쳐 자동 복제
  • Auto-Scaling: 요청량에 따라 테이블의 읽기/쓰기 용량을 자동으로 조절

DynamoDB 핵심 구성 요소

• 테이블(Tables) 데이터의 집합체 (예: People 테이블, Cars 테이블)
• 항목(Items) 테이블을 구성하는 개별 데이터 단위 (RDBMS의 행에 해당)
• 속성(Attributes) 항목을 구성하는 세부 데이터 요소 (예: ID, 이름, 주소 등)
• 유연한 스키마 기본 키(PK)를 제외하고는 속성이나 데이터 형식을 미리 정의할 필요가 없으며, 각 항목은 고유하거나 중첩된 속성을 가질 수 있음

DynamoDB의 키(Key) 구조

• Partition Key (파티션 키):
  • RDBMS의 Primary Key와 유사한 역할로 테이블 내 유일한 값이어야 함
  • 데이터가 저장될 물리적 공간(Partition)을 결정하며 일치 검색(Equal)만 지원
• Sort Key (정렬 키):
  • 같은 파티션 내에서 데이터를 정렬하는 기준
  • 일치, 부등호, 포함 등 범위 지정 검색을 지원하여 정교한 쿼리를 가능하게 함

Lambda를 활용한 DynamoDB 최적화

• Batch 작성 지원 BatchWriteItem API를 통해 한 번에 최대 25개의 항목을 삽입할 수 있어 데이터 추가 효율이 높음
• 자동화 운용 CloudWatch Events와 연동하여 특정 주기마다 Lambda 함수를 실행, 정기적인 데이터 처리가 가능
• Join 기능 구현 DynamoDB는 자체적인 Join을 지원하지 않으므로, 복잡한 데이터 결합이 필요한 경우 Lambda를 통해 로직으로 구현

• 정의: 클라우드 컴퓨팅 제공업체를 통해 데이터와 파일을 인터넷에 저장하는 모델. 사용자는 퍼블릭 인터넷 또는 전용 프라이빗 네트워크 연결을 통해 스토리지에 액세스 가능.
• 클라우드 사용 시 이점: 비용 효율성, 민첩성 향상, 더 빠른 배포, 효율적인 데이터 관리, 확장성
• 스토리지 종류: File Storage, Block Storage, Object Storage (사용자가 데이터를 어떻게 읽고 쓰는지 인터페이스 관점에서 구분)

2. 스토리지 유형별 상세 분석

① Block Storage (예: Amazon EBS)

• 역할: 물리적 하드웨어(HDD, SSD)와 비슷한 역할을 수행하며 이를 흉내 냄. 가상머신(EC2)은 이를 자신의 하드디스크라고 생각함
• 특징: 스토리지 어디에 저장되어 있는지 등의 세부 작업은 직접 하지 못함(물리적 디바이스 관리는 OS가 담당)
• 데이터 처리: 데이터를 Block 형태로 Read/Write 함. 빠른 속도를 위해 각 블록에 고유 식별자(ID#)를 부여
• 기타: 백업 기능을 제공하기도 하며 SAN(Storage Area Network) 역할을 수행

② File Storage (예: Amazon EFS)

• 역할: 데이터를 파일 단위의 계층 구조로 저장함. 애플리케이션에 가장 널리 사용되는 유형
• 특징: 데이터를 파일 단위로 다루며 직접 데이터를 관리함(서버 기능도 수행). NFS, NAS 기술 사용 가능함. 로컬 하드 드라이브와 유사한 접근 방식을 가짐
• 사용 시나리오: 블록 스토리지에 '서버'가 추가된 느낌으로, 여러 서버나 사용자가 동일 파일 시스템에 동시 접근하거나 네트워크를 통한 파일 공유가 필요할 때 사용

③ Object Storage (예: Amazon S3)

• 역할: 대용량 미디어 파일, 이미지, 백업 등 비정형 데이터 저장을 위한 스토리지
• 특징: 데이터를 오브젝트(파일+메타데이터) 단위로 다룸. 전송된 형식 그대로 객체 데이터로 저장하며, 사용자가 직접 메타데이터 지정 가능
• 접근 방식: 객체는 '보안 버킷'이라는 공간에 저장되며, HTTP 프로토콜 기반 REST API 호출을 통해 접근
  • REST API란? HTTP의 장점을 살려 자원을 이름으로 구분하고 상태를 주고받는 API 방식.
• 사용 시나리오: 정적 웹 콘텐츠 호스팅, 전 세계 데이터센터 분산, 저렴한 비용으로 장기 보관 시 유리

3. Amazon S3 (Simple Storage Service) 심화

• 주요 특징: 확장성이 뛰어나 저장 용량을 신경 쓸 필요가 없으며, 버전 관리/암호화/복제 기능으로 데이터를 보호. 사용한 만큼만 비용을 지불
• 구성 요소:
  • 버킷(Bucket): 최상위 디렉토리(컨테이너). 폴더와 유사함. 무제한 객체 저장 가능. 계정당 최대 100개 생성 가능. 전 세계에서 유일한 이름을 가져야 함
  • 객체(Object): 버킷 안의 파일. 크기는 최대 5TB. Key(이름)와 버전 ID로 식별됨.
• 객체의 상세 구성: Key(이름), Value(데이터), Version ID, Metadata(수정일, 타입, 소유자, 사이즈), 태그, 액세스 제어 정보.
• 태그 활용 보안: * s3:ExistingObjectTag: 기존 객체에 특정 태그가 있는지 확인.
  • s3:RequestObjectTagKeys: 허용할 태그 키 제한
  • s3:RequestObjectTag: 허용할 태그 키 및 값 제한
  • 예시: environment: production 태그가 있는 객체만 읽기 허용 가능.
• URL 형식 예시: https://awsinaction.s3.ap-southeast-2.amazonaws.com/img/cat.png
  • 버킷명: awsinaction / 리전: ap-southeast-2 / 키네임: img/cat.png

4. S3 보안 및 관리 기능

데이터 암호화

• 서버 측 암호화 (Server-Side Encryption): AWS가 자동으로 보호. 업로드 시 암호화, 다운로드 시 복호화
  • 종류: SSE-S3(기본), SSE-KMS, DSSE-KMS, SSE-C.
  • 요청 헤더 예시: "x-amz-server-side-encryption": "AES256"
• 클라이언트 측 암호화: 내 로컬 컴퓨터에서 암호화 후 업로드. 제3자에게 노출을 원천 방지하나 관리 복잡성이 높음

액세스 제어 (Access Control)

• 기본값은 Private임 (통째로 퍼블릭 설정 안 됨)
• IAM: 사용자/역할 기준. 내 계정 내 유저가 무엇을 할 수 있는지 제어
• ACL: 계정 단위 기준. 다른 AWS 계정에 대해 읽기/쓰기 권한 부여
• 버킷 정책: 버킷/객체 기준. 단일 버킷 내 모든 객체 권한을 세부 구성(IP나 도메인 제한 가능).
• CORS: 출처가 다른 서버 간의 리소스 공유를 허용(Access-Control-Allow-Origin 헤더 사용).
• Pre-signed URL: 임시 URL 발급. 특정 시간 동안만 권한 없는 사용자에게 액세스 부여. 생성자가 유효한 권한을 보유해야 함.

스토리지 관리

• 버전 관리: 업데이트 시 버전이 추가됨. 실수로 삭제/덮어쓰기 시 복원 가능. 한 번 활성화 시 비활성화 불가.
• 객체 복제: 동일 리전(SRR) 또는 타 리전(CRR)에 비동기 자동 복제. 배치 복제는 기존 객체 복제 시 사용.
• 스토리지 클래스: 요구사항에 맞는 클래스 선택 가능.
• 수명 주기(Lifecycle):
  • 전환 작업: 일정 기간 후 저렴한 클래스로 이동 (30일 뒤 IA, 60일 뒤 Glacier 등).
  • 만료 작업: 일정 기간 후 객체 자동 삭제.

5. Amazon CloudFront (CDN)

• 정의: 글로벌 콘텐츠 전송 네트워크 서비스. 짧은 지연 시간과 빠른 속도로 데이터 전송. S3 앞단에서 보안 기능 제공
• CDN 원리: 여러 서버에 데이터를 분산 캐싱하여 사용자에게 가장 가까운 서버에서 배포
• 주요 인프라:
  • Edge Location: 원본 서버의 데이터를 캐싱하여 사용자에게 제공하는 지리적 거점
  • Regional Edge Caches(REC): 오리진과 엣지 사이의 캐시 계층. 엣지에 없으면 REC를 먼저 확인하여 오리진 부하를 줄임.
• 동작 방식: 요청 → 엣지 확인 → 캐시 있으면 응답 / 없으면 오리진 포워딩 → 엣지 캐싱 후 응답.
• Origin Server: S3(정적) 및 EC2/ELB(동적) 연결 가능. 동적 콘텐츠는 TTL 동안 수정사항이 안 보일 수 있으므로 주의 필요.
• 보안 및 전송 최적화:
  • HTTPS 지원: 오리진이 지원 안 해도 CloudFront에서 설정 가능.
  • 지리적 제한: 특정 지역 접근 제한 가능.
  • Signed URL: 특정 파일 하나에 대해 허용된 사용자만 접근 허용 (유료 결제 등)
  • Signed Cookie: 다수의 파일에 대한 액세스 제공 (로그인한 유료 회원 등)

• 빌드 파일 준비: 배포할 웹 프로젝트의 빌드 파일을 다운로드하고 압축을 해제

2. Amazon S3 버킷 생성 및 설정

1. S3 콘솔 접속: [버킷 만들기] 버튼을 클릭
2. 리전 및 이름 설정:
   • 리전: 사용자 데이터 지연 시간 단축과 비용 절감을 위해 지리적으로 가까운 리전(예: 서울)을 선택
   • 이름: 전역적으로 고유한 이름을 지정 (중복 불가)
3. 생성 완료: 그 외 설정은 기본값을 유지하고 [버킷 만들기]를 완료

3. 정적 파일 업로드

1. 파일 업로드: [업로드] 버튼을 클릭
2. 주의사항: 빌드 폴더 자체를 올리는 것이 아니라, 빌드 폴더 내부에 있는 개별 파일 및 폴더들을 선택하여 업로드 (예: index.html, static/ 등)

4. S3 정적 웹사이트 호스팅 활성화

1. 호스팅 설정: 버킷 상단 [속성] 탭 → 최하단 [정적 웹사이트 호스팅] 편집 클릭
2. 활성화: * 인덱스 문서: index.html 입력
   • 오류 문서: index.html 입력 (SPA 라우팅 대응)
3. 저장 후 생성된 엔드포인트로 접속
   • 403 Forbidden 에러 발생 (정상)
   • 보안을 위해 외부 접근이 막혀 있으므로 CloudFront를 사용해야함

5. CloudFront 배포 생성 (CDN 설정)

1. CloudFront 콘솔 접속: [배포 생성] 버튼을 클릭
2. 원본(Origin) 설정:
   • 오리진 도메인: 앞서 생성한 S3 버킷을 선택
   • 원본 액세스: 원본 액세스 제어 설정(OAC, 권장)을 선택
   • OAC 생성: [Create new OAC] 버튼 클릭 → 기본 설정 유지 후 [Create] 클릭
3. 보안 및 기타 설정:
   • WAF: 보안 보호 비활성화 선택 (실습용이니)
   • 기본값 루트 객체: index.html 입력
4. 배포 완료: [배포 생성]을 누르면 도메인이 생성됌
   • 하지만 여전히 접속 안 됨! CloudFront가 S3에 접근할 권한이 아직 없기 때문..

6. S3 버킷 정책 수정 (권한 부여)

1. 정책 복사: * CloudFront 콘솔 → 생성한 배포 선택 → [원본] 탭 → 원본 선택 후 [편집]
   • [정책 복사] 버튼을 클릭하여 CloudFront가 생성해준 정책 문구(JSON)를 복사
2. S3에 정책 적용:
   • S3 콘솔 접속 → 해당 버킷 선택 → [권한] 탭
   • [버킷 정책] 편집 버튼 클릭 → 복사한 내용을 붙여넣고 저장
3. 이제 CloudFront 배포 도메인으로 접속하면 웹사이트가 정상적으로 나타남

왜 이렇게 복잡하게 하니?

• S3 단독 호스팅: 보안에 취약하며 속도가 느릴 수 있음
• CloudFront 병행:

1. 보안 - S3를 외부에 직접 공개하지 않고 CloudFront만 통하게 하여 데이터를 보호 (OAC 설정의 이유)
2. 속도 - 전 세계 Edge Location에 콘텐츠를 캐싱하여 사용자에게 더 빠르게 전달
3. 비용 - 캐싱을 통해 S3 직접 요청 횟수를 줄여 비용을 최적화

• 작업: 리전 선택(서울) → VPC 생성 (이름 태그 설정)
• 설정: DNS 확인 및 DNS 호스트이름 활성화 체크
• ❓ IPv4 CIDR를 왜 수동으로 입력?
  • VPC는 나만의 독립적인 가상 네트워크 영토를 선언하는 것. 수동으로 입력하는 이유는 내가 관리할 네트워크의 크기와 주소 범위를 직접 결정하기 위해서!!
  • 특히 기업 환경에서는 다른 VPC나 회사 내부망(On-premise)과 연결할 때 주소가 겹치면 통신이 불가능함. 따라서 나중에 확장성이나 연결성을 고려하여 겹치지 않는 적절한 크기(예: /16)를 직접 지정해야하기 때문에 수동으로 입력

Step 2. Public 및 Private 서브넷 생성

• VPC 범위: 10.0.0.0/16
• 서브넷 구성: 2a, 2c 가용 영역에 각각 퍼블릭/프라이빗 배치

1. public subnet : 10.0.1.0/24 -> ap-northeast-2a
2. private subnet : 10.0.2.0/25-> ap-northeast-2a
3. public subnet : 10.0.3.0/24 -> ap-northeast-2c
4. private subnet : 10.0.4.0/25 -> ap-northeast-2c

• ❓ 왜 Public이 Private보다 더 많은 주소를 할당?
  • 실무에서는 사실 반대인 경우가 더 많긴함. 보통 DB나 내부 로직이 돌아가는 Private 영역에 서버가 훨씬 많이 들어가기 때문 , 하지만 학습용 실습이나 특정 아키텍처에서는 외부와 소통하는 서비스(웹 서버, 로드밸런서, NAT 게이트웨이 등)가 위치하는 Public 영역을 넉넉하게 잡음

• 주소 할당량은 정답이 있는 게 아니라, 해당 서브넷에 얼마나 많은 리소스를 배치할 것인가에 따른 설계자의 의도.. 실습에서는 Public 통신 테스트를 위해 좀 더 넉넉하게 할당한 것

Step 3. Public 서브넷 자동 할당 IP 설정

• Public 서브넷 2개에 대해 '퍼블릭 IPv4 주소 자동 할당' 활성화
• 이 설정을 켜야만 이 서브넷에 생성되는 EC2들이 부팅될 때 자동으로 인터넷 주소(Public IP)를 부여받아 우리가 밖에서 접속할 수 있게 됌..

Step 4. EC2 인스턴스 생성

• AMI: ubuntu
• 인스턴스 유형: t2.micro
• 키페어: 생성 또는 있는 거 사용
• Public EC2: 보안그룹(SSH, HTTP), 퍼블릭 IP 활성화 (외부 접속용)
• Private EC2: 보안그룹(SSH, HTTP), 퍼블릭 IP 비활성화 (내부망 전용)

Step 5. 인터넷 게이트웨이(IGW) 생성 및 연결

• IGW 생성 후 내가 만든 VPC에 연결
• VPC라는 닫힌 성벽에 바깥세상으로 나가는 문을 하나 다는 것과 같음. 이 문이 없으면 아무리 Public IP가 있어도 인터넷 통신이 불가능.

Step 6. 라우팅 테이블(Route Table) 설정

• 작업: Public용 라우팅 테이블 생성 → Public 서브넷 삽입 → 인터넷 게이트웨이 추가

• ❓라우팅 테이블에 Public 서브넷을 왜 연결?

  • 라우팅 테이블은 이정표임. 서브넷을 이 테이블에 연결하는 이유는 이 서브넷 안에 있는 모든 리소스는 이 이정표를 보고 길을 찾으라고 명령하는것.
  • 연결하지 않으면 서브넷은 기본(Default) 라우팅 테이블을 따르는데, 그러면 외부로 나가는 길을 모를수도 있음. 따라서 너희(Public Subnet)는 인터넷 게이트웨이로 가는 길이 적힌 이 전용 이정표를 봐!라고 명시해 주는 것

• ❓인터넷 게이트웨이 왜 추가

  • 이정표에 바깥세상(0.0.0.0/0)으로 가고 싶으면 아까 만든 그 성문(IGW)으로 가라는 내용을 적어 넣는 작업. 이 규칙이 있어야 비로소 진짜 퍼블릭 서브넷이 됌.

IP (Internet Protocol)

인터넷에 연결된 장치를 식별하는 고유 주소

• 공인 IP: 인터넷에서 사용하는 주소
• 사설 IP: 내부 네트워크에서 사용하는 주소
• 고정 IP: 변하지 않는 주소
• 유동 IP: 바뀔 수 있는 주소

DNS (Domain Name System)

도메인 이름과 IP 주소를 서로 변환해주는 분산형 데이터베이스

• 도메인 → IP 변환: Forward DNS
• IP → 도메인 변환: Reverse DNS
• 계층 구조: Root DNS → TLD DNS → Authoritative DNS 순으로 질의

DNS는 하나의 서버가 모든 정보를 가지는 구조가 아니라, 각 서버가 일부 정보를 나누어 가지는 분산 구조

• DNS 레코드 타입:
  • A: 도메인을 IPv4 주소에 매핑.
  • CNAME: 도메인을 다른 도메인에 매핑.
  • NS: 도메인 관리 권한이 있는 네임 서버 지정.
  • Alias: Route 53 전용, 도메인을 AWS 리소스에 직접 연결.

네트워크 통신 흐름

• DHCP(Dynamic Host Configuration Protocol) - 내 컴퓨터에 IP 주소를 자동으로 할당해주는 과정
• ARP(Address Resolution Protocol) - IP 주소를 물리적 주소(MAC 주소)로 변환하는 과정
• DNS
• TCP(Transmission Control Protocol) - 데이터를 안전하게 주고받기 위해 연결하는 과정
• HTTP/HTTPS

전화기를 설치하고(DHCP), 상대방의 주소를 알아내고(ARP/DNS), 연결 라인을 확보한 뒤(TCP), 대화를 나누는(HTTP) 과정,,

Route 53

AWS에서 제공하는 DNS 서비스

단순히 도메인과 IP를 연결하는 것만이 아니라, 트래픽을 어떤 대상으로 보낼지 결정하는 기능도 함께 제공

• 역할: DNS + 헬스체크 + 장애 조치(Failover) + 라우팅 정책(GSLB)
• 주요 라우팅 정책:
  • 단순: 표준 DNS 기능.
  • 가중치 기반: 설정한 비율로 트래픽 분산
  • 지리적 위치/근접: 사용자 또는 리소스 위치 기반 라우팅
  • 지연 시간: 응답 속도가 가장 빠른 리전으로 연결
  • 장애 조치: 대상이 정상일 때만 트래픽 전송
  • 다중 응답: 무작위로 여러 레코드 응답

로드 밸런서와 비슷해 보일 수 있지만 완전히 같지는 않음

• 로드 밸런서: 들어온 트래픽을 여러 서버에 분산
• Route 53: DNS 단계에서 어느 대상으로 보낼지 결정

DNS 레코드

DNS 서버가 요청에 어떻게 응답할지 정의한 정보

기본 형식 : RR(Name, Value, Type, TTL)

주요 레코드

• A 레코드 도메인 이름을 IPv4 주소에 매핑

• CNAME 하나의 도메인 이름을 다른 도메인 이름에 매핑

• NS 해당 도메인을 관리하는 네임서버 정보

• Alias Route 53 전용 특수 레코드 AWS 리소스와 도메인을 연결할 때 사용

• TTL: DNS 응답을 캐시에 얼마나 오래 저장할지 정하는 값

• 테스트 시: 짧게 설정 / 운영 시: 보통 300초 이상 권장

Route 53 라우팅 정책

• 단순 라우팅 -> 기본 DNS 응답 방식
• 가중치 기반 라우팅 -> 트래픽 비율 다르게 가능 [ 예) A 서버 80% / B 서버 20% ]
• 지리적 위치 기반 라우팅 -> 사용자 위치 기준으로 다른 대상으로 연결
• 지리적 근접 라우팅 -> 리소스 위치 기준으로 가까운 곳에 연결
• 지연 시간 기반 라우팅 -> 지연 시간이 가장 낮은 리전으로 연결
• 장애 조치 라우팅 -> 정상인 대상에만 연결 / 헬스 체크와 함께 사용
• 다중 응답 라우팅 -> 여러 레코드 중 일부를 무작위로 응답

호스팅 영역

DNS 레코드들을 저장해 두는 공간 -> 특정 도메인에 대해 어떤 레코드를 둘지 관리하는 장소

• Public Hosted Zone: 인터넷에서 접근 가능
• Private Hosted Zone: 같은 VPC 내부에서만 접근 가능

VPC (Virtual Private Cloud)

AWS 안에서 만드는 가상 네트워크 하나의 독립된 네트워크처럼 동작해서 보안, 관리, 확장 측면에서 유리

• 리전 단위로 생성
• 리전당 기본 5개까지 생성 가능
• VPC당 최대 5개의 CIDR 블록 설정 가능
• 사설 IPv4 범위만 할당 가능
• 다른 VPC나 외부 네트워크와 CIDR 대역이 겹치면 안 됨

Subnet

VPC를 더 작은 네트워크 단위로 나눈 것 VPC 안에서 리소스를 배치하는 IP 범위

• Public Subnet / Private Subnet

특징

• 서브넷은 하나의 AZ에만 속할 수 있음
• 서브넷의 IP 범위는 반드시 VPC의 CIDR 범위 안에 있어야 함

서브넷을 나누는 이유

• 보안 격리
• IP 주소 효율적 사용
• 관리 편의성

CIDR

IP 주소 범위를 표현하는 표기법

예시 ; 192.168.0.0/24

의미

• 앞부분: 네트워크 ID (192.168.0.0)
• 뒷부분: 호스트 ID 범위 - 나머지 8비트(32비트 - 24비트)
• 서브넷 마스크 (/24): 앞의 24비트를 고정

슬래시 뒤의 서브넷 마스크가 클수록 네트워크 ID 부분이 길어지고, 내가 쓸 수 있는 IP(호스트 ID 부분)는 적어짐

IP 주소 = 네트워크 ID + 호스트 ID

AWS에서도 VPC와 서브넷의 주소 범위를 정할 때 CIDR 사용

IGW (Internet Gateway)

VPC가 인터넷과 통신할 수 있도록 연결하는 게이트웨이

VPC는 기본적으로 외부와 격리된 네트워크라서 인터넷 연결을 위해 IGW가 필요 하지만 IGW만 붙인다고 바로 인터넷이 되는 것은 아님 -> 인터넷 통신이 되려면 같이 필요

• VPC에 IGW 연결
• 라우팅 테이블에 인터넷 방향 경로 추가
• 공인 IP 또는 퍼블릭 접근 조건 충족

Route Table

트래픽을 어디로 보낼지 정하는 규칙표?

예를 들어 특정 목적지로 가는 요청을 로컬로 보낼지, IGW로 보낼지, NAT Gateway로 보낼지 결정

• local → 같은 VPC 내부 통신
• 0.0.0.0/0 → IGW → 인터넷 통신
• 0.0.0.0/0 → NAT Gateway → 프라이빗 서브넷의 외부 통신

하나의 라우팅 테이블을 여러 서브넷에 연결할 수도 있음

Public Subnet / Private Subnet

Public Subnet

인터넷과 직접 연결 가능한 서브넷

• IGW 연결
• 라우팅 테이블에 인터넷 경로 존재
• 공인 IP 부여 가능
• Bastion Host
• NAT Gateway
• Public EC2

Private Subnet

인터넷에서 직접 접근 불가능한 서브넷

• DB
• 내부 서버
• 외부에 노출되면 안 되는 애플리케이션 서버

NAT Gateway

Private Subnet의 리소스가 외부 인터넷으로 나갈 수 있게 해주는 장치

내부 → 외부 가능 외부 → 내부 직접 접근 불가

즉, 프라이빗 서브넷 안의 인스턴스가 패키지 다운로드, 외부 API 호출, 업데이트 같은 작업은 가능하게 하고, 외부에서 직접 들어오는 연결은 막는 구조

동작 흐름 : Private Subnet 리소스 → NAT Gateway → IGW → 인터넷

• Public Subnet에 생성
• Elastic IP 사용
• 특정 AZ에 생성
• 여러 AZ에 각각 만들면 가용성 향상
• 시간당 비용 + 데이터 처리 비용 발생

Bastion Host

외부에서 Private Subnet 내부 서버로 안전하게 접속하기 위한 중간 서버

보통 Public Subnet에 두고, 운영자는 먼저 Bastion Host에 접속한 뒤 그 내부에서 Private EC2로 SSH 접속

즉, 외부 사용자가 Private EC2에 바로 들어가는 것이 아니라 중간 관문을 하나 두는 방식

• 보안 그룹 설정 예시 Bastion Host: 특정 외부 IP만 SSH 허용 Private EC2: Bastion Host에서 오는 SSH만 허용

NACL

Subnet 단위에서 트래픽을 제어하는 보안 장치

보안 그룹이 인스턴스 단위라면, NACL은 서브넷 단위?

• 서브넷을 오가는 트래픽 제어
• 허용과 거부 규칙 모두 설정 가능
• 서브넷 생성 시 기본 NACL에 자동 연결
• 기본 NACL은 비교적 넓게 허용
• 사용자 정의 NACL은 처음에 허용 규칙 없이 시작
• 규칙 번호가 낮을수록 우선순위 높음

보안 그룹 vs NACL

• 더 세밀하게 인스턴스를 보호 → 보안 그룹
• 서브넷 단위로 큰 흐름 제어 → NACL

AWS 네트워크 구조

• Region : AWS 데이터 센터가 모여 있는 지리적 영역
• AZ (Availability Zone) : 하나 이상의 데이터 센터 묶음 / 여러 AZ가 모여 하나의 Region 구성
• VPC : Region 안에 만드는 독립 네트워크
• Subnet : VPC를 더 작게 나눈 네트워크 단위 ( 각 서브넷은 하나의 AZ에 속함 )

VPC Peering

서로 다른 VPC끼리 연결하는 방식

원래 VPC는 서로 독립적이지만, 피어링을 설정하면 마치 같은 네트워크처럼 통신 가능

• AWS 내부 네트워크로 연결
• private IPv4 또는 IPv6 사용
• 서로 다른 계정 간 가능
• 서로 다른 리전 간 가능
• VPC CIDR 대역이 겹치면 안 됨
• 피어링 관계는 전이되지 않음
• 라우팅 테이블도 함께 수정 필요

전이되지 않는다는 말 ; A-B 연결, B-C 연결이 있어도 A와 C가 자동으로 연결X

VPC Endpoint

VPC 내부에서 AWS 서비스로 직접 연결하는 방식

예를 들어 Private Subnet의 인스턴스가 S3, SNS 같은 AWS 서비스에 접근해야 할 때, 굳이 NAT Gateway → IGW → 인터넷 경로를 거치지 않도록 해줌

• AWS 내부 네트워크 이용
• 더 안전
• 더 효율적
• 인터넷 우회 불필요

NAT Gateway와 VPC Endpoint 차이

NAT Gateway

인터넷을 통해 외부로 나가는 통로 경로 : Private Subnet → NAT Gateway → IGW → 외부 인터넷/AWS 서비스

VPC Endpoint

AWS 내부망으로 바로 연결 경로 : Private Subnet → VPC Endpoint → AWS 서비스 AWS 서비스 접근만 필요하다면 VPC Endpoint가 더 적절한 경우가 많음 장점: 보안성 향상, 속도개선, 비용 최적화

Spring Boot 애플리케이션을 AWS EC2에 배포하고, ALB(Application Load Balancer) 뒤에 연결해 두었는데 계속 502 Bad Gateway 가 발생했다. 처음에는 애플리케이션 자체 문제, 보안 그룹, 헬스체크 경로 문제를 의심했다. 그런데 결론적으로는 대상 그룹(Target Group)의 Protocol Version이 HTTP2로 설정되어 있었던 것이 핵심 원인이었다.

정리하면, 내 서비스는 일반적인 Spring Boot 백엔드였고 8080 포트에서 HTTP로 정상 동작하고 있었다. 직접 EC2 내부에서 확인해 보면 /health 엔드포인트는 200 OK를 반환했다. 그런데도 ALB 대상 그룹에서는 계속 Unhealthy가 떴고, 결국 502가 발생했다.

먼저 확인했던 것들

처음에는 가장 흔한 원인부터 점검했다.

• 애플리케이션이 실제로 8080 포트에서 실행 중인지
• /health 엔드포인트가 200을 반환하는지
• 대상 그룹 상태 검사 경로가 /health로 되어 있는지
• 성공 코드가 200인지
• 보안 그룹에서 포트 8080이 열려 있는지

직접 EC2에서 확인했을 때는 /health가 정상 응답을 주고 있었다. 그래서 애플리케이션이 죽은 것은 아니었고, 헬스체크 경로도 틀리지 않았다.

또 AWS 문서상 ALB 대상 그룹의 상태 검사에서는 HTTP/1.1 또는 HTTP/2를 사용하는 경우 유효한 URI 경로를 지정할 수 있고, 성공 코드는 기본적으로 200이다. 따라서 /health, 200 조합 자체는 문제 없는 설정이었다.

이상했던 점

문제는 대상 그룹 상세 설정을 자세히 보다가 발견했다.

• Protocol: HTTP
• Port: 8080
• Protocol version: HTTP2
• Health check path: /health
• Success code: 200

겉보기에는 크게 이상해 보이지 않을 수 있다. 하지만 AWS 공식 문서에 따르면, Application Load Balancer는 기본적으로 타깃에 HTTP/1.1로 요청을 보낸다. 다만 대상 그룹의 Protocol version 설정을 통해 타깃으로 HTTP/2 또는 gRPC를 사용하도록 바꿀 수 있다. 즉, 나는 평범한 Spring Boot 백엔드를 올려 두었는데, 대상 그룹이 백엔드와 통신할 때 HTTP2를 쓰도록 설정되어 있었던 것이다.

왜 이게 문제가 되었나

내 애플리케이션은 브라우저나 curl로 접근했을 때는 잘 응답했다. 이 테스트들은 사실상 일반적인 HTTP 요청 확인에 해당한다. 그런데 ALB는 대상 그룹 설정에 따라 타깃과 통신하는 방식이 달라질 수 있다.

AWS 문서에는 대상 그룹의 프로토콜 버전에 따라 요청 프로토콜과의 조합 결과가 달라진다고 명시되어 있다. 특히 HTTP/1.1 요청을 HTTP/2 대상 그룹으로 보내는 조합은 오류가 될 수 있다. 또한 프로토콜 버전이 맞지 않으면 ALB에서 프로토콜 불일치 문제가 발생할 수 있다고 설명한다. ([AWS Docs][2])

결국 내 경우는 다음과 같이 이해할 수 있었다.

• 애플리케이션 자체는 정상
• /health도 정상 응답
• 하지만 ALB 대상 그룹이 백엔드와 통신할 때 HTTP2를 기대
• 실제 백엔드는 그 환경에 맞지 않음
• 상태 검사 실패
• 타깃이 Unhealthy
• 최종적으로 502 발생

해결 방법

해결은 단순했다. 대상 그룹의 Protocol Version을 다음과 같이 바꾸면 되었다.

• Protocol: HTTP
• Port: 8080
• Protocol version: HTTP1
• Health check path: /health
• Success code: 200

AWS 공식 문서상 ALB는 기본적으로 타깃에 HTTP/1.1로 요청을 보내므로, 일반적인 Spring Boot 백엔드라면 이 설정이 가장 자연스럽다. 설정을 바꾼 뒤에는 대상 그룹 상태가 정상으로 바뀌고, 502도 해결되었다. 안되면 대상그룹 - 로드밸런서를 다시 만들면 HTTP1로 잘 적용된다!!!

왜 HTTP2로 설정되어 있었는지는 아직 모르겠다

솔직히 말하면, 왜 대상 그룹 Protocol Version이 HTTP2로 바뀌어 있었는지는 나도 정확히 모르겠다. 내가 의도적으로 설정한 기억은 없다.

가능한 추측은 몇 가지 있다.

• 대상 그룹 생성 시 콘솔에서 잘못 선택했을 가능성
• 기존 설정을 복사하거나 수정하는 과정에서 바뀌었을 가능성
• 다른 문서를 참고하면서 HTTP2가 더 “최신” 설정처럼 보여 무심코 선택했을 가능성

하지만 중요한 것은 원인을 특정하는 것보다, 백엔드 서버가 어떤 프로토콜을 기대하는지와 대상 그룹 설정이 일치해야 한다는 점이다.

이번 이슈에서 배운 점

이번 문제를 겪으면서 느낀 것은, ALB 502가 난다고 해서 무조건 애플리케이션 코드 문제라고 보면 안 된다는 점이다.

내가 실제로 확인했던 순서는 이랬다.

1. 애플리케이션 프로세스/컨테이너가 살아 있는지 확인
2. EC2 내부에서 /health가 200인지 확인
3. 대상 그룹의 헬스체크 경로와 성공 코드 확인
4. 보안 그룹 확인
5. 마지막으로 대상 그룹의 Protocol Version 확인

특히 앞의 것들이 모두 정상인데도 타깃이 계속 Unhealthy라면, Protocol Version까지 반드시 확인해야 한다.

한 줄 결론

Spring Boot 백엔드는 정상인데 ALB에서만 헬스체크가 실패하고 502가 난다면, 대상 그룹의 Protocol Version이 HTTP2로 되어 있지 않은지 꼭 확인하자. 일반적인 백엔드라면 HTTP1 설정이 맞을 가능성이 크다.

아이템 요약

육아 초보 부모들을 위한 개인 맞춤형 육아용품 큐레이션 앱 코코베이(Cocobay)를 구상

과잉 정보 속에서 제품을 고르기 어려운 부모들을 위해 월령별 가이드, AI 추천, 예산 계산기, 할인 알림 등 기능을 제공

팀 구성 및 역할

• 기획: 육아용품 시장 리서치, 사용자 인터뷰, 페르소나 설정
• 디자인: UI/UX
• 프론트엔드 개발: 추천 홈화면, 예산 계산기, 할인 알림 기능 구현
• AI 모델 개발: AI 렌즈 기반 유사 상품 탐색 기능 초기 모델 구현

프로젝트 진행 과정

• 육아 부모 대상 설문 및 심층 인터뷰 진행
• 맘카페 크롤링을 통한 정보 탐색 피로 분석
• 기획 → 디자인 → 프론트 구현 → AI 모델 → 발표자료 제작까지 진행
• Notion + Figma + GitHub로 협업

잘했다고 생각하는 점

• 사용자 중심 문제 정의가 명확했고, 인터뷰 기반 페르소나가 구체적이었음
• 실사용자의 고민을 직접 반영한 기능 기획
• 디자인과 개발 간 협업이 매끄럽고 속도감 있게 진행됨
• 실제 프론트엔드 구현물 + AI 모델까지 일정 내에 완성

아쉬운 점

• 데이터 기반 기능의 정확도와 검증 부분은 시간이 부족해 MVP 수준에 머물렀음
• 백엔드 연동하지 못하고 프론트에서 그친것이 아쉬움
• 체험단 확보 및 초기 홍보 전략을 실제 실행해보진 못하여 유저 피드백 수집 및 반복 개선을 하지 못한 점이 아쉬움

향후 발전 방향

• AI 렌즈 정확도 개선 및 자체 데이터셋 구축
• 제휴몰 연동을 통한 수익화 실험

개인적으로 얻은 것

• 사용자 인터뷰부터 실 프로토타입 개발까지, 스타트업의 문제 정의 – 솔루션 설계 – MVP 개발 – 피칭 전 과정을 경험
• 팀 내 빠른 의사결정과 다른 파트 팀원들과의 협업의 중요성을 체감
• 피봇되는게 당연하고 이 과정을 단순히 힘들다고 회피하지 않기
• 아이디어만 있다면 충분히 공부해서라도 구체화 가능하다. 너무 불가능하다고 생각하지 말기!

ch3

ch4

ch5

ch6

ch7

ch8

ch9

ch10

ch11

ch12

ch13

ch14

ch15

ch16

ch17

ch18

소프트웨어 프로세스 1

소프트웨어 프로세스 2

sw 모델링 및 표현도구

요구공학

시스템 모델링

아키텍쳐설계

객체지향소프트웨어

ch8

ch9

ch10

ch11

ch12

ch13

ch14

ch15

ch16

ch17

ch18

ch19

ch20

ch21

ch2

ch3

ch4 ch5

ch6

ch7 ch8 ch9

족보 풀이

1. 기본 골격

가장 기초적인 형태 @app.get("/") 같은 데코레이터가 이 주소로 오면 아래 함수를 실행해라고 알려줌

from fastapi import FastAPI

app = FastAPI()

# GET 요청을 받음
@app.get("/")
async def read_root():
    return {"message": "Hello World"}

• async def: 비동기 함수로 정의
  • 데이터베이스나 AI 요청처럼 오래 걸리는 작업에 필수 -> ai가 오래걸려도 그걸 기다지리않고 다른걸 할수있음
• Return: 딕셔너리({})를 리턴하면 자동으로 JSON으로 변환되어 나감

2. 경로 변수 (Path Parameter)

URL 경로 자체에 들어있는 변수를 받음 예: /items/5 -> item_id는 5

@app.get("/items/{item_id}")
async def read_item(item_id: int):  # 타입 힌트(int) 필수!
    return {"item_id": item_id}

• item_id: int: 이렇게 타입을 적어두면, 사용자가 /items/foo라고 문자를 넣었을 때 FastAPI가 알아서 숫자만 넣으라고 에러를 냄

3. 쿼리 파라미터 (Query Parameter)

URL 뒤에 ?로 붙는 변수 경로({})에 없는 변수를 함수 인자로 넣으면 자동으로 쿼리 파라미터가 됌 예: /items/?skip=0&limit=10

@app.get("/items/")
async def read_items(skip: int = 0, limit: int = 10):
    return {"skip": skip, "limit": limit}

• skip: int = 0: 값이 안 들어오면 기본값 0 사용

4. 데이터 받기

POST 요청으로 복잡한 데이터를 받을 때 사용 Pydantic이라는 라이브러리로 데이터의 모양(스키마)을 정의

from pydantic import BaseModel

# 1. 데이터 모양 정의 (붕어빵 틀)
class Item(BaseModel):
    name: str
    price: float
    is_offer: bool = None  # 선택 사항

# 2. 함수에서 사용
@app.post("/items/")
async def create_item(item: Item): # item 변수는 Item 클래스 모양이어야 함
    return {"name": item.name, "price": item.price}

• 사용자가 JSON 데이터를 보내면, FastAPI가 Item 클래스 모양과 맞는지 검사하고, 자동으로 변수(item)에 넣어줌
• item.name처럼 점(.)을 찍어서 데이터에 접근할 수 있음

5. 라우터 나누기 (APIRouter)

기능별로 파일을 쪼갤 때 사용

파일: `users.py`

from fastapi import APIRouter

router = APIRouter()

@router.get("/users/")
async def read_users():
    return [{"username": "Rick"}, {"username": "Morty"}]

파일: main.py (메인)

from fastapi import FastAPI
from . import users # users.py 불러오기

app = FastAPI()

# users의 라우터를 메인에 합체!
app.include_router(users.router)

자동 문서화 (Swagger UI)

FastAPI의 가장 큰 장점 코드를 짜고 서버를 켜면, 자동으로 API 설명서 사이트를 만들어줌

• 서버 실행 후 주소창에: http://localhost:8000/docs
• API를 직접 테스트 가능 (Postman 없어도 됨)

1. 웹소켓과 STOMP 기초 개념

단순 웹소켓만 쓰면 로우 레벨이라 메시지 형식을 일일이 다 정해야 함 그래서 우리는 STOMP 규격 사용했음

• 구조: 메일함처럼 특정 주소를 '구독(Sub)'하고, 그 주소로 메시지를 '발행(Pub)'하는 방식임.

• 장점: 메시지 브로커를 통해 채팅방별로 메시지를 꽂아주기가 훨씬 편함.

• Publisher(발행자): 채팅 메시지를 보내는 사람 (클라이언트)

• Subscriber(구독자): 채팅방에 들어와서 메시지를 받는 사람 (클라이언트)

• Broker(중개자): 메시지를 받아서 구독 중인 사람들에게 뿌려주는 서버

2. 백엔드 설정 (Spring Boot)

먼저 의존성에 spring-boot-starter-websocket 추가되어 있어야 함.

[WebSocketConfig.java]

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        // 메시지 받을 때: /sub/chat/room/1 이런 식으로 구독함
        config.enableSimpleBroker("/sub"); 
        // 메시지 보낼 때: /pub/chat/message 이런 식으로 보냄
        config.setApplicationDestinationPrefixes("/pub");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws") // 프론트가 접속할 엔드포인트
                .setAllowedOrigins("https://www.example.com") // 프론트 도메인 필수
                .withSockJS(); // 낮은 버전 브라우저 대응
    }
}

3. 채팅 로직 흐름 (우리 서비스 특화)

글쓴이가 게시글(Post) 댓글에서 선택해서 팟 참여 확정 -> 채팅방 생성 구조로 기획을 했음..

1. 팟 확정: 게시글 작성자가 참여자를 선택하고 '확정' 누름.
2. 채팅방 생성: 서버에서 ChatRoom 만들고 선택된 인원들을 ChatMember로 등록함.
3. 알림 발송: 참여자들에게 "채팅방에 초대되었습니다"라고 알림 쏨.
4. 입장 및 구독: 프론트에서 roomId를 받아 해당 경로(/sub/chat/room/{id})를 구독함.
5. 메시지 전송(Publish): 유저가 채팅 치면 프론트에서 /pub/chat/message로 JSON 데이터를 전송

[ChatController.java]

@Controller
@RequiredArgsConstructor
public class ChatController {
    private final SimpMessageSendingOperations messagingTemplate;

    @MessageMapping("/chat/message") // 프론트가 /pub/chat/message로 보낼 때
    public void message(ChatMessageDto message) {
        // DB에 채팅 내역 저장하는 로직 추가 가능
        // 구독 중인 사람들에게 메시지 전달
        messagingTemplate.convertAndSend("/sub/chat/room/" + message.getRoomId(), message);
    }
}

4. 프론트엔드와 협업할 때 주의사항

① 보안 및 인증 (가장 많이 막히는 부분)

• 웹소켓은 일반 HTTP 요청이랑 다르게 Header에 토큰 담기가 까다로움....
• 해결: 연결 시점(connect)에 쿼리 파라미터로 토큰을 보내거나, STOMP의 connectCallback 헤더에 JWT 토큰을 실어 보내야 함. 백엔드에서 ChannelInterceptor를 구현해서 토큰 검증 로직 따로 짰음

② CORS 에러

• 웹소켓 엔드포인트(.addEndpoint("/ws"))에도 .setAllowedOrigins 설정을 정확히 해줘야 함. 안 그러면 프론트에서 접속 못 함......

③ 도메인 연결 (HTTPS/WSS)

• 서비스 HTTPS 적용했다면 프론트도 ws://가 아니라 wss://로 접속해야 함.
• AWS ALB(로드밸런서) 쓰고 있으면 웹소켓 프로토콜도 지원하도록 설정 확인해야 함 (기본적으로 지원하지만 간혹 타임아웃 이슈 있음).

5. 오류 해결 및 팁

• 채팅방 자동 생성 이슈: 댓글에서 선택해서 채팅방 만들 때, 선택된 인원들의 Member ID 리스트를 받아서 ChatMember(중간 테이블)에 저장해야 했음. 그래야 나중에 "내 채팅방 목록" 조회할 때 내가 속한 방만 가져올 수 있었음
• 무한 루프 방지: 프론트에서 메시지 받고 바로 다시 메시지 쏘는 로직 들어가면 서버 터짐. 이벤트 리스너 관리 잘하라고 프론트한테 말해줘서 해야함!

사소하지만 디테일 구현하고자 한 포인트

유저마다 last_read_at(마지막 읽은 시간)을 필드로 둠. 채팅방 목록 불러올 때 이 시간 이후로 쌓인 메시지 개수를 쿼리로 날려서 "안 읽은 메시지 N개" 기능을 구현했음..

Full-Stack HTTPS 인프라 구축 완벽 정리

1. 인프라 구조 설계

• Front-end: Vercel (자동 HTTPS 적용됨) → www.example.com
• Back-end: AWS EC2 + ALB (수동 설정 필요) → api.example.com
• 핵심: 하나의 도메인을 사서 서브도메인으로 앞뒤를 나눠서 관리함.

2. 도메인 구매 및 Route 53 연결

1. 도메인 구매: 가비아 등에서 맘에 드는 거 삼.
2. 호스팅 영역 생성: AWS Route 53 가서 구매한 도메인으로 '퍼블릭 호스팅 영역' 만듦.
3. 네임서버(NS) 교체:

• Route 53에서 생성된 NS 레코드 값 4개 복사함.
• 가비아 관리 페이지 가서 기존 네임서버 지우고 복사한 값 넣음. (맨 끝 마침표 . 빼고) 전파되는데 시간 좀 걸림

3. SSL 인증서 발급 (ACM)

1. 인증서 요청: AWS ACM 가서 *.example.com , example.com 형태로 2개 포함해 신청
2. DNS 검증: 검증 방식은 'DNS 검증' 선택
3. 레코드 생성: "Route 53에서 레코드 생성" 버튼 누르면 알아서 CNAME 생성
4. 상태 확인: '발급됨' 뜰 때까지 대기 ( 시간소요)

4. 로드밸런서(ALB) 및 타겟 그룹 세팅

1. 대상 그룹(Target Group) 생성:

• 유형은 '인스턴스', 포트는 스프링 부트 포트(8080)로 설정
• 내 EC2 인스턴스 체크해서 타겟에 포함시키기

2. ALB 생성:

• Application Load Balancer 선택
• 가용 영역(AZ)은 최소 2개 이상의 퍼블릭 서브넷 선택해야함 (나는 a,c선택함)
• 보안 그룹: 80(HTTP), 443(HTTPS) 둘 다 열려 있어야 함.

3. 리스너 설정:

• HTTPS:443: 아까 ACM에서 만든 인증서 걸어주고, 대상 그룹으로 넘기기
• HTTP:80: 호스트 헤드 = 도메인 , URL로 리디랙션

        -> 모든 요청을 HTTPS로 리디렉션 (상태 코드 301) -> 1순위

5. Route 53 - A 레코드 연결

1. Route 53 호스팅 영역 다시 들어감. 1-1. 서브도메인(백엔드용) 1-2. 레코드 생성: www 혹은 api 등 서브도메인 입력 1-3. 별칭(Alias): 스위치 켜고, 'ALB에 대한 별칭' 선택해서 만든 로드밸런서 주소랑 연결 1-1. 도메인(프론트용) 1-2. 레코드 생성: 아무런 이름 입력 X 1-3. 별칭(Alias) 끄기: ALB에 대한 별칭 해제하고 프론트의 vercel 배포 주소를 넣기

6. CORS 및 헬스 체크 이슈 해결 (중요함!)

• CORS 에러: 프론트(www)랑 백(api) 도메인이 다르기 때문에 스프링 부트에서 허용해줘야 함. allowedOrigins에 프론트 주소 정확히 작성하기
• Health Check: ALB는 주기적으로 서버가 살아있는지 체크해줌 (/ 경로가 404 뜨면 서버 죽은 줄 알고 트래픽 끊음)
  • 스프링 부트에 간단하게 200 OK 뱉는 /health 컨트롤러 만들고, 대상 그룹 설정에서 헬스 체크 경로를 /health로 바꿔서 테스트하기

1. Nginx 설치

# 패키지 매니저 업데이트
sudo yum update -y

# Nginx 설치
sudo yum install nginx -y

# Nginx 실행 및 서버 부팅 시 자동 실행 설정
sudo systemctl start nginx
sudo systemctl enable nginx

2. 설정 파일 수정

# 기본 설정 파일 백업 
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

# 설정 파일 열기
sudo nano /etc/nginx/nginx.conf

3. nginx.conf 내용 수정

server {
    listen       80;
    listen       [::]:80;
    server_name  도메인 www.도메인;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;

        # SSE 및 실시간 통신 설정
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_cache_off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        chunked_transfer_encoding off;
    }

    # 기존에 있던 다른 설정들은 일단 그대로 두기
}

4. 적용 및 확인

# 문법 체크 
sudo nginx -t

# Nginx 재시작
sudo systemctl restart nginx

주의사항 (AWS 보안 그룹)

AWS 보안 그룹에서 80 포트를 여는 것이 필수

Git Bash를 열고 명령어를 입력

mysql -h <RDS_엔드포인트_주소> -u <마스터_사용자_이름> -p

잠깐! 만약 여기서 무한 로딩시 AWS RDS 보안 그룹(3306 포트)에서 '내 IP'가 허용되어 있는지 다시 확인

2. 비밀번호 입력

Enter password: 라는 문구가 뜨면 RDS 생성 시 설정했던 비밀번호를 입력하고 엔터 (입력할 때 화면에 아무 글자도 안 보이지만 실제로는 입력되고 있는 중..)

3. 데이터베이스 생성 및 확인

접속에 성공해서 mysql> 프롬프트가 보이면 아래 명령어들을 입력

-- 1. 데이터베이스 생성
CREATE DATABASE madcamp;

-- 2. 생성 확인 
SHOW DATABASES;

-- 3. 생성한 DB 선택
USE madcamp;

-- 4. 테이블 생성 SQL

--5. 생성된 테이블 목록 확인
SHOW TABLES;
테이블 이름이 리스트로 쭉 떠야 함

3. 특정 테이블 구조 확인 
(예를 들어 member 테이블이 설계한 대로 잘 만들어졌는지 컬럼을 확인하고싶을때)
DESC member;

1. 안드로이드 스튜디오 상단 메뉴에서 Tools -> Device Manager를 클릭
2. 또는 오른쪽 사이드바에 있는 기기 모양 아이콘(Device Manager)을 클릭

2단계: 가상 기기 만들기

1. Device Manager 창에서 [Create device] (또는 + 버튼)를 누르기
2. Hardware 선택: 목록에서 원하는 기기를 고르기

• 팁: Pixel 7이나 Pixel 8처럼 옆에 Play Store 로고가 있는 기기를 고르기

3. 기기를 선택했으면 오른쪽 하단 [Next]를 누르기

3단계: 안드로이드 OS 버전 선택

1. 가상 핸드폰에 설치할 안드로이드 버전 고르기
2. 추천: API 34 (Android 14) 또는 API 33 (Android 13)을 권장함
3. 버전 이름 옆에 파란색 [Download] 아이콘이 있다면 먼저 클릭해서 설치하기
4. 다운로드가 끝나면 해당 버전을 선택하고 [Next]를 누르기

4단계: 설정 마무리

1. Verify Configuration: 기기 이름을 정하는 단계인데, 기본값으로 두고 [Finish]를 선택
2. 이제 Device Manager 리스트에 방금 만든 기기가 나타남

5단계: 앱 실행하기

1. 안드로이드 스튜디오 상단 툴바가 방금 만든 가상 기기 이름으로 선택되어 있는지 확인
2. 그 옆에 있는 초록색 재생 버튼(▶️, Run 'app') 클릭
3. 기다리면 컴퓨터 화면에 핸드폰 모양 창이 뜨면서 안드로이드가 부팅되고 코드가 실행됌

즉, 해야할일 = 디자인의 수치(색상, 간격, 폰트)를 참고해 안드로이드용 XML로 번역하기

1단계: 안드로이드 스튜디오 프로젝트 설정

V0의 UI를 구현하기 위해 프로젝트를 먼저 생성

1. New Project → Empty Views Activity를 선택하세요.

주의: 그냥 Empty Activity는 최신 Compose 방식이라 Java와 맞지 않고 언어선택도 안됌 (compose는 코틀린에서만 사용) 반드시 Views가 붙은 것을 골라야 XML과 Java를 사용하기_ 2. Language를 Java로 설정 3. Build Configuration Language는 Groovy DSL로 선택 (예제가 많음!!)

2단계: 디자인 에셋(색상, 폰트) 옮기기

V0에서 사용한 색상값과 폰트를 안드로이드에 미리 등록하기

• 색상 등록: res/values/colors.xml 파일을 열고 기획하신 색상을 추가

  <resources>
    <color name="primary">#1E3A8A</color>
    <color name="secondary">#64748B</color>
    <color name="background">#F8FAFC</color>
    <color name="status_stored">#16A34A</color>
    </resources>
  

* 폰트 적용: 1.  `res` 폴더 우클릭 → New → Android Resource Directory → Resource type을 font로 선택
2.  다운로드한 Noto Sans KR 파일(.ttf)을 `res/font` 폴더에 넣기 (파일명은 소문자와 언더바만 가능: `noto_sans_kr.ttf`).
* 테마 설정: `res/values/themes.xml`에서 `android:fontFamily`를 지정하면 앱 전체에 적용됌

---

### 3단계: 화면 구조 잡기 (탭 구성)

'리턴즈' 앱은 하단 탭이 4개이므로 `BottomNavigationView`를 사용해야 합니다.

1. Layout 만들기: `res/layout/activity_main.xml`에서 화면 하단에 하단 바를 배치합니다.
2. Menu 만들기: `res/menu` 폴더를 만들고 4개의 탭(홈, 갤러리, 습득등록, 분실등록) 아이콘과 이름을 정의합니다.
3. Fragment: 각 탭을 클릭했을 때 바뀔 화면 4개를 생성합니다. (우클릭 → New → Fragment → Fragment (Blank))
* `HomeFragment`, `GalleryFragment`, `FoundRegFragment`, `LostRegFragment`



---

### 4단계: XML로 UI 번역하기 (V0 코드 보고 그리기)

V0에서 본 디자인 요소들을 안드로이드 뷰로 바꾸기

| V0 (웹 요소) | 안드로이드 (XML 요소) | 설명 |
| --- | --- | --- |
| `<div>` (박스) | `LinearLayout` 또는 `ConstraintLayout` | 요소를 담는 그릇 |
| `<h1>`, `<p>` | `TextView` | 글자 표시 |
| `<input>` | `EditText` | 입력창 |
| `<img>` | `ImageView` | 사진 |
| `List`, `Flex` | `RecyclerView` | 목록 구현 |
| `Button` | `Button` 또는 `MaterialButton` | 클릭 버튼 |

예시: 탭 1의 검색창 만들기

```xml
<EditText
    android:id="@+id/search_bar"
    android:layout_width="match_parent"
    android:layout_height="50dp"
    android:hint="제목 또는 장소 검색"
    android:background="@drawable/bg_search_rounded" 
    android:padding="12dp" />

(둥근 모서리는 res/drawable에 XML 파일을 따로 만들어 적용...가장 하단 참조)

5단계: Java 코드로 기능 연결하기

이제 화면(XML)과 로직(Java)을 연결해야함

1. View 연결: findViewById()를 사용하여 Java 코드에서 XML 부품을 불러오기

   TextView titleText = findViewById(R.id.item_title);
   titleText.setText("파란 우산 습득");
   

```

2. 데이터 리스트: 탭 1의 목록을 보여주기 위해 Adapter가 필요 데이터(리스트) -> 어댑터 -> RecyclerView 순서로 연결

3. 탭 전환 로직: BottomNavigationView의 아이템 클릭 리스너를 만들어 클릭 시 프래그먼트를 교체(FragmentTransaction)하게 함

가장 오류 많이 나는 부분

1. 둥근 모서리와 테두리: V0(Tailwind)의 rounded-lg 같은 효과는 안드로이드에서 res/drawable에 shape XML 파일을 만들어야함 (귀찮기도하고 약간 복잡?)
2. RecyclerView: 리스트 구현이 처음엔 꽤 복잡 (Item XML, ViewHolder, Adapter 3종 세트가 필요함,, but 한 번 배우면 계속 씀/시작만 어렵다~)
3. ViewBinding: findViewById를 수백 번 쓰는 대신 ViewBinding이라는 기술을 사용하면 코드가 훨씬 깨끗해짐