Airflow 설치 전에 반드시 확인해야 할 사항이 있습니다:

• 지원 버전: Python, Kubernetes 호환성 확인 필수
• 필수 조건: 시스템 패키지, 사용자 권한, 네트워크 설정 등
• 의존성 관리: Providers 및 Extras 패키지를 통한 기능 확장
• DB 설정: Metadata DB는 Airflow의 핵심, 업그레이드 시 마이그레이션 필요

🛠 설치 방식 비교

1. 공식 소스 코드 설치 (From Source)

• 추천 대상: 소프트웨어 무결성과 커스텀 빌드가 중요한 팀
• 장점: ASF 정책에 따라 신뢰성 있는 소스 제공
• 단점: 설치 및 유지보수에 드는 시간과 노력 증가
• 책임:
  • 모든 컴포넌트 빌드 및 설치
  • DB 구성, 자동화 스크립트 작성
  • 리소스 모니터링 및 성능 튜닝 전담

2. PyPI 설치 (pip)

• 추천 대상: Python 기반 배포에 익숙한 팀
• 장점: 패키지 설치가 간단하고 빠름
• 단점: 프로덕션 환경에서의 튜닝은 별도 필요
• 책임:
  • 제약 파일을 사용한 안정적 설치
  • DB 및 모니터링 설정
  • 커스텀 구성 및 리소스 관리

3. 공식 Docker 이미지

• 추천 대상: 컨테이너 인프라(Docker, Compose)에 익숙한 팀
• 장점: 격리된 환경에서 빠르게 구성 가능
• 단점: 커스텀 dependency가 많다면 이미지 재빌드 필요
• 책임:
  • docker-compose 등으로 multi-container 설정 구성
  • DB, 모니터링, 업그레이드 전략 수립

4. Helm Chart (Kubernetes 기반)

• 추천 대상: Kubernetes 클러스터 운영 경험이 있는 팀
• 장점:
  • 커뮤니티에서 관리하는 안정적인 배포 구조
  • 자동화된 컴포넌트 재시작 및 복구
• 단점:
  • Helm Chart 및 K8s 리소스 커스터마이징 학습 필요
• 책임:
  • Helm 값 파일 관리
  • 커스텀 이미지 빌드 및 배포 파이프라인 구성

5. Managed Airflow Services

• 추천 대상: 직접 운영 부담을 줄이고 싶은 팀
• 장점:
  • 설치, 업그레이드, 리소스 조절 모두 위임 가능
• 단점:
  • 비용 증가
  • 커스터마이징 제한
• 책임: 대부분 매니지드 서비스에서 처리. 문서 확인 필요

6. 3rd-party 배포 옵션

• 추천 대상: 기존 레거시 인프라를 유지해야 하는 경우
• 주의사항: 공식 지원 없음, 커뮤니티 지원 한계 있음

⚙️ 운영 환경에서 고려할 요소

Airflow는 복잡한 시스템입니다. 다음과 같은 요소가 성능과 리소스 요구사항에 영향을 줍니다:

• DAG 개수, 동시 실행 Task 수
• DAG의 복잡도 및 외부 시스템 연동 여부
• 설치 방식에 따른 Infra 요구사항 (Docker vs K8s vs VM)
• Scheduler 튜닝 및 리소스(CPU, Memory) 설정
• Providers 및 Plugin 사용 범위

🧠 팁: Fine-tuning Scheduler, Best Practices 문서를 통해 사전 튜닝 전략을 준비하세요.

MySQL의 시작은 의외로 mSQL (Mini SQL)이라는 또 다른 경량 데이터베이스와 관련이 깊습니다. 당시 MySQL의 개발자들은 빠른 속도를 위해 자체 ISAM(Indexed Sequential Access Method) 기반의 로우레벨 스토리지 엔진을 사용하고 있었고, 이를 SQL 인터페이스로 연결하기 위해 mSQL을 고려했습니다.

하지만 mSQL은 테스트 결과 다음과 같은 한계점이 발견되었습니다:

• 성능 부족: 자체 ISAM 루틴의 속도를 따라가지 못함
• 유연성 결여: 복잡한 쿼리와 다양한 요구사항을 충족하기 어려움

결국, MySQL 개발자들은 다음과 같은 결정을 내리게 됩니다:

"mSQL은 우리가 원하는 성능을 제공하지 못하니, 우리가 직접 SQL 인터페이스를 만들자. 단, mSQL API와 최대한 유사하게 구현해서 기존 코드를 쉽게 이식할 수 있도록 하자."

이 결정은 단순한 기능 개발을 넘어, 오픈소스 생태계와의 호환성을 염두에 둔 철학적인 선택이었다고 볼 수 있습니다.

MySQL이라는 이름의 유래

MySQL의 이름에서 ‘My’는 단순한 영문 접두사가 아닙니다. 공동 창립자인 Monty Widenius의 딸의 이름에서 유래한 것입니다. 즉, ‘My’는 개인적인 의미가 담긴 이름이고, ‘SQL’은 우리가 알고 있는 Structured Query Language에서 따온 것입니다.

이런 작명은 단순히 기능 중심이 아닌 개발자 중심의 철학과 감성이 녹아 있는 상징적인 예라고 볼 수 있습니다.

마스코트 돌고래, ‘Sakila’의 이야기

MySQL의 로고를 보면 귀여운 돌고래가 떠오르실 텐데요. 이 돌고래의 이름은 Sakila입니다. 재미있는 점은 이 이름이 내부에서 정해진 것이 아니라, 전 세계 사용자들이 참여한 “Name the Dolphin” 콘테스트를 통해 탄생했다는 점입니다.

최종 선정된 이름 Sakila는 다음과 같은 배경을 가지고 있습니다:

• 제안자: Ambrose Twebaze, 에스와티니(구 스와질랜드) 출신 오픈소스 개발자
• 의미: SiSwati어에서 유래된 여성 이름이며, 탄자니아 아루샤 근처에 위치한 마을 이름이기도 함

즉, 이 이름은 단순한 마스코트 명칭을 넘어 글로벌 커뮤니티와의 연결 고리를 상징하며, 오픈소스 생태계의 가치를 잘 보여주는 사례라고 할 수 있습니다.

Kubernetes에서 오브젝트는 "원하는 상태(desired state)"의 선언입니다. 이 선언은 다음과 같은 클러스터 상태를 정의합니다:

• 어떤 애플리케이션이 어떤 노드에서 실행 중인지
• 애플리케이션에 할당된 리소스
• 재시작 정책, 업그레이드 방식, 장애 허용성과 같은 동작 정책

오브젝트는 단순한 리소스 정보 이상의 의미를 가지며, Kubernetes는 이 선언을 기반으로 클러스터를 끊임없이 조율합니다. 이처럼 오브젝트는 "명령"이 아니라 "의도"를 기록하는 방식이라는 점에서, 선언적(declarative) 접근을 대표합니다.

오브젝트의 구조

대부분의 Kubernetes 오브젝트는 다음과 같은 공통 필드를 갖습니다:

apiVersion: <API 버전>
kind: <오브젝트 종류>
metadata:
  name: <오브젝트 이름>
  namespace: <네임스페이스 (선택)>
spec:
  ... 원하는 상태에 대한 정의 ...

필드 설명

• apiVersion: 해당 오브젝트를 처리할 API의 버전
• kind: 생성하고자 하는 오브젝트의 종류 (예: Deployment, Pod 등)
• metadata: 이름, 라벨, 네임스페이스 등 식별자 정보
• spec: 오브젝트가 어떤 상태를 가져야 하는지 정의

