99duuk

2026년 4월 러닝 챌린지

99duuk — Thu, 30 Apr 2026 17:15:29 +0900

이번달은 300k 마일리지를 목표로 잡고..
최대한 많이 달리려고 노력했다. 어째저째 300k가 채워지긴 했다.
한 200k 부터는 달리는게 너무너무 지루했고 달리기 너무너무 싫었다.
꺼드럭거리기 위해 참고 달렸다....

열심히 달리고 또 열심히 마셨다.. 술을 최대한 안먹는다 ... 라고 다짐했지만 마실 상황이 자주 발생했다.
매일 10k 정도씩 잡고 달리다보니 몸 회복이 많이 더뎠다.
육체가 참 나약하다.........
한 430페이스로 달린다고 생각하고 시곌 확인해보면 500, 530인 날도 많았다.
끌어올린 심폐 능력에 비해 근력이 곧잘 버텨지지 않았다.

지난달 k마라톤 하프 달리면서 복근과 코어에 힘이 빠지면서 상체가 무너지는걸 크게 느꼈기 때문에 이번달은 상체 훈련(?)이라고 하면 거창하지만 대충 푸쉬업, 평행봉, 턱걸이를 섞어서 해줬다.
거의 루틴이

퇴근 ->
옷갈아입고 푸쉬업 + 케틀벨 컬 + ab슬라이드 ->
한강 이동 ->
달리는 중간중간에 한스장 들려서 턱걸이와 평행봉

이렇게 돌렸다.

확실히 상하체가 튼튼해진 것 같긴하다...
장거리 달릴때 상체 말리는 문제가 ab슬라이드하면서 많이 좋아졌다.
하지만 팔운동을 하면서 팔 근육의 불균형이 심해졌다. 눈바디로 봤을때도 차이가 난다.
특히나 달리며 팔치기 할때 오른팔이 훨씬 많이, 크게 움직인다.
요걸 어떻게 교정하지 않으면 분명 장거리 달릴 때 문제가 생길 것 같다.
우선 11월 제마 풀을 목표로.. 4월에 이어서 마일리지를 가능한 땡겨봐야할 것 같다.
짧은 거리보단 긴 거리 위주로... 페이스 신경쓰지 말고........
매일 10k 달리기보다 이틀에 20k씩 달리는게 나을 것 같다는 생각이 든다.

다음 대회는 5/30 여명마라톤 하프인데.. 목표는 1시간 23분이다.
5월은 연휴도 많고 여명 하프 테이퍼링 하려면 일주일은 또 마일리지를 줄일테니 현실적으로는 아마 250k??? 정도가 가능하지 않을까..

아무튼 처음으로 300k를 넘겨봤다....
뿌듯하다거나 뭐 그런 생각보다... 도대체 오육백씩 달리는 사람들은 어케하는건지 모르겠다.
가능한건가????
주 6일 20k씩 달려도 500k가 안되는데????????? 대체 어케함!!!!!

아침에 자주자주 달리고 싶은데 일찍 일어나는게 여간 어려운 일이 아니다..
수요일 소울루프 아니면 도저히 여섯시에 일어나서 달리러 가지 못하겠다...........

2026년 1,2,3월 러닝 챌린지

99duuk — Thu, 2 Apr 2026 17:26:15 +0900

2월 22일 대구마라톤을 앞두고, 장경인대 부상은 도통 나아질 기미가 보이지 않았다.
12월, 1월.. 제대로 훈련했으면 풀마라톤 기대감에 마음이 상당히 부풀었을텐데,
이럴거면 미리 취소할 걸 그랬나.. 후회만 가득했다.

매일매일 스트레칭하고 주무르고 누르고 쉬어도 차도가 없었다.
이번엔 중둔근은 멀쩡했고, 고관절 쪽에 문제가 있다고 생각했다.

대충 눌러봤을때 Tensor Fasciae Latae 부근에 통증이 많았다. 고관절 틀어짐 때문에 해당 부근이 뻣뻣해지거나 뭉치거나.. 염증이 생겼다고 예상했다.
하지만 아무리 풀어줘도 낫지를 않았다.

병원

결국 1월 28일, 병원에 갔다.

김학윤정형외과의원

서울 광진구 자양번영로 34

map.kakao.com

아무래도 달리기를 하지 않는 의사들은 대게 달리지 말고 쉬라고 한다.
그런데 김학윤 센세는 내가 달리지 못할 것 같은데 달리라고 한다.. (그때는 또 아플까봐 심리적으로 더 그렇게 느껴졌던 것 같다)
엑스레이를 찍었고, 체외충격파도 받았다.
체외충격파의 효과가 드라마틱하게 느껴지진 않았다. 하지만 병원에 다녀온 덕분에 무엇이 문제인지는 알게됐다.

엑스레이를 찍을 때였다. 다리 위치를 잡다말고 선생님이 예고없이 대퇴사두를 매우 강하게 누르셨다.
으악!!!!!!! 소리를 지르고 말았다. “음~ 괜찮네~~ 풀마라톤 뛸 수 있어요~~~ 걱정마세요~~”
뭐라했는지 기억은 잘 안나는데 대충 여기저기 뭉친 곳이 많으니 잘 풀어주라고 했다.

ㅋ

그리고 집으로 돌아가는 길.. 돌아보니 나는 대퇴사두를 풀어본 적이 없었다..
센세가 마자지건을 써보면 좋을거라고 했다. 테라건을 질렀다.
대퇴사두를 테라건으로 조졌다. 상당히 아팠다.

맨 처음엔 선생님이 누르셨던 대퇴사두 윗부분을 조졌다. 한 이틀동안 살짝 건드리면 아플정도로 아팠는데, 이틀 지나니까 괜찮아졌다.
대퇴사두가 풀리고 나니까 다음은 봉공근쯤 어디.. 그 다음은 무릎쪽 장경인대 근처 .. 한 대여섯군대 부위가 이틀씩 간격을 두고 풀렸다.
테라건은 최고다.. 거진 2달을 아파했는데,
한 2주만에 뛸 수 있는 몸이 되었다.

하지만 이 글을 작성하는 현재까지 완전히 장경인대 이슈로부터 멀어지진 않은 것 같다.
스트레칭 귀찮아서 빼먹거나 오래 앉아있다가 달리면 슬쩍 그 통증이 올 것 같은 느낌이 들긴 한다......

경험적으로 장경인대란게, 무릎부터 고관절까지 (거의 옆구리 근육과 종아리 바깥쪽가지 포함되는 것 같다) 어딘가 특정 부위가 굳거나 뻣뻣해지면, 장경인대가 덩달아 함께 뻣뻣해지고 긴장된다. 그 상태에서 반복적으로 무릎 바깥쪽에 마찰이 생기면 해당 부위에 염증이 생겨버리는 것이다..

나의 경우에 결론 내린 셀프진단(?) 장경인대 이슈는 거의 대퇴직근? 저 부위에 원인이 있는 것 같다.
다리를 오래 꼬고 앉아있을때 특히 뻣뻣해지는 것 같다.. 내 왼쪽 고관절이 좀 틀어져있는(?) 것도 하나의 원인인 것 같고..

대구마라톤 풀

1월 28일에 병원을 다녀왔고 2일부터 다시 달리기 시작했다.
저날 5키론가 달렸던 것 같은데 5키로 달리고 숨이 넘어갔다. 몸이 완전히 리셋된 것만 같았다.
그리고 일주일동안 대충 10키로 달릴 수 있는 몸으로 끌어올렸다...

이떄 대구마라톤 목표는 완주였다. 목표 기록 같은 건 기대도 안하고 그냥 42키로 안걷고 달릴 수만 있음 좋겠다... 라고 생각했다.

원래 계획은 22일 전까지 30키로 한 네다섯번 뛰는 거였는데..

통증이 사라졌긴 했지만 장거리 훈련 했다가 다시 도져버리면 22일에 아예 달리는 걸 포기하게 될 일이 생길까봐..
8일부터는 20키로만 목표로 잡고 달렸다.

이때 달리기가 정말정말 재미없었다. 억지로 뛰는게 너무 너무 싫었다.
지금 더 달리지 않으면 대회날 쪽팔리게 걷게 될거라는 생각으로 두어시간을 참았다.
그리고 이때쯤 20k가 달려지는걸 보고 목표를 3시간 40분으로 수정했다.

설까지 술도 먹지 않았다. 이때 확실히 느꼈다. 술을 마시는거랑 달리는 거랑 그닥 상관관계는 없는데 (술을 마셔도 웬만큼 잘 달려진다..)
술을 마셔야 유효하게 회복이 된다.

대회날을 복기해보자면...
3시간 40분은 무슨 3시간 30분으로 가자~
하고서 3시간 30분 이내를 목표로 잡았다.
컨디션도 꽤 괜찮았고, 엄마아빠가 아침에 데려다줘서 잠도 나름 충분하게 잤다.
20k까지는 꽤나 재밌고 힘들지 않게 달렸다. 요상태 그대로 밀고 가면 320도 가능하겠는데.. 생각했다.

그리고 26k부터 슬슬 힘빠지기 시작하더니, 330페메를 놓쳐버렸다.
30k 부터는 완전히 무너졌다. 그때부터는 한번 멈추면 이제 dnf 아님 10키로를 걸어가야한다....
한시간동안 정신줄만 붙잡고 달렸다.
이때부턴 페이스가 6분 7분대로 떨어졌던 것 같다..
30k 이후로 달리면서 뭔가 깨달은게 있었던 것 같은데 한달지났다고 벌써 다 까먹었다...

