예를 들어 관광지의 이미지와 소개 문장을 OpenAI Vision API에 전달하면, COZY, NATURE, ROMANTIC처럼 추천에 사용할 무드 정보를 반환받는다.

이미지 태깅은 어떤 흐름으로 동작할까?

태깅 대상 Spot마다 다음 과정을 수행한다.

Spot 이미지 URL, 설명 조회 ↓ OpenAI Vision API 호출 ↓ 무드 분석 결과 반환 ↓ SpotMood 저장 ↓ Spot 상태를 PUBLISHED로 변경

여기서 가장 오래 걸리는 구간은 OpenAI API 응답을 기다리는 시간이었다.

처음에는 관광지 하나씩 순서대로 태깅했다.

for (Spot spot : pendingSpots) {
    spotMoodTagger.tagSpot(spot);
}

그리고 이 전체 과정을 하나의 트랜잭션으로 묶었다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void tagSpot(Spot spot) {
    List<String> imageUrls = spotImageRepository.findBySpotId(spot.getId());
    String overview = spotTranslationRepository
        .findBySpotIdAndLocale(spot.getId(), KOREAN);

    MoodAnalysisResult result =
        moodAnalysisClient.analyze(imageUrls, overview);

    spotMoodRepository.save(spotMood);
    spot.publish();
    spotRepository.save(spot);
}

그 결과...

처리 시간이 정말 심각하게 오래 걸렸다.. 😅

관광지 하나의 LLM API 응답을 기다린 뒤 다음 Spot을 처리하는 순차 구조였기 때문이다.

트랜잭션 경계부터 분리하기

일단 가장 큰 문제는 LLM 응답을 기다리는 동안에도 DB 트랜잭션이 계속 열려 있다는 점이었다.

앞서 이미지 적재 과정에 사용한 Virtual Thread로 여러 건을 동시에 호출하는 방식을 사용하려고 했다.

하지만 기존 구조 그대로 병렬화하면, 각 작업이 LLM 응답을 기다리는 2~5초 동안 DB 커넥션을 계속 점유하게 된다.

작업 1: DB 커넥션 점유 → LLM 응답 대기 → 저장 작업 2: DB 커넥션 점유 → LLM 응답 대기 → 저장 작업 3: DB 커넥션 점유 → LLM 응답 대기 → 저장

핵심 문제

LLM API를 호출하는 동안에는 DB 작업을 하지 않으므로, 이 구간에서 트랜잭션을 유지할 이유가 없었다.

태깅 과정을 세 가지 단계로 나누면:

1. 이미지와 설명 조회
2. LLM API 호출
3. 분석 결과 저장과 Spot 상태 변경

이 중 원자성이 필요한 부분은 마지막 단계다.

따라서 저장과 상태 변경만 같은 트랜잭션으로 묶는 방식으로 수정하였다.

public long tagSpot(Spot spot) {
    // 1. DB 조회
    List<String> imageUrls = spotImageRepository.findBySpotId(spot.getId());
    String overview = spotTranslationRepository
        .findBySpotIdAndLocale(spot.getId(), KOREAN);

    // 2. LLM 호출
    llmSemaphore.acquireUninterruptibly();
    long llmStartNanos = System.nanoTime();

    MoodAnalysisResult result;
    try {
        result = moodAnalysisClient.analyze(imageUrls, overview);
    } finally {
        llmSemaphore.release();
    }

    long llmLatencyMs =
        (System.nanoTime() - llmStartNanos) / 1_000_000;

    // 3. 저장 구간만 트랜잭션 적용
    transactionTemplate.executeWithoutResult(status -> {
        SpotMood spotMood = SpotMood.create(
            spot.getId(),
            result.vector(),
            result.tags(),
            result.confidence()
        );

        spotMoodRepository.save(spotMood);
        spot.publish();
        spotRepository.save(spot);
    });

    return llmLatencyMs;
}

변경 후 처리 흐름

DB 조회 ↓ 커넥션 반환 ↓ LLM API 호출 ↓ DB 커넥션 미사용 ↓ 결과 저장 + 상태 변경 ↓ 짧은 트랜잭션 종료

TransactionTemplate을 사용해 저장 구간에만 트랜잭션을 열었다. 같은 클래스 내부에서 @Transactional 메서드를 호출할 때 프록시가 적용되지 않는 문제도 피할 수 있었다.

Virtual Thread로 여러 태깅 작업 실행하기

이전 글들에서 본 Virtual Thread와 Semaphore를 조합한 방식이다.

• 글 1 (Chunk): 데이터 검증을 트랜잭션 밖으로 분리
• 글 2 (GCS): Virtual Thread + Semaphore로 네트워크 I/O 병렬화

여기서는 "DB 트랜잭션 범위 분리" 를 추가로 적용한다!

트랜잭션 범위를 분리한 뒤, 각 Spot 태깅 작업을 Virtual Thread로 병렬 실행했다.

Executors.newVirtualThreadPerTaskExecutor();

동시성 제어