또한, Kubernetes는 status라는 필드를 통해 현재 상태(actual state)를 기록합니다. 이는 시스템이 자동으로 업데이트하며, 사용자는 수정하지 않습니다.

예제: Deployment 오브젝트

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위 YAML은 nginx 컨테이너를 2개의 복제본으로 실행하는 Deployment를 정의합니다. 중요한 점은 이 설정이 단순히 "2개의 nginx를 실행하라"는 명령이 아니라, "2개가 항상 존재해야 한다"는 의도를 담고 있다는 것입니다. Kubernetes는 이 의도를 만족시키기 위해 pod를 생성하고, 실패 시 재시작하며, 롤링 업데이트도 처리합니다.

적용 방법:

kubectl apply -f deployment.yaml

오브젝트와 API

오브젝트는 결국 Kubernetes API를 통해 정의되고 조작됩니다. kubectl CLI는 이러한 API 호출을 추상화해주는 도구일 뿐입니다. 직접 프로그램에서 오브젝트를 생성하거나 조회하고 싶다면, Kubernetes 클라이언트 라이브러리를 사용할 수 있습니다 (Go, Python, Java 등).

유효성 검사 (Validation)

Kubernetes v1.25부터는 서버 측 필드 유효성 검사가 도입되었습니다. 기존에는 kubectl --validate=true를 통해 클라이언트 측에서만 필드 유효성을 검사했지만, 이제는 서버에서 직접 잘못된 필드나 중복된 항목을 검사합니다.

검사 옵션

• strict: 유효하지 않으면 에러
• warn: 유효하지 않아도 경고만 출력
• ignore: 검사를 수행하지 않음

기본값은 strict이며, 이는 CI/CD 환경에서 잘못된 리소스 정의로 인한 장애를 미리 방지하는 데 효과적입니다.

Kafka를 사용하려면 먼저 최신 릴리스를 다운로드해야 합니다. Scala 버전에 따라 바이너리를 선택해야 하며, 예시는 Scala 2.13과 Kafka 4.0.0 기준입니다.

$ tar -xzf kafka_2.13-4.0.0.tgz
$ cd kafka_2.13-4.0.0

✅ TIP: 로컬 실행을 위해 Java 17 이상이 설치되어 있어야 합니다.

🚀 Step 2: Kafka 서버 실행

🛠 옵션 1: 로컬 환경에서 직접 실행

# 클러스터 UUID 생성
$ KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"

# 로그 디렉토리 포맷
$ bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c config/server.properties

# Kafka 서버 실행
$ bin/kafka-server-start.sh config/server.properties

🐳 옵션 2: Docker 사용

JVM 기반 이미지

$ docker pull apache/kafka:4.0.0
$ docker run -p 9092:9092 apache/kafka:4.0.0

GraalVM 기반 Native 이미지

$ docker pull apache/kafka-native:4.0.0
$ docker run -p 9092:9092 apache/kafka-native:4.0.0

✅ TIP: 도커로 빠르게 테스트 환경을 만들 수 있지만, 로그 볼륨 마운트 등 설정도 함께 고려하세요.

📁 Step 3: 토픽 생성

Kafka에서 이벤트는 토픽 단위로 저장됩니다. 토픽은 파일 시스템의 폴더와 유사합니다.

$ bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092

토픽 정보 확인:

$ bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092

✍️ Step 4: 이벤트 생산 (Producer)

$ bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092
>This is my first event
>This is my second event

🚀 한 줄 입력마다 개별 이벤트로 저장됩니다.

📥 Step 5: 이벤트 소비 (Consumer)

$ bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092

Ctrl-C로 종료할 수 있으며, 복수의 콘슈머가 동시에 동일 토픽을 소비하는 것도 가능합니다.

🔄 Step 6: Kafka Connect로 외부 연동

파일 → Kafka 토픽 → 파일 구조의 간단한 파이프라인을 구성할 수 있습니다.

설정 추가

$ echo "plugin.path=libs/connect-file-4.0.0.jar" >> config/connect-standalone.properties

테스트 데이터 작성

$ echo -e "foo\nbar" > test.txt

커넥트 실행

$ bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties

결과 확인

$ more test.sink.txt
foo
bar

Kafka 토픽에서 직접 확인도 가능:

$ bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic connect-test --from-beginning

🧠 Step 7: Kafka Streams로 실시간 처리

Kafka Streams는 Kafka 토픽의 데이터를 실시간으로 처리할 수 있는 Java/Scala 클라이언트 라이브러리입니다.

WordCount 예제

KStream<String, String> textLines = builder.stream("quickstart-events");
KTable<String, Long> wordCounts = textLines
    .flatMapValues(line -> Arrays.asList(line.toLowerCase().split(" ")))
    .groupBy((keyIgnored, word) -> word)
    .count();

wordCounts.toStream().to("output-topic", Produced.with(Serdes.String(), Serdes.Long()));

☑️ 실시간 집계, 윈도우, 조인 등 복잡한 스트림 연산을 처리할 수 있어 실시간 데이터 분석에 적합합니다.

🧹 Step 8: 환경 정리

# Kafka 종료: Ctrl-C
# 로그/데이터 삭제
$ rm -rf /tmp/kafka-logs /tmp/kraft-combined-logs

Job

• 정의: 전체 배치 작업을 의미하는 컨테이너
• 구성: 하나 이상의 Step으로 구성됨
• 설정: Java DSL 또는 XML 설정 가능

@Bean
public Job sampleJob(JobRepository jobRepository) {
    return new JobBuilder("sampleJob", jobRepository)
            .start(step1())
            .next(step2())
            .build();
}

🧱 실행 단위와 흐름

JobInstance

• Job 정의 + 식별자(JobParameters)
• 동일한 Job 정의라도 다른 파라미터로 실행되면 새로운 JobInstance 생성

JobParameters

• JobInstance를 유일하게 식별하는 파라미터 집합
• 날짜, 버전, ID 등 비즈니스 키 포함 가능

JobExecution

• 하나의 JobInstance 실행 시도 (성공/실패 관계없이 1회 실행)
• 재시도 시 새로운 JobExecution 생성됨

Step

• Job을 구성하는 단위 실행 블록
• 독립적으로 구성 가능
• ItemReader, ItemProcessor, ItemWriter를 조합

StepExecution

• Step의 실행 이력 단위
• JobExecution과 매핑됨

ExecutionContext

• JobExecution 또는 StepExecution에 종속된 상태 저장소
• 직렬화 가능해야 하며, 재시작 시 상태 복구에 사용됨

ExecutionContext ec = stepExecution.getExecutionContext();
ec.putLong("linesRead", 40321L);

📦 처리 구성요소

ItemReader

• 입력 데이터 소스로부터 데이터를 읽는 컴포넌트
• null 반환 시 더 이상 읽을 데이터가 없음을 의미

ItemProcessor

• 비즈니스 로직을 수행하는 처리 컴포넌트
• 유효하지 않은 데이터는 null 반환으로 필터링 가능

ItemWriter

• 처리된 데이터를 출력하는 컴포넌트

🗃️ 메타데이터 저장 구조

Spring Batch는 실행 이력을 아래와 같은 테이블에 저장합니다:

• BATCH_JOB_INSTANCE: Job 이름 및 파라미터
• BATCH_JOB_EXECUTION: Job 실행 정보 (상태, 시작/종료 시간 등)
• BATCH_STEP_EXECUTION: Step 실행 정보
• BATCH_EXECUTION_CONTEXT: 상태 정보

🧪 예제 시나리오로 이해하기