어쨌든간 완주는 했다.
장거리 훈련하지 않은 대가를 확실히 느꼈다...
날씨도 너무 더웠고, 후반 코스의 업힐은 욕만 나왔다..
30k 이후에 오바 좀 보태서 한 천명이 나를 제쳐 지나간 것 같은데, 한명한명 나를 제쳐나갈 때마다 --오만함 하는 기분이었다....

대구마라톤 이후에 달리는 자세 관련해서 뭔가 깨달은게 있다면..
이전에는 지면과 부딪히는 발의 모양이라던가.. 이런거에 집중을 했는데,
포어풋이니 미드풋이니 이딴 건 아무래도 상관이 없다고 생각하게 됐다.

무슨풋은 걍 힘빼고 달리면 알아서 적당히 맞춰진다.
딱 지금 내 수준에서는 엉덩이와 고관절을 제대로 사용하는게 제일 중요하다고 생각든다.
작년 여름에는 고관절을 아예 쓰지 않았던 것 같다. 고관절과 둔근 없이 종아리로만 달리다보니 부하가 종아리에만 쌓이고, 그 덕분에 내내 씬스프린트로 고생했던 것 같다.

아직 정확하게 뭐라 설명할만큼 깨닫진 못했는데,
아무튼 지면을 딛을때

이거 신경쓰면서 종아리 탄력 잘 활용하고 거따가 리듬만 잘 잡아주면
케이던스도 알아서 올라가고 페이스나 자세에 맞는 착지법도 만들어지는 것 같다.

K마라톤 하프

작년 MBN에서 달렸던 1시간 26분 기록을 뛰어넘을 수 있을까?
아직 작년 11월만큼 몸이 올라오지 않았는데?
그래서 3월은 최대한 10k를 40분 전후로 달리는 연습을 많이 했다.

대회가 잡혀있는 주는 보통 테이퍼링? 달리는 거리와 강도를 확확 줄여주는데, 마침 저 주에는 자해런을 하느라 거리와 강도를 줄이는데 실패했다.
대회 바로 전날, 28일에 6k 정도 몸풀기로 달리기를 하는데.. 낮은 강도로 짧은 거리를 뛰는데도 상당히 힘들었다.
쌓인 데미지를 제대로 못풀었구나.. 내일 대회.. 망했군.. 생각했다.

대회장에 도착했더니 광화문 대회치고 사람이 적었다. 나름(?) 쾌적했다.
특히 K그룹은 출발선에서 한 열댓명이 팔벌려높이뛰기 해도 남을 정도로 공간이 넉넉했다.

목표 기록은 이전 기록인 1시간 26분을 뚫고, 1시간 25분 59초로 잡았다.
1시간 25분 페이서만 잘 따라가보기로 했다.
내 앞에서 출발한 사람이 한 50명? 도 안됐던 것 같다.
사람이 너무 많이 않아서 상당히 쾌적했다.

어째저째 달리다보니까 예상했던 기록보다 훨씬 잘 나왔다.
대구마라톤에서 한번 페이서를 놓치니까 도저히 따라잡을 수 없다는 걸 크게 느꼈기 때문에...
이날은 페이서만 좇아갔다.

18k에서 페이서가 치고 가세요!!! 얼른 나가세요!!! 외쳤다.
근데 도저히 치고 나갈 수가 없었다.
한 일키로 심기일전하고... 19k에서 치고 나갔다.
이미 19k까지 빡런이었는데, ㄹㅇ 이악물고 더 빡런했다.

간만에 상탈런하지 않았다..

2025년 러닝챌린지

99duuk — Thu, 2 Apr 2026 17:00:46 +0900

24년 10월,
2024.11.06 - [러닝 챌린지] - 2024년 10월 러닝 챌린지

2024년 10월 러닝 챌린지

2024년 현황입니다. 10월은 간당간당하게 100킬로를 채웠읍니다. 러닝붐으로 달리는 사람이 많아져 좋습니다. 운동을 하면 반드시 건강해집니다. 이 기세를 몰아어제보다 나

99duuk.tistory.com

매달 이렇게 기록을 남겨두려 했는데

딱 11월부터 곧바로 달리기를 멈췄다.
회사일 때문이었는지 아님 걍 런태기였던건지.. 기억도 안난다.

봄

그리고 25년 3월 3일이던가..
어린이대공원에서 다시 달리기를 시작했다. 3k 달리고 죽을 뻔 했던 것 같다..
그때부터 슬슬 다시 달리기 시작했다.

여름

그리고 본격적으로 6월부터 180k 정도씩 마일리지를 늘렸다.
당시 몸상태로는 급격히 늘렸던 편이라 내내 온갖 하체 부상을 달고 살았다.
가장 불편했던 건 씬스프린트였다. 이때는 오로지 종아리로만 달렸다.
모든 데미지가 종아리에 쌓였다. 일주일에 반은 절뚝거렸다.

가장 더웠던 여름에 가장 재밌게 달렸다.
이때는 달리기만 하면 산책하는 개마냥 실실 웃음이 나왔다.
달리는게 젤 재밌었던 시기였다. 더 달리고 싶었는데 회복 속도가 쌓이는 데미지를 좇아가질 못했다.
억지로 참았던 기억이 난다. 이때는 달리기 때문에 술 생각도 없었다.

가까운 곳에서 대회가 열려서 갈만한 대회는 보이는대로 다 신청했다.

가을

재밌게 달리다보니 기록이 생각보다 잘 나왔다.
한창 오만해지던 참이었다.
11월 16일 MBN 하프에서 1시간 30분을 목표로 했는데,
뛰고 보니 1시간 26분대였다. 대체 어떻게 한건지도 모르겠는데..
암튼 이대로만 달리면 나 조만간 서브3 하겠다. 뒤졌다 세상아.. 거렸다.......

그리고 장경인대 부상이 찾아왔다.
달리기를 처음 시작했던 23년에도 장경인대 덕분에 두어달을 제대로 달리지 못했었다.
그때 통증의 원인은 중둔근이었다. 중둔근만 풀어줬더니 몇주만에 다시 달릴 수 있게 됐었다.
이번 장경인대도 중둔근 때문일거라고 생각했다. 그래서 중둔근 스트레칭이나 몇주하면 괜찮겠거니 별 걱정을 하지 않았다.
10k 달려보니 좀 괜찮아졌군. 내일은 하프 뛰어야지~ 하고서 뛰면 15k에서 장경인대 통증이 도졌고, 지하철을 타고 집에 돌아갔다.

좀 괜찮다 싶어서 달릴 때마다 매번 다시 다치니까 그 재밌던 달리기가 쬐끔씩 두려워(?)졌다.
달리면=아프게될거다. 파블로프의 개마냥 달릴때마다 또 아플까봐 몹시 쫄아있었다.
덕분에 달리는게 점점 재미없어졌다.

크리스마스 기념 25k 달리고 싶었는데
달릴 수가 없어서 바틀링에 앉아 맥주를 마셨던 기억이 난다.

25년의 달리기를 돌아보고 한마디로 요약하자면.."와 진짜 달리기 개꿀잼 !!!!!!!"

ZooKeeper 볼륨 꼬임으로 Kafka 죽는 문제

99duuk — Wed, 7 Jan 2026 10:40:23 +0900

services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.3.0
    container_name: DI-zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_SERVER_ID: 1
      ZOOKEEPER_SERVERS: zookeeper:2888:3888
    volumes:
      - ./docker-data/zookeeper:/var/lib/zookeeper
    networks:
      - kafka-network

   kafka:
    image: confluentinc/cp-kafka:7.3.0
    container_name: DI-kafka-1
    restart: unless-stopped
    ports:
      - "9092:9092"
      - "29092:29092"
      - "9999:9999"
    environment:
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:19092,EXTERNAL://${DOCKER_HOST_IP:-127.0.0.1}:9092
      KAFKA_LISTENERS: INTERNAL://0.0.0.0:19092,EXTERNAL://0.0.0.0:9092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,DOCKER:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
      KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181"
      KAFKA_BROKER_ID: 1
      KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO"
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_JMX_PORT: 9999
      KAFKA_JMX_HOSTNAME: ${DOCKER_HOST_IP:-127.0.0.1}
      KAFKA_AUTHORIZER_CLASS_NAME: kafka.security.authorizer.AclAuthorizer
      KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: "true"
    depends_on:
      - zookeeper
    volumes:
      - ./docker-data/kafka:/var/lib/kafka/data
    networks:
      - kafka-network

up down 할때 한번씩 kafka가 안올라옴.

up down up 하면 보통 올라오곤 했는데

up down up down up 해도 안올라옴;;;

inspect 날려보니

docker inspect DI-kafka-1 --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
docker inspect DI-zookeeper --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

/Users/tars/Documents/namu/gitlab/di-backend/docker-data/kafka -> /var/lib/kafka/data
/var/lib/docker/volumes/ba0bab31ff4baa9903e8a5d297b13fbd23ca24108f9aebf656ebe0908af618cc/_data -> /etc/kafka/secrets