Virtual Thread를 사용한다고 해서 모든 API 호출을 한꺼번에 보내면 안 된다. OpenAI API 요청 제한에 걸리거나, 429 오류가 발생할 수 있기 때문이다.

그래서 실제 LLM API 호출 구간은 Semaphore 로 제한했다.

Semaphore llmSemaphore = new Semaphore(concurrency);

성능 측정 결과

동일한 태깅 작업을 대상으로 동시성 값만 변경해 처리 시간을 비교했다.

동시성 10에서 전체 처리 시간이 187초에서 19.5초로 약 9.6배 단축 되었다!

결과 분석:

• 평균 LLM 호출 시간: 약 3.5~3.9초
• 동시성 10에서 p95: 약 7초
• 429 오류: 없음

정리

기존 구조처럼 LLM 호출까지 트랜잭션에 포함한 상태로 병렬 처리했다면, 작업 수가 늘수록 커넥션 점유 시간이 늘어나 처리 시간도 오래 걸렸을 것이다.

핵심 최적화 기법:

• Virtual Thread: 여러 I/O 작업을 가볍게 실행
• Semaphore: LLM API 동시 요청 수 제한
• TransactionTemplate: 태그 저장과 상태 변경을 원자적으로 처리
• 설정 파일: 코드 수정 없이 동시성 값 조정

기존에는 해당 URL을 DB에 그대로 저장하고 클라이언트에서 이미지를 조회하는 구조였다.

그런데 회의중에 팀원분이 이런 의견을 주셨다.

이미지를 전부 외부 API에 의존하면, 해당 서버 상태에 우리 서비스도 영향을 받는 것 아닌가?

실제로 이미지 서버 장애나 URL 변경이 발생하면 MOODI의 이미지 피드에도 바로 영향을 줄 수 있다.

그래서 외부 이미지를 우리 스토리지에 미리 저장해서 제공하는 방식으로 변경하기로 했다.

MOODI는 GCP 환경에서 운영하고 있기 때문에 이미지 저장소로 Google Cloud Storage(GCS) 를 선택했다.

GCP GCS

Google Cloud Storage는 버킷을 주시므로 구성된 스토리지 서비스이다. 버킷을 사용하면 스토리지 클래스와 연결된 개별 객체를 저장할 수 있을 뿐만 아니라, 폴더 내에서 개별 객체를 계층적으로 정리할 수도 있다.

버킷이란? 파일을 저장하는 큰 저장 공간을 말한다.

예를 들어 이미지 100장을 저장한다면 버킷을 이미지마다 만드는 것이 아니라, 버킷 하나를 만들고 그 안에 100개의 Object를 저장하는 식이다.

버킷 만들기

1. 새 프로젝트 및 버킷 만들기

2. 권한 설정

이미지 적재 파이프라인 변경

기존에는 CSV의 TourAPI 이미지 URL을 그대로 DB에 저장했다.

기존:

CSV → TourAPI URL → DB

변경 후:

CSV ↓ TourAPI 이미지 다운로드 ↓ GCS 업로드 ↓ GCS URL ↓ DB 적재

의존성 추가

implementation("com.google.cloud:google-cloud-storage:2.49.0")

인터페이스 분리

애플리케이션 로직이 GCS 구현체에 직접 의존하지 않도록 업로드 인터페이스를 분리했다.

public interface SpotImageUploader {
    String upload(String sourceUrl, String fileName);
}

실제 GCS 업로드는 GcsSpotImageUploader 가 담당하도록 했다.

이미지 15,000장을 어떻게 처리할까?

이미지 다운로드와 GCS 업로드는 네트워크 I/O 작업이다.

I/O 작업의 특징

네트워크 I/O는 요청을 보낸 후 응답을 기다리는 "대기 시간"이 대부분이다.

예를 들어 이미지 하나를 처리하는데 2초가 걸린다면:

• 다운로드 요청 → 1초 대기
• 업로드 요청 → 1초 대기

하지만 이 "대기 시간"동안 CPU는 놀고 있다.

따라서 여러 이미지를 동시에 처리하면:

이미지1 다운로드 중(1초) = 이미지210도 동시 다운로드 이미지1 업로드 중(1초) = 이미지210도 동시 업로드

이렇게 병렬 처리하면 시간을 획기적으로 단축할 수 있다.

그래서 Java 21 Virtual Thread 를 이용해 병렬 처리했다.

Executors.newVirtualThreadPerTaskExecutor();

동시성 제어

그런데 Virtual Thread를 사용한다고 해서 모든 요청을 동시에 보내도 되는 것은 아니었다. 원본 이미지 서버나 GCS에 과도한 요청이 발생할 수 있기 때문이다.

그래서 동시 처리 개수를 최대 10개로 제한했다.

private static final int MAX_CONCURRENT_UPLOADS = 10;

private final Semaphore semaphore =
        new Semaphore(MAX_CONCURRENT_UPLOADS);

실행 흐름

1,000개 작업 생성 ↓ Virtual Thread로 실행 ↓ Semaphore ↓ 최대 10개씩 이미지 다운로드 + GCS 업로드

업로드에 실패했을 때?