1. EndOfDayJob을 01-01에 실행 → 실패
2. 01-01 동일 파라미터로 재실행 → 성공
3. 01-02 파라미터로 실행 → 성공

→ JobInstance는 2개, JobExecution은 3개 생성됨

⚙️ Java 기반 설정 시 참고

@Configuration
@EnableBatchProcessing
public class BatchConfig {

    @Bean
    public JobLauncher jobLauncher(JobRepository jobRepository) {
        return new SimpleJobLauncher(jobRepository);
    }

    @Bean
    public Step sampleStep() {
        return stepBuilderFactory.get("sampleStep")
            .<Input, Output>chunk(10)
            .reader(reader())
            .processor(processor())
            .writer(writer())
            .build();
    }

    // reader(), processor(), writer() 구현 생략
}

✅ 실무에서 얻는 이점

🔍 영속성 컨텍스트란?

EntityManager는 내부적으로 영속성 컨텍스트(Persistence Context)를 유지한다. 쉽게 말해, JPA가 엔티티를 관리하는 메모리 공간이다.

• 1차 캐시: 영속성 컨텍스트 내부에서 가장 핵심적인 역할을 수행.
• 엔티티의 PK를 키, 실제 객체를 값으로 가지는 Map 형태.

Member member = new Member();
member.setId("member1");
member.setUsername("회원1");
em.persist(member); // 비로소 영속 상태 진입

이제 member1은 1차 캐시에 저장된다.

📌 1차 캐시의 이점

1. 조회 최적화

Member find1 = em.find(Member.class, "member1"); // SELECT 발생
Member find2 = em.find(Member.class, "member1"); // 캐시에서 조회, SELECT 없음

• 같은 트랜잭션 내에서 동일 엔티티 조회 시, DB가 아닌 1차 캐시에서 가져옴

2. 동일성 보장 (==)

System.out.println(find1 == find2); // true

• 같은 인스턴스를 반환하기 때문에 == 비교도 true
• 이는 JPA가 제공하는 REPEATABLE READ 수준의 트랜잭션 일관성을 보장하는 핵심 기제

🕐 쓰기 지연 (Write-Behind Buffering)

em.persist() 호출 시, 바로 DB에 INSERT 되지 않는다.

em.getTransaction().begin();
em.persist(memberA);
em.persist(memberB);
// 아직 INSERT 없음
em.getTransaction().commit(); // 이 순간 INSERT SQL 실행

➕ 이점

• 여러 INSERT 쿼리를 모아서 한 번에 보내 성능 최적화 가능
• Hibernate는 hibernate.jdbc.batch_size 옵션으로 JDBC 배치 처리도 지원

🧼 변경 감지 (Dirty Checking)

Member member = em.find(Member.class, "member1");
member.setUsername("변경됨");
em.getTransaction().commit(); // UPDATE SQL 자동 발생

• em.update() 같은 명시적 호출 필요 없음
• JPA는 최초 상태 스냅샷과 비교해 변경이 있으면 UPDATE 쿼리 생성

✅ 내부 동작 원리

1. 영속 상태 진입 시 스냅샷 생성
2. 트랜잭션 커밋 시점에 현재 상태와 비교
3. 변경 사항 있으면 UPDATE SQL 생성 후 실행

🗑️ 엔티티 삭제

Member member = em.find(Member.class, "member1");
em.remove(member);
em.getTransaction().commit(); // DELETE SQL 발생

• 마찬가지로 커밋 시점에 삭제 쿼리 실행

🔄 플러시 (Flush)

• 영속성 컨텍스트 → DB 반영 작업
• 커밋 시점 자동 수행 or 수동으로 em.flush() 호출 가능

em.flush(); // 강제로 DB에 반영

💡 실무 팁

• 트랜잭션 범위 안에서 같은 엔티티 여러 번 조회하면 DB 부하 줄일 수 있음
• 변경 감지 메커니즘을 이해하면 불필요한 update() 호출 줄일 수 있음
• JDBC 배치 설정을 잘 활용하면 대량 INSERT 시 성능 개선 가능

✅ MVC 패턴이란?

MVC(Model-View-Controller)는 소프트웨어 설계의 관심사 분리(Separation of Concerns)를 위한 대표적인 아키텍처입니다. 웹 개발에서 이 패턴은 특히 유지보수와 확장성을 확보하는 데 강력한 장점을 제공합니다.

🔹 구성 요소

• Model: 애플리케이션의 데이터 및 비즈니스 로직 담당 (ex. DB 연동, 서비스 로직)
• View: 사용자에게 보여지는 UI (HTML, Thymeleaf 등)
• Controller: 클라이언트 요청을 받고, 적절한 모델을 선택 및 처리 후 뷰로 전달

과거에는 JSP 안에 비즈니스 로직, 화면 처리, DB 연동이 한 파일에 몰려있는 Model 1 방식이 많았지만, 이는 유지보수 지옥을 불러왔습니다. 현대적 방식인 MVC는 이를 구조적으로 분리합니다.

✅ Spring MVC 예제 코드

간단한 Hello 예제를 통해 MVC 구조를 설명하겠습니다.

📌 Controller

@Controller
public class HelloController {

    @GetMapping("hello-mvc")
    public String helloMvc(@RequestParam("name") String name, Model model) {
        model.addAttribute("name", name);
        return "hello-template"; // templates/hello-template.html 뷰 반환
    }
}

📌 View (hello-template.html)

<html xmlns:th="http://www.thymeleaf.org">
<body>
  <p th:text="'hello ' + ${name}">hello! empty</p>
</body>
</html>

📌 실행 예시

http://localhost:8080/hello-mvc?name=spring

➡️ 브라우저 출력: hello spring

✅ 템플릿 엔진 - Thymeleaf

Thymeleaf는 HTML을 그대로 작성하면서, 서버 사이드에서 동적으로 데이터를 바인딩할 수 있는 템플릿 엔진입니다.

장점

• 정적 HTML로도 열람 가능 → 퍼블리셔 협업 용이
• 스프링 부트와 자연스럽게 통합
• 뷰 레이어 로직 최소화 가능

템플릿 파일은 resources/templates 경로에 .html 파일로 작성하며, ${} 문법으로 모델 값을 치환합니다.

✅ 전체 흐름 요약 (텍스트 기반 순서도)

1. 사용자가 URL 접속: /hello-mvc?name=spring
2. 내장 톰캣이 요청을 받고 Spring DispatcherServlet으로 전달
3. HelloController.helloMvc() 메서드 매핑
4. name 파라미터를 Model에 담고 "hello-template" 리턴
5. ViewResolver가 템플릿 파일 hello-template.html을 탐색
6. Thymeleaf가 모델 값을 바인딩하여 HTML 렌더링
7. 최종 HTML을 브라우저에 반환

✅ 실전 개발에서의 적용 포인트

• Controller는 얇게 유지: 최대한 비즈니스 로직은 Service 레이어로 위임
• Model은 DTO로 깔끔하게 구성: 불필요한 객체 넘기지 않기
• View는 순수 화면 전용: 로직 없이 화면 구성만 책임지도록

변수란 무엇인가?

"변수"는 말 그대로 변할 수 있는 수(value)입니다. 프로그래밍에서는 값을 저장하고, 그 값을 참조할 수 있는 이름이 붙은 메모리 공간을 의미하죠.

왜 변수가 필요한가?

아래와 같은 코드를 보겠습니다:

fun main() {
    println(10)
    println(10)
    println(10)
}

단순히 10을 3번 출력합니다. 하지만 요구사항이 바뀌어 20으로 바꿔야 한다면?
→ 3곳 모두 직접 수정해야 합니다. 이 작업이 100군데면 어떨까요?

이런 상황에서 변수를 도입하면 다음과 같이 바뀝니다:

fun main() {
    var a = 10
    println(a)
    println(a)
    println(a)
}

이제는 a의 값만 바꾸면 전체 출력 결과가 바뀝니다.

변수 선언과 초기화

var a: Int // 변수 선언
a = 10     // 초기화

또는 한 줄로 간단히:

var a = 10

• var는 변할 수 있는 변수를 선언합니다.
• val은 변하지 않는 변수를 선언할 때 사용합니다 (불변 변수).
• a는 변수명이고, Int는 정수 타입입니다.

변수 사용의 이점

1. 재사용성: 여러 곳에서 같은 값을 사용 가능
2. 유지보수 용이성: 한 번만 값 변경하면 전체 수정
3. 가독성 향상: 의미 있는 이름을 통해 코드 의도 전달
4. 동적 입력 대응 가능: 사용자 입력 등 변하는 값 대응

실행 흐름 예시

fun main() {
    var a = 20
    println(a)
    println(a)
    println(a)
}

모든 출력 결과는 20. 변수 하나만 수정했을 뿐인데 전체 출력이 함께 바뀌었습니다.

변수란 무엇인가?

"변수"는 말 그대로 변할 수 있는 수(value)입니다. 프로그래밍에서는 값을 저장하고, 그 값을 참조할 수 있는 이름이 붙은 메모리 공간을 의미하죠. 이 공간은 프로그램이 실행되는 동안 필요한 데이터를 저장하고, 다시 사용할 수 있게 해주는 매우 핵심적인 기능입니다.

왜 변수가 필요한가?

아래와 같은 코드를 보겠습니다:

public class Var1 {
    public static void main(String[] args) {
        System.out.println(10);
        System.out.println(10);
        System.out.println(10);
    }
}

위 코드는 단순히 숫자 10을 3번 출력합니다. 만약 요구사항이 바뀌어 20을 출력하라고 한다면, 해당 숫자를 직접 모두 수정해야 합니다. 3번이면 괜찮지만, 100군데에 10이 쓰였다면요?

이런 상황에서 변수를 사용하면 다음과 같이 바뀝니다:

public class Var2 {
    public static void main(String[] args) {
        int a = 10;
        System.out.println(a);
        System.out.println(a);
        System.out.println(a);
    }
}

이제는 a의 값만 바꾸면 전체 출력 결과가 함께 바뀝니다.

변수의 선언과 초기화

int a; // 변수 선언
a = 10; // 변수 초기화

혹은 한 줄로도 가능합니다:

int a = 10;

• int는 정수형 데이터를 저장할 수 있는 타입입니다.
• a는 변수명으로, 메모리의 주소를 간접적으로 표현합니다.
• =는 대입 연산자이며, 오른쪽 값을 왼쪽 변수에 저장합니다.

주의: 자바에서 =는 수학에서의 "같다"가 아니라 "값을 넣는다"는 의미입니다.

변수 사용의 이점

1. 재사용성: 값을 여러 번 사용할 수 있습니다.
2. 유지보수 용이성: 한 번에 값 변경이 가능합니다.
3. 가독성 향상: 의미 있는 이름을 통해 코드의 의도를 표현할 수 있습니다.
4. 사용자 입력 대응: 사용자의 동적인 입력값을 저장해 처리할 수 있습니다.

실행 흐름 요약

int a = 20; // 변수 선언 및 초기화
System.out.println(a); // 20 출력
System.out.println(a); // 20 출력
System.out.println(a); // 20 출력

모든 출력 결과는 20입니다. 변수 하나만 수정했을 뿐인데 전체 출력이 함께 바뀌었죠. 이는 유지보수가 쉬운 코드를 만드는 핵심입니다.

기존에는 pip, venv, pip-tools, poetry 등 다양한 도구를 사용해 Python 패키지를 관리해왔지만, uv는 특히 속도, 의존성 해석의 정확성, 그리고 단순한 UX에서 강점을 보입니다. 다음과 같은 장점이 있습니다:

• Rust로 작성되어 매우 빠릅니다.
• pip의 제약 파일(constraints.txt)을 그대로 활용 가능
• 가상 환경 생성부터 패키지 설치까지 일관된 워크플로우 제공

Airflow처럼 의존성이 복잡한 패키지 설치에 특히 유리합니다.

📦 설치 전 요구 사항

• Python 3.9, 3.10, 3.11, 3.12 중 하나 (Airflow 2.7.0 이상 기준)
• uv 설치 (설치 가이드)

🏡 AIRFLOW_HOME 설정 (선택 사항)

export AIRFLOW_HOME=~/airflow  # 기본값은 ~/airflow

설치를 시작하기 전에 환경 변수를 설정하면, 관련 설정 파일이 원하는 디렉토리에 저장됩니다.

📥 Airflow 설치

AIRFLOW_VERSION=3.0.0
PYTHON_VERSION="$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")')"

CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"

uv pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

Python 버전에 따라 URL이 달라지므로 자동 추출하는 방식 추천

▶️ Airflow Standalone 실행

airflow standalone

• 웹 UI: http://localhost:8080
• 관리자 계정 정보는 터미널에 출력됨
• 예시 DAG(example_bash_operator) 활성화 후 상태 확인 가능

🧪 간단한 테스트

# 개별 태스크 실행
airflow tasks test example_bash_operator runme_0 2015-01-01

# DAG 백필 실행
airflow backfill create --dag-id example_bash_operator \
    --start-date 2015-01-01 \
    --end-date 2015-01-02

⚙️ 프로덕션 대비: 컴포넌트 개별 실행

airflow db migrate

airflow users create \
    --username admin \
    --firstname Peter \
    --lastname Parker \
    --role Admin \
    --email spiderman@superhero.org

airflow api-server --port 8080
airflow scheduler
airflow dag-processor
airflow triggerer

airflow users 명령은 Flask AppBuilder(FAB) 인증 매니저가 활성화된 경우에만 사용 가능

• 멀티스레드 기반 커널 스레드 구조: CPU 코어를 최대한 활용할 수 있도록 설계되어 병렬 쿼리 처리에 강합니다.
• 모듈화된 설계: 스토리지 엔진을 모듈처럼 쉽게 추가할 수 있어, 상황에 맞는 커스터마이징이 가능합니다.
• CMake 기반 구성: 다양한 플랫폼에서 손쉽게 빌드 가능. 실제로 윈도우, 리눅스, macOS 등에서 모두 운영해본 경험상 호환성 문제는 거의 없습니다.

📦 스토리지 엔진

• InnoDB: 트랜잭션 지원, 외래 키, MVCC, 충돌 복구 기능 포함.
• MyISAM: 빠른 읽기 성능, 풀텍스트 인덱싱 가능. 트랜잭션은 미지원.
• 기타 엔진: MEMORY, ARCHIVE 등 필요에 따라 선택 가능.

📌 대규모 트랜잭션 처리나 복잡한 비즈니스 로직이 필요한 경우는 무조건 InnoDB 추천.

📊 데이터 타입 및 표현력

• 정수, 부동소수점, 문자열, 날짜/시간, BLOB, TEXT, ENUM, SET 등 다양한 타입 지원.
• OpenGIS 공간 데이터 타입도 제공되어 위치 기반 데이터 저장 가능.

🧠 SQL 기능 및 쿼리 최적화

• GROUP BY, ORDER BY, JOIN, 서브쿼리, 윈도우 함수 등 거의 모든 SQL 기능 지원.
• EXPLAIN으로 쿼리 실행 계획 분석 가능.
• SHOW 및 INFORMATION_SCHEMA를 통해 내부 상태 점검 및 모니터링 가능.

🧪 실제 운영 중에도 EXPLAIN + ANALYZE 조합은 슬로우 쿼리 튜닝 시 가장 많이 쓰는 방법입니다.

🔐 보안과 접근 제어

• 호스트 기반 인증 및 비밀번호 암호화 전송.
• GRANT 문을 통한 정교한 권한 분리 가능.

실무에서는 서비스 계정에 최소 권한만 부여하는 것이 중요합니다 (Principle of Least Privilege).

📈 확장성과 성능

• 수천만 ~ 수십억 레코드도 무리 없이 처리 가능.
• 테이블당 최대 64개 인덱스, 각 인덱스는 최대 16개 컬럼 포함 가능.

운영 중이던 로그성 테이블에서 20억 행 이상 저장해도 쿼리 튜닝만 잘하면 충분히 쓸 수 있었습니다.

🔌 연결성 및 프로토콜

• TCP/IP, 유닉스 도메인 소켓, Windows Named Pipe 등 다양한 프로토콜 지원.
• JDBC, ODBC, .NET, Python, PHP 등 거의 모든 언어에서 연결 가능.

다양한 언어의 API 지원은 마이크로서비스 환경에서 큰 장점입니다.

🌍 로컬라이제이션 및 다국어 지원

• 다양한 문자셋 및 정렬(collation) 지원.
• 서버 및 클라이언트별 타임존 설정 가능.

여러 지역 사용자 데이터를 다룰 때, UTF-8과 타임존 설정은 정말 중요합니다.

🛠️ 클라이언트 툴 및 유틸리티

• CLI 도구: mysql, mysqldump, mysqladmin, mysqlcheck, myisamchk
• GUI 도구: MySQL Workbench

스크립트 자동화할 때는 CLI 도구를, ERD 작성이나 시각적 쿼리 작성엔 Workbench를 애용합니다.

Kubernetes 클러스터는 크게 두 영역으로 나뉩니다:

• Control Plane (제어 플레인): 클러스터의 브레인 역할
• Worker Node (작업 노드): 실제 컨테이너가 돌아가는 환경

이 두 영역이 상호작용하며 클러스터 전체의 상태를 유지합니다.

⚙️ 제어 플레인 구성요소 분석

1. kube-apiserver

• 클러스터의 진입점으로, 모든 명령은 API Server를 통해 전달됩니다.
• 인증/인가, 요청 유효성 검사, 상태 저장 등 다양한 역할 수행
• 실무 팁: kubectl 커맨드는 모두 여기로 향합니다. API latency 모니터링 중요

2. etcd

• 클러스터의 상태 정보를 저장하는 분산 키-값 저장소
• 모든 리소스 상태 (파드, 서비스, 설정 등) 가 저장됨
• 실무 팁: 고가용성 구성 필수. 백업 전략 반드시 수립해야 함

3. kube-scheduler

• 스케줄링되지 않은 Pod를 찾아 적절한 노드에 할당
• 리소스 상황, taint/toleration, affinity 등을 고려함
• 실무 팁: 커스텀 스케줄러를 붙여 특정 워크로드를 별도 노드로 분리 가능

4. kube-controller-manager

• 컨트롤러 집합체로, Deployment, Node, ReplicaSet 등 관리
• 선언적 상태 유지의 핵심
• 실무 팁: 실제 문제의 원인을 트래킹할 때 컨트롤러 로그 확인 필수

5. cloud-controller-manager (선택적)

• AWS, GCP 등 퍼블릭 클라우드 리소스와의 통합 역할
• 노드 등록, 로드밸런서 관리 등
• 실무 팁: 클라우드 환경에서만 사용되며, bare-metal에는 필요 없음

🖥️ 노드 구성요소 분석

1. kubelet

• 각 노드에 존재하며, 해당 노드의 Pod가 제대로 동작하는지 주기적으로 체크
• 컨테이너 런타임과 직접 통신
• 실무 팁: 상태 불량 시 kubelet 로그 (/var/log) 확인이 빠른 진단에 유용

2. kube-proxy

• 각 노드의 네트워크 규칙 설정 및 서비스 IP 라우팅 처리
• iptables 또는 IPVS 기반으로 동작
• 실무 팁: 네트워크 이슈 시 가장 먼저 살펴볼 요소

3. Container Runtime

• 컨테이너 실행의 실질적 엔진 (예: containerd, CRI-O)
• kubelet이 이 런타임을 통해 컨테이너를 구동
• 실무 팁: 도커는 deprecated 됨. containerd로 전환하는 것이 표준화 추세

🧩 Addons (클러스터 기능 확장)

- CoreDNS

• 클러스터 내 DNS 서비스 제공
• 서비스 이름으로 통신이 가능하게 만듦

- Dashboard

• 웹 UI를 통한 클러스터 시각화 관리

- Metrics Server / Prometheus

• 자원 사용량 모니터링

- EFK / Loki

• 중앙 집중식 로그 수집 및 분석

⚒️ 실무 적용 포인트

• kube-apiserver 의 SLA는 전체 클러스터 가용성과 직결됨 → 장애 대응 프로세스 마련
• etcd 백업/복구 시나리오 정립 → 사고 발생 시 복구 속도에 결정적
• 노드 단의 kubelet 이슈는 대부분 컨테이너 실행 문제로 이어짐 → 사전 모니터링 중요

Kafka는 전통적인 메시지 브로커(예: RabbitMQ, ActiveMQ)를 대체할 수 있는 강력한 메시징 플랫폼입니다. 내장된 파티셔닝, 복제, 장애 허용성 덕분에 대규모 시스템에서도 안정적으로 메시지를 처리할 수 있습니다.

사용 시나리오

• 생산자/소비자 간 완전 비동기 메시지 처리
• 대용량 데이터 큐 처리
• Latency는 낮고, Durability는 높은 환경이 필요한 경우

2. 웹사이트 사용자 활동 추적

Kafka의 초기 목적은 웹사이트에서 발생하는 사용자 활동(페이지 뷰, 검색, 클릭 등)을 실시간으로 수집하고 분석하기 위함이었습니다.

사용 시나리오

• Page view, 클릭 로그 등을 토픽 단위로 분리해 저장
• 실시간 대시보드 생성
• 분석용 DWH(Hadoop, Redshift 등) 적재 파이프라인 구성

3. 운영 메트릭 및 모니터링 데이터 수집

운영 메트릭을 수집하고, 이를 중앙에서 집계 및 시각화하는 데 Kafka가 많이 사용됩니다.

사용 시나리오

• 마이크로서비스에서 수집되는 상태 정보 및 성능 지표 수집
• Prometheus, Grafana 등과 연계한 실시간 모니터링

4. 로그 집계(Log Aggregation)

Kafka는 기존의 로그 수집 시스템(Scribe, Flume 등)을 대체할 수 있으며, 다양한 로그 소스를 하나의 스트림으로 통합할 수 있습니다.

장점

• 파일 단위가 아닌 이벤트 스트림으로 처리
• 다양한 소스/서버에서 들어오는 로그를 하나의 토픽으로 집계
• 빠른 소비자 확장이 가능

5. 스트림 처리 (Stream Processing)

Kafka를 중심으로 구성된 데이터 파이프라인은 다단계 실시간 처리를 위한 훌륭한 기반이 됩니다. Kafka Streams, Apache Storm, Apache Samza 등 다양한 스트림 처리 프레임워크와 연동할 수 있습니다.

예시

RSS 수집기 → Kafka (raw topic)
 → 정제/필터링 → Kafka (clean topic)
 → 개인화 추천 → Kafka (recommend topic)

6. 이벤트 소싱 (Event Sourcing)

Kafka는 애플리케이션의 상태 변화를 순차적인 이벤트로 저장하는 Event Sourcing 패턴의 저장소로 적합합니다.

사용 시나리오

• 도메인 객체의 상태 변경 이력을 전체 저장
• 재현 가능한 시스템 상태 관리

7. 분산 시스템의 커밋 로그

Kafka는 분산 시스템의 외부 커밋 로그로 활용되어 데이터 복제 및 장애 복구 시 강력한 도구가 됩니다.

관련 기능

• 로그 압축(Log Compaction): 최신 상태만 유지하면서도 이벤트 로그의 무결성을 보장
• Apache BookKeeper와 유사한 사용 방식

Spring Batch는 대용량 데이터 처리에 특화된 프레임워크로, 다양한 사용자 니즈를 만족시키기 위해 계층화된 구조를 갖습니다. 아래는 핵심 구성 요소입니다.

✅ 주요 계층

• Application Layer: 사용자가 작성하는 Job, Step, 커스텀 리더/라이터 등
• Batch Core Layer: JobLauncher, Job, Step 등의 핵심 런타임 컴포넌트 포함
• Infrastructure Layer: ItemReader, ItemWriter, RetryTemplate 등 공통 유틸리티 제공

이러한 구조는 확장성, 테스트 용이성, 재사용성 측면에서 유리합니다.

📐 배치 시스템 설계 원칙

1. 온라인/배치 공존 고려

• 데이터 공유 및 락 전략을 함께 고려해야 함
• 커먼 컴포넌트 활용 권장

2. I/O 최소화

• 가능하면 메모리 내에서 처리
• 불필요한 SQL 쿼리 제거 (불필요한 재조회, 테이블 스캔 등)

3. 데이터 무결성 보장

• 체크섬, 레코드 수, 논리 검증 포함
• 재처리 방지 (처리 중에 합산 등을 같이 수행)

4. 스트레스 테스트 및 백업 고려

• 실제 운영량 수준에서 테스트 필요
• Flat 파일 기반일 경우, 파일 백업 절차도 중요

🧩 실무 배치 패턴 및 애플리케이션 유형

💡 애플리케이션 유형

• 변환(Conversion)
• 검증(Validation)
• 추출/업데이트(Extract/Update)
• 처리/포맷(Output/Format)

🧰 유틸리티 단계

• Sort / Split / Merge 같은 표준 처리 유틸리티 활용

📦 입력 소스에 따른 분류

• DB 기반 / 파일 기반 / 메시지 기반

⚙️ 배치 처리 전략

1. 일반 배치 처리

• 단순 배치 윈도우에서 실행
• 단일 커밋, 락 고려 필요 없음

2. 온라인과 동시 처리

• 락을 최소화하는 Optimistic Locking 또는 Pessimistic Locking 전략 필요

// Optimistic Locking 예시
UPDATE customer
SET status = 'PROCESSED'
WHERE id = ? AND last_updated = ?

3. 병렬 처리

• 병렬 실행 시, 공유 리소스 락 관리 필요
• Control Table 방식 사용 가능

4. 파티셔닝 (Partitioning)

• 대용량 데이터를 여러 인스턴스로 분할 처리
• Spring Batch의 PartitionHandler 활용 가능

🔀 파티셔닝 전략 심층 분석

전략 1. 고정 분할

• 레코드를 일정 수로 나누어 처리 (pre-processing overhead 존재)

전략 2. 키 컬럼 기반 분할

• location_code 등 특정 키 컬럼 기준 분할

전략 3. View 기반

• 파티션별 뷰 구성 후 뷰 대상으로 배치 수행

전략 4. 처리 인디케이터 추가

• 상태 컬럼(예: status) 기반 동시 실행 보장

전략 5. 테이블 → Flat File 추출 후 분할

• 외부 배치 인프라와 연동 시 유용

전략 6. Hash 컬럼 추가

• hash_key 로 구간 분배, 분산 제어 용이

🧠 실전 설계 팁

✔ 중앙 파티션 테이블 설계

CREATE TABLE partition_meta (
  program_id VARCHAR(20),
  partition_no INT,
  key_low VARCHAR(100),
  key_high VARCHAR(100),
  PRIMARY KEY (program_id, partition_no)
);

• 유연한 파티셔닝 및 관리 가능

✔ 데드락 방지

• 테이블 설계 시 인덱싱 전략 주의
• 핫스팟 테이블(예: log, control, lock table) 신중 설계

✔ 파라미터 자동 전달 구조 구축

• 실행 전 파라미터 유효성 검증 포함
• 파티션 간 격리 및 실패 시 재시도 처리 설계 포함

💡 영속성 컨텍스트란?

영속성 컨텍스트는 "엔티티를 영구 저장하는 환경"입니다. 정확히는 다음과 같은 특징을 갖는 논리적 개념입니다:

• 엔티티 객체를 관리하는 메모리 내 저장소
• EntityManager를 통해 접근
• 눈에 보이지 않지만 JPA의 거의 모든 동작의 기반

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
Member member = new Member("member1", "회원1");
em.persist(member);

위 코드에서 persist() 호출은 DB에 바로 insert하는 것이 아니라, 영속성 컨텍스트에 저장하는 작업입니다.

📦 엔티티 생명주기

JPA 엔티티는 아래 네 가지 상태를 가질 수 있습니다:

Member member = new Member(); // 비영속
em.persist(member);           // 영속
em.detach(member);            // 준영속
em.remove(member);            // 삭제

🚀 언제 DB에 반영될까?

JPA는 persist() 시점에 DB에 insert 쿼리를 날리지 않습니다. 실제 쿼리는 트랜잭션 커밋 시점에 발생합니다.

em.getTransaction().commit(); // 이 시점에 insert 쿼리 실행

이러한 방식은 쓰기 지연(Write-Behind) 또는 트랜잭션 단위의 배치 처리라 부르며, 성능 최적화에 매우 유리합니다.

✅ 영속성 컨텍스트의 이점

1. 1차 캐시

   • 동일 트랜잭션 내에서 find() 시 DB를 다시 조회하지 않음

2. 동일성(identity) 보장

   • 같은 트랜잭션 내 동일 엔티티 조회 시 동일 객체 반환 (== 비교 가능)

3. 쓰기 지연 (Transactional Write-Behind)

   • 쿼리 최소화 및 트랜잭션 단위의 처리 가능

4. 변경 감지(Dirty Checking)

   • 엔티티 값 변경 감지 후 자동 update 쿼리 생성

5. 지연 로딩(Lazy Loading)

   • 연관 객체는 실제 접근 시점에 쿼리 실행 (필요할 때만 조회)

1. 정적 컨텐츠 (Static Content)

정적 컨텐츠는 가장 단순한 형태의 웹 리소스 제공 방식입니다. 서버는 로직 없이 파일을 있는 그대로 브라우저에 반환합니다.

🔹 특징

• 서버 처리 로직 없음
• 빠르고 단순
• HTML, CSS, JS, 이미지 파일 등
• SEO에 유리

🔹 Spring Boot에서의 처리 방식

Spring Boot는 기본적으로 /resources/static 디렉토리에 위치한 파일들을 정적 컨텐츠로 서빙합니다.

폴더 구조

src/main/resources/static/hello-static.html

예제 HTML

<!DOCTYPE HTML>
<html>
<head>
<title>static content</title>
<meta charset="UTF-8" />
</head>
<body>
정적 컨텐츠 입니다.
</body>
</html>

접근 URL

http://localhost:8080/hello-static.html

🔹 처리 순서

1. 브라우저가 /hello-static.html 요청
2. Spring은 해당 URL을 처리할 컨트롤러 존재 여부 확인
3. 없으면 /static 폴더에서 파일 탐색 후 반환

❗ 정적 컨텐츠는 단순하지만 동적 처리(예: 사용자 맞춤형 페이지)가 불가합니다.

2. MVC와 템플릿 엔진

전통적인 서버 사이드 렌더링 방식입니다. 컨트롤러가 모델 데이터를 생성하고, 뷰 템플릿(예: Thymeleaf, JSP)을 통해 HTML을 생성합니다.

🔹 구조

• Model: 비즈니스 데이터
• View: 템플릿 엔진 (JSP, Thymeleaf 등)
• Controller: 요청 처리 및 데이터 전달

🔹 장점

• 서버 주도형 렌더링으로 복잡한 비즈니스 로직 처리에 적합
• SEO 및 초기 로딩 최적화

🔹 단점

• 클라이언트와 서버 간 결합도가 높음
• 화면 변경 시 서버 템플릿까지 변경 필요

Spring MVC는 이 구조를 자연스럽게 지원합니다. @Controller + ModelAndView 조합이 일반적입니다.

3. API 방식 (JSON 기반)

모던 웹/모바일 환경에서는 API 방식이 널리 사용됩니다. 서버는 HTML 대신 JSON 형식의 데이터만 클라이언트에 전달하며, UI는 클라이언트(React, Vue, 모바일 앱)가 담당합니다.

🔹 특징

• 데이터와 UI 완전 분리 (백엔드/프론트엔드 분리)
• JSON 포맷 주로 사용
• 모바일 앱, SPA(React, Vue)와의 통신에 적합

🔹 장점

• 재사용성, 확장성 우수
• 프론트엔드 독립 개발 가능
• 서버 간 통신에도 적합 (Microservice)

🔹 단점

• SEO 대응 어려움
• 클라이언트 개발 비용 증가

@RestController
public class HelloApiController {
    @GetMapping("/api/hello")
    public Map<String, String> hello() {
        return Map.of("message", "Hello, API!");
    }
}

코틀린도 자바처럼 "표준 스펙과 구현체" 개념이 있을까?

코틀린은 자바처럼 공식적으로 표준 스펙과 다양한 구현체를 나눠 설명하진 않지만, 코틀린 또한 JVM 기반 언어로서 자바 생태계를 그대로 활용합니다.

• JetBrains가 주도하는 공식 구현체

  • 코틀린은 JetBrains에서 개발하며, 공식 컴파일러 및 툴체인을 제공합니다.
  • 코틀린 컴파일러는 Java 바이트코드를 생성함으로써 JVM에서 실행됩니다.

• JVM 구현체 활용

  • Oracle OpenJDK, Amazon Corretto, Eclipse Temurin 등 자바 구현체 위에서 실행됩니다.
  • 따라서 다양한 OS에서 실행 가능한 점은 자바와 동일합니다.

코틀린의 컴파일과 실행 구조

코틀린의 실행 과정은 자바와 유사하며 다음과 같은 단계로 나뉩니다:

1. 컴파일 (kotlinc)

   • .kt → .class (바이트코드)
   • 자바와 동일하게 문법 검사 및 바이트코드 최적화 수행

2. 실행 (java)

   • JVM이 .class 파일을 실행
   • 코틀린은 JVM 위에서 동작하므로 실행 방식은 자바와 동일

실무에서 Kotlin + Spring Boot 조합은 JVM 생태계의 이점을 그대로 누릴 수 있습니다.

IntelliJ IDEA에서 코틀린은 어떻게 다를까?

IntelliJ IDEA는 코틀린의 본가인 JetBrains에서 만든 IDE이기 때문에 코틀린 개발에 최적화되어 있습니다.

• Kotlin SDK 설치 및 자동 구성
• kotlinc, java 명령 자동 실행
• 컴파일 결과는 자바와 마찬가지로 out/ 폴더에 생성됨
• 코틀린 또한 디컴파일 기능을 통해 바이트코드 분석 가능

개발 속도와 학습 효율 모두 자바보다 더 뛰어나다는 평도 많습니다.

운영체제 독립성: 코틀린도 자바처럼 자유롭다

코틀린은 JVM에서 실행되므로 운영체제 독립성을 그대로 이어받습니다.

• .class 파일은 OS에 구애받지 않음
• JVM만 설치되어 있으면 Windows, macOS, Linux 어디서든 실행 가능
• 예: 개발은 macOS + Kotlin, 운영은 AWS 리눅스 서버 + Amazon Corretto

Kotlin/Native나 Kotlin Multiplatform을 활용하면 이식성을 더 극대화할 수도 있습니다.

실무에서의 적용 시나리오

✅ 실무 TIP: Kotlin 프로젝트의 경우도 자바와 마찬가지로 운영환경과 동일한 JVM 구현체를 맞춰주는 것이 중요합니다.

# 개발: macOS + Kotlin + Eclipse Temurin
# 운영: AWS EC2 + Kotlin + Amazon Corretto

• Kotlin으로 개발한 애플리케이션도 .class 파일로 컴파일됨
• 운영 환경에서는 해당 .class 파일을 그대로 실행

자바는 왜 "표준 스펙과 구현체"로 나눠질까?

자바는 단일한 구현체가 아닌, 표준 스펙(Java Specification)과 이를 따르는 다양한 구현체(Java Implementation)의 구조를 가지고 있습니다.

• 표준 스펙 (JCP에 의해 관리)

  • 자바 언어가 어떤 구조로 만들어져야 하는지 정의한 설계도
  • 예: 컴파일러 동작 방식, JVM 구조, 필수 라이브러리 명세 등

• 구현체

  • 다양한 회사들이 스펙을 기반으로 만든 실제 실행 가능한 자바 플랫폼
  • 대표적인 구현체:
    • Oracle OpenJDK
    • Amazon Corretto (AWS에 최적화)
    • Eclipse Temurin (Adoptium)

스펙이 일관되기 때문에 구현체 간 호환성이 매우 높습니다. 실무에서 특정 구현체를 바꿔도 대부분 문제가 발생하지 않죠.

자바의 컴파일과 실행 구조

자바의 실행 과정은 다음 두 단계로 나뉩니다:

1. 컴파일 (javac)

   • .java → .class (바이트코드)
   • 문법 오류 검출 및 바이트코드 최적화 수행

2. 실행 (java)

   • JVM이 .class 파일을 읽고 실행
   • 이 과정에서 플랫폼에 맞는 JVM이 역할을 수행

실무에서는 이 구조를 잘 이해하고 있어야 디버깅, 성능 튜닝, 배포 전략 설계에서 실수를 줄일 수 있습니다.

IntelliJ IDEA에서 자바는 어떻게 다를까?

현대 개발자에게는 IDE가 곧 생산성입니다. 특히 IntelliJ IDEA는 자바 개발에서 필수적인 도구 중 하나입니다.

• 자바 SDK 설치 자동화
• javac, java 실행 자동화
• 컴파일 결과는 out/ 폴더에서 확인 가능
• 디컴파일 기능 제공 (단, 주석 등은 복원되지 않음)

초보자뿐만 아니라, 프로젝트 설정이 복잡한 엔터프라이즈 환경에서도 매우 유용합니다.

운영체제 독립성: 자바의 가장 큰 강점 중 하나

자바 프로그램은 어떤 운영체제에서도 실행될 수 있습니다. 이유는 JVM이 각 OS에 맞는 실행 환경을 제공하기 때문이죠.

• .class 파일은 OS에 구애받지 않음
• Windows, macOS, Linux에 맞는 JVM만 있으면 실행 가능
• 예: 개발은 macOS, 배포는 AWS 리눅스 서버 (Amazon Corretto)

이러한 구조 덕분에 "Write Once, Run Anywhere"라는 자바의 철학이 실현될 수 있었습니다.

실무에서의 적용 시나리오

✅ 실무 TIP: 운영환경은 대부분 리눅스입니다. 따라서 로컬에서는 Windows나 macOS를 쓰더라도, 서버 환경과 동일한 JDK 버전과 구현체를 맞춰주는 게 좋습니다.

# 개발: macOS + Eclipse Temurin
# 운영: AWS EC2 + Amazon Corretto

• 개발 중에는 로컬에서 빠른 실행과 디버깅
• 배포 시에는 운영환경(JVM 최적화된 리눅스)으로 전환

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼입니다. 2014년 Google이 오픈소스로 공개했으며, 이름은 그리스어로 "조타수(helmsman)"를 의미합니다.

• 확장성: 수천 개의 컨테이너를 관리할 수 있는 구조
• 이식성: 온프레미스, 퍼블릭 클라우드, 하이브리드 환경 모두 지원
• 커뮤니티 중심 발전: CNCF(Cloud Native Computing Foundation) 주도로 빠르게 발전

Kubernetes가 필요한 이유

컨테이너는 애플리케이션을 패키징하고 배포하는 훌륭한 방법이지만, 실제 운영 환경에서는 다음과 같은 문제가 발생합니다.

• 장애 복구(컨테이너가 죽으면 자동 재기동)
• 서비스 디스커버리 및 로드밸런싱
• 무중단 배포 및 롤백
• 리소스 최적화

Kubernetes는 이런 운영 이슈를 체계적으로 해결합니다. 복잡한 분산 시스템의 구축과 운영을 프레임워크 수준에서 지원하는 것이죠.

Kubernetes 주요 기능

1. 서비스 디스커버리와 로드밸런싱

• Kubernetes는 DNS 이름 또는 자체 IP를 통해 Pod(컨테이너 집합)에 접근할 수 있게 합니다.
• 트래픽이 많을 경우 로드밸런서를 통해 네트워크 부하를 분산합니다.

2. 스토리지 오케스트레이션

• 로컬 스토리지, 퍼블릭 클라우드 스토리지(AWS EBS, GCP Persistent Disk 등)를 자동으로 마운트할 수 있습니다.

3. 자동화된 롤아웃 및 롤백

• 선언적 방식(Declarative Approach)으로 원하는 상태를 정의하면, Kubernetes가 실제 상태를 점진적으로 맞춰갑니다.

4. 자동 리소스 배치 (Bin Packing)

• 컨테이너별 CPU, 메모리 요청량을 기반으로 최적화된 노드에 컨테이너를 배치합니다.

5. 셀프 힐링(Self-Healing)

• 실패한 컨테이너를 자동으로 재시작하거나 교체합니다.
• 상태 확인이 실패한 컨테이너는 외부에 노출하지 않습니다.

6. 보안 및 설정 관리

• 비밀번호, OAuth 토큰, SSH 키 등 민감한 정보를 안전하게 저장하고 배포할 수 있습니다.

7. 수평적 확장

• 명령어, UI, 또는 CPU 사용량을 기반으로 Pod 수를 자동 확장하거나 축소합니다.

Kubernetes는 무엇이 아닌가

• PaaS가 아님: 전체 개발 플랫폼을 제공하지 않고, 필요한 기능만 제공합니다.
• CI/CD 툴이 아님: 소스코드 빌드 및 배포는 외부 시스템과 통합해야 합니다.
• 어플리케이션 서비스 제공자가 아님: 데이터베이스, 캐시 같은 서비스는 직접 운영하거나 별도 배포해야 합니다.
• 중앙집중식 오케스트레이터가 아님: 다양한 컨트롤러들이 비동기적으로 상태를 유지합니다.

Kubernetes의 역사적 배경

1. 전통적 서버 환경

• 물리 서버 위에 여러 앱이 동작 → 리소스 경합 및 비효율 문제

2. 가상화 시대

• VM 도입 → 자원 격리 및 효율 개선, 하지만 무겁고 느림

3. 컨테이너 시대

• OS 공유 기반 경량화 → 빠른 배포, 높은 이식성, 리소스 최적화

컨테이너 기술의 급격한 발전은 복잡한 컨테이너 환경을 운영할 수 있는 관리 시스템(Kubernetes)의 등장을 자연스럽게 이끌었습니다.

"워크플로우를 코드로 정의하고, 배치 실행을 체계화하는 플랫폼"

Airflow는 Python 코드로 워크플로우(DAG: Directed Acyclic Graph)를 정의하고, 주기적으로 실행되도록 스케줄링하며, 실행 상태를 모니터링할 수 있게 해줍니다.

특징은 다음과 같습니다:

• Workflows as Code: Python으로 파이프라인을 작성
• 동적 생성: 코드로 DAG를 동적으로 만들 수 있음
• 확장성: 다양한 오퍼레이터 제공, 필요시 직접 개발 가능
• 유연성: Jinja 템플릿을 통한 파라미터화 지원
• 웹 UI 제공: DAG와 Task 상태를 시각화 및 관리 가능

간단한 예제 살펴보기

from datetime import datetime

from airflow import DAG
from airflow.decorators import task
from airflow.operators.bash import BashOperator

# DAG 정의
with DAG(dag_id="demo", start_date=datetime(2022, 1, 1), schedule="0 0 * * *") as dag:
    hello = BashOperator(task_id="hello", bash_command="echo hello")

    @task()
    def airflow():
        print("airflow")

    hello >> airflow()

요약

• DAG: "demo"라는 이름으로 매일 자정마다 실행.
• Task: hello (bash 실행) -> airflow (python 실행) 순서로 의존성 설정.

왜 Airflow를 써야 할까?

1. 코드 기반 워크플로우 정의

• Git을 통한 버전 관리, 리뷰, 롤백이 가능.
• 협업 및 테스트 작성이 용이.

2. 복잡한 파이프라인 스케줄링 가능

• DAG 안에서 Task 간 의존성을 자유롭게 설정.
• Backfill, Catchup 등 과거 데이터에 대한 재처리 지원.

3. 생태계와 확장성

• S3, GCS, Spark, Kubernetes 등 수많은 오퍼레이터 존재.
• 필요시 커스텀 오퍼레이터 제작 가능.

4. 운영 편의성

• 웹 UI를 통한 상태 모니터링 및 Task 재실행.
• 각 Task별 로그 확인 가능.

주의해야 할 점

배치성 워크플로우에 최적화

• Airflow는 유한한 시작과 끝을 가진 배치 파이프라인에 최적화.
• Kafka 같은 스트리밍 환경에는 부적합.

"클릭" 기반이 아님

• 워크플로우를 정의할 때 반드시 코딩이 필요.
• 노코드/로우코드 솔루션을 찾는다면 다른 도구를 고려해야 함.

실무 적용 팁

• 초기 세팅: 로컬에 Docker Compose로 띄워 실험해보기.
• 구조 설계: DAG와 Task를 너무 무겁게 만들지 말 것 (단일 책임 원칙 적용).
• 모듈화: 공통 기능은 Python 모듈로 분리하여 재사용성 높이기.
• 모니터링: SLA 미준수 알림 설정, 실패 Task 알림을 Slack이나 PagerDuty로 연동.