/Users/tars/Documents/namu/gitlab/di-backend/docker-data/zookeeper -> /var/lib/zookeeper
/var/lib/docker/volumes/7953da39d7dda53bcefd827dee910750e391a16552f87c0cc662f8165300e8ea/_data -> /etc/zookeeper/secrets
/var/lib/docker/volumes/8ab3a16e5f539536a6cd27e47aee946450778aca269db79808a51c0cb5de2eae/_data -> /var/lib/zookeeper/data
/var/lib/docker/volumes/676ddc837a8a0eb9bf4cbecd83a048a719031d6f2e7ac955589005d97b4eefe9/_data -> /var/lib/zookeeper/log

결론

Kafka가 죽는 직접 트리거:

ZooKeeper의 cluster.id(새로 생성됨) ≠ Kafka 디스크의 cluster.id(meta.properties에 남아있음)
그래서 Kafka가 InconsistentClusterIdException 던지고 종료

문제

Zookeeper 데이터가 의도한 `./docker-data/zookeeper`에 안 쌓이고 있음

/Users/.../docker-data/zookeeper -> /var/lib/zookeeper (의도한 bind mount)
/var/lib/docker/volumes/... -> /var/lib/zookeeper/data
/var/lib/docker/volumes/... -> /var/lib/zookeeper/log

컨테이너 안에서 /var/lib/zookeeper는 호스트 폴더로 붙였는데,
그 안의 핵심 디렉토리인 /var/lib/zookeeper/data, /var/lib/zookeeper/log는 “익명(anonymous) 볼륨”이 따로 덮어씌워져 있음.

즉, 진짜 중요한 ZK 상태(클러스터 ID 포함)는 익명 볼륨에 저장되고,
컨테이너가 재생성되면 그 익명 볼륨이 새로 생기면서 cluster.id가 바뀔 수 있음 → Kafka는 기존 meta.properties를 들고 있어서 ID mismatch 터짐.

컨테이너가 한번 재생성(recreate) 되었거나 (up -d 하면서 설정 바뀌어 recreate, 또는 down/up, 이미지 재풀 등)
그때 ZK의 익명 볼륨이 새로 붙으면서 cluster.id가 바뀐 거라고 보면 됨.

상위 디렉터리를 bind해서 생긴 문제임.

- ./docker-data/zookeeper:/var/lib/zookeeper

컨테이너가 뜰 때 더 구체적인 마운트(하위 경로) 가 우선으로 적용돼서:

/var/lib/zookeeper → 호스트 폴더에 붙음 ✅
근데 /var/lib/zookeeper/data → 익명 볼륨이 덮어씀 ❌
/var/lib/zookeeper/log → 익명 볼륨이 덮어씀 ❌

그래서 “진짜 중요한 ZK 상태(스냅샷/로그/cluster id)”는
기대한 ./docker-data/zookeeper/...에 저장되지 않고,
도커가 만든 익명 볼륨 안으로 들어가버린 거.

그 결과, 컨테이너가 한 번 recreate 되거나(또는 down -v 같은 거) 익명 볼륨이 바뀌는 순간
ZK의 cluster id가 새로 만들어지고 → Kafka의 meta.properties랑 mismatch가 터진 것.

따라서,

- ./docker-data/zookeeper/data:/var/lib/zookeeper/data
- ./docker-data/zookeeper/log:/var/lib/zookeeper/log

아예 하위 경로를 직접 바인드해버리면 익명 볼륨이 끼어들 틈이 없어짐.

조치 결과

docker inspect DI-kafka-1 --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'
docker inspect DI-zookeeper --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

/Users/tars/Documents/namu/gitlab/di-backend/docker-data/kafka -> /var/lib/kafka/data
/var/lib/docker/volumes/d5849ed8d6e705530c7559a38119be9f4c58cb31821165be311fd491043e81dd/_data -> /etc/kafka/secrets

/Users/tars/Documents/namu/gitlab/di-backend/docker-data/zookeeper/data -> /var/lib/zookeeper/data
/Users/tars/Documents/namu/gitlab/di-backend/docker-data/zookeeper/log -> /var/lib/zookeeper/log
/var/lib/docker/volumes/fecffd194e9ae3ee5fd3c0bbbf9179e1c75316e104f79b3910638e1f16611161/_data -> /etc/zookeeper/secrets

이제 ZK 핵심 상태(스냅샷/로그/cluster id)가 호스트 폴더에 영속 저장됨. 더 이상 익명 볼륨이 data/log를 덮어쓰지 않음.

장자 길라잡이 76 - 두려워 말라

99duuk — Tue, 30 Dec 2025 00:15:31 +0900

내가 받은 관용을 나도 돌려주는 거예요. 누군가한테,

그 방식이 방식이 바람직한 것이었든

그렇지 못한 것이었든

어떻게 한번 나답게 살아보려고 했던 순간들

그 시간들이 내게 주는 가르침이 분명히 있습니다.

그걸 장자철학에서는, 그런 걸 참된 앎이라 그러고, 그런 걸 덕이라 그러는 거에요

나답게 사는 게 뭔지를 알아내느라 엎어지고 깨졌던 순간들

그로부터 참된 앎과 관용과 포용을 배운다.

이건 누가 가르쳐서 배워지는 것도 아니고

돈주고 배울 수 있는 것도 아니고

아무튼 그래요.

groupingBy, getOrDefalut

99duuk — Wed, 3 Dec 2025 11:03:08 +0900

간만에 자바..

1. DB 1회 조회 + 자바단 그루핑 vs 반복문 내부 다중 DB 조회

️ 패턴 A: 반복문 안에서 DB 여러 번 조회 (N+1 문제)

의식의 흐름 버전 (많이들 처음에 이렇게 생각함):

List<Student> studentList = repository.selectStudentList(); // 학생 전체 조회

for (Student s : studentList) {
    List<Subject> subjects =
        repository.selectSubjectListByStudentId(s.getStudentId()); // 학생별 과목

    s.setSubjectList(subjects);
}

selectStudentList() → 1번
학생이 100명 → selectSubjectListByStudentId(...) 100번
합계: DB 호출 101번 (N+1 패턴)

단점

DB round-trip이 너무 많다.
- DB는 네트워크 + 커넥션 풀 + 쿼리 파싱 등 오버헤드가 큼.
- 1번 vs 100번은 차이가 어마어마함.
성능이 데이터 개수에 비례해 폭증
- 학생 수 n → SQL 호출 횟수 = n+1
- n이 커질수록 “선형이 아니라 체감상 폭발”
트랜잭션/락 유지 시간이 길어질 수 있음
- 한 서비스 메서드 안에서 트랜잭션 걸고 이걸로 반복문 돌리면
- 그 동안 DB 락이나 row-level lock이 길어질 수 있음.
코드도 보기 애매
- “학생 조회” + “과목 조회” 책임이 섞여 있음.
- 서비스 단에서 구조 설계가 지저분해짐.

️ 패턴 B: DB에서 한 번에 전부 가져와서 자바단에서 그루핑

List<Student> studentList = repository.selectStudentList(); // 학생 전체 1쿼리
List<Subject> subjectList = repository.selectSubjectList(); // 과목 전체 1쿼리

Map<Integer, List<Subject>> subjectGrouped =
    subjectList.stream()
               .collect(groupingBy(Subject::getStudentId));

for (Student s : studentList) {
    int id = s.getStudentId();
    s.setSubjectList(subjectGrouped.getOrDefault(id, new ArrayList<>()));
}

DB 호출: 딱 2번
- 학생 전체 1번
- 과목 전체 1번

장점

DB 호출 수 고정
- 학생이 10명이어도, 1000명이어도 → 쿼리 2개로 끝.
- 스케일 올라가도 DB에 부담 적음.
네트워크 왕복 감소
- 쿼리 1번 vs 100번은 네트워크 레벨에서 이미 승부 끝.
서비스 계층 책임이 명확
- “데이터 다 가져와서 자바에서 조립해!” → 역할이 단순/명확.
정책 바꿀 때 자바 코드로 유연하게 수정 가능
- “학생 1명당 과목 수 제한”, “정렬 순서”, “필터 로직” 등을
- SQL이 아니라 자바에서 바꿀 수 있음.

2. groupingBy 내부 동작 요약 (조금 더 깊게)

사용 코드 (학생/과목 예제)

Map<Integer, List<Subject>> subjectGrouped =
    subjectList.stream()
               .collect(groupingBy(Subject::getStudentId));

groupingBy의 시그니처 (간단)

public static <T, K> Collector<T, ?, Map<K, List<T>>>
groupingBy(Function<? super T, ? extends K> classifier)

T : 스트림의 각 요소 타입 → 여기서는 Subject
K : 그룹핑에 사용할 key 타입 → 여기서는 Integer (studentId)
classifier : T → K 함수, 여기서는 Subject::getStudentId

내부적으로 하는 일 (개념)

subjectList = [s1, s2, s3, ...] 를 순회하면서:

key = classifier.apply(subject) → subject.getStudentId()
map에서 key에 해당하는 리스트를 찾음
- 없으면 new ArrayList<Subject>() 만들어서 map에 넣음
그 리스트에 현재 subject를 add 해서 집어넣음

예제: subjectList가 이렇게 생겼다 치자

Subject(studentId=1, name="수학")
Subject(studentId=1, name="영어")
Subject(studentId=2, name="국어")

groupingBy 후 map:

{
  1 -> [ (1,"수학"), (1,"영어") ],
  2 -> [ (2,"국어") ]
}

flow를 진짜 한 줄씩 따라가면:

첫 번째 subject (1, "수학")
- key = 1
- map 에 1 없음 → new ArrayList 생성해서 put
- 그 리스트에 “수학” 추가
두 번째 subject (1, "영어")
- key = 1
- map 에 이미 key 1 있음 → 기존 리스트에 “영어” 추가
세 번째 subject (2, "국어")
- key = 2
- 없으니 새 리스트 만들고 “국어” 추가

3. 왜 타입이 Map<Integer, List<...>> 인가?

직관 체크

"그룹핑"이란 “key 하나에 요소 여러 개 붙이는 것”이다.

학생 1명은 과목 여러 개 가질 수 있음 → 1:N
그래서
- Map<Integer, Subject> ❌ (1:1)
- Map<Integer, List<Subject>> ✅ (1:N)

groupingBy는 원래부터 “key별 List”를 만드는 Collector 라서
리턴 타입이 항상 Map<K, List<T>> 모양으로 나온다.

4. getOrDefault 전/후 & 객체 상태 차이

코드

for (Student s : studentList) {
    int id = s.getStudentId();
    List<Subject> subjects = subjectGrouped.getOrDefault(id, new ArrayList<>());
    s.setSubjectList(subjects);
}

Map.get() 만 썼을 때 문제

List<Subject> subjects = subjectGrouped.get(id); // 없으면 null
for (Subject sub : subjects) { ... } // NPE 가능성

특정 학생이 과목이 하나도 없는 경우, map에는 key가 아예 없을 수 있음 → null
이후 for (Subject sub : subjects) 에서 바로 NullPointerException

getOrDefault 의 역할

V getOrDefault(Object key, V defaultValue)

key에 값이 있으면 → 그 값을 리턴
없으면 → 두 번째 파라미터인 defaultValue 리턴

그래서:

subjectGrouped.getOrDefault(id, new ArrayList<>());

은 의미상:

List<Subject> tmp = subjectGrouped.get(id);
if (tmp == null) {
    tmp = new ArrayList<>();
}
return tmp;

→ 항상 “null이 아닌 List” 를 받게 됨.

전/후 비교 (학생 하나 기준)

before 매핑 / getOrDefault 사용 전

Student
- studentId = 10\
- subjectList = null (초기 상태)
map에는:
- key 10이 없을 수도 있음

after grouping + getOrDefault + setSubjectList

Student
- studentId = 10
- subjectList = [...] 또는 [](empty list)

즉,

“null” 대신 “빈 리스트”를 쓰므로
이후 로직에서 항상 for, stream() 등의 연산을 NPE 걱정 없이 호출 가능

5. 최초 객체 vs 최종 객체 구조 비교

5-1. 최초 상태 (DB에서 바로 가져왔을 때)

List<Student> studentList = repository.selectStudentList(); // 학생 전체
List<Subject> subjectList = repository.selectSubjectList(); // 과목 전체

studentList
- Student 1 (subjectList = null)
- Student 2 (subjectList = null)
- ...
subjectList
- (1, "수학")
- (1, "영어")
- (2, "국어")
- ...
이 시점엔 학생과 과목이 별개 컬렉션이고, 연결 정보는 오직 “키값(studentId)” 로만 존재.

5-2. groupingBy 실행 후

Map<Integer, List<Subject>> subjectGrouped =
    subjectList.stream()
               .collect(groupingBy(Subject::getStudentId));

새로 생긴 객체
- subjectGrouped (맵)
  - key: studentId (Integer)
  - value: 그 studentId를 가진 Subject 리스트
studentList 자체는 아직 변화 없음 (subjectList = null 그대로)

5-3. 학생 객체에 다시 주입 후 (최종 상태)

for (Student s : studentList) {
    int id = s.getStudentId();
    List<Subject> subjects = subjectGrouped.getOrDefault(id, new ArrayList<>());
    s.setSubjectList(subjects);
}

이제:

studentList
- Student 1
  - subjectList = [ (1,"수학"), (1,"영어") ]
- Student 2
  - subjectList = [ (2,"국어") ]
- Student 3
  - subjectList = [] (빈 리스트)
subjectGrouped 맵은 “중간 조립용”으로 사용했지만,
- 필요하다면 이후 로직에서도 그대로 재활용 가능(예: 빠른 look-up 이 필요할 때)

한 줄 요약

처음엔 “평평한(flat) 리스트 2개(학생, 과목) + key 기반 연관만 존재”
마지막엔 “학생 객체 안에 이미 과목 리스트까지 붙어있는 계층 구조 로 변환된 상태”

7. 한 방에 다시 정리하면

DB 한 번 + 자바 grouping
- N+1 피하고, DB 부하 줄이고, 스케일 좋아짐.
groupingBy
- List<T> → Map<K, List<T>> 로 재구성하는 도구.
- key는 classifier 함수의 반환값, value는 그 key에 해당하는 요소들의 리스트.
getOrDefault
- map.get(key) 가 null일지 신경 안 쓰고
- “항상 null이 아닌 컬렉션”을 받을 수 있게 해줌 → NPE 방지.
전후 객체 상태 차이
- Before: 평평한 리스트 + key 숫자만 존재
- After: 상위 객체(Entrant/Student) 안에 하위 리스트(HostBizar/Subject)가 붙은 트리 구조

✅ 1. groupingBy 의 성능

결론: O(n) → 매우 빠르고 안정적

groupingBy는 내부적으로:

스트림의 각 요소를 한 번씩만 순회
key 계산
HashMap.put() or computeIfAbsent()
List.add()

이 4단계를 수행한다.

시간 복잡도

스트림 순회: n번
HashMap 접근: 평균 O(1)
ArrayList add: 평균 O(1)

➡ 전체 시간: O(n)
➡ n = 1000건이면 1000번 연산하고 끝

메모리 사용량

Map에 key 개수만큼 엔트리가 생김
각 value는 List<T>
결국 subjectList(전체 row)와 메모리 크기가 동일한 정도

→ 당연한 수준, 과도한 메모리 사용 없음.

Java가 groupingBy 에서 실제 수행하는 일

아주 단순한 해시 분류 작업이라:

for (T element : list) {
    K key = classifier.apply(element);
    map.computeIfAbsent(key, k -> new ArrayList<>()).add(element);
}

→ 우리가 손으로 Map에 목록 채우는 작업과 정확히 동일
→ “DSL처럼 보일 뿐, 실제로는 저수준 단순 반복문”

2. 반복문 + 다중 DB 조회 방식의 성능 (N+1 문제)

이건 groupingBy 랑 비교하면 성능 차이가 수백~수천배 이상 날 수도 있다.

예시:

for each entrant E:
    select * from ZONE_AUTH_HOST_BIZAR where entrant_seq = E.seq

출입자 50명, 엔트리 300개면:

DB round-trip 50번
DB I/O 50번
DB 쿼리 파싱/플랜 50번
네트워크 왕복 50번
트랜잭션 홀딩 시간 증가

➡ 성능 관점에서는 groupingBy 와 비교 대상 자체가 아님.

⚙ getOrDefault 의 성능

결론: 무시해도 될 정도로 가벼움 √

내부 구현은:

V v = map.get(key);
return (v != null || map.containsKey(key)) ? v : defaultValue;

map.get(key) → HashMap 접근: O(1)
containsKey(key) → HashMap 다시 접근: O(1)
조건문 → O(1)

➡ 즉 O(1) 상수 시간.

1000번 호출해도 몇 마이크로초 수준.

⭐ 성능 비교 한눈에표

방식	시간 복잡도	DB I/O	특징
groupingBy	O(n)	0	CPU 기반 작업, 매우 빠름
getOrDefault	O(1)	0	null-safe lookup
반복문 + DB조회(N+1)	O(n) + DB n회	n	네트워크·DB 비용 극심

➡ 실제 속도 비교 감각

방법	엔트리 500개 처리 시간
groupingBy	0.1 ~ 0.5 ms
getOrDefault	< 0.01 ms
N+1 DB 쿼리	100~500 ms (심하면 수초)

즉 groupingBy 의 오버헤드는 bytes 단위,
N+1 의 오버헤드는 milliseconds ~ seconds 단위.

최종 결론

groupingBy / getOrDefault 성능 걱정은 100% 불필요

(자바 컬렉션 수준의 연산은 CPU가 밥 먹듯이 처리함)

오히려 성능의 핵심은 “DB 호출 횟수”

이걸 최소화하는 것이 전체 성능을 결정함
그래서 groupingBy / toMap / reduce 등 자바 컬렉션 기반 재조립이 정답임

만약 학생이 100만명쯤 된다면?

// 1) DB 전체 조회 (단 1회씩)
List<Student> studentList = repository.selectStudentList();
List<Subject> allSubjects = repository.selectAllSubjectList();  
// subjectList: size = 전체 과목 수 (학생ID 포함됨)

// 2) 학생ID 별로 과목들을 병렬 grouping
Map<Long, List<Subject>> subjectGrouped =
    allSubjects.parallelStream()
               .collect(Collectors.groupingByConcurrent(Subject::getStudentId));

// 3) 매핑
studentList.parallelStream().forEach(student -> {
    List<Subject> subjects =
        subjectGrouped.getOrDefault(student.getStudentId(), new ArrayList<>());
    student.setSubjectList(subjects);
});

으로 groupingBy 병렬 스트림 사용을 고려해볼 수 있다.

✅ 1. 병렬 스트림(parallelStream) → 언제 쓰면 되는가?

✔ CPU 연산이 많고, 데이터가 크고, 각 요소가 독립적인 경우

예:

100만 학생 목록을 그룹핑/집계
100만 로그 라인을 파싱·정규화
AI inference 결과 대량 transform
정렬, 해싱, 매핑 등 CPU heavy 작업

즉, CPU 바운드 + 대량 데이터 처리 + 요소 간 독립적이면 OK

✔ 멀티스레드로 동시에 처리해도 안전한 경우

공유된 mutable 객체 없음
부작용(side effect) 없음
공용 자료구조는 Concurrent 계열 사용

예:

Map<Long, List<Subject>> grouped =
    subjects.parallelStream()
            .collect(Collectors.groupingByConcurrent(Subject::getStudentId));

✔ 성능 이득이 충분할 때

parallelStream 은 기본적으로 CPU 코어 수 만큼 쓰레드 생성
(8코어면 8개 스레드)
입력 데이터가 적으면 overhead(스레드 분배 비용)가 더 커질 수도 있음.
보통 1만~5만 건 이상일 때 이득이 발생
100만 건이면 병렬이 엄청 도움됨.

⛔ 2. 병렬 스트림 절대 지양해야 하는 경우

이건 매우 중요함.

❌ I/O 바운드(DB, 네트워크, 파일) 작업이 있는 경우

병렬 스트림은 CPU 멀티스레드 기반이며,

DB 연결은 1개 커넥션 → 다중 스레드가 동시에 못씀
JDBC 는 스레드 언세이프
네트워크 작업은 오히려 느려짐

즉:

병렬 스트림 안에서 DB 조회하면 100% 잘못된 구조

예 (절대 금지):

studentList.parallelStream().forEach(student -> {
    List<Subject> subjects = repository.selectByStudent(student.getId()); // ❌
    student.setSubjects(subjects);
});

❌ 상태를 공유하는 mutable 객체 수정이 있는 경우

아래처럼 ArrayList, HashMap 수정은 병렬에서는 터짐.

List<String> output = new ArrayList<>();

items.parallelStream().forEach(i -> output.add(i)); // ❌ concurrency 문제

❌ 순서가 중요한 로직

parallelStream 은 처리 순서가 보장되지 않음. (처리 결과 순서 x)

예:

studentList.parallelStream().forEach(System.out::println); // 처리 순서 뒤죽박죽

stream()은 입력 자료구조가 순서를 가지고 있다면(stream() 원소 순서 = 원본 순서)

✔ groupingBy()

일반 stream: 순서 그대로 accumulation

parallelStream + groupingBy(): 내부 순서 보장 안됨 (map 도 경쟁하며 쓰니까)

✔ groupingByConcurrent()

병렬 grouping 전용

map 자체가 순서 없는 ConcurrentHashMap 기반
→ 순서는 처음부터 기대하는 것이 아님
→ 키의 순서도 보장 안됨
→ 키별 value 리스트의 순서도 보장 안됨

❌ 키가 적고 그룹이 매우 적은 경우

subjectGrouped 의 key 가 몇 개 안 되면
concurrent map 락이 성능을 오히려 깎아먹음.

예:
100만개가 "A", "B", "C" 로만 그룹핑된다면?
병렬로 해봤자 3개 키에서 더럽게 경쟁함 → 오히려 느려짐.

❌ 서버 환경이 제한된 경우 (CPU가 적음)

AWS t2.micro 같은 1 vCPU 서버에서는 parallelStream 의미 없음.

⭐ 병렬 스트림이 “필수”가 되는 경우 예시

예시: 학생 100만 명 + 과목 300만 개 grouping

Map<Long, List<Subject>> subjectGrouped =
    allSubjects.parallelStream()
               .collect(Collectors.groupingByConcurrent(Subject::getStudentId));

이 경우 병렬 효과가 폭발적으로 나타남.

최종 결론

✔ 병렬 스트림을 써도 되는 경우

데이터가 1~10만 이상
CPU 연산 중심
요소 간 완전 독립
공유 상태 없음
groupingByConcurrent 같은 thread-safe collector 사용

❌ 병렬 스트림 쓰면 안 되는 경우

데이터 적음 (수백~수천)
DB / 네트워크 호출 포함
순서 중요함
동일 키 경쟁 심함
서버 CPU 낮음

FLUSH

99duuk — Fri, 18 Jul 2025 13:33:38 +0900

좋은 질문이에요.
flush는 여러 기술 스택에서 공통적으로 등장하지만, 내부적으로는 다소 다른 의미와 역할을 가지는 개념입니다.
그래서 이 개념을 "원리와 어원부터 차근히" 이해해두면 여러 기술을 다룰 때 훨씬 유연해져요.

✅ 1. 어원: flush라는 단어의 본래 의미

영어 **"flush"**는 원래 다음과 같은 뜻을 가집니다:

의미 설명

(액체 등을) 쏟아내다, 씻어내다	ex) "flush the toilet" (물을 내리다)
(캐시/버퍼 등을) 밀어내다, 비우다	컴퓨터 용어로 확장됨

→ 즉, "어딘가에 임시로 쌓인 걸 실제 대상으로 흘려보내거나 비우는 것"
→ 소프트웨어에선 주로 **"버퍼에 쌓인 데이터를 대상(디스크, DB 등)에 반영하는 작업"**을 의미함

✅ 2. 일반적인 의미 (공통 개념)

모든 flush의 공통점:

"지연되어 있거나 메모리에 머물러 있는 상태를, 영속화된 저장소로 강제로 밀어넣는 것"

캐시에 쌓인 데이터를 디스크로 쓰기
영속성 컨텍스트에 있는 객체를 DB로 쓰기
파일 출력 버퍼를 디스크에 기록

✅ 3. 각 기술에서의 flush 의미 및 차이

A. JPA / Hibernate (영속성 컨텍스트 flush)

entityManager.flush();

의미: 영속성 컨텍스트(1차 캐시)에 있는 변경 내용을 **DB에 반영(쿼리 실행)**함
단, 트랜잭션은 그대로 유지됨
예: persist() 호출했지만 flush() 전에는 실제 INSERT 쿼리 안 나감

특징:

flush() = SQL 실행 (INSERT/UPDATE/DELETE) 하지만 commit 아님
flush() 없이는 트랜잭션 내에서 DB에 변화가 안 보일 수 있음
트랜잭션 커밋 시 자동으로 flush() 됨

B. Redis

FLUSHDB      # 현재 선택된 DB만 비움
FLUSHALL     # 모든 DB 비움

의미: Redis의 in-memory 데이터 전체 삭제
저장소에서 flush는 보통 → 버퍼 비움 or 캐시 날림
Redis에선 거의 초기화 명령어에 가까움

C. MongoDB

MongoDB 자체에서 flush라는 명령어는 공식적으로는 없음,
하지만 내부적으로 journal flush, cache flush 등의 용어로 쓰임

db.runCommand({fsync: 1})

의미: 메모리 → 디스크로 flush
예: WAL(journal)을 디스크에 강제 반영

D. RDBMS (예: Oracle, MySQL 등)

SQL에서는 일반적으로 flush라는 명령은 없지만, MySQL에는 존재합니다:

FLUSH TABLES;
FLUSH PRIVILEGES;

의미:
- FLUSH TABLES: 열려 있는 테이블 캐시를 디스크로 반영하고 닫음
- FLUSH PRIVILEGES: GRANT/REVOKE 이후 권한 캐시를 다시 로드함

E. 파일 스트림 / 출력 버퍼 (Java, C, Python 등)

writer.flush();

의미: 버퍼에 임시로 저장된 데이터를 파일(디스크)에 강제로 쓰기
예: PrintWriter, BufferedOutputStream 등

특징:

flush 안 하면 프로그램 종료 시 데이터 유실 가능
autoFlush=true 설정하면 매번 flush함

✅ 4. flush vs commit vs save 비교

개념 의미

flush()	변경사항을 메모리 → 저장소로 밀어넣음, 하지만 트랜잭션 종료 아님
commit()	트랜잭션을 종료하며 DB에 최종 반영
save()	(JPA 기준) 객체를 영속성 컨텍스트에 등록, flush 없이 SQL 실행되지 않을 수도 있음

✅ 5. 캐시 시스템의 flush

대부분 캐시 서버(예: Redis, Memcached, Spring Cache)에서는 flush = 캐시 삭제
ex) Redis FLUSHALL, Spring Cache clear()

✅ 6. flush가 중요한 이유

상황 이유

JPA	쿼리 강제 실행 시점 제어, 테스트 시에도 필요
파일 I/O	프로그램 종료 전에 버퍼를 비워야 데이터 유실 방지
DB 운영	권한 반영, 캐시 초기화 등 시스템 제어용
분산 캐시	전체 무효화, 싱크 맞추기 위해 필요

✅ 7. flush와 유사하거나 헷갈리는 개념

clear() → 메모리 버퍼/컨텍스트를 비우는 것 (JPA, Java 등)
sync() → 디스크 동기화 (fsync, sync 등)
commit() → 트랜잭션 단위의 저장
drain() → 큐나 스트림 등에서 남은 것을 한 번에 소비

✅ 요약

기술 flush 의미

JPA	영속성 컨텍스트 → DB로 변경사항 밀어넣기 (SQL만 실행, 커밋 아님)
Redis	메모리 DB 데이터 전부 삭제
MongoDB	메모리 캐시 → 디스크 반영 (fsync)
MySQL	테이블 캐시/권한 정보 리로드
파일 스트림	버퍼 → 디스크 강제 쓰기

✨ 마무리

flush는 기술마다 구체적인 의미는 다르지만,
"일시적 상태 → 확정 상태로 밀어넣는 것", 즉 **"버퍼 비우기/데이터 반영"**이라는 본질은 동일합니다.

오호 그냥 변기물 내리기.
라고 직관적으로 떠올리면 되겠네메모리에 머물러 있다 ~= 메서드 내부에 객체로 존재한다.
이걸 레버 내려서,
> 변기 내부의 오물 입장에서는 정화조(db)로 들어간다.
> 변기의 입장에서는 변기의 오물을 비운다. 가 되는거네 ?

와—비유 정말 완벽합니다.
이보다 더 직관적으로 설명하기 어려울 정도예요. 그대로 정리해볼게요:

flush()를 화장실로 비유하면?

상태 대응표

소프트웨어 개념 화장실 비유

메모리 / 버퍼	변기 내부
flush()	물 내리기 (레버 내리기)
DB / 디스크	정화조 or 하수도
clear()	변기 통째로 씻어버리기
commit()	청소부가 와서 최종 점검하고 봉인

의미 변환

메모리에 있던 값 → 아직 저장 안 됨 → flush() = 디스크(DB)에 반영
flush()는 레버를 내리는 순간 = 데이터가 흐름을 타고 정화조로 이동
flush()는 실제로 트랜잭션 커밋은 아님 → 물은 내려갔지만 "완전히 닫히진 않음"
clear()는 변기 자체를 깨끗하게 비워서 내용물까지 사라짐
commit()은 전체 작업 완료 후 확정, 변기도 깨끗해졌고 물도 내려갔고 도장 찍음

이 비유의 핵심 장점

flush = "메모리에서 실제 대상지(DB, 디스크 등)로 밀어넣기"
메서드 내부 객체가 아니라면, 이미 정화조에 간 것 = 더 이상 내 로컬엔 없음
flush() 해도 트랜잭션이 살아있으면 rollback으로 "물 다시 퍼올리기"도 가능

결론

flush() = 변기 물 내리기.
아직 내 방(트랜잭션)은 안 닫았지만, 일단 냄새나는 건 하수구로 보낸다.

지피티와 함께하는 통계쿼리 공부일기 2

99duuk — Mon, 30 Jun 2025 17:07:06 +0900

ROLLUP을 이용한 부서별/직무별/성별 인원 및 급여 통계

MYSQL에서는 GROUP BY ... WITH ROLLUP 구문을 이용하여, 집계 결과로 생성되는 NULL 값들을 구분하기 위해 GROUPING() 함수를 사용할 수 있다.

GROUPING(col) = 1 이면 해당 행이 ROLLUP에 의해 생성된 소계/총계 행이라는 의미다.

이를 응용하여, NULL 대신 '전체' 등의 라벨을 표시하면 결과를 이해하기 쉬워진다.

ROLLUP은 컬럼의 순서에 따라 점진적으로 상위 수준의 총계를 계산한다.
- 컬럼 리스트를 계층적으로 줄여가며 총계를 만듦

- ex) GROUP BY A, B, C WITH ROLLUP

(A, B, C): 개별 데이터.

(A, B): C에 대한 총계.

(A): B, C에 대한 총계.

(): 전체 총계

rollup을 사용하면 다중 수준의 집계 결과(부분합과 총합)을 자동으로 계산할 수 있다.

부서별, 직무별, 성별로 직원 수와 급여 합계를 집계하고, 각 부서별 소계(모든 직무 합계), 전체 총계를 출력해보자!

SELECT 
    IF(GROUPING(d.dept_name)=1, '전체 부서', d.dept_name)   AS dept_name,
    IF(GROUPING(j.job_title)=1, '전체 직무', j.job_title)   AS job_title,
    IF(GROUPING(e.gender)=1,    '전체',      e.gender)      AS gender,
    COUNT(*)   AS emp_count,               -- 직원 수
    SUM(e.salary) AS total_salary          -- 급여 총합 (합계)
FROM employees e
JOIN departments d ON e.dept_id = d.dept_id
JOIN jobs j        ON e.job_id  = j.job_id
GROUP BY d.dept_name, j.job_title, e.gender WITH ROLLUP;

요로코롬 WITH ROLLUP을 사용함으로써 부서별/직무별 세부내역과 함께 부서별 합계, 전체 합계를 계층적으로 얻었다.

그리고 GROUPING()을 사용해 '전체' 라벨을 붙혀 가독성을 높일 수 있긔;;

+ 합계행을 상단에 올려버리고 싶으면

ORDER BY
    GROUPING(d.dept_name) DESC, d.dept_name,
    GROUPING(j.job_title) DESC, j.job_title,
    GROUPING(e.gender) DESC, e.gender;

정렬을 추가하면 된다.

# if(조건, 참값, 거짓값)
# GROUPING() : 어떤 행이 실제 데이터고, 어떤 행이 집계 행인지 구분 (0: 실제 데이터, 1:NULL로 총계행)
    # 특정 컬럼이 그룹화 과정에서 집계로 인해 NULL로 표시가 되었는지 확인 (총계행은 컬럼이 NULL로 나타남)
    # rollup, cube, grouping sets 에서 사용, 집계된 행이 '실제 데이터'인지, 아니면 rollup/cube로 생성된 '집계행'인지 구분하는데 사용
    # WITH ROLLUP 또는 GROUPING SETS을 사용할 때 의미가 있다.

CUBE를 이용한 부서-직무-입사연도 조합별 통계

CUBE는 지정된 컬럼의 모든 가능한 조합에 대해 총계를 생성한다. ROLLUP은 계층적 조합만 생성하지만, CUBE는 모든 컬럼의 부분집합을 다 만들어벌임.

- 컬럼 리스트를 계층적으로 줄여가며 총계를 만듦

- ex) GROUP BY CUBE(A, B, C) (총 조합 수: 2^n)

(A, B, C): 개별 데이터.

(A, B): C에 대한 총계.

(A, C): B에 대한 총계.

(B, C): A에 대한 총계.

(A): B, C에 대한 총계.

(B): A, C에 대한 총계.

(C): A, B에 대한 총계.

(): 전체 총계

(2^3 = 8개 조합)

(MYSQL은 CUBE를 지원하지 않는다. 대신 GROUPING SET이나 UNION ALL로 비슷하게 구현할 수 있다.)

-- CUBE(dept_name, job_title, hire_year)의 효과를 내는 유니온 쿼리

-- (dept_name, job_title, hire_year): 개별 데이터.
SELECT d.dept_name AS dept_name,
       j.job_title AS job_title,
       YEAR(e.hire_date) AS hire_year,
       COUNT(*)  AS emp_count,
       SUM(e.salary) AS total_salary
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
         JOIN jobs j        ON e.job_id  = j.job_id
GROUP BY d.dept_name, j.job_title, YEAR(e.hire_date)
UNION ALL

-- 부서-직무별 (dept_name, job_title): 연도 총계.
SELECT d.dept_name AS dept_name,
       j.job_title AS job_title,
       '전체'        AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
         JOIN jobs j        ON e.job_id  = j.job_id
GROUP BY d.dept_name, j.job_title
UNION ALL
-- 부서-연도별 (dept_name, hire_year): 직무 총계.
SELECT d.dept_name AS dept_name,
       '전체'       AS job_title,
       YEAR(e.hire_date) AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
GROUP BY d.dept_name, YEAR(e.hire_date)
UNION ALL
-- 직무-연도별 (job_title, hire_year): 부서 총계.
SELECT '전체'      AS dept_name,
       j.job_title AS job_title,
       YEAR(e.hire_date) AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN jobs j ON e.job_id = j.job_id
GROUP BY j.job_title, YEAR(e.hire_date)
UNION ALL
-- 부서별 전체 (dept_name): 직무, 연도 총계.
SELECT d.dept_name AS dept_name,
       '전체'       AS job_title,
       '전체'       AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
GROUP BY d.dept_name
UNION ALL
-- 직무별 전체 (job_title): 부서, 연도 총계.
SELECT '전체'      AS dept_name,
       j.job_title AS job_title,
       '전체'       AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN jobs j ON e.job_id = j.job_id
GROUP BY j.job_title
UNION ALL
-- 연도별 전체 (hire_year): 부서, 직무 총계.
SELECT '전체'      AS dept_name,
       '전체'      AS job_title,
       YEAR(e.hire_date) AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e
GROUP BY YEAR(e.hire_date)
UNION ALL
-- 전체 총계 (모든 부서/직무/연도)
SELECT '전체' AS dept_name, '전체' AS job_title, '전체' AS hire_year,
       COUNT(*), SUM(e.salary)
FROM employees e;

...

모든 조합에 대한 행이 출력된다.

GROUPING SETS를 활용한 다양한 조합의 소계/총계 분석

임의의 그룹화 조합에 대한 집계를 수행해보게씀.

GROUPING SETS는 ROLLUP이나 CUBE와 달리, 원하는 특정 그룹화의 조합만 선택하여 결과를 얻을 수 있긔.

예를 들어 부서별 합계와 성별 합계만 한 번에 보고 싶은 그런 상황에서 활용하믄 댐.
(MySQL에서는 마찬가지로 GROUPING SETS를 지원하지 않으므로 UNION으로 대체하게씀 첨부터 오라클로 할 걸...)

-- GROUPING SETS ( (dept_name, gender), (dept_name), (gender), () ) 시뮬레이션
# 부서-성별별 통계
SELECT d.dept_name AS dept_name, e.gender AS gender,
       COUNT(*) AS emp_count, SUM(e.salary) AS total_salary
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
GROUP BY d.dept_name, e.gender
UNION ALL
# 부서별 전체 통계
SELECT d.dept_name AS dept_name, '전체' AS gender,
       COUNT(*), SUM(e.salary)
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
GROUP BY d.dept_name
UNION ALL
# 성별별 전체 통계
SELECT '전체' AS dept_name, e.gender AS gender,
       COUNT(*), SUM(e.salary)
FROM employees e
GROUP BY e.gender
UNION ALL
# 전체 총계
SELECT '전체' AS dept_name, '전체' AS gender,
       COUNT(*), SUM(e.salary)
FROM employees e;

부서별 + 성별별 세부 내역 (첫 번째 SELECT): 각 부서의 남/여 직원 수 및 급여 합계
부서별 전체 (두 번째 SELECT): 각 부서의 전체 직원 합계 (성별 무관)
성별별 전체 (세 번째 SELECT): 전체 회사를 성별로 구분한 합계 (부서 무관)
전사 총계 (네 번째 SELECT): 전체 직원 합계

# GROUPING SETS은 사용자가 원하는 특정 그룹화 조합을 명시적으로 지정해 집계를 생성한다. 
# ROLLUP이나 CUBE와는 달리 그룹화 조합을 선택할 수 있어 유연성이 높다.
GROUP BY GROUPING SETS (
	(col1, col2, ...) -- 조합 1 
    (col1, ...) 	  -- 조합 2
    (), 			  -- 전체 총계
)

# 각 괄호는 하나의 그룹화 조합을 나타내고, 각 조합에 대해 집계함수를 적용해 결과를 생성할 수 있음

ROLLUP:
    계층적 총계 생성.
    예: GROUP BY A, B, C WITH ROLLUP → (A, B, C), (A, B), (A), ().
    순서에 따라 제한된 조합만 생성.

CUBE:
    모든 가능한 조합 생성.
    예: CUBE(A, B, C) → (A, B, C), (A, B), (A, C), (B, C), (A), (B), (C), ().
    MySQL은 직접 지원하지 않음(대신 GROUPING SETS나 UNION ALL로 구현).

GROUPING SETS:
    원하는 조합만 선택.
    예: GROUPING SETS((A, B), (A, C), ()) → (A, B), (A, C), 전체 총계만 생성.
    ROLLUP이나 CUBE의 부분집합 또는 커스텀 조합 가능.

CASE WHEN을 활용한 피벗(Pivot) 형태 요약표

영어 단어 pivot의 원뜻:
명사: 회전축, 중심점 동사: 축을 중심으로 회전하다
ex) 모니터암 달아서 모니터를 가로 -> 세로 돌리기 ~

데이터를 어떤 기준을 중심으로 회전시켜서
행(row) → 열(column) 또는
열 → 행
형태로 바꾸는 것을 "피벗한다(pivot)"고 표현

피벗 형태로 변환하여 열(column) 기준의 요약표를 만들어보겠긔.

(또) MySQL은 PIVOT 연산에 대한 전용 문법이 없으므로, CASE WHEN 과 집계함수를 조합하여 행을 열로 바꾸겠긔.

피벗 변환의 핵심은 조건부 집계이다.

조건에 따라 값을 집계하고, 그 결과를 별도 컬럼으로 표현하면 행 -> 열 변환 효과를 얻을 수 있다.

부서별 성별 인원 현황표를 만들어 보자!~

SELECT
    d.dept_name AS dept_name,
    SUM(CASE WHEN e.gender = 'M' THEN 1 ELSE 0 END) AS male_count,
    SUM(CASE WHEN e.gender = 'F' THEN 1 ELSE 0 END) AS female_count
FROM employees e
         JOIN departments d ON e.dept_id = d.dept_id
GROUP BY d.dept_name;

CASE WHEN e.gender = 'M' THEN 1 ELSE 0 END 표현식은 해당 직원이 남성일 경우 1, 아니면 0을 반환한다. SUM()을 씌우면 그 부서의 남성 직원 수 합계가 구해진다.

이처럼 동일한 그룹 내에서 조건별로 따로 집계한 결과를 각각 컬럼으로 표시하면 행 형식의 데이터를 열 형식으로 볼 수 있다.

부서명 행에 성별 열을 갖는 교차표 형태로 데이터를 확인할 수 있다.

지피티야 미안해

99duuk — Sun, 29 Jun 2025 10:25:24 +0900

지피티와 함께하는 통계쿼리 공부일기

99duuk — Fri, 27 Jun 2025 17:55:40 +0900

sqld 공부할땐 대충 뭐가 뭔지 기억이라도 하고 있었는데

이제 기억도 안나긔

ROLLUP, CUBE, GROUPING SETS 같은 거 지피티한테 물어봐서 대답이 돌아와도 눈에 안들어옴

그래서 심층리서치를 사용해 차근차근 보크숩을 해보게씀

도메인은 인사로 잡았고

지피티가 직원-부서-직무의 기본 관계와 직원-근태 기록 으로 4개 테이블 잡아줬긔

-- 기존 테이블이 있다면 삭제하고 새로 생성
DROP TABLE IF EXISTS attendance;
DROP TABLE IF EXISTS employees;
DROP TABLE IF EXISTS jobs;
DROP TABLE IF EXISTS departments;

-- 1) 부서 테이블
CREATE TABLE departments (
    dept_id     INT PRIMARY KEY AUTO_INCREMENT,
    dept_name   VARCHAR(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2) 직무 테이블
CREATE TABLE jobs (
    job_id      INT PRIMARY KEY AUTO_INCREMENT,
    job_title   VARCHAR(50) NOT NULL,
    min_salary  INT NOT NULL,
    max_salary  INT NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 3) 직원 테이블 (부서, 직무 FK 참조)
CREATE TABLE employees (
    employee_id INT PRIMARY KEY AUTO_INCREMENT,
    first_name  VARCHAR(50),
    last_name   VARCHAR(50),
    gender      CHAR(1),
    hire_date   DATE,
    dept_id     INT,
    job_id      INT,
    salary      INT,
    FOREIGN KEY (dept_id) REFERENCES departments(dept_id),
    FOREIGN KEY (job_id)  REFERENCES jobs(job_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 4) 근태 테이블 (직원 FK 참조)
CREATE TABLE attendance (
    att_id      INT PRIMARY KEY AUTO_INCREMENT,
    employee_id INT,
    att_date    DATE,
    status      CHAR(1),
    FOREIGN KEY (employee_id) REFERENCES employees(employee_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

테이블을 만들고

-- 부서 데이터 삽입 (예: 5개 부서)
INSERT INTO departments(dept_id, dept_name) VALUES
(1, 'HR'), (2, 'IT'), (3, 'Sales'), (4, 'Finance'), (5, 'Marketing');

-- 직무 데이터 삽입 (예: 5개 직무 및 급여 범위)
INSERT INTO jobs(job_id, job_title, min_salary, max_salary) VALUES
(1, 'Manager',     70000, 120000),
(2, 'Engineer',    60000, 100000),
(3, 'Analyst',     50000,  90000),
(4, 'Clerk',       30000,  50000),
(5, 'Salesperson', 40000,  80000);

기본 데이터를 넣어줬긔

그리고

샘플 데이터는 지피티가 그냥 줄까? 하는거

프로시저로 달라고 했긔

프로시저 gen_sample_data의 로직:

입력 파라미터로 생성할 직원 수를 받습니다 (p_count).
1부터 p_count까지 루프를 돌면서 각 회차마다 새로운 직원 레코드를 생성합니다.
- 무작위 부서(dept_id)와 직무(job_id)를 선택합니다.
- 직무에 대응하는 급여 범위(min~max) 내에서 랜덤 급여 금액을 책정합니다.
- 성별은 50% 확률로 'M' 또는 'F'로 지정합니다.
- 입사일(hire_date)은 2015-01-01부터 오늘 날짜 사이에서 무작위 날짜를 생성합니다.
- 직원의 이름은 예시용으로 몇 가지 남녀 이름 목록에서 무작위로 선택합니다 (남성 이름: John, Mike, Robert / 여성 이름: Jane, Emily, Anna 등). 성(last_name)은 Kim, Lee, Park, Choi, Smith 등에서 임의 선택합니다.
직원 레코드를 INSERT한 후 LAST_INSERT_ID()를 이용해 방금 생성된 직원의 ID를 가져옵니다.
이어서 해당 직원의 근태 기록을 5~15건 사이의 랜덤 개수로 생성합니다.
- 각 근태 레코드에 대해, 직원의 입사일 이후 오늘 사이의 임의 날짜를 선택합니다. (※ 입사일 이전 날짜는 생성하지 않음)
- 근태 상태는 80% 확률로 'P'(출석), 20% 확률로 'A'(결석)로 지정합니다.
루프를 완료하면 지정한 수의 직원과 다수의 근태 레코드가 데이터베이스에 삽입됩니다.

아래는 해당 프로시저 생성 및 실행 스크립트입니다. 프로시저를 생성한 후, 예시로 100명의 직원을 생성하도록 호출합니다 (원하는 데이터 양에 따라 파라미터를 조정 가능):

DELIMITER $$
CREATE PROCEDURE gen_sample_data(IN p_count INT)   #프로시저 선언부, p_count : 몇 명의 직원을 생성할지 받는 파라미터, $: 구분자로 내부의 ;를 무시하고 문장 끝이 END $ 라는 것을 알려줌
BEGIN
    DECLARE i INT DEFAULT 1;        # 직원 생성 루프용 변수
    DECLARE dept_count INT;         # 전체 부서 수 저장 변수
    DECLARE job_count INT;          # 전체 직무 수 저장 변수
    DECLARE rand_dept INT;          # 무직위로 선택할 부서 ID
    DECLARE rand_job INT;           # 무직위로 선택할 직무 ID
    DECLARE min_sal INT;            # 직무의 최소 급여
    DECLARE max_sal INT;            # 직무의 최대 급여
    DECLARE rand_gender CHAR(1);    # 성별 (M/F)
    DECLARE fn VARCHAR(50);         # 이름
    DECLARE ln VARCHAR(50);         # 성
    DECLARE hire_dt DATE;           # 입사일
    DECLARE empId INT;              # 생성된 직원의 ID
    DECLARE att_count INT;          # 생성할 근태 데이터 수
    DECLARE days_range INT;         # 입사일~오늘까지 일수 차이
    DECLARE days_offset INT;        # 랜덤 근태 날짜를 위한 오프셋
    DECLARE att_dt DATE;            # 생성할 근태 날짜
    DECLARE att_status CHAR(1);     # 출결 상태 (P/A)

    # 총 부서 수와 직무 수 조회
    SELECT COUNT(*) INTO dept_count FROM departments;
    SELECT COUNT(*) INTO job_count FROM jobs;

    WHILE i <= p_count DO   # 직무 수만큼 반복
        # 무작위 부서 및 직무 선택
        SET rand_dept = FLOOR(1 + RAND() * dept_count);
        SET rand_job = FLOOR(1 + RAND() * job_count);

        -- 선택된 직무의 급여 범위 조회
        SELECT min_salary, max_salary INTO min_sal, max_sal
        FROM jobs WHERE job_id = rand_job;

        # 성별 무작위 선택
        IF RAND() < 0.5 THEN
            SET rand_gender = 'M';
        ELSE
            SET rand_gender = 'F';
        END IF;

        # 성별에 따라 이름 무작위 선택
        IF rand_gender = 'M' THEN
            CASE MOD(i, 3)
                WHEN 0 THEN SET fn = 'John';
                WHEN 1 THEN SET fn = 'Mike';
                ELSE SET fn = 'Robert';
            END CASE;
        ELSE
            CASE MOD(i, 3)
                WHEN 0 THEN SET fn = 'Jane';
                WHEN 1 THEN SET fn = 'Emily';
                ELSE SET fn = 'Anna';
            END CASE;
        END IF;

        # 성 무작위 선택
        CASE MOD(i, 5)
            WHEN 0 THEN SET ln = 'Kim';
            WHEN 1 THEN SET ln = 'LEE';
            WHEN 2 THEN SET ln = 'Park';
            WHEN 3 THEN SET ln = 'Choi';
            WHEN 4 THEN SET ln = 'Smith';
        END CASE;

        # 입사일: 2015년 1월 1일부터 오늘까지 무작위
        SET hire_dt = DATE_ADD('2015-01-01', INTERVAL FLOOR(RAND() * 4018) DAY);

        # 직원 데이터 삽입
        INSERT INTO employees(dept_id, job_id, first_name, last_name, gender, hire_date, salary)
            VALUES (rand_dept, rand_job, fn, ln, rand_gender, hire_dt, FLOOR(min_sal + RAND() * (max_sal - min_sal + 1)));

        # 방금 삽입한 직원 ID 저장
        SET empId = LAST_INSERT_ID();

        # 5~15개 사이의 무작위 근태 데이터 개수 설정
        SET att_count = FLOOR(RAND() * 11) + 5;

        # 입사일 기준 오늘까지 일수 계산
        SET days_range = DATEDIFF(CURDATE(), hire_dt);
        IF days_range < 0 THEN
            SET days_range = 0;
        END IF;

        WHILE att_count > 0 DO  # 근태 데이터 수만큼 반복
            IF days_range > 0 THEN
                SET days_offset = FLOOR(RAND() * (days_range + 1));
            ELSE
                SET days_offset = 0;
            END IF;
            SET att_dt = DATE_ADD(hire_dt, INTERVAL days_offset DAY);    # 근태 일자 생성

            # 출결 상태 무작위 (80% 출석, 20% 결석)
            IF RAND() < 0.2 THEN
                SET att_status = 'A';
            ELSE
                SET att_status = 'P';
            END IF;

            # 근태 데이터 삽입
            INSERT INTO attendance(employee_id, att_date, status) VALUES (empId, att_dt, att_status);

            # 근태 카운트 감소
            SET att_count = att_count - 1;
        END WHILE;

        # 다음 직원
        SET i = i + 1;
        END WHILE;
    END $$
    DELIMITER ;



    # 직원 100명 생성
    CALL gen_sample_data(100);

짜자잔~ (짜잔형 아님)

TIP: 대량의 데이터를 생성할 때
RAND() 함수를 사용하면 편리합니다. 위에서는 부서/직무 선택, 성별 결정, 날짜 오프셋 결정 등에
RAND()를 활용했습니다. MySQL 8.0 기준으로 이러한 프로시저와 함수 사용이 가능하며, 데이터 양을 조절하여 다양한 시나리오를 실습할 수 있습니다 datacamp.com.

이렇게 준비했긔.

다음 포스팅에서는 본격저긍로 통계쿼리를 연습해보겠긔

그럼 다음 포스팅에서 건강하게 만납시다~

99duuk

2026년 4월 러닝 챌린지

2026년 1,2,3월 러닝 챌린지

병원

대구마라톤 풀

K마라톤 하프

2025년 러닝챌린지

봄

여름

가을

ZooKeeper 볼륨 꼬임으로 Kafka 죽는 문제

결론

문제

Zookeeper 데이터가 의도한 ./docker-data/zookeeper에 안 쌓이고 있음

상위 디렉터리를 bind해서 생긴 문제임.

조치 결과

장자 길라잡이 76 - 두려워 말라

groupingBy, getOrDefalut

1. DB 1회 조회 + 자바단 그루핑 vs 반복문 내부 다중 DB 조회

️ 패턴 A: 반복문 안에서 DB 여러 번 조회 (N+1 문제)

단점

️ 패턴 B: DB에서 한 번에 전부 가져와서 자바단에서 그루핑

장점

2. groupingBy 내부 동작 요약 (조금 더 깊게)

사용 코드 (학생/과목 예제)

groupingBy의 시그니처 (간단)

내부적으로 하는 일 (개념)

예제: subjectList가 이렇게 생겼다 치자

3. 왜 타입이 Map<Integer, List<...>> 인가?

4. getOrDefault 전/후 & 객체 상태 차이

코드

Map.get() 만 썼을 때 문제

getOrDefault 의 역할

전/후 비교 (학생 하나 기준)

before 매핑 / getOrDefault 사용 전

after grouping + getOrDefault + setSubjectList

5. 최초 객체 vs 최종 객체 구조 비교

5-1. 최초 상태 (DB에서 바로 가져왔을 때)

5-2. groupingBy 실행 후

5-3. 학생 객체에 다시 주입 후 (최종 상태)

한 줄 요약

7. 한 방에 다시 정리하면

✅ 1. groupingBy 의 성능

결론: O(n) → 매우 빠르고 안정적

시간 복잡도

메모리 사용량

Java가 groupingBy 에서 실제 수행하는 일

2. 반복문 + 다중 DB 조회 방식의 성능 (N+1 문제)

⚙ getOrDefault 의 성능

결론: 무시해도 될 정도로 가벼움 √

⭐ 성능 비교 한눈에표

최종 결론

groupingBy / getOrDefault 성능 걱정은 100% 불필요

오히려 성능의 핵심은 “DB 호출 횟수”

만약 학생이 100만명쯤 된다면?

✅ 1. 병렬 스트림(parallelStream) → 언제 쓰면 되는가?

✔ CPU 연산이 많고, 데이터가 크고, 각 요소가 독립적인 경우

✔ 멀티스레드로 동시에 처리해도 안전한 경우

✔ 성능 이득이 충분할 때

⛔ 2. 병렬 스트림 절대 지양해야 하는 경우

❌ I/O 바운드(DB, 네트워크, 파일) 작업이 있는 경우

❌ 상태를 공유하는 mutable 객체 수정이 있는 경우

❌ 순서가 중요한 로직

❌ 키가 적고 그룹이 매우 적은 경우

❌ 서버 환경이 제한된 경우 (CPU가 적음)

⭐ 병렬 스트림이 “필수”가 되는 경우 예시

예시: 학생 100만 명 + 과목 300만 개 grouping

최종 결론

✔ 병렬 스트림을 써도 되는 경우

❌ 병렬 스트림 쓰면 안 되는 경우

FLUSH

✅ 1. 어원: flush라는 단어의 본래 의미

✅ 2. 일반적인 의미 (공통 개념)

✅ 3. 각 기술에서의 flush 의미 및 차이

A. JPA / Hibernate (영속성 컨텍스트 flush)

B. Redis

C. MongoDB

D. RDBMS (예: Oracle, MySQL 등)

E. 파일 스트림 / 출력 버퍼 (Java, C, Python 등)

✅ 4. flush vs commit vs save 비교

Zookeeper 데이터가 의도한 `./docker-data/zookeeper`에 안 쌓이고 있음