이미지 하나가 실패했다고 해당 Spot 데이터까지 적재되지 않는 것은 피하고 싶었다.

따라서:

• 성공 → GCS URL 저장
• 실패 → 기존 TourAPI URL 유지

동시에 실패 건수는 별도로 집계해서 이후 확인 및 재시도가 가능하도록 했다.

이미지 크기 제한

또한, 외부에서 이미지를 직접 다운로드하기 때문에 비정상적으로 큰 응답을 방지하기 위해 이미지 크기는 최대 10MB로 제한 했다.

기존 데이터 마이그레이션

신규 데이터는 이제 데이터를 적재하는 과정에서 바로 GCS에 저장되지만, DB에는 기존 TourAPI URL 약 15,000건이 남아 있었다.

기존 데이터를 다시 전체 적재하는 대신 별도의 이미지 마이그레이션 로직을 만들었다.

기존 TourAPI URL 조회 ↓ 이미지 다운로드 ↓ GCS 업로드 ↓ DB URL 변경

이 작업은 한 번 실행하고 종료되는 작업이므로 Cloud Run Job 으로 실행했고, 기존 이미지 데이터를 GCS로 이전시켰다!

처음에는 JPA를 사용해 한 건씩 저장했는데, 로그를 확인해보니 약 10,000건을 적재하는 동안 약 37,000번의 DB 요청이 발생하고 있었다.

데이터 한 건마다 다음 작업이 반복됐기 때문이다.

데이터 1건
 → existsBy SELECT
 → Spot INSERT
 → Translation INSERT
 → Image INSERT

게다가 각 데이터를 REQUIRES_NEW 트랜잭션으로 저장하고 있었다. REQUIRES_NEW는 기존 트랜잭션이 있어도 잠시 중단하고 새 트랜잭션을 만들어서 실행한다.

한 행을 저장할 때마다 REQUIRES_NEW를 호출했다면, 10,000건을 저장하면서 10,000개의 트랜잭션이 각각 시작되고 커밋된 것이다.

각각 커밋했을 때의 장점

장점은, 한 건이 실패해도 다른 건에 영향을 주지 않게 할 수 있다는 것이다.

하지만 대량 적재에서는 매번

트랜잭션 시작 → SQL → COMMIT

을 반복하니까 비용이 커진다.

실제로 4,877건을 기준으로 측정했을 때,

existsBy : 1.3초
save     : 8.3초
----------------
total    : 9.6초

전체 시간의 약 87%가 저장 과정에서 발생했다.

Chunk란?

기존 방식은 데이터 한 건마다 DB 작업을 수행하는 구조였다.

1건 처리 → commit
1건 처리 → commit
1건 처리 → commit
...

Chunk 처리는 여러 데이터를 일정 크기로 묶어서 처리하는 방식이다.

예를 들어 Chunk Size가 1,000이라면,

1~1000     → 하나의 Chunk
1001~2000  → 하나의 Chunk
2001~3000  → 하나의 Chunk
...

처럼 처리할 수 있다.

이를 통해 매번 발생하던 DB 접근이나 트랜잭션 비용을 줄일 수 있다.

그래서 기존의 행 단위 처리를 약 1,000건 단위의 Chunk 처리로 변경했다.

existsBy 역시 한 건씩 조회하지 않고 Chunk에 포함된 데이터의 존재 여부를 한 번에 조회하도록 변경했다.

4,877번 SELECT
     ↓
5번 SELECT

당연히 빨라질 거라고 생각했다.

그런데 결과는 오히려 더 느려졌다..!

Chunk로 묶었는데 왜 더 느려졌을까?

원인은 데이터에 포함된 지원하지 않는 여행코스 6건이었다.

5개의 Chunk 중 4개는 정상 처리됐지만, 해당 데이터가 포함된 Chunk 하나가 실패했다.

문제는 실패 처리 방식이었다.

1,000건 Chunk
   ↓
잘못된 데이터 발견
   ↓
Chunk 전체 Rollback
   ↓
약 1,000건을 다시 개별 REQUIRES_NEW로 저장

6건의 잘못된 데이터 때문에 정상 데이터까지 다시 처리하고 있었던 것이다.

결국 문제는 Chunk 자체가 아니라 검증과 트랜잭션의 범위에 있었다.

그래서 파싱과 데이터 검증을 트랜잭션 밖으로 분리했다.

Parsing & Validation
        ↓
정상 데이터만 Chunk 생성
        ↓
DB 저장

그 결과 문제가 있던 6건은 DB 작업 전에 제외됐고, 5개의 Chunk가 모두 성공하면서 fallback도 0회가 되었다.

JPA에서 JDBC Batch로

다음으로 저장 과정 자체를 개선했다.

일반적인 서비스 로직은 계속 JPA를 사용하되, 대량 데이터 적재만 별도의 JDBC 경로로 분리했다.

application/
 ├─ SpotBatchWriter
 └─ SpotImportRow

infrastructure/persistence/
 └─ SpotBatchJdbcWriter

특히 Translation과 Image는 JdbcTemplate.batchUpdate()를 이용해 여러 INSERT를 묶어서 처리했다.

그 결과 4,877건 기준으로

Before
9.6초 / 510건/s

After
3.2초 / 1,527건/s

약 3배의 처리량 개선을 확인할 수 있었다.

Upsert 전환

마지막으로 existsBy 자체도 제거했다.

기존에는

SELECT exists
 → 없으면 INSERT
 → 있으면 SKIP

했지만, PostgreSQL의 INSERT ... ON CONFLICT DO UPDATE를 사용하면 DB가 신규/기존 데이터를 판단할 수 있다.

UPSERT
 → 신규 데이터: INSERT
 → 기존 데이터: UPDATE

덕분에 존재 여부를 미리 조회할 필요가 없어졌고, 재적재 시 변경된 관광지 정보도 반영할 수 있게 되었다.

정리

최적화 과정은 다음과 같았다.

행 단위 JPA 저장
    ↓
Chunk 적용
    ↓
오히려 느려짐
    ↓
파싱/검증을 트랜잭션 밖으로 분리
    ↓
JDBC Batch
    ↓
Upsert

처음에는 단순히 Chunk로 묶으면 빨라질 거라고 생각했다.

하지만 실제로는 Chunk 크기보다 트랜잭션 범위와 실패 처리 방식이 더 중요했다.

또한 일반적인 CRUD에는 JPA를 그대로 사용하면서, 대량 적재처럼 성능이 중요한 작업만 JDBC로 분리하는 것도 하나의 방법이라는 것을 알게 되었다.

Kotlin

자바는 클래스 파일을 JVM이 실행하며, 코틀린도 가상 머신인 JVM 에서 실행할 수 있다.

또한 클래스명과 파일명을 다르게 설정해도 되는 특징을 가진다.

기본적인 변수 선언 방식

val 변수명 : 타입 = 값

컬렉션 타입

val data1: Array<Int> = Array(3,{0}) 

NULL 제어

코틀린은 null 과 not null 을 명확하게 구분해서 선언해야 한다.

var data2: Int?=10

과 같이, 타입 뒤에 물음표를 추가하여 Null 허용으로 선언할 수 있다.

생성자

코틀린에서는 생성자를 주 생성자, 보조 생성자로 구분한다.

class 클래스이름 constructor(){} //주 생성자 선언

함수는 매개변수를 선언할 때 var 나 val 키워드를 추가할 수 없다.

주 생성자에서만 유일하게 var , val 키워드로 매개변수를 선언하여 클래스의 멤버 변수로 만들 수 있다.

class 클래스이름 {
    constructor()~~
}

오브젝트 클래스

코틀린에서 오브젝트 클래스는 익명 클래스 를 만들 목적으로 사용한다.

선언과 동시에 객체를 생성하며, object 뒤에 콜론을 입력하고 그 뒤에 클래스의 상위 또는 인터페이스를 입력해야한다.

object: A {} // 클래스를 A 타입으로 선언한 것

컴패니언 클래스

자바의 static 메서드와 비슷하다.

클래스 이름으로 멤버에 접근할 수 있게 하려면 companion 이라는 키워드로 선언해야한다.

suspend

함수 안에서 잠깐 기다렸다가 나중에 이어지는 코루틴 함수를 호출하면, 바깥 함수에도 suspend를 붙인다.

runBlocking

runBlocking {}은 코루틴 밖(테스트, main 등)에서 suspend 함수를 실행하기 위한 진입점이다.

• 블록 내부의 코루틴이 끝날 때까지 현재 스레드는 기다린다.

runBlocking - JUnit 테스트 흐름

JUnit 테스트 시작
  → runBlocking으로 코루틴 실행
  → get 함수 호출
  → 콜백 응답이 올 때까지 테스트 대기
  → 성공하면 assert 검증
  → 테스트 종료

runBlocking {} 안은 람다 블록이다. return@runBlocking의 @runBlocking은 어노테이션이 아니라 라벨이고, “이 블록까지만 반환한다”는 뜻이다.

val result = runBlocking {
    if (isValid) {
        return@runBlocking "성공"
    }


    "실패"
}

return@runBlocking "성공"

은:

테스트 함수 전체를 끝내는 게 아니라 runBlocking 블록의 결과를 "성공"으로 정한다. 따라서 result에 "성공"이 들어가게 된다.

CountDownLatch

여러 작업이 끝날 때까지 한 스레드가 기다려야 할 때 사용한다.

new CountDownLatch(3)

• 기다릴 작업 수를 3으로 설정
• 각 작업이 완료되면 countDown() 호출
• 기다리는 쪽에서 await() 호출
• count가 0이 되면 await() 중인 스레드가 다시 실행됨

🤝 느낀점

앞으로 업무에서 Kotlin 코드를 접하게 될 것 같다. 그동안은 자바로만 개발을 진행해서 코틀린에 대해서는 정말 기초적인 문법도 모르는 상황이었기 때문에 기본적인 지식이 필요했다.

1. 모르는 건 혼자 찾아보지 말고 바로 물어보자.. 2. 무조건 꼼꼼하게 확인! (코드작성이던 문서확인이던 모두..)

그리고 인턴이랑 취준 병행하는게 생각보다 쉽지 않을 것 같다.. 이번주는 연휴도 있는 만큼, 다시 개인 공부를 열심히 해야할 것 같다.

Spring Boot로 만든 API를 어디에 배포할지 고민하다가** Google Cloud Platform의 여러 서비스를 검토했고, 최종적으로 **Cloud Run을 선택했다.

GCP에서 애플리케이션을 배포하는 방식은 여러 가지가 있다. 대표적으로는:

• Compute Engine
• App Engine
• Cloud Run

Compute Engine

Compute Engine은 GCP에서 가장 전통적인 방식으로, Ubuntu 같은 OS가 설치된 VM을 빌려서 직접 운영한다.

AWS의 EC2와 같은 역할을 한다.

Internet
   ↓
Compute Engine
   ↓
Spring Boot
   ↓
Cloud SQL

Cloud Run

Cloud Run은 요청 또는 이벤트를 통해 호출 가능한 컨테이너를 실행할 수 있는 완전 관리형 애플리케이션 플랫폼이다.

Google Cloud 에서는 대표적으로 Cloud Functions 와 Cloud Run 이라는 2가지 Serverless 서비스를 제공하고 있다.

Cloud Run은, ** Docker 컨테이너를 올리면 Google이 실행 환경을 전부 관리한다!**

Internet
   ↓
Cloud Run (컨테이너 실행)
   ↓
Spring Boot (Docker 이미지)
   ↓
Cloud SQL

👩‍💻 왜 선택했을까?

1. 컨테이너로 패키징하고 쉽게 앱을 활성화 할 수 있다.

• 인프라를 직접 관리 할 필요없이, Docker 이미지를 통해 쉽게 배포할 수 있다.

  2. 오토 스케일링을 제공한다.

• 요청량에 따라 자동으로 인스턴스를 증감한다. 야간에는 0개까지 줄어들어 비용 절감도 가능하다.

  3. GCP 서비스와 자연스러운 통합이 이루어진다.

• ** Cloud SQL**: 관리형 PostgreSQL 데이터베이스
• Artifact Registry: Docker 이미지 저장소
• Secret Manager: DB 자격증명 같은 민감 정보 관리
• VPC 및 IAM: 보안 정책

  4. 프로젝트 규모에 맞는 구성

• 복잡한 인프라를 구축할 이유가 없었다.

💥 한계점

Cloud Run은 리버스 프록시, SSL, 로드밸런싱 기능까지 제공하지만, 커스텀 도메인을 붙이기 위해서는 Cloud Load Balancer를 따로 만들어야 했다. 그런데, 여기서 두가지 비용이 발생한다.

• 고정 IP 할당 비용: 매월 고정 요금
• Load Balancer 운영 비용: 트래픽에 따른 요금
• 설정 복잡도: 자체 서명 인증서 관리, SSL 업데이트 등

해결책 - Firebase Hosting

대신 Firebase Hosting을 프록시로 사용하기로 결정했다.

Internet (dev-api.moodi.kr)
   ↓
Firebase Hosting (무료)
   ↓ (rewrite 설정)
Cloud Run

Firebase Hosting의 장점:

• 커스텀 도메인 연결
• SSL 자동 발급/갱신
• rewrite 기능: firebase.json에서 모든 요청을 Cloud Run으로 포워드
• 무료!

firebase.json 설정은 간단하다:

json
{
  "hosting": {
    "rewrites": [
      {
        "source": "/**",
        "run": {
          "serviceId": "moodi-api",
          "region": "asia-northeast1"
        }
      }
    ]
  }
}

이 한 줄로 모든 HTTP/HTTPS 요청이 Cloud Run으로 가고, SSL도 자동으로 관리된다.

최종 정리

Cloud Run 선택 이유

• 서버 관리 부담 없음 - 인프라 관리 비용 절감
• 자동 스케일링 - 요청에 따른 유동적 운영
• GCP 서비스 통합 - Cloud SQL, Secret Manager 등과 자연스럽게 연결
• 배포 자동화 - GitHub Actions + Workload Identity Federation
• 비용 효율성 - 작은 프로젝트 규모에 맞는 선택

참고: https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run?hl=ko

인턴 시작!

👩‍💻

이번주부터 인턴을 시작하게 되었다!

앞으로 인턴을 하며 적어도 2주에 한번씩 회고를 작성해보려고 한다. 회고의 목적은 "기록"이다. 기록하지 않으면 다 흘러가버릴 정보와 기억들이다 ..

이번주는 개발을 위한 세팅과 인수인계를 하며 시간을 보냈다._ (기존 코드를 보면서 이런 구조로 되어있구나~ 이런 흐름으로 진행되는구나~를 이해하는 시간이었다.)_

부서에서 진행중인 업무는 한마디로 검증 개발이다. 그중에서도 차량 소프트웨어 검증 개발을 다룬다.

검증 개발(Verification & Validation)

제품이나 소프트웨어가 기획서의 요구 사항에 맞게 올바르게 만들어졌는지, 그리고 사용자의 실제 목적을 충족하는지 체계적으로 테스트하고 확인하는 과정이다.

그렇다면, 검증과 확인의 주요 차이는 무엇일까?

• 검증(Verification)은 개발자 관점, 사양서와 설계대로 만들어졌는지 확인하는 과정을 말하며,

• 확인(Validation)은 사용자 관점, 실제 사용자의 요구와 목적에 부합하는지 테스트하는 과정이라고 말할 수 있다.

QA나 Tester와 비슷한 업무라고 생각할 수 있지만, 직접 경험해보니 실제로는 개발적인 요소가 훨씬 많이 요구되는 직무라는 것을 느꼈다.

이번주에 관련해서 배운 것과 공부한 개념들을 정리해보려고 한다.

💡 이번주 학습 기록

CCTS 란?

차량의 VHAL(Vehicle HAL) 프로퍼티가 명세서대로 정확하게 구현되어 있는지 검증하는 테스트 코드이다.

AAOS

Android Automotive OS의 약자로, 자동차에 내장되는 인포테인먼트 플랫폼이다. (쉽게 말하면 차량 소프트웨어)

AAOS는 several Layer로 이루어져 있고, 각각의 레이어는 고유의 역할과 요소를 가진다.

Android Automotive 환경에서는 차량 내부 통신 인터페이스인 VHAL(Vehicle HAL)과 상위 *IVI *애플리케이션 사이를 연결하는 서비스가 필수적이다.

CAN Simulator

"차가 없어도 차가 있는 것처럼 CAN 통신을 흉내 내는 도구"라고 생각하면 된다.

예를 들면,

CAN Simulator가 "차량 속도 = 80km/h" 메시지를 전송
테스트 프로그램이 해당 메시지를 수신
시스템이 정상적으로 속도를 표시하거나 특정 API를 호출하는지 검증

이런 식으로 입력(CAN 메시지) → 시스템 동작 → 결과 검증을 자동화하는 데 많이 사용할 수 있다.

Log Level

로그 레벨은 시스템에서 로그의 중요도를 구분하기 위한 기준이다.

ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF

이중 운영업무에서 자주 볼 수 있는 로그는 DEBUG, INFO, WARN, ERROR이다. https://www.tutorialspoint.com/log4j/log4j_logging_levels.htm

🤝 느낀점

면접 볼 때, 면접관님이 이 업무에서 중요한건 무엇보다 꼼꼼함, 커뮤니케이션 능력이라고 말씀해 주셨다.

업무는 명세서를 기반으로 테스트 코드를 작성하는 것에서 시작된다. 이후 오류가 발생하면 수만 줄에 달하는 로그를 직접 확인하며 분석하고 원인을 찾아야 한다. 결국 작은 단서 하나도 놓치지 않는 꼼꼼함이 검증 개발에서 가장 중요한 기본기가 된다.

평소 나는 다른 사람의 피드백을 잘 받아들이는 편이라고 생각했다.

하지만 모든 의견을 그대로 수용하기보다는, 내 설계의 근거를 논리적으로 설명하고 필요한 부분은 설득하는 능력 역시 중요하다는 점을 배웠다. (무조건 고집을 부리는 것이 아니라, 근거 있는 판단을 할 수 있어야 한다는 의미이다)

또한 내가 짠 코드에 대해 정확하게 왜 이렇게 짰는지, 어떻게 설계한 건지 이유를 정확하게 설명할 수 있어야 한다. (물론 일반적인 소프트웨어 개발을 할 때도 당연한 부분이다!)

그리고 첫주차라 그런지 출근은 정말 힘든거구나.. 를 느꼈다 ...ㅎㅎ

아무튼 회사에서 다음주에 더 열심히 배워야 할 것 같다 ... 🙂

모든 프로그래머가 알아야 하는 응답 지연 값

• 메모리는 빠르지만 디스크는 아직도 느리다.
• 디스크 탐색은 가능한 한 피하라.
• 단순한 압축 알고리즘은 빠르다.
• 데이터를 인터넷으로 전송하기 전에 가능한 압축해야한다.
• 데이터 센터는 보통 여러 region에 분산되어 있고, 센터들 간에 데이터 주고받는 데에 시간이 소요된다.

고가용성

시스템이 오랜 시간동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어이다.

• 고가용성은 퍼센트(percent)로 표현하는데, 100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미한다.
• 대부분의 서비스가 99% ~ 100% 사이의 값을 갖는다.

장애 허용(Fault Tolerant)과의 차이

• 장애 허용은 장애가 생기더라도 시스템이 이상 없이 동작할 수 있도록 보장하는 특성이고, 고가용성은 빠르게 복구하는 특성이라고 한다.

저장소 요구량 추정

가정

• 월간 능동 사용자는 3억명
• 50%의 사용자가 트위터를 매일 사용
• 평균적으로 매일 2건의 트윗을 올림
• 미디어 포함 트윗은 10%
• 데이터는 5년간 보관됨

추정

• *QPS (Query Per Second) *추정치

  • Daily Active User, DAU = 3억 * 50% = 1.5억명 (50%의 사용자가 트위터를 매일 사용하므로, 월간 사용자의 50%는 매일 트위터를 사용하는 사용자의 수와 같다.)
  • QPS = 1.5억 * 2트윗/24시간/3600초 = 약 3500
  • 최대 QPS (Peek QPS) = 2*QPS = 약 7000

• 미디어 저장을 위한 저장소 요구량

  • 평균 트윗 크기
  • tweet_id = 64바이트
  • 텍스트 = 140바이트
  • 미디어 = 1MB
  • 미디어 저장소 요구량 = 1.5억 * 2 * 10% * 1MB = 30TB/일
  • 5년간 미디어를 보관하기 위한 저장소 요구량 : 30TB * 365 * 5 = 약 55PB

팁

• 가정은 적어두기
• 단위를 붙이기
• 계산은 근사치를 활용하기
• QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수를 추정해야함

1. 사용자는 도메인 이름을 이용하여 웹사이트에 접속한다.
   • 이 과정에서 도메인 이름을 DNS에 질의해, IP 주소로 변환하는 과정이 필요
2. DNS 조회 결과로 IP 주소가 반환된다.
3. 해당 IP 주소로 HTTP 요청이 전달된다.
4. 요청을 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답을 반환한다.

웹 어플리케이션 ➡️ 서버 구현용 언어, 클라이언트 구현용 언어 사용 모바일 앱 ➡️ HTTP 프로토콜을 주로 이용

데이터베이스

1. 관계형 데이터베이스 관리 시스템(RDBMS)

• mysql, Oracle, PostgreSQL…

2. 비 관계형 데이터베이스 다음과 같은 경우에 선택한다.

• 낮은 지연 응답 시간
• 다루는 데이터가 비정형일 경우
• 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 될 경우
• 아주 많은 양의 데이터를 저장할 필요가 있을 경우

데이터베이스 다중화

서버 사이에 주-부 관계를 설정하고 데이터의 원본은 주 서버에, 사본은 부 서버에 저장하는 방식이다.

주 데이터베이스: 쓰기 연산, 데이터베이스 변경 명령어 실행

부 데이터베이스: 읽기 연산. 데이터 베이스 를 변경하는 명령어는 주 데이터베이스로만 연결되어야 한다.

장점

• 읽기 연산은 부 데이터베이스 서버들로 분산되어 병렬 처리 되므로, 성능이 좋아진다.
• 데이터베이스 서버 가운데 일부가 파괴되어도 데이터는 안정성이 보장될 수 있다.
• 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터 베이스 서버에 장애가 발생하더라도 다른 서버에 있는 대이터를 가져와 계속 서비스 할 수 있다.

데이터베이스의 규모 확장

데이터 베이스의 규모를 확장하는 데는 두가지 접근법이 있다.

수직적 규모 확장법(Scale Up)

기존 서버에 더 많은, 고성능의 자원을 증설하는 방법이다.

수평적 규모 확장법

샤딩이라고도 불리는데, 더 많은 서버를 추가함으로써 성능을 향상시키는 방법이다.

샤딩의 주의점

1. 샤드 키(Shard Key)를 잘 선택해야 한다.
2. JOIN이 어려워진다.(당연히..데이터가 나누어져 있기 때문에)
3. 트랜잭션이 어려워진다. (서로 다른 DB라 분산 트랜잭션이 필요함)
4. 운영이 복잡해진다.

인덱스

↓

쿼리 튜닝

↓

캐시(Redis)

↓

Read Replica

↓

샤딩

샤딩은 구조 자체를 바꾸는 작업이라 비용이 크기 때문에 마지막 수단으로 고려하는 경우가 많다.

로드밸런서

부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할이다.

캐시

캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빠르게 처리될 수 있도록 하는 저장소이다.

• 캐시는 휘발성 메모리 이므로, 중요한 데이터는 지속적 저장소에 두어야 한다.
• 캐시 서버를 여러개로 분산시켜 단일 장애 지점(SPOF)이 생기는 문제를 해결할 수 있다.
• 캐시 메모리를 과할당하여, 캐시의 성능을 개선시킬 수 있다.
• 캐시에 메모리가 가득 찼을 경우, LRU나 LFU, FIFO 정책을 사용한다.

단일 장애 지점: 어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중단시켜 버릴 수 있는 경우, 해당 지점을 단일 장애 지점(SPOF) 이라고 부른다.

일관성: 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부

데이터 방출 정책: 캐시의 메모리가 찼을 때, 기존 데이터를 내보내기 위한 정책

• LFU : 사용된 빈도가 가장 낮은 데이터 내보내는 정책
• LRU : 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 정책
• FIFO : 가장 먼저 캐시에 들어온 데이터를 가장 먼저 내보내는 정책
  
  

CDN

CDN은 정적 콘텐츠를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크이다.

동작 과정

1. 사용자가 image URL을 이용해 이미지에 접근한다.
2. CDN 서버의 캐시에 이미지가 없는 경우, 서버는 원본 서버에 요청하여 파일을 가져온다.
3. 원본 서버가 파일을 CDN 서버에 반환한다.
4. CDN 서버는 파일을 캐시하고 사용자에게 반환한다.

➡️ 정적 컨텐츠를 웹서버가 아닌 CDN을 사용하여 더 나은 성능을 보장할 수 있고, 캐시를 사용하여 데이터베이스 부하를 줄일 수 있다.

무상태 웹 계층

무상태 아키텍처는, 서버가 사용자의 이전 요청 정보를 기억하지 않는 구조를 말한다.

상태정보를 보관하는 서버는 클라이언트 정보(상태)를 유지하여 요청들 사이에 공유되도록 하지만, 무상태 서버에는 이런 장치가 없다.

상태 서버의 경우 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 하는데, 이는 로드밸런서에 부담을 주게 된다.

무상태가 필요한 이유

1. 서버를 쉽게 늘릴 수 있다 (Scale Out)

트래픽이 많아졌다고 가정해보자.

상태를 저장하면

Server A (세션 있음)
Server B (세션 없음)

로드밸런서가 마음대로 보내면 로그인 정보가 없어서 오류가 난다.

그래서 Sticky Session(고정 세션) 같은 추가 작업이 필요하게 된다.

반면 Stateless는

Server A
Server B
Server C
Server D

모든 서버가 동일하게 동작하기 때문에, 불필요하게 추가작업을 진행할 필요가 없다.

2. 장애에 강하다

Server1 다운 ⬇️ Server2가 처리

이런 구조는 단순하고, 안정적이며, 규모 확장이 쉽다.

3. 로드밸런싱이 쉬워진다 요청을 처리할 때 사용자별로 다른 서버로 보낼 필요성이 없기 떄문이다. 어떤 서버가 요청을 처리해도 결과는 같다.

4. 서버 메모리를 덜 사용한다

데이터 센터

장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내되는데, 통상 이 절차를 지리적 라우팅이라고 부른다.

이 데이터 센터중 하나에 심각한 장애가 발생하면, 모든 트래픽은 장애가 없는 데이터 센터로 전송된다.

다중 데이터센터를 만들기 위해 고려해야 할 조건

• 트래픽 우회 - 올바른 데이터 센터로 트래픽을 보내기
• 데이터 동기화 - 데이터 센터마다 별도의 데이터베이스 다중화 하기
• 테스트와 배포 - 여러 위치에서 애플리케이션 테스트, 자동화 배포가 모든 데이터 센터에 동일하게 설치되도록 하기
  
  

  메세지 큐

메세지 큐에 일단 보관된 메시지는 소비자가 꺼낼때까지 안전히 보관된다는 특성을 보장하는 비동기 통신 컴포넌트

한마디로 지금 당장 처리하지 않아도 되는 일을 나중에 처리하도록 중간에 맡겨놓는 시스템이다.

• 메세지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.
• Publish/Producer는 메세지 큐에 발행한다. 큐에는 보통 Consumer/Subscribe가 메세지를 꺼내서 동작을 수행한다.
  
  

정리

• 웹 계층은 무상태 계층으로
• 모든 계층에 다중화 도입
• 가능한 한 많은 데이터 캐시
• 여러 데이터센터 지원
• 정적 컨텐츠 → CDN 통해 서비스
• 데이터 계층 → 샤딩을 통해 그 규모를 확장할 것
• 각 계층은 독립적 서비스로 분한
• 자동화 도구 활용, 시스템 지속적 모니터링

기존 블로그 : https://0618amy.tistory.com/

취업을 준비하면서 느낀 건 .. 이력서만으로는 프로젝트에서 내가 어떤 고민을 했고, 어떤 방식으로 해결했는지에 대한 사고과정을 다 담기가 힘들다는 것이다.

이전부터 개발 블로그가 있긴 했지만, 경험을 정리 할 때 Notion을 더 자주 이용했었다.

1. 따로 웹브라우저 들어갈 필요 없이 접근성이 좋고,

2. 마크다운 형식으로 쉽고 빠르게 글 작성이 가능하기 때무네..

전부 다 깔끔하게 글 정리를 해놓은 건 아니다. 약간 뒤죽박죽인 부분도 있긴 하지만 일단 나 혼자 보는거니까 .. ㅎㅎ

그런데 요즘 노션 페이지수가 많아지다 보니 오히려 찾아보기도 불편해졌고, 하나의 흐름으로 정리하기도 쉽지 않았다. (면접 준비하면서 느꼈다 ㅠㅠ) 다시 티스토리를 써볼까 했지만.. 글 작성 방식이 나에게는 불편하게 느껴졌다.

그래서 가독성이 좋고, 에디터가 편한 Velog로 넘어오게 되었다 !

기존에도 마크다운 형식으로 정리를 했었어서, 확실히 티스토리보다 편하게 느껴지는 것 같다. 옆에 미리보기로 바로 뜨는것도 좋은듯??

앞으로는 내가 배우고 경험한 것들을 벨로그에 꾸준히 정리해보려고 한다. 앞으로는 노션 대신 쓸 것 같다 ..!

취업 준비 기록도 하나씩 올려야지 .. 👩‍💻👩‍💻