1.삶은 풀어야 할 숙제가 아니라 겪어봐야 할 신비다
문제는 당신 안에 있다
나만의 고유한 삶을 살자
의미와가치는 평판에 달려 있지 않다


2.배움을 멈추지 않는 한 우리는 계속 성장할 것이다
앎을 실천함으로써 삶을 바꾸자
바꿀수 없는것에 매이지 말고, 바꿀 수있는것에 살아라


3.인생은 빗속에서 춤추는 법을 배우는 것
해결할 수 있는 일은 근심할 필요가 없다
해결할 수 없는 일 또한 근심할 필요가 없다.

반드시라는 마음을 내려놓고
물 흐르듯이

욕망, 두려움 을 초월한다면 자유롭다

[어떻게 어른이 되는가]-엄성우 지음 

1. 겸손이란 무엇일까.

신이 아니기에 모든면에서 완벽하지 않고,

그런 불완정성을 스스로 인지할 수 있기에 다른 동물과 구분이 된다.

자신의 가치와 남의 가치를 비교하지 않는 것으로 출발

2. 왜 겸손해야 할까.

남을 불쾌하게 하지 않고 자신도 미움받지 않는다.

자기평가에 연연하지 않고 진정으로 중요한 것을 추구한다.

귀한 배움을 얻기 위해서는 남의 잘난척 정도는 가볍게 받아줄수도 있는 여유로운 태도가 필요할수도 있다. (이것도 겸손)

겸손만큼 쉽고 안전한 덕목이 없다.

3. 겸손은 예의나 친절함과 어떻게 다를까

예의 바름은 대부분 겉으로 드러나는 것.

겸손은 친절과는 다르다. 친절하게 태도를 가질수는 있으나

겸손은 결국 스스로를 어떻게 여기는가에 내면에서 나오는 소리에 달려있음

내적겸손을 갖추어야 외적겸손이 자연스럽게 발현된다.

4. 겸손한 사람은 자신에 대해 잘 알까?

자신의 탁월함을 알고도 겸손할 수 있는가.

내가 뛰어나다고 해서 내가 남보다 가치가 있는 것은 아니다. 탁월성을 안다고 겸손하지 못한것은 아님.

오히려 자신이 가진 힘과 영향력을 제대로 알지 못해서 생기는 문제도 있다. (가진자의 횡포, 상처주는 막말)

자신이 가진 탁월함을 제대로 알아야 적절히 활용하며 그에 걸맞는 행동을 할 수 있다.

"너 자신을 알라"

"내가 모른다는 사실이라도 알면 지혜로울 수 있다"

5. 겸손한 사람은 스스로를 어떻게 의식할까?

지나치게 자신을 의식하면 겸손하지 못할 수 있다.

"겸손이란 자신을 하찮게 생각하는 것이 아니라 자신에 대해 너무 많은 생각을 하지 않는 것이다" - C.S. 루이스

자신의 가치를 알맞게 가늠하는 사람은 꼭 필요한 경우가 아니면 자신을 화제의 중심에 두지 않는다.

"우리는 우리에 대해 무슨 이야기를 하는지보다 우리에 대한 이야기 자체에 더 신경을 쓰고,

우리를 어떻게 부르는지와 상관없이 사람들 입에 오르내린다는 사실로 만족스러워 한다. " - 몽테뉴

쓸데없는 것에 기뻐하는 사람들

우리는 자신의 것이 아닌 것에 대해서 과시하지 않아야 한다.

6. 감사와 겸손, 겸손과 자기비하, 겸손과 오만

보통 겸손한 사람은 감사를  잘한다. 하지만 감사할 줄은 알지만 겸손하지 못한 사람도 있다. 

진짜 겸손한 사람은 자신을 중심에 두려는 성향이 적어서, 남을 돕거나 진리를 추구하는 등

인생의 중요하고 가치있는 일을 실천해 나가는 사람.

---------

겸손과 자기비하는 마치 비슷해보이지만 다르다.

자신을 스스로 깎아 내리려는 성향이 선의,용기 등 다른 덕목을 발휘하는데 방해가 되는를 기준으로 본다면

자기비하는 그 부정적인 태도로 자신과 그 주위에 악영향을 미친다.

예를 들어서 상을 받거나 축하를 받을때 스스로 깎아내린다면, 혹은 자신이 받은 상의 가치를 깎아 내린다면

그 상을 준사람, 받은 또 다른 사람, 또 그 상을 받지 못한사람과 그 상을 받도록 도와준 모든 사람에게 실례

겸손은 자신을 낮추는 태도가 아닙니다. 자신에게 엄격한 것도 아니며,

자신을 깎아 내린다는 것은 결국 자신과 비슷한 위치에 있는 사람도 깎아내리는 것이 되기 때문이다.

자신을 드러내는 행동이 반드시 오만한 것은 아니다.

자랑에도 이유가 있다면 겸손에 어긋나지 않으며

결국 겸손은 자기비하와 오만 사이의 중용이다.

"덕 이란 모자람과 지나침의 양 극단 사이의 중용" - 아리스토텔레스

** 자존감의 크기가 아니라 자존감의 근거에 달려있다.

겸손하지 못한 사람은 Better에 중점을 두고,

겸손한 사람은 Good에 중점을 둔다. 즉, 가치있고 의미있는 것을 추구하고 실현함으로써 높아진 자존감을 얻게 되는 것

Flink State vs 외부 저장소를 활용한 값 관리: 어떤 선택이 더 합리적일까?

개요

실시간 데이터 처리 파이프라인에서 흔히 등장하는 과제 중 하나는 “사용자 피로도, Aggregation등” 값 관리입니다.
예를 들어, 마케팅 알림이나 이벤트 푸시 발송 시스템에서 동일 사용자에게 너무 많은 알림이 전달되지 않도록 시간/횟수 기반 제약을 두어야 할 필요도 있고, 일정 시간내의 이벤트 Aggregation등의 처리가 필요한 경우도 있습니다.
 
이를 구현하는 방법은 크게 두 가지로 나눌 수 있습니다.

1. Flink State를 통한 관리
2. Redis 등 외부 저장소를 통한 관리

 실제 운영 환경에서 이 두 가지 접근법을 모두 검토했으며, 각 방식의 장단점과 보완 방법을 정리해 보았습니다.
 

Flink State 기반 관리

동작 방식

• Flink의 KeyedProcessFunction 또는 RichFlatMapFunction에서 ValueState, ListState, MapState 등을 활용.
• 사용자별 키(userId)로 state를 유지하고, 이벤트 처리 시 조건을 체크.
• checkpoint/restore 메커니즘을 통해 exactly-once 보장 가능.

장점

• 일관성 보장: Flink state는 checkpoint와 함께 관리되어 장애 상황에서도 데이터 유실 최소화.
• 처리 성능 최적화: 외부 호출 없이 JVM 내부 메모리/로컬 RocksDB로 state 접근 → 지연(latency) 최소화.
• 운영 단순화: 외부 저장소 장애와 무관하게 파이프라인 내에서 관리 가능.

단점

• 확장성 한계: State 크기가 커질수록 checkpoint 부하가 증가.
• 비즈니스 연계성 부족: 파이프라인 외부 서비스(예: CRM, 백오피스)에서 동일 피로도 정책 확인 어려움.
• 운영 가시성 부족: state는 Flink 내부에 있어 모니터링/조회가 불편.
• 복원 불안정 : Operator나 내부 Class등의 변경이 생길경우 복원이 정상적으로 되지 않음

보완 방법

• TTL(State Time-to-Live)을 활용해 불필요한 state 자동 정리.
• State backend(RocksDB) 튜닝으로 대규모 데이터 관리 가능.
• 필요 시 side-output 등으로 state snapshot을 외부 DB로 export하여 조회용 데이터 구축.

외부 저장소(Redis 등) 기반 관리

동작 방식

• 이벤트 처리 시 Redis에 사용자별 카운터 / 타임스탬프를 저장.
• 피로도 체크 시 Redis 조회 → 조건 충족 시 이벤트 처리, 아니면 drop.
• Redis의 INCR, EXPIRE 등을 활용하여 TTL 기반 제어 가능.

장점

• 외부 접근성 우수: CRM, 백오피스, API 등 다양한 외부 시스템에서 즉시 참조 가능.
• 운영 유연성: Redis 데이터만 보면 전체 상태 확인 가능.  (Prefix 를 이용, 전체 Keys는 운영중 절대 안됨!)
• 확장성: Redis Cluster 등으로 수평 확장 가능.
• 안정성 : Flink App의 재부팅 / 결함으로부터 자유로움

단점

• 일관성 취약: Flink 처리 중 실패/재처리 시 Redis 값이 중복 증가할 수 있음.
• 성능 부담: 외부 I/O 호출로 인해 latency 증가 가능.
• 운영 복잡성: Redis 장애 시 파이프라인도 영향 받을 수 있음.

보완 방법

• 원자적 연산(GET+INCR) 사용 및 Lua Script 기반 트랜잭션 처리.
• 배치 보정 파이프라인: 하루/주 단위로 Redis 카운트를 원천 이벤트 로그와 맞추어 정합성 보정.
• 모니터링/알림 : Redis Replica/Cluster 구성을 통한 가용성 확보

보관하는 값의 종류에 따른 차이점

운영 중 겪었던 문제

처음에는 모든  데이터를 Flink state로 관리하려 했습니다.
하지만 장애 복구 시 state 복원 크기가 커지면서 문제가 발생했습니다.

• 복원 사례: 수십 GB 단위 state를 가진 잡이 재시작될 때→ 그동안 KPU(Flink 작업 슬롯)를 넉넉하게 늘려야만 안정적인 복구 가능
• → 운영 비용과 복잡성이 증가
• → Checkpoint restore 시간이 수십 분 이상 소요

이 경험을 통해 모든 값을 state에 넣는 건 정답이 아님을 깨달았습니다.
 

State로 관리하면 좋은 값들

State는 Flink의 강력한 무기입니다. 특히 **“스트림 내에서 바로 계산되는 값”**에는 최적화되어 있습니다.

• 누적 값 (counters): 예) 특정 키(userId)의 이벤트 누적 개수
• 평균/합/통계치 (aggregation): 예) 지난 5분간 클릭률 평균
• 세션/윈도우 기반 임시 상태: 예) 10분 세션 동안 발생한 이벤트 패턴
• 비교적 작은 사이즈의 데이터: 예) 단일 사용자 최근 5개 이벤트 저장

➡️ 이런 값들은 Flink checkpoint/restore와 exactly-once 보장이 잘 맞아떨어집니다.
 

외부 저장소로 관리하면 좋은 값들

반면, **“외부에서 참조가 필요하거나, 중복 증가가 치명적이지 않은 값”**은 Redis 같은 외부 저장소가 더 적합합니다.

• Fatigue (발송 제약):→ CRM/운영툴에서 실시간 확인 가능
  • 중복으로 값이 과증가해도 보수적으로 동작 (안 보내는 쪽으로 기울어 안전)
• 장기 보존이 필요한 값:→ Redis/DB에 두면 조회와 보정(batch pipeline) 용이
  • Flink state에 두면 checkpoint 부하 ↑
• 운영 가시성이 중요한 값:
  • 운영자가 즉시 확인하고 조정해야 하는 데이터 (예: 사용자별 발송 제한 카운터)

➡️ 이런 값들은 Flink state보다 외부 저장소 + 보정 파이프라인이 더 안정적입니다
 

결론 및 선택 가이드

• Flink State 중심 전략: 성능과 일관성이 가장 중요할 때 선택.
  • 알림 피로도 관리가 파이프라인 내부 로직에 국한되고, 외부에서 별도 조회 필요성이 적을 경우 적합.
• Redis 중심 전략: 운영 가시성, 보수적 동작, 외부 연계성
  • 단, 재처리/중복 처리 리스크를 줄이기 위한 보완책이 필수.

맺음말

결국, fatigue 관리의 초점이 “실시간 정확성”인지 “운영 편의성”인지에 따라 선택지가 달라집니다.
저의 고민과 정리를 바탕으로, 비슷한 고민을 하고 계신 분들께 도움이 되길 바랍니다.

AWS Managed Flink + Kinesis DataStream 실시간 데이터 처리 시스템 개요

1. 개요

최근 데이터 처리 환경은 “실시간”이라는 키워드가 핵심입니다.

대용량 이벤트 스트림을 빠르게 수집하고, 실시간으로 분석·가공한 뒤 다양한 시스템에 전달해야 하는 요구가 있어서

AWS에서 제공되고 있는 Amazon Kinesis DataStream와 **Amazon Managed Service for Apache Flink(이하 Managed Flink)**를 활용해봤습니다.

이번 글에서는 이 두 서비스를 활용해 실시간 데이터 파이프라인을 구축하는 기본 개념과 설계 포인트를 정리해봅니다.

2. 서비스 개요

2.1 Amazon Kinesis

Kinesis는 AWS의 완전관리형 스트리밍 데이터 서비스입니다. (Kafka 와 유사하다고 생각하시면 됩니다.)

이 중 **Kinesis Data Streams(KDS)**를 사용하면 초당 수백 MB~GB급 이벤트를 안정적으로 수집·버퍼링할 수 있습니다.

특징

• 샤드(Shard) 단위로 처리량 확장 가능 -> 파티션 과 유사
• 순서 보장 및 재처리 지원
• 초당 수천 TPS 가능
• SDK, Firehose, CLI 등 다양한 연동 방식

2.2 Amazon Managed Flink

Apache Flink를 완전관리형으로 제공하는 서비스입니다.

Managed Flink를 사용하면 클러스터 관리나 배포 인프라 고민 없이, Flink 애플리케이션 개발에 집중할 수 있습니다.

단, 기본 Flink와 다르게 조정할 수 없는 Configuration 들이 있으니 공식문서를 참조해야 합니다.

특징

• Flink 버전 업그레이드 및 인프라 관리 자동화
• Kinesis, S3, DynamoDB 등 AWS 서비스와 Native 연동
• Checkpoint/Savepoint를 통한 상태(State) 복구 지원
• Scaling 자동화(Parallelism 조정)

3. 시스템 아키텍처 개요

1. Producer: 실시간 Event 수집 Platform
2. Kinesis Data Streams: 실시간 데이터 Queue
3. Managed Flink: 실시간 데이터 처리(Enrichment, Filtering, Aggregation)
4. Sink: 결과 저장(S3)

4. 구현 시 주요 고려사항

4.1 데이터 모델 & 직렬화

• Flink와 Kinesis 간 전송 데이터는 기본사용은 kryo사용(reflect방식)으로 성능이 떨어지기 때문에 추후 스키마 진화를 생각하면 Avro, Protobuf 등 직렬화 포맷 선택하는것이 유리하다.

4.2 상태 관리(State Management)

• Flink는 Keyed State와 Operator State를 제공
• 상태 크기가 커질수록 Checkpoint 주기와 저장소 성능이 중요하다.
• AWS에서는 기본적으로 S3에 Checkpoint/Savepoint 저장하며 사용자는 접근이 불가능하다.

4.3 Checkpoint / Savepoint 전략

• Checkpoint: 장애 시 자동 복구
• Savepoint: 버전 배포·롤백 시 수동 복구
• 체크포인트 주기는 1분~5분 권장, 처리량과 지연 시간에 따라 조정

4.4 Source/Sink Connector

• Source: KinesisStreamsSource 또는 Flink Kinesis Connector
• Sink: S3 로 기본사용

4.5 확장성(Scaling)

• Kinesis는 샤드 수로 확장
• Flink는 parallelism 조정 
• 병목 지점(Shard → Flink 병렬도) 일치 여부 체크 필요
• Parallelism과 KPU가 자동으로 계산되는데  4.2의 상태관리와 연관되어 재기동시 backpressure , 지연이 발생하지 않도록 처리시간 + 복원시간을 고려해야 한다.

5. 운영 팁

1. CloudWatch + Managed Flink Metrics로 레이턴시, 백프레셔(backpressure) 모니터링
2. Kinesis 샤드 모니터링 → 샤드 split/merge 자동화 스크립트 준비
3. Flink 애플리케이션 버전 관리 → Git + CI/CD (CodePipeline, CodeBuild) 연동 , Flink재기동은 자동보다는 수동을 추천
4. Data retention: Kinesis는 최대 7일, 그 이상은 S3에 Raw Data 저장
5. 배포 전 로컬 환경에서 Flink MiniCluster로 테스트
6. Flink 내 ProecssFunction에 대해서는 Harness를 이용해서 최대한 Test Code를 작성해둔다.

6. 간단한 예제 플로우

• Source: Kinesis에서 JSON 데이터 읽기
• KeyBy: UserId 단위 처리
• ProcessFunction: 룰 매핑, 데이터 보강
• Sink: S3 저장

DataStream<Event> source = env
    .fromSource(kinesisSource, WatermarkStrategy.noWatermarks(), "Kinesis Source")
    .map(json -> parseJson(json));

source
    .keyBy(Event::getUserId)
    .process(new CustomEnrichmentFunction())
    .addSink(s3Sink);

7.  결론

AWS Managed Flink + Kinesis 조합은 실시간 데이터 분석 파이프라인을 빠르고 안정적으로 구축할 수 있는 강력한 도구입니다.

인프라 운영 부담을 줄이고, 비즈니스 로직에 집중할 수 있다는 점이 가장 큰 장점입니다.

다만, 체크포인트 전략, 상태 크기 관리, Kinesis 샤드 수 조정 등 운영 노하우가 중요하니, 충분히 검증 / 모니터링을 후 본격 도입하는 것을 추천드립니다.

OAuth 2.0 Resource Server에서 JWT 토큰을 검증하고 권한을 처리하는 방법에 대해 알아보겠습니다. Spring Security를 사용하여 Resource Server를 구성하고, JWT 토큰의 scope와 roles 클레임을 권한으로 변환하는 과정을 살펴볼 것입니다. 또한, 자주 발생하는 SSL 관련 오류와 그 해결 방법에 대해서도 다룰 예정입니다.

OAuth2 Authorization Server Setup

개요

AWS RDS와 DynamoDB의 비용 및 성능 비교는 데이터베이스 선택 시 중요한 고려사항입니다. 이 분석에서는 두 서비스의 비용 구조, 성능 특성, 그리고 대규모 쓰기 작업 시나리오에서의 비용 효율성을 살펴보았습니다. 또한 고가용성을 위한 중복 구성 시의 비용과 Spring Boot와의 연동 방법에 대해서도 논의하였습니다.