KIOR

케이뱅크 계좌 지급정지 이의제기 승인 후기(당근거래 편)

KO_O — Mon, 6 Apr 2026 11:15:26 +0900

정말... 다시는 겪고 싶지 않은 일

저와 같은 '불안핑'들에게 안정이 되기를 바라며

결론부터 얘기하면 저는 이의제기가 승인되어 계좌가 해제되었습니다.

저의 사례를 공유드립니다.

# 반갑지 않은 연락...

2026년이 되어서 즐거운 마음으로 출근하여 올해의 계획을 세우고 있을때... 카톡과 문자가 왔습니다...

date. 2026.01

온라인으로 이의제기 신청은 연락 받은 영업일 기준 하루 뒤에 온더라구요!

다른 글에서도 법률 상담했던 기록에서도 이의제기는 빠르면 빠를 수록 좋다고하여

저는 e-mail과 Fax로 하는 것으로 마음을 먹고 진행하였습니다.

먼가 촉이 왔죠...

2025년 12월 말에 ' 당근거래'가 문제가 되었을 것으로

우선, 와이프에게 상황을 공유했습니다.

당시 와이프에게 요청한 조치는 아래와 같습니다.

# 거래자가 문제가 있으니 거래중지 요청

# 관련 채팅자료 모두 촬영

# 거래자 프로필

# 거래자 연락처 및 사기 조회

# 나의 거래내역

아내가 당근을 조치하는 동안 제출해야하는 서류를 준비했습니다.

# 이의제기신청서(자필작성)

# 신분증 사본

# 객관적인 증빙자료

# 보인서명사실확인서 (가까운 주민센터)

# 이의제기신청서

다들 수기로 작성해야하고 먼가 잘 못쓰면 안될 것 같고 그런 마음일 것 같아요...
저도 그래서 저보다 법률을 잘 아는 GPT에게 부탁해서 초안을 작성했습니다.

나중에 많은 후기들을 보고 아래의 내용이 포함되면 좋다는 점을 알았습니다.
( GPT 초안에 저는 대부분들어가 있었고 만약 이미 제출을 하셨다면 보완자료로 제출할 수 있습니다! )
- 시간 순으로 상황 설명
- 내가 진행한 거래는 피해자의 거래와 관련없는 정당한 거래였다.
- 나는 성실한 사회인으로써 관련 사건에 공모할 이유가 없다.
- 나는 관련 사건에 파생된 선의의 피해자이다.
- 관련하여 수사 협조가 필요하다면 적극적으로 협조하겠다
- 이러한 사실관계를 고려하여 관련 조치를 해제 하기를 바란다.

# 객관적인 증빙자료

- 당근거래 채팅: 모든 내용을 스크린 샷하여 문서화
- 익시오 통화요약: 스크린 샷하여 문서화
- 거래자: 인적사항(주민등록증 등)
- 거래 사진 또는 영상

이것도 진행 과정에서 많은 후기를 찾으며 알게된 사실 입니다.
금융기관은 사진이나 영상을 중요하게 생각한다고 합니다.
저의 경우 고가의 물품 거래고 대리인이 나온다고 하여 찝찝하여 와이프와 배달책이 거래하는 장면을 사진으로 몰래 찍어둔 것이 있어서 첨부하였습니다.

# CCTV
프렌차이즈 카페에서 거래하여 거래장면이 있을 것으로 판단되어서 지인 경찰에게도 문의하여 볼 수 있는지 확인하니 신고 후 가능하다하여 '112'신고하여 CCTV 연람을 시도했습니다...!

근데... CCTV 못봅니다.
경찰관님 안내로는 제가 피해를 받은 사실이 없고! (맞죠... 저는 정상거래라서 금전적.. 물질적... 손해가 없죠...)
가장 중요한 사건번호가 없기 때문에 도움을 줄 수 없다는 것이었습니다!
나중에 지금 피해를 입었다고 주장하는 피해자 분이 서면제출(사건 접수)를 하게 되어서 사건번호가 있을때 도움을 줄 수 있다는 것이 었습니다.

제가 할 수 있는 최선은 카페 사장님에게 거래때 영상을 별도로 보관만 해달라는 요청을 했습니다.

# 걱정 NoNO
본인이 영상이나 사진이 없다고 걱정하지 마세요!
많은 후기들에서도 사진이나 영상이 없어도 이의제기 받아드려진 상황이 많습니다!
그리고 고객센터 안내에서도 없을 경우 채팅기록과 같은 것들로 대체될 수 있다고 합니다.

# 중간 정리

'케이뱅크'를 통해서 '계좌 중지' 및 사기와 연관된 거래 내용을 통보 받음.
이의제기 서류 준비
Fax 및 e-mail로 서류 제출
고객센터 연락하여 정상적으로 서류 접수되었는지 확인

# Fax 제출
요즘 Fax를 잘 안쓰죠... 저도 그래서 이번 기회에 찾다가 사용했던 어플을 공유드립니다!
(참고로 저는 Apple 유저 입니다.)

AppStore에 '모바일 팩스'라고 찾아보면 주황배경 어플이 있습니다.
해당 어플로 pdf로 된 서류를 제출했습니다!

# 고객센터
너무 연락하여 고객센터 번호를 외웠습니다. 1522-1000 > 8번 > 1번
저는 대부분 10-15분 정도 대기 후 연락이 가능했습니다.( 가장 오래 기다른건 50분? 딱 1번입니다. )

상담사 분에게 계좌번호를 알려드리고 서류를 보냈는데 확인이 되는지 몇장이 전달되었는지 확인하면 접수는 완료되었습니다.

# 결론

저의 경우 이의제기 신청하고 승인되기 까지 (영업일 기준: 12일 > 공휴일 포함: 16일) 걸렸습니다.

서류를 제출하고 서류가 관련부서에서 받았다고 연락온 것은 (영업일 기준: 9일 > 공휴일 포함: 11일) 걸렸습니다.

저는 금융과 관련된 것이다 보니 '불안핑' 상태로 시간을 보냈습니다.( 중간중간 우편도 와요...)

많은 분들이 얘기하시죠... 나도 피해자인데 왜 이 부분을 내가 소명해야 하는가...

그래서 당근페이, 번개페이 등이 있는거라고...

저는 월급날이 겹치지 않았지만... 공과금이나 자동이체때 걸렸던 분들 후기 보니... 정말... 어렵더라구요...

혹시나 해서 보험 어플부터 미리 카드사에 연락해서 가상계좌 확인하고...

!! 확실한 것은 은행 지점을 방문하면 계좌이체나 이런 것들 가능합니다!

케이뱅크 고객 상담사 분들에게 죄송하지만 저는 해결되는 날까지 매일 1번씩 연락드렸습니다.

거의... 출근해서 또는 점심먹고 이렇게 연락을 계속 했었습니다.

(처음 알았습니다. 1522 번호로 연락은 무제한이 아니라는 것을... 하하)

케이뱅크 고객상담에 대해서 불만이 많은 글들이 있습니다.

겪은 저로써 할 수 있는 말은 case by case 입니다. 저는 대부분 친절한 상담과 동일한 가이드 내용을 받았습니다.

고객 상담사 선생님들을 이해해드려야 하는 부분은... 그 분들이 이 건을 해결할 수 있는 실무자 분들이 아닙니다...

메모나 확인 정도 가능하시고 관련 규정으로 처리 방식을 안내해주시는게 최선이라는 점 입니다.

# 이의제기 승인 후

저는 이의제기 승인 후 해당 계좌를 스스로 '거래 중지'하였습니다.
다들 웬만하면 계좌를 삭제하는 것 보다는 중지하여 금융거래 기록을 보유하는게 좋다고 하더라구요.
그리고 어차피 남아 있는 금액이 2개월 간 사용할 수 없기 때문에...

이 글을 찾아서 읽고 계신다면... 저와 같은 상황이겠죠?

와이프가 옆에서 계속 말했고 지나고 나서 생각드는 것은

"나는 잘 못한게 없다"

억울하죠... 그냥 난 중고거래 하건데...

하지만 항상 돌다리 두두리고 건너라고 조심하고

그냥 액땜 하고 무슨 좋은 일이 나에게 일어나려고 하나

위안을 삼고 있습니다.

본 포스팅이 많은 분들에게 도움이되고 마음이 불안이 줄기를 바랍니다!

JEUS JSP는 200, CSS는 404가 뜨는 이유(Too many open files)

KO_O — Fri, 3 Apr 2026 14:54:19 +0900

개발 목적으로 Webtob/JEUS 구성을 위한 분들을 위한 가이드 포스팅 :)

TmaxSoft Engineer의 설치방식으로 진행되며, JEUS는 11년 연속 국내 1위 미들웨어입니다.

⭐️ Situation

기동 이후에 잘 사용하다가 시간이 지나면서 어느 순간에 도달하면 아래와 같은 상황이 재현되었습니다.

JSP는 브라우저에서 정상으로 호출되었고, css 같은 정적 리소스만 '404(Not Found)'가 발생됩니다.

[확인 방법: 개발자 도구(F12) > 네트워크]

Task

JEUS 제품의 문제인지?

아니라면 어떤식으로 접근하여 문제를 해결해서 운영에 지장이 없도록 하는 것이 목적.

Action

시간이 경과 이후에 '동적 리소스'는 정상 호출되고, '정적 리소스'는 404(Not Found) 된다는 점이 이상하여

JVM HeapMemory의 문제 일 수도 있다고 생각이 들었습니다.

유사한 장애가 발생한 버그 리포팅을 연구소에서 찾기 시작했습니다.

메모리 또는 제품의 문제 건으로 패치가 제공된 것은 없었습니다.

연구소 Action을 확인 중 fd의 영향으로 유사한 문제가 발생한 사례를 발생했습니다.

바로 재현 환경을 구축하기로 했습니다.

[단일 컨테이너 + HTTP listener + Application] 설정하여 기동했습니다.

"장애 유도 시나리오" 아래와 같습니다.

1. JSP 호출

2. curl으로 '정적 리소스'를 할당된 openfiles 수까지 호출.

3. JSP 호출

sleep.jsp

0.00MB

# 정적 리소스(sleep.jsp 등)를 지속적으로 호출하여 FD를 소모시키는 스크립트
while true; do 
  curl -v "http://admin:8080/sleep.jsp?ms=120000"
  sleep 0.1
done

JVM 할당된 최대 openfiles 확인.

[jeus@admin:/home/jeus]$ jps -m
69 DomainAdminServerBootstrapper -domain jeus_domain -u wasadmin -server adminServer
137 Jps -m
[jeus@admin:/home/jeus]$ cat /proc/69/limits | grep open
Max open files 1048576 1048576 files

JVM 사용중인 fd 확인.

[jeus@admin:/home/jeus]$ ls /proc/69/fd | wc -l
215

✅ Result

WAS 동작 메커니즘을 이해하고 있고 LOG를 분석했다면 보다 쉽게 해결할 수 있는 문제입니다.

첫번째 핵심은 두 자원의 처리 방식 입니다.

[동적 리소스]

컴파일 완료: 첫 호출시 .java > .class로 컴파일 되어 ClassLoader 의해서 Metaspace에 적재.
불필요 접근: load된 호출은 Disk의 jsp를 다시 열지 않습니다.
메모리에 있는 서블릿 객체를 실행하여 결과물만 스트리밍할 뿐입니다.

결론적으로 'open files' 꽉 찬 상태여도 새로운 소켓 연결(FD)만 맺을 수 있다면 실행 자체는 성공합니다.

[정적 리소스]

필수적 접근: 요청을 할때마다 서버 디스크의 실제 경로에서 파일을 Open하여 읽어야 합니다.

결론적으로 'open files' 제한에 걸리면 파일을 열기 위한 File Descriptor를 할당받지 못하여 응답으로 파일을 찾지 못한 것으로 간주하여 I/O Error를 반환하게 됩니다. 최종적으로 브라우저에는 404 NotFound가 반환됩니다.

두번쨰 핵심은 로그 입니다.

해당 로그를 조금만 보거나 search 해보면 아래의 결론을 얻습니다.

"운영체제(OS) 레벨에서 프로세스가 열 수 있는 파일 서술자(File Descriptor)의 한도를 초과"

해당의 경우 단순히 파일만 못 여는 게 아니라, 새로운 네트워크 접속을 받아들이는 Acceptor 쓰레드 자체가 Selector를 생성하지 못해(Too many open files) 중단되었기 때문에 서비스 불능 상태에 빠진 것입니다.

[2026.04.03 03:23:17:143][0] [serverA1-95] [NET-0013] The acceptor NonBlockingChannelAcceptor: admin:8080 is corrupted because it has exceeded the fail limit count[NonBlockingChannelAcceptor: admin:8080].
<<__Exception__>>
java.io.IOException: Too many open files
at java.base/sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:533)
at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:285)
at jeus.io.impl.nio.NonBlockingChannelAcceptor.run(NonBlockingChannelAcceptor.java:118)
at java.base/java.lang.Thread.run(Thread.java:834)
<<__!Exception__>>

[2026.04.03 03:23:17:155][0] [serverA1-95] [NET-0007] Replacing the acceptor NonBlockingChannelAcceptor: admin:8080 (attempt 1) failed because of the following exception.
<<__Exception__>>
java.io.IOException: Too many open files
at java.base/sun.nio.ch.EPoll.create(Native Method)
at java.base/sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:79)
at java.base/sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
at java.base/java.nio.channels.Selector.open(Selector.java:295)
at jeus.io.impl.nio.NonBlockingChannelAcceptor.replaceSelector(NonBlockingChannelAcceptor.java:203)
at jeus.io.impl.nio.NonBlockingChannelAcceptor.acceptorCorrupted(NonBlockingChannelAcceptor.java:176)
at jeus.io.impl.nio.NonBlockingChannelAcceptor.acceptFailed(NonBlockingChannelAcceptor.java:167)
at jeus.io.impl.nio.NonBlockingChannelAcceptor.run(NonBlockingChannelAcceptor.java:134)
at java.base/java.lang.Thread.run(Thread.java:834)

⚙️ Resolve

System ulimit Check

[jeus@admin:/home/jeus]$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31323
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192 c
pu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Modify settings.

# 설정 변경 (예: 65536)
vi /etc/security/limits.conf

# 내용 추가 (JEUS 설치계정 / ex:jeus)
jeus soft nofile 65536
jeus hard nofile 65536

주의: JEUS7 이상은 반드시 'NodeManager'의 open files 값을 따라 Container 값이 할당 됩니다.

(단, standalone 모드 기동인 startManagedServer 기동은 예외)

개인적인 생각

인프라를 점점 공부하면 더 Low-level의 움직임을 궁금하게 됩니다...

이러한 이유가 모든 Application이 OS위에서 한정된 자원을 나누어 쓰는 본질에서 벗어날 수 없기 때문인거 같습니다.

Cloud Native 환경에서도 ulimit이나 sysctl 파라미터는 존재하기 때문에 이를 간과했을 때 발생하는 장애는 다른 장애들보다 훨씬 더 분석하기 까다롭게 다가옵니다...

이런 점을 대응하기 위해서 계속 더 파고... 또 파고... 계속 파고... 정리하면 똑똑이가 되겠죠?

What does it mean? Cgroup

KO_O — Thu, 2 Apr 2026 15:46:13 +0900

리눅스 시스템 운영이나 쿠버네티스를 공부하다 보면 반드시 마주하게 되는 개념이 있습니다.

바로 Cgroup(Control Groups)입니다.

컨테이너 기술의 뿌리가 되는 이 핵심 기술을 실무 관점에서 정리해 보겠습니다.

What is Cgroup?

Cgroup(Control Groups)은 프로세스들이 사용하는 시스템 자원(CPU, 메모리, 네트워크 대역폭, 디스크 I/O 등)을 그룹별로 제한하고 격리할 수 있는 리눅스 커널의 핵심 기능입니다.

쉽게 말해, 특정 프로세스가 서버의 모든 자원을 독점하지 못하도록 "너는 CPU 20%만 써!" 또는 "너는 메모리 1GB까지만 사용해!"라고 울타리를 치는 작업이라고 이해하면 쉽습니다.

Namespace vs Cgroup
- Namespace: 프로세스가 보는 '환경'을 격리 (이름표, 네트워크, PID 등)
- Cgroup: 프로세스가 사용하는 '자원'을 제한 (CPU, Memory 등)

✅ Cgroup의 주요 기능 4가지

기능	설명
자원 제한 (Limiting)	특정 그룹의 메모리 사용량이나 CPU 점유율을 제한합니다.
우선순위 (Prioritization)	특정 그룹에 더 많은 CPU 사이클이나 디스크 I/O 대역폭을 할당합니다.
회계/측정 (Accounting)	그룹 단위로 자원 소모량을 모니터링하고 통계를 산출합니다.
제어 (Control)	그룹 내의 모든 프로세스를 한 번에 정지(Freeze)하거나 재시작합니다.

⚙️ 실전! 리눅스에서 Cgroup 확인하기

리눅스 시스템에서 Cgroup은 파일 시스템 형태로 관리됩니다.

아래 경로에서 현재 시스템의 Cgroup 설정 내용을 직접 확인할 수 있습니다.

# cgroup 마운트 정보 확인
$ mount | grep cgroup

# cgroup v2를 사용하는 시스템에서의 경로
$ ls -l /sys/fs/cgroup

# 특정 프로세스가 어떤 cgroup에 속해 있는지 확인 (PID 1번 기준)
$ cat /proc/1/cgroup

알아두기: 최근 배포판(RHEL 9, Ubuntu 22.04 등)은 Cgroup v2를 기본으로 사용합니다.

항목	Cgroup v1	Cgroup v2
구조	다중 계층 (Multiple Hierarchies)	단일 통합 계층 (Unified Hierarchy)
출력 형태	자원별로 여러 줄 출력	0::/ 단 한 줄 출력
자원 제어	각 자원 파일이 흩어져 있음	/sys/fs/cgroup 아래 통합 관리
복잡도	매우 높음 (설정이 서로 꼬일 수 있음)	낮음 (직관적이고 효율적임)
등장 배경	2.6 커널 (2000년대 후반)	4.5 커널 (2016년~) / 최근 배포판 표준

Cgroup과 네트워크: 패킷에 '신분증'을 달아주다

많은 분이 Cgroup을 CPU와 메모리 제한용으로만 알고 계시지만, 사실 네트워크 트래픽 제어에서도 핵심적인 역할을 합니다.

Cgroup은 프로세스가 내보내는 네트워크 패킷에 '이 패킷은 어느 그룹 소속이다'라는 이름표를 붙여줍니다.

Cgroup v1: 전용 컨트롤러 방식

v1에서는 크게 두 가지 컨트롤러를 통해 네트워크를 관리했습니다.

net_cls (Network Classifier): 패킷에 클래스 ID를 부여합니다.
리눅스의 tc(Traffic Control) 명령어와 연동하여 특정 그룹의 대역폭(Bandwidth)을 10Mbps로 제한하는 등의 작업이 가능합니다.
net_prio (Network Priority): 네트워크 인터페이스별로 패킷의 우선순위를 지정하여 중요한 서비스의 통신을 먼저 처리하게 합니다.

Cgroup v2: eBPF와의 강력한 결합

v2로 넘어오면서 구조가 완전히 바뀌었습니다.
별도의 컨트롤러 대신 eBPF(extended Berkeley Packet Filter) 기술을 직접 활용합니다.

왜 eBPF인가요?
단순히 ID만 부여하던 과거와 달리, 이제는 Cgroup 단위로 eBPF 프로그램을 걸어 "이 그룹에서 나가는 패킷 중 80번 포트만 허용해!" 같은 정교한 필터링을 커널 레벨에서 초고속으로 수행할 수 있기 때문입니다.

Kubernetes와의 연결고리

쿠버네티스 YAML 파일에 설정하는 "resoruces.limits" / "requests" 결국 내부적으로 이 Cgroup을 통해 제어됩니다.

CPU Limit: Cgroup의 "cpu.max"(v2) 또는 "cpu.cfs_quota_us"(v1) 설정을 통해 제어됩니다.
Memory Limit: Cgroup의 "memory.max" (v2) 또는 "memory.limit_in_bytes" (v1) 설정을 통해 Pod의 메모리 폭주를 방지합니다.

만약 Pod가 설정된 Memory Limit을 초과하려고 하면, 커널은 Cgroup의 정책에 따라 해당 프로세스를 OOM(Out Of Memory) Kill 시켜 시스템 전체의 안정성을 보장합니다.

⚙️ cgroup Memory

# Command
docker run --name stress-test --memory "500m" --memory-swap "500m" -dit python:3.11 python3 -c 'import time; d=[]; [(d.append(" "*1024*1024*50), print(f"Allocated: {(i+1)*50}MB"), time.sleep(3)) for i in range(20)]'

KIOR  /Users/kior  d start stress-test stress-test
KIOR  /Users/kior  d inspect stress-test | grep -i oom
"OOMKilled": false,
"OomScoreAdj": 0,
"OomKillDisable": null,

KIOR  /Users/kior  docker events --filter container=stress-test
2026-04-02T14:55:15.660647796+09:00 container oom b3a1998cd5365ccf2d98bec7c00ced0f3f314d5e9ade821705a4b9d7060f5331 (desktop.docker.io/ports.scheme=v2, image=python:3.11, name=stress-test)
2026-04-02T14:55:15.739624421+09:00 container die b3a1998cd5365ccf2d98bec7c00ced0f3f314d5e9ade821705a4b9d7060f5331 (desktop.docker.io/ports.scheme=v2, execDuration=27, exitCode=137, image=python:3.11, name=stress-test) ^C% ✘

KIOR  /Users/kior  d inspect stress-test | grep -i oom
"OOMKilled": true,
"OomScoreAdj": 0,
"OomKillDisable": null,

System에서는 /sys/fs/cgroup/memory.events 에서 종합 'oom_kill' 횟수를 알 수 있습니다.

"docker stats" 통해서 자원을 모니터링 하면 보다 이해가 쉽습니다!

⚙️ cgroup CPU

메모리 테스트에서 '즉사(OOM Kill)'를 확인했다면, CPU 테스트는 조금 다른 양상을 보입니다.

⭐️ CPU는 왜 '죽지' 않는가?

CPU 과도 사용으로 인해 컨테이너가 직접 Kill 되는 현상은 발생하지 않습니다. 이는 자원의 성격 차이 때문입니다.

압축성(Compressible) 자원: CPU는 '시간'의 자원입니다.
제한치에 도달하면 커널은 프로세스를 죽이는 대신 실행 시간을 쪼개는 Throttling(쓰로틀링)을 걸어 속도를 늦춥니다.
결과: 프로세스는 "느려질 뿐" 죽지 않고 좀비처럼 끈질기게 살아남습니다.

✅ Kubernetes 환경에서의 '간접 사망'

실무(K8s)에서는 CPU 때문에 컨테이너가 재시작되는 경우가 빈번한데, 이는 Cgroup이 죽인 것이 아니라 시스템의 판단입니다.

Throttling → Latency 증가 → livenessProbe 실패 → Restart
CPU 쓰로틀링으로 앱이 너무 느려져 헬스체크 응답을 제때 못 보내면, 쿠버네티스는 앱이 멈춘 것으로 판단하여 컨테이너를 재기동시킵니다.

cgroup Network (심화)

네트워크 cgroup은 CPU/메모리에 비해 로컬 환경에서 테스트 기록을 남기기가 매우 까다로운 영역입니다.

⭐️ 테스트가 까다로운 이유

Cgroup 자체는 패킷에 '이름표(Class ID)'만 붙여줄 뿐, 실제로 속도를 줄이는 것은 커널의 tc(Traffic Control) 도구와 협업해야 하기 때문입니다. 또한 컨테이너에 NET_ADMIN 권한을 부여해야 하는 등 설정이 복잡합니다.

✅ 그럼에도 얻을 수 있는 결과

복잡한 설정을 거치면 다음과 같은 확실한 결과를 얻을 수 있습니다.

Bandwidth Shaping: 특정 컨테이너의 대역폭을 정교하게 제한(예: 10Mbps)할 수 있습니다.
Latency Control: 패킷 전송 시 고의적인 지연을 발생시켜 네트워크 불안정 상황을 시뮬레이션할 수 있습니다.
Noisy Neighbor 방지: 특정 서비스의 트래픽 폭주가 노드 전체의 대역폭을 점유하여 다른 서비스에 영향을 주는 문제를 해결합니다.

자원	성격	한계 도달 시	현상
Memory	비압축성	OOM Kill	프로세스 즉사 (사라짐)
CPU	압축성	Throttling	속도 저하 (생존 가능)
Network	흐름 제어	Queueing/Loss	지연 발생 (정체)

마무리

내용이 꽤 깊었지만, Cgroup의 핵심만 요약하면 의외로 단순합니다.

+ Cgroup = 시스템 자원을 그룹별로 제한 및 격리
+ Namespace = 프로세스가 보는 환경을 격리 (PID, Network 등)
+ Memory = 비압축성 자원, 한계 도달 시 OOM Killer 작동
+ CPU = 압축성 자원, 한계 도달 시 Throttling 발생
+ Network = tc와 협업하여 대역폭 및 지연 시간 제어
+ livenessProbe = CPU 쓰로틀링 시 컨테이너 재기동의 원인
+ Exit Code 137 = 커널에 의해 강제 종료된 사망 기록

인프라 공부는 부지런히...

JEUS LOG(D_SESSION-2183, D_SESSION-3188, D_SESSION-3186)

KO_O — Tue, 27 Jan 2026 12:57:35 +0900

개발 목적으로 Webtob/JEUS 구성을 위한 분들을 위한 가이드 포스팅 :)

TmaxSoft Engineer의 설치방식으로 진행되며, JEUS는 11년 연속 국내 1위 미들웨어입니다.

Event

JEUS8.5에서 확인된 Log 입니다.

해당 로그는 패치에 따라서 발생이 됩니다.( ~2022.01 / 2025.02 ~ )

# Session recive
[D_SESSION-2183] The connection(serverA1) was unable to find the session manager. opcode = 0x103, name=serverN1

# Session Send
[D_SESSION-3188] <RemoteEngine(serverA1)> An error occurred. The session manager received an error packet from serverN1.
[D_SESSION-3186] Sending the backup session to serverN1 failed.( count = 1 )

결론적으로 session backup이 일방적으로 한쪽에서 정상적으로 되지 않음으로 운영자 입장에서 세션에 문제가 발생할 수 있는 여지가 생겼음으로 수정하는게 맞습니다

TmaxSoft JEUS 입장

Application과 Container 이름을 동일시 하는 것을 비권고 합니다.

이유는 내부 엔진동작으로 어디까지 공개할 수 있을까 싶습니다만... 직원 분들은 (ims-341005) 참고하시면 좋겠습니다.

간략하게 Session Engine에서 백업 과정에서 이름이 문제가 발생된다 정도로 알아주세요 :)

수정방법

수정 방법은 간단합니다.

컨테이너 명을 변경 또는 Application 배포 폴더/war 명을 변경

✅ 재현 시나리오

# Application 배포 PATH를 컨테이너 명과 같게 합니다.

[DAS]jeus_domain.adminServer>list-clusters List of Clusters ====================================================================
+----------+-------------------------+-------+-----------+---------+
| Cluster | Server List | MEJB | Class FTP | Running |
+----------+-------------------------+-------+-----------+---------+
| c-server | serverA1, serverN1 | false | false | true |
+----------+-------------------------+-------+-----------+---------+ ====================================================================

[DAS]jeus_domain.adminServer>appinfo
Application information for the domain [jeus_domain]. ================================================================================
+------------+-------------+------+------------+-------------+-----------------+
|Application | Application | State| Target | Target | Application Path |
| ID | Type | | Servers | Clusters | |
+------------+-------------+------+------------+-------------+-----------------+
| server | WAR | RUNNING | | c-server | /sw/jeus/serverA1 |
+------------+-------------+------+------------+-------------+-----------------+ ================================================================================

재현 시나리오는 Application 배포 방식이 폴더 또는 WAR 일때, Container 이름을 동일하게 serverA1으로 설정했습니다.

(ex: /sw/jeus/app/serverA1 또는 /sw/jeus/app/severA1.war )

그러므로 serverA1으로 요청되어 생성된 session은 정상적으로 백업되지 않을 것 입니다.

✅ 결과보기

(정상) backup

[2026.01.27 01:23:59:058][2] [serverN1-24] [D_SESSION-3103] Successfully received backup sessions from <serverA1> . count = 1

[2026.01.27 01:23:59:059][2] [serverA1-90] [D_SESSION-3105] <app_welcome> Successfully sent backup session(s) to the backup server( serverN1 ). count = 1

(비정상) backup

[2026.01.27 01:19:03:648][1] [serverN1-27] [D_SESSION-2183] The connection(serverA1) was unable to find the session manager. opcode = 0x103, name=serverN1

[2026.01.27 01:19:03:660][1] [serverA1-53] [D_SESSION-3188] <RemoteEngine(serverA1)> An error occurred. The session manager received an error packet from serverN1.

[2026.01.27 01:19:03:662][1] [serverA1-53] [D_SESSION-3186] Sending the backup session to serverN1 failed.( count = 1 )

로그를 야금야금 DeepDive하면 이상한 점이 보입니다.

JEUS에서 Application 배포시의 이름(id)으로 Container에서 배포되지 않는 점을 확인할 수 있습니다.

(폴더 이름/ 이름.war 의 "이름"으로 배포된다는 점을 알 수 잇습니다.)

이번 문제는 그 점이 포인트가 됩니다.

내부 엔진 session-scope 동작에서 위에서 언급한 "이름"과 Container 명이 동일할 경우 특정 기능 활성화되는 점이 있습니다.

반드시 TmaxSoft에서 권고된 방향으로 Config를 수정하고 적용하시기를 적극 추천드립니다

개인적인 생각

요즘 여러 이슈들을 보면서 스스로가 많이 변했다고 느끼고 있습니다.

경험으로 인하여 이슈를 근거 기반으로 원인을 찾자고 매번 이야기 하면서... 반대가 된 방식으로 일을 한다는 느낌을 받았습니다.

경찰 수사로 따지면 범인을 지정해두고 원인을 맞춘다는 느낌이랄까... ㅎㅎ

물론 아직은 타율이 좋아서 문제가 아니라고 생각했는데 장기적으로 이런 모습이 좋지 않다고 느꼈습니다.

앞으로 더 꼼꼼하게 로그를 뜯고 씹고 맛보면서 더 솔루션의 동작과 인프라를 이해하면서 접근하도록 다짐합니다!

WebtoB ACL 설정 방법 정리 (ACCESS 절로 IP 접근 허용·차단하기)

KO_O — Wed, 14 Jan 2026 12:50:59 +0900

WebtoB/JEUS 개발 환경을 구성하고자 하는 분들을 위한 실전 가이드 :)

본 글은 TmaxSoft 엔지니어 방식에 따라 진행되며, WebtoB는 11년 연속 국내 1위 웹 서버입니다.

✅ Q: WebtoB에는 ACL(Access Control List) 기능이 있나요?

A: 네. 있습니다 :)
WebtoB에서는 유사한 "ACCESS 절"이라고 존재합니다.

알아두기

WebtoB는 방화벽(WAF) 뒤에 구성합니다.
보안적으로 방화벽 다음 구간은 보안구역으로 취급하기 때문에 해당 구역에서 'Deny'를 하는 행위를 이미 보안에 취약하다고 보는 경우가 있습니다. 그래서
엔지니어들은 가급적이면 방화벽에서 적용하는 것을 권고하고 위에 언급한 부분을 감수하고 적용하겠다고 하였을 때 지원을 하고 있습니다.

⚙️ 설정하기

Client에서 접속을 시도할 때 IP, network/netmask, Header 정보들을 기준으로 요청을 허용 / 제한을 설정 가능 :)

WebtoB Config에서 적용이 가능한 것을 DIRECTORY, URI, EXT 그리고 TCPGW 적용이 가능하다.

TEST Infra Arch

IP 기준으로 허용 / 제한 대해서 포스팅 합니다.

그 외 설정은 티맥스소프트 공식 메뉴얼을 참고하여 적용하시기를 바랍니다.

⚙️ SET #허용

http.m > 특정 IP만 허용 ACCESS절 추가하기

(생략)
*URI
u_docker Uri = "/", SvrName = "docker", SvrType = JSV, GotoEXT=N, VhostName = "v_docker", AccessName="access1"

*ACCESS
access1 Order="allow,deny", Allow="172.18.0.3"

Result

bash-5.1# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::	ip6-localnet
ff00::	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.18.0.3	webp


bash-5.1# curl http://172.18.0.2:8080/index.jsp
Access Success

bash-5.1# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::	ip6-localnet
ff00::	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.18.0.4	admin


bash-5.1# curl http://172.18.0.2:8080/index.jsp
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE> 302 Found </TITLE>
</HEAD><BODY>
<H1>Found</H1>
<HR>
</BODY></HTML>

⚙️SET #제한

http.m > 특정 IP만 제한 ACCESS절 추가하기

(생략)
*URI
u_docker Uri = "/", SvrName = "docker", SvrType = JSV, GotoEXT=N, VhostName = "v_docker",
AccessName="access1"

*ACCESS
access1 Order="deny,allow", Deny="172.18.0.3"

Result

bash-5.1# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::	ip6-localnet
ff00::	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.18.0.3	webp


bash-5.1# curl http://172.18.0.2:8080/index.jsp
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE> 302 Found </TITLE>
</HEAD><BODY>
<H1>Found</H1>
<HR>
</BODY></HTML>

bash-5.1# cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::	ip6-localnet
ff00::	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.18.0.4	admin


bash-5.1# curl http://172.18.0.2:8080/index.jsp
Access Success

알아두기

2개 이상의 IP 허용/제한 가능.
[ ex: access1 Order="allow,deny", Allow="172.18.0.3, 172.18.0.4" ]
대역으로 허용/제한 가능.
[ ex: access1 Order="deny,allow", Deny="172.18.0." ]
header 값으로 허용/제한 가능.
[ ex: access1 Order="allow,deny", AllowIf="X-Forwarded-For 100.100.100.100" ]
Deny 제한되면 ERROR 로그에 아래와 같이 남습니다.

[2026-01-14T03:17:14] [CLIENT(172.18.0.3)] [E] [ERR-00026] A URI is denied of access. {uri=/} GET /index.jsp HTTP/1.1
[2026-01-14T03:17:17] [CLIENT(172.18.0.4)] [E] [ERR-00026] A URI is denied of access. {uri=/} GET /index.jsp HTTP/1.1

옵션에 따른 우선 순위

Deny,Allow	- Method > Deny > DenyIf > Allow > AllowIf 순서 매치 - 요청 메소드가 항목에 포함되지 않을 경우, 요청을 허용 - Deny, DenyIf에는 매치하지만 Allow, AllowIf와 매치하지 않는 경우 거절 - 이외는 허용
Allow,Deny	- Method > Allow > AllowIf > Deny > DenyIf 순서 매치 - 요청 메소드가 항목에 포함되지 않을 경우, 요청을 거절 - Allow, AllowIf에는 매치하지만 Deny, DenyIf와 매치하지 않는 경우 허용 - 이외는 거절

✅ 결론

이제 2026년 연초가 되면 모든 도메인은 보안 점검을 진행하게 됩니다 :)

TmaxSoft는 설치 당시부터 오랜 업력으로 만들어진 표준으로 대부분의 보안취약사항을 조치를 함께하지만...

새롭게 나오거나 누락되는 경우가 있습니다.

이번 포스팅은 ACL으로 접근을 허용/제한할 수 있는 기능에 대해서 작성하였습니다.

제가 요청 받았던 사이트의 경우 "특정 uri는 관리용으로 접근을 제한" 해야지 보안취약사항에서 문제가 발생하지 않는 상황입니다.

이 글을 읽는 분들도 유사한 상황에서 제일 상단의 " 알아두기"를 참고하고

적용해보시는 것을 고려하시면 좋을 것 같습니다.

Apache 소스(src) 컴파일 설치 및 시작

KO_O — Fri, 9 Jan 2026 08:35:59 +0900

Apache Web Server는 안정성과 유연성을 갖춘 오픈소스 웹 서버

인터넷 서비스의 기반을 이루는 핵심 기술

Apache 설치 방식은 ?

운영 환경에서 Apache HTTP Server(httpd)를 설치할 때 가장 많이 고민하는 것이 패키지 매니저(yum/dnf) 방식과 소스 컴파일(src) 방식입니다. 대다수 편리성으로 패키지 매니저를 통해서 처음 설치를 시작하지만 결국... 보안 패치 정책/버전 통제/모듈 옵션 필요 시 소스 컴파일(src)이 유리하게 됩니다.

비교

항목	yum / dnf (패키지)	소스 컴파일 (src)
목적	안정성, 표준 경로, 손쉬운 유지보수	최신 버전, 맞춤 빌드, 다중 버전 공존
버전	배포판 검증 버전(상대적으로 보수적)	공식 최신 버전 선택 가능
의존성	자동 해결(mod_ssl, apr, pcre 등)	수동 해결 필요(또는 `--with-included-apr` 활용)
업데이트	`dnf/yum update`로 일괄 관리	재빌드 필요(보안패치 시 재컴파일)
설치 경로	/etc/httpd, /var/log/httpd 등 표준	임의 지정(예: /usr/local/apache2)
운영/장애 대응	매뉴얼과 사례 풍부, 유지보수 용이	담당자 숙련도 필요, 문서화 필수

[ 개인적 생각 ]
대부분 서비스 운영사는 보안취약사항, EOL, 각 표준사항들을 고려해야 함으로 소스 컴파일(src) 방식을 추천합니다.
소스 컴파일(src) 설치는 어렵다고 하지만 제공되는 SHELL 사용하여 설치하면 보다 편리하게 설치할 수 있습니다.

⚙️ Apache(src) 설치

✅ 파일 준비하기

네트워크 환경에 따라 아래의 방법 중 선택하시면 됩니다.

[인터넷망] wget, curl, git 명령어를 통해서 받습니다.
[폐쇄망] 로컬PC에 다운로드 후 sftp Upload

# SHELL 다운로드

curl -L -O https://github.com/jo0ozip/kior-system-oss/raw/refs/heads/main/Apache/apache-kior-system_latest.tar.gz

[kior-oss@89790c086e28 ~]$ curl -L -O https://github.com/jo0ozip/kior-system-oss/raw/refs/heads/main/Apache/apache-kior-system_latest.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  1850  100  1850    0     0   4755      0 --:--:-- --:--:-- --:--:--  4755


[kior-oss@89790c086e28 ~]$ ls
apache-kior-system_latest.tar.gz
[kior-oss@89790c086e28 ~]$ pwd
/sw

wget https://github.com/jo0ozip/kior-system-oss/raw/refs/heads/main/Apache/apache-kior-system_latest.tar.gz

[kior-oss@89790c086e28 ~]$ wget https://github.com/jo0ozip/kior-system-oss/raw/refs/heads/main/Apache/apache-kior-system_latest.tar.gz
--2026-01-05 01:27:53--  https://github.com/jo0ozip/kior-system-oss/raw/refs/heads/main/Apache/apache-kior-system_latest.tar.gz
Resolving github.com (github.com)... 20.200.245.247
Connecting to github.com (github.com)|20.200.245.247|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/jo0ozip/kior-system-oss/refs/heads/main/Apache/apache-kior-system_latest.tar.gz [following]
--2026-01-05 01:27:53--  https://raw.githubusercontent.com/jo0ozip/kior-system-oss/refs/heads/main/Apache/apache-kior-system_latest.tar.gz
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.108.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1850 (1.8K) [application/octet-stream]
Saving to: ‘apache-kior-system_latest.tar.gz’

apache-kior-system_l 100%[====================>]   1.81K  --.-KB/s    in 0s

2026-01-05 01:27:53 (10.4 MB/s) - ‘apache-kior-system_latest.tar.gz’ saved [1850/1850]


[kior-oss@89790c086e28 ~]$ ls
apache-kior-system_latest.tar.gz

설치 경로 생성

설치할 경로는 예시로 "/sw/apache" 진행합니다.

[kior-oss@89790c086e28 ~]$ mkdir -p /sw/apache
[kior-oss@89790c086e28 ~]$ cd /sw/apache
[kior-oss@89790c086e28 apache]$ pwd
/sw/apache

다운받은 TAR 파일을 해제하여 "tarballs" 라는 폴더 안에 필요한 모듈들을 받도록 하겠습니다.

[kior-oss@89790c086e28 ~]$ ls
apache-kior-system_latest.tar.gz

[kior-oss@89790c086e28 ~]$ tar -zxvf apache-kior-system_latest.tar.gz -C /sw/apache
bash_profile
shell/
shell/
1_install.sh shell/
0_check_env.sh tarballs/

[kior-oss@89790c086e28 ~]$ ls /sw/apache
bash_profile shell tarballs

[kior-oss@89790c086e28 ~]$ cd /sw/apache/tarballs
[kior-oss@89790c086e28 tarballs]$

이하 예시 내용은 curl 진행하도록 하겠습니다.

(당연히 wget으로 됩니다 !!)

OpenSSL 다운로드

curl -L -O https://github.com/openssl/openssl/releases/download/openssl-3.5.4/openssl-3.5.4.tar.gz

[kior-oss@89790c086e28 tarballs]$ curl -L -O https://github.com/openssl/openssl/releases/download/openssl-3.5.4/openssl-3.5.4.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 50.7M  100 50.7M    0     0  24.3M      0  0:00:02  0:00:02 --:--:-- 28.6M

[kior-oss@89790c086e28 tarballs]$ ls
openssl-3.5.4.tar.gz

apr 다운로드

curl -L -O https://dlcdn.apache.org//apr/apr-1.7.6.tar.gz

[kior-oss@89790c086e28 tarballs]$ curl -L -O https://dlcdn.apache.org//apr/apr-1.7.6.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1111k  100 1111k    0     0  2162k      0 --:--:-- --:--:-- --:--:-- 2162k

[kior-oss@89790c086e28 tarballs]$ ls
apr-1.7.6.tar.gz openssl-3.5.4.tar.gz

apr-util 다운로드

curl -L -O https://dlcdn.apache.org//apr/apr-util-1.6.3.tar.gz

[kior-oss@89790c086e28 tarballs]$ curl -L -O https://dlcdn.apache.org//apr/apr-util-1.6.3.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  543k  100  543k    0     0   592k      0 --:--:-- --:--:-- --:--:--  592k

[kior-oss@89790c086e28 tarballs]$ ls
apr-1.7.6.tar.gz apr-util-1.6.3.tar.gz openssl-3.5.4.tar.gz

pcre 다운로드

curl -L -O https://github.com/PCRE2Project/pcre2/releases/download/pcre2-10.47/pcre2-10.47.tar.gz

[kior-oss@89790c086e28 tarballs]$ curl -L -O https://github.com/PCRE2Project/pcre2/releases/download/pcre2-10.47/pcre2-10.47.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0
100 2727k  100 2727k    0     0   444k      0  0:00:06  0:00:06 --:--:--  444k

[kior-oss@89790c086e28 tarballs]$ ls
apr-1.7.6.tar.gz apr-util-1.6.3.tar.gz openssl-3.5.4.tar.gz pcre2-10.47.tar.gz

httpd 다운로드

curl -L -O https://dlcdn.apache.org/httpd/httpd-2.4.66.tar.gz

[kior-oss@89790c086e28 tarballs]$ curl -L -O https://dlcdn.apache.org/httpd/httpd-2.4.66.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 9597k  100 9597k    0     0  6730k      0  0:00:01  0:00:01 --:--:-- 6725k

[kior-oss@89790c086e28 tarballs]$ ls
apr-1.7.6.tar.gz apr-util-1.6.3.tar.gz httpd-2.4.66.tar.gz openssl-3.5.4.tar.gz pcre2-10.47.tar.gz

여기까지가 설치를 위한 파일들을 준비를 완료했습니다.

2026.01.08 기준으로 파일들은 LTS 또는 최신 버전으로 진행하였습니다.

✅ 설치하기

설치를 진행하기 위해서는 총 4단계로 진행됩니다.

1. 시스템 환경변수 설정
2. SHELL 실행

시스템 환경변수 설정

잘 따라서 오셨으면 "/sw/apache" 하위에 "bash_profile" 이라고 파일이 있습니다. (파일명이 .bash_profile 아님)

만약 없다면 "apache-kior-system_latest.tar.gz" 풀어서 적용하시면 됩니다.

적용하기 전에 'bash_profile' 파일에서 설정해야하는 부분을 먼저 수정합니다.

[kior-oss@89790c086e28 apache]$ vi bash_profile

...(생략)

export APACHE_HOME="/sw/apache"
export APACHE_ENGINE_HOME="/sw/apache/apache2.4"
export APACHE_LIBS_HOME="${APACHE_HOME}/apache-libs"
export APACHE_LOG_HOME="/sw/apache/apache2.4/log"

export VER_OPENSSL="openssl-3.5.4" //tarballs에 있는 TAR의 버전을 기입 하기 동일.
export VER_PCRE2="pcre2-10.47"
export VER_APR="apr-1.7.6"
export VER_APRUTIL="apr-util-1.6.3"

(생략)...

[kior-oss@89790c086e28 apache]$ ls
bash_profile shell tarballs
[kior-oss@89790c086e28 apache]$ cp -rp bash_profile ~/.bash_profile
[kior-oss@89790c086e28 apache]$ source ~/.bash_profile

[kior-oss@89790c086e28:/sw/apache]$ echo ${APACHE_HOME}
/sw/apache

SHELL 실행

설치를 위한 준비는 끝났습니다! SHELL를 실행합니다!

[kior-oss@89790c086e28:/sw/apache/shell]$ ls
0_check_env.sh 1_install.sh
[kior-oss@89790c086e28:/sw/apache/shell]$ sh 0_check_env.sh ######################################################
# Apache Build Environment Check @BLOG_KIOR ######################################################
[INFO] Checking build tools
✘ gcc: not installed
✘ make: not installed
✘ perl: not installed
✔ tar: installed (/bin/tar)

[INFO] Checking development library packages
✘ expat-devel: not installed
✘ zlib-devel: not installed

[Done] Apache build environment check completed.

체크 하였을때 필요한 패키지 도구들이 설치 되어 있지 않는 경우가 있습니다.

yum/dnf 같은 패키지 매니저를 통해서 다운하도록 합니다.

[Help command: yum install -y gcc make perl expat-devel zlib-devel ]

패키지가 설치되면 다시 한번 확인하고 다음으로 넘어갑니다.

######################################################
# Apache Build Environment Check @BLOG_KIOR ######################################################
[INFO] Checking build tools
✔ gcc: installed (/usr/bin/gcc)
✔ make: installed (/usr/bin/make)
✔ perl: installed (/usr/bin/perl)
✔ tar: installed (/usr/bin/tar)

[INFO] Checking development library packages
✔ expat-devel: installed
✔ zlib-devel: installed

[Done] Apache build environment check completed.

[kior-oss@89790c086e28:/sw/apache/shell]$ ls
0_check_env.sh 1_install.sh
[kior-oss@89790c086e28:/sw/apache/shell]$ sh 1_install.sh
[STEP 0/5] Extracting tarballs...
✔ Tarballs extracted.
[STEP 1/5] Building OpenSSL...
→ \

( @분 완료 )

[kior-oss@89790c086e28:/sw/apache/shell]$ sh 1_install.sh

[STEP 0/5] Extracting tarballs...
✔ Tarballs extracted.
[STEP 1/5] Building OpenSSL...
✔ OpenSSL build completed.
[STEP 2/5] Building APR...
✔ APR build completed.
[STEP 3/5] Building APR-util...
✔ APR-util build completed.
[STEP 4/5] Building PCRE...
✔ PCRE build completed.
[STEP 5/5] Building Apache HTTPD...
→ /
✔ Apache HTTPD build completed.

✅ 설치완료

설치가 완료되면 우선 버전정보와 load된 모듈을 확인합니다.
그 후 기동하여 Welcome 페이지를 호출합니다.

[kior-oss@89790c086e28:/sw/apache/shell]$ httpd -V
Server version: Apache/2.4.66 (Unix)
Server built: Jan 8 2026 20:07:47
Server's Module Magic Number: 20120211:141
Server loaded: APR 1.7.6, APR-UTIL 1.6.3, PCRE 10.47 2025-10-21
Compiled using: APR 1.7.6, APR-UTIL 1.6.3, PCRE 10.47 2025-10-21
Architecture: 64-bit
Server MPM: worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/sw/apache/apache2.4"
-D SUEXEC_BIN="/sw/apache/apache2.4/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"

# 리눅스는 1024이하에서 ROOT 권한이 있어야 바인딩이 가능!(Docker와 같은 환경은 제외)
[root@89790c086e28 /]# id
uid=0(root) gid=0(root) groups=0(root)

[root@89790c086e28 /]# setcap 'cap_net_bind_service=+ep' /sw/apache/apache2.4/bin/httpd

[kior-oss@89790c086e28:/sw]$ apachectl start
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message

[kior-oss@89790c086e28:/sw]$ ps -ef | grep httpd
kior-oss 74 1 0 23:13 ? 00:00:00 /run/rosetta/rosetta /sw/apache/apache2.4/bin/httpd /sw/apache/apache2.4/bin/httpd -k start
kior-oss 75 74 0 23:13 ? 00:00:00 /run/rosetta/rosetta /sw/apache/apache2.4/bin/httpd /sw/apache/apache2.4/bin/httpd -k start
kior-oss 76 74 0 23:13 ? 00:00:00 /run/rosetta/rosetta /sw/apache/apache2.4/bin/httpd /sw/apache/apache2.4/bin/httpd -k start
kior-oss 77 74 0 23:13 ? 00:00:00 /run/rosetta/rosetta /sw/apache/apache2.4/bin/httpd /sw/apache/apache2.4/bin/httpd -k start

[kior-oss@89790c086e28:/sw]$ netstat -an | grep 80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

apache 기동시 Warning LOG

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message

# 서비스에는 무관합니다
1. Apache가 자신의 서버의 FQDN(정규 도메인 이름) 찾지 못함
2. 임시로 IP주소(172.17.0.2)를 부여
3. 경고를 없애기 위해서는 httpd.conf에 ServerName 명시적으로 설정

마무리

apache 설치를 조금 더 편안하게 할 수 있도록 작성한 포스팅입니다.

아래의 순서를 정리해두도록 하겠습니다.

+ GitHub에서 TAR 다운로드
+ 설치 서버에서 경로생성 및 TAR 묶음 해제
+ tarballs 폴더에 컴파일할 패키지 다운로드
+ 시스템 환경변수 설정
+ SHELL 실행

Apache 설치를 위한 SHELL은 2025년도 부터 준비했던 건데...

핑계를 두며 미루다 2026년에 되어서 마무리하게 되었습니다...

미루지 말고 바로바로 올리도록!

What does it mean? 기계어 ~ IDE

KO_O — Mon, 5 Jan 2026 08:00:42 +0900

What is mean?

기계어 / 어셈블리어 / 저수준 언어 / 고수준 언어 / 컴파일러 / 인터프리터 / IDE 같은 용어들은 개발을 시작할 때 가장 먼저 만나는 개념입니다. 처음엔 비슷해 보여도 컴퓨터가 이해하는 방식과 사람이 작성하는 방식의 차이를 기준으로 정리하면 훨씬 깔끔해집니다.

기계어(Machine Language)란?

기계어는 컴퓨터(CPU)가 직접 이해하고 실행할 수 있는 언어이며, 0과 1(이진수)로 이루어져 있습니다.

컴퓨터 입장에서는 가장 자연스러운 언어(= 바로 실행 가능)
사람 입장에서는 읽고 쓰기 어렵고 실수하기 쉬움

예를 들어, 우리가 “더하기”를 하고 싶다고 해도 컴퓨터는 0101 같은 비트 단위 명령으로 받아들입니다.

즉, 기계어는 사람이 아니라 CPU를 위한 언어라고 보면 됩니다.

어셈블리어(Assembly Language)란?

어셈블리어는 기계어를 사람이 알아보기 쉬운 기호(니모닉) 형태로 표현한 언어입니다.

기계어를 그대로 쓰기 어렵기 때문에 등장
기계어와 1:1로 대응되는 명령이 많음
CPU/아키텍처에 따라 문법과 명령이 달라짐 (예: x86, ARM)

즉, 기계어를 사람이 조금이라도 읽을 수 있게 "번역해 둔 표현 방식"이라고 이해하면 좋아요.

저수준 언어 vs 고수준 언어

✅ 저수준 언어(Low-level Language)

저수준 언어는 기계(하드웨어)에 가까운 언어입니다.

대표적으로 기계어, 어셈블리어
하드웨어 제어에 유리하지만 사람이 쓰기 불편
CPU 구조/레지스터/메모리 같은 개념과 밀접

✅ 고수준 언어(High-level Language)

고수준 언어는 사람이 이해하기 쉬운 표현에 가까운 언어입니다.

대표적으로 C, C++, Java, Python, JavaScript 등
문법이 사람에게 익숙하고, 생산성이 높음
대신 실행을 위해서는 결국 기계어로 변환 과정이 필요

정리하면, 저수준 언어 > 컴퓨터가 좋아하는 방식, 고수준 언어 > 사람이 좋아하는 방식

프로그래밍 언어란?

프로그래밍 언어는 컴퓨터와 소통하기 위해 만들어진 언어입니다.

사람이 “무엇을 하고 싶은지”를 코드로 표현
컴퓨터가 이해할 수 있도록 결국 기계어로 변환되어 실행

우리가 작성하는 대부분의 코드는 고수준 언어이고, 컴퓨터가 실제로 실행하는 것은 기계어입니다.

그래서 변환해주는 도구 > 대표가 바로 컴파일러/인터프리터입니다.

컴파일 언어 vs 인터프리터 언어

✅ 컴파일 언어(Compiled Language)

컴파일 언어는 소스 코드 전체를 한 번에 기계어로 변환해 실행 파일을 만든 뒤 실행합니다.

코드 전체를 번역(컴파일) → 실행 파일 생성 → 실행
한 번 만들어진 실행 파일은 빠르게 실행되는 경우가 많음
대표 예시: C, C++ (일반적으로 이런 방식으로 분류)

✅ 인터프리터 언어(Interpreted Language)

인터프리터 언어는 코드를 한 줄(또는 한 단위씩) 읽으면서 해석하고 바로 실행합니다.

실행 파일을 “미리” 만들기보다, 실행 시점에 해석하면서 동작
즉시 실행이 쉬워 학습/개발 속도가 빠른 편
대표 예시: Python, JavaScript (일반적으로 이런 방식으로 분류)

컴파일 > 미리 번역해서 실행 파일 만들고 실행
인터프리터 > 실행하면서 바로바로 해석

*참고로 실제 구현은 언어/환경에 따라 혼합(JIT 등)되는 경우도 많지만, 입문 단계에서는 위 구분으로 이해하면 가장 좋습니다.

IDE란?

IDE(Integrated Development Environment)는 개발에 필요한 기능을 한 번에 제공하는 통합 개발 환경입니다.

즉, 코딩만 할 수 있는 단순 편집기가 아니라, 개발 생산성을 높이기 위한 도구들이 묶여 있는 “개발용 프로그램”이에요.

✅ IDE가 보통 제공하는 기능

코드 편집 (문법 하이라이트, 자동 들여쓰기)
자동완성 (코드 추천, 함수/변수 추적)
디버깅 (브레이크포인트, 변수 값 확인)
빌드/실행 (컴파일 및 실행 버튼으로 동작)
프로젝트 관리 (폴더 구조, 의존성 관리)

대표적으로 IntelliJ IDEA, Eclipse, Visual Studio, VS Code(확장 포함) 같은 것들이 여기에 해당합니다.

마무리

처음에는 용어가 복잡해 보이지만, 이렇게 정리하면 의외로 단순합니다.

+ 기계어 = 컴퓨터가 직접 실행하는 0과 1
+ 어셈블리어 = 기계어를 사람이 읽을 수 있게 기호로 표현
+ 저수준 언어 = 기계에 가까움 (기계어/어셈블리어)
+ 고수준 언어 = 사람에 가까움 (Java, Python 등)
+ 프로그래밍 언어 = 컴퓨터와 소통하기 위한 언어
+ 컴파일 언어 = 미리 번역해 실행 파일 생성 후 실행
+ 인터프리터 언어 = 실행하면서 한 줄씩 해석
+ IDE = 개발에 필요한 기능을 통합 제공하는 프로그램

프로그래밍 공부는 부지런히...

What does it mean? 코딩 vs 프로그래밍

KO_O — Fri, 2 Jan 2026 19:14:42 +0900

What is mean?

오늘날 IT 산업은 우리 생활 곳곳에 깊숙이 자리 잡고 있습니다. 하지만 IT 분야에 처음 진입할 때는 용어의 어려움이 진입 장벽으로 느껴지기도 합니다. 이번에는 코딩과 프로그래밍, 앱과 프로그램의 차이와 함께 관련된 용어들의 의미를 정리해보겠습니다.

IT를 처음 접하면 자주 마주치는 질문입니다. 용어가 비슷하게 쓰이다 보니 더 헷갈리죠.

이번 글은 딱 7가지 키워드로 개념을 깔끔하게 잡는 것이 목표입니다.

코딩 (Coding)
프로그래밍 (Programming)
개발 (Development)
소프트웨어 (Software)
프로그램 (Program)
데이터 (Data)
라이브러리 (Library)

✅ 코딩(Coding): "코드를 입력하는 작업 자체"

코딩은 프로그래밍 언어로 된 코드(문장)를 작성하는 행위를 말합니다.
예를 들면 Python으로 print("Hello")를 쓰거나, Java로 Controller 클래스를 만드는 것입니다.

즉, 코딩은 손으로 코드를 입력해 컴퓨터가 이해할 수 있는 형태로 옮기는 작업에 가깝습니다.

(문법, 변수, 조건문, 반복문 같은 요소들이 코딩의 단골손님이죠.)

✅ 프로그래밍(Programming): "절차와 알고리즘을 설계하는 것"

프로그래밍은 코딩보다 더 넓은 범위를 가집니다.

무엇을 만들지 요구사항을 정리
어떤 순서로 처리할지 절차(로직)를 수립
효율적으로 처리하기 위해 알고리즘을 선택
예외 상황, 성능, 테스트까지 고려

이 모든 과정을 통칭합니다. 그래서 흔히 "코딩은 프로그래밍의 일부"라고 말합니다.

✅ 개발(Development)

현재는 역할이 세분화되어 다양한 직무로 존재합니다. 개발이라는 용어는 여전히 가장 자주 쓰이며 포괄적인 의미를 가집니다.

개발은 소프트웨어를 설계(Architecture)하고, 구현(Implementation)하며, 배포 및 운영(Operations), 유지보수(Maintenance)까지 포함하는 전반적인 기술 과정을 통칭합니다. 즉, 개발은 코딩과 프로그래밍을 모두 포함하는 상위 개념입니다.

형상관리(Git), 빌드/배포(CI/CD)
모니터링/로그/장애 대응
보안(권한/취약점), 성능 튜닝
문서화, 협업 프로세스

✅ 소프트웨어(Software)

컴퓨터의 하드웨어가 본체, CPU, 메모리처럼 물리적으로 눈에 보이고 만져지는 부분이라면,
소프트웨어는 반대로 보이지 않는 요소들(명령·규칙·로직·프로그램·데이터 등)을 통칭합니다.

✅ 프로그램(Program): "목적에 맞는 작업을 수행하는 명령 모음"

프로그램은 사용자의 명령에 따라 목적에 맞는 작업을 수행하는 일련의 명령(Instruction)들의 모음입니다.

핵심은 “프로그램은 실행 가능한 형태로 정리된 명령의 집합”이라는 점입니다.

시스템 프로그램 vs 응용 프로그램
프로그램은 크게 두 종류로 나눠 이해하면 깔끔합니다.
+ 시스템 프로그램: 운영체제(OS)처럼 컴퓨터 이용 환경을 제공하는 프로그램
+ 응용 프로그램: 사용자가 목적에 따라 직접 사용하는 프로그램

앱(App)과 프로그램(Program)은 뭐가 달라?
현대에는 “앱”이라는 단어가 널리 쓰이면서, 앱과 프로그램이 혼용되기도 합니다.
+ 프로그램: 실행 가능한 소프트웨어 전반을 의미하는 큰 개념
+ 앱(App): 주로 사용자가 직접 실행하는 응용 프로그램을 친근하게 부르는 말

즉, 대부분의 앱은 프로그램의 한 종류라고 보면 됩니다.

✅ 데이터(Data)

데이터는 프로그램이 작업을 수행하는 데 필요한 기초 자료를 말합니다.
숫자, 문자열, 이미지, 파일, DB 레코드, 로그 등 "처리 대상"은 대부분 데이터에 해당합니다.

그래서 같은 프로그램이라도 어떤 데이터를 입력하느냐에 따라 결과는 완전히 달라질 수 있습니다.

✅ 라이브러리(Library)

라이브러리는 하나 이상의 프로그램에서 활용할 수 있도록 정리된 데이터와 명령어(함수·클래스)의 집합입니다.

"필요할 때 가져다 쓰는 도구 상자"라고 생각하면 이해하기 쉽습니다.

로그를 남기기 위한 로깅 라이브러리
DB 접속을 위한 JDBC 드라이버
HTTP 호출을 위한 클라이언트 라이브러리

라이브러리를 잘 활용하면, 검증된 기능을 빠르게 조합할 수 있어 개발 속도와 품질을 함께 높일 수 있습니다.

마무리

처음에는 용어가 복잡해 보이지만, 이렇게 정리하면 의외로 단순합니다.

+ 코딩은 쓰는 것
+ 프로그램은 설계+구현
+ 개발은 전 과정
+ 소프트웨어 > 프로그램(데이터 처리, 데이터 처리 과정에서 라이브러리 활용)

2026년 시작되면서 다시 예전처럼 모든 기록을 남기기로 마음을 먹어서 Restart!

작년(2025) 여러 일과 기대했던 일들이 잘 풀리지 않으면서 정신적 휴식을 했던거 같습니다.

이제는 다시 열공 모드로 도움이 될 포스팅을 꾸준하게 남기도록 하겠습니다 :)

애매했던 것들 부터 정리하려고 합니다

What does it mean? Developer(개발자)

KO_O — Mon, 15 Sep 2025 22:29:11 +0900

What is mean?

오늘날 IT 산업은 우리 생활 곳곳에 깊숙이 자리 잡고 있습니다. 그 중심에는 개발자라는 직업이 있습니다. 개발자는 단순히 코드를 작성하는 사람을 넘어, 세상에 새로운 가치를 만드는 창조자이자 문제 해결사라고 할 수 있습니다. 이번 글에서는 개발자의 전반적인 의미와 다양한 분야별 역할을 정리해보겠습니다.

통상적인 개발자 설명

개발자는 컴퓨터 프로그램을 설계, 구현, 유지보수하는 사람을 뜻합니다.

소프트웨어, 웹, 모바일, 게임 등 다양한 분야에서 활동하며, 요구사항을 분석하고 이를 코드로 옮기는 과정이 핵심 역할입니다.

즉, 문제를 해결하기 위해 기술을 활용하는 전문가라고 할 수 있습니다.

✅ 웹 개발자

웹 개발자는 인터넷 환경에서 동작하는 웹사이트나 웹 애플리케이션을 만드는 사람입니다.

프론트엔드와 백엔드를 구분하여 각각의 역할을 수행하기도 하며, 전체를 아우르는 경우도 있습니다.

주요 기술로는 HTML, CSS, JavaScript, 그리고 서버 개발 언어 및 데이터베이스가 있습니다.

✅ 웹 퍼블리셔 / UI 개발자

웹 퍼블리셔는 웹 디자이너가 만든 시안을 실제 화면으로 구현하는 역할을 담당합니다.

HTML과 CSS를 통해 구조와 스타일을 만들고, 사용자에게 보기 좋은 화면을 제공합니다.

UI 개발자는 사용자 경험(UX)을 고려한 인터페이스를 구현하여 사용자가 편리하게 서비스를 이용할 수 있도록 합니다.

✅ 프론트엔드 개발자

프론트엔드 개발자는 사용자가 직접 보는 영역, 즉 브라우저 화면을 개발합니다.

React, Vue, Angular 같은 프레임워크를 활용하며, 사용자 경험과 성능을 동시에 고려해야 합니다.

디자인 감각과 프로그래밍 기술이 모두 요구되는 직무입니다.

✅ 백엔드 개발자

백엔드 개발자는 서버와 데이터베이스를 다루며, 보이지 않는 부분에서 핵심 로직을 담당합니다.

회원 관리, 결제 시스템, 데이터 처리 등 서비스의 본질적인 기능을 구현합니다.

Java, Spring, Node.js, Python, Go 등의 언어와 프레임워크가 주로 사용됩니다.

✅ 풀스택 개발자

풀스택 개발자는 프론트엔드와 백엔드 모두를 이해하고 구현할 수 있는 개발자입니다.

작은 스타트업이나 프로토타입 개발에서 특히 유용하며, 넓은 범위의 기술 스택을 다루는 만큼 학습량이 많습니다.

✅ 모바일 개발자

모바일 개발자는 스마트폰과 태블릿 환경에서 동작하는 앱을 개발합니다.

대표적으로 iOS(Swift, Objective-C)와 Android(Java, Kotlin)가 있으며, 최근에는 Flutter, React Native 같은 크로스 플랫폼 기술도 활용됩니다.

✅ 게임 개발자

게임 개발자는 엔진(Unity, Unreal Engine 등)을 활용하여 게임을 구현합니다.

그래픽, 사운드, 물리 연산 등을 종합적으로 다루며, 창의성과 기술력이 동시에 요구됩니다.

대규모 온라인 게임부터 인디게임까지 다양한 분야가 존재합니다.

✅ 응용 소프트웨어 개발자

응용 소프트웨어 개발자는 특정 목적에 맞는 프로그램을 제작합니다.

예를 들어 회계 관리 프로그램, 영상 편집 소프트웨어, CAD 프로그램 등이 이에 해당합니다.

사용자의 요구사항을 분석해 최적의 기능을 구현하는 것이 중요합니다.

✅ 임베디드 개발자

임베디드 개발자는 하드웨어와 밀접한 소프트웨어를 개발합니다.

IoT 기기, 가전제품, 자동차 시스템 등에서 활약하며, C, C++ 언어가 많이 쓰입니다.

제한된 자원(메모리, CPU)을 고려해 최적화된 코드를 작성하는 능력이 필요합니다.

✅ 정보 보안 전문가

정보 보안 전문가는 시스템과 데이터를 해킹으로부터 지키는 역할을 합니다.

취약점을 분석하고, 방화벽·침입 탐지 시스템 등을 설계·운영합니다.

보안 사고가 빈번한 시대에 점점 더 중요해지고 있는 분야입니다.

❓ 해커와 크래커

보안 분야에서 종종 등장하는 용어로 해커와 크래커가 있습니다.

해커는 원래 기술적 호기심으로 시스템을 탐구하는 사람을 의미했지만, 오늘날에는 보안 전문가로 불리기도 합니다.

반면 크래커는 악의적으로 시스템을 침투하거나 파괴하는 사람을 뜻합니다.

✅ AI 개발자

AI 개발자는 인공지능 기술을 활용해 서비스를 개발하는 사람입니다.

머신러닝, 딥러닝, 자연어 처리, 컴퓨터 비전 등이 주요 분야입니다.

Python, TensorFlow, PyTorch 같은 프레임워크를 다루며, 데이터와 알고리즘에 대한 깊은 이해가 필요합니다.

마무리

2025년 8월 ~9월 중순이 될때 까지 너무 바쁜 일정을 보냈습니다.

흐릿해지는 개념을 다시 기억하고자 "Basic IT" 라는 카테코리를 시작하기로 했습니다 :)

초장기에 지식의 공백이 느껴질 때 서점에서 구매한 '혼자 공부하는 얄팍한 코딩지식'을 다시 보면서 기록하려고 합니다~

'개발자'라는 직업을 고민하는 분들에게 도움이 되는 마음으로 저의 경험을 남겨두겠습니다.

학부 시절에는 새로운 언어와 끊임없는 기술을 학습해야하는 것을 어려움을 느낄때

좋은 기회로 '미들웨어 엔지니어'를 할 수 있게 되었습니다.

그리고 석사를 졸업하고 현재는 미들웨어 엔지니어로써 방화벽, 네트워크, 각 솔루션, Cloud Platform을 공부합니다.

그렇지만 개발 언어 공부도 합니다.

결론은... 둘다 해야합니다.

자신의 주로 쓰는 손이 오른쪽? 왼쪽? 차이 일뿐 결국 두 손을 사용하여 박수를 칠 수 있도록 단련해야합니다.

자신의 흥미가 어느쪽에 있을지 고민해보세요 :)

Tomcat Session Clustering on Kubernetes

KO_O — Wed, 16 Jul 2025 17:52:11 +0900

Apache Tomcat은 경량의 오픈소스 웹 애플리케이션 서버입니다.

서블릿과 JSP를 실행할 수 있는 Java 기반 서버로, 개발과 운영 모두에 유용합니다.

SET Tomcat 9 Kubernetes Cluster

Tomcat을 Kubernetes 환경에서 클러스터링(세션 복제)하기 위해 과거에는 DNS_PING, KUBE_PING 등의 방식이 사용되었지만, Tomcat 9 이후부터는 Apache에서 직접 제공하는 CloudMembershipService 기반의 KUBE_API 방식이 공식적으로 권장되고 있습니다.

이 방식은 Kubernetes API를 직접 호출하여 현재 클러스터 내에서 실행 중인 Tomcat Pod를 확인하고, 클러스터를 동적으로 구성합니다.

#. `server.xml` 클러스터 설정 예시

Tomcat의 $CATALINA_BASE/conf/server.xml에 아래 내용을 추가합니다.

  <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
    <Channel className="org.apache.catalina.tribes.group.GroupChannel">
      <Membership
        className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService">
        <!-- Kubernetes API를 통한 클러스터 구성 -->
        <!-- 옵션: namespace, labelSelector 지정 가능 -->
        <!--
        <Property name="namespace" value="kior-system"/>
        <Property name="labelSelector" value="app=oss-tomcat"/>
        -->
      </Membership>
    </Channel>

    <Manager className="org.apache.catalina.ha.session.BackupManager"
             expireSessionsOnShutdown="false"
             notifyListenersOnReplication="true"/>
  </Cluster>

#. SET serviceAccount & RBAC

CloudMembershipService는 Kubernetes API를 조회하기 때문에, Tomcat Pod에 ServiceAccount와 RBAC(RoleBinding)을 부여해야 합니다.

# sa-rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-tomcat
  namespace: kior-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: r-tomcat-cluster
  namespace: kior-system
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rb-tomcat-cluster
  namespace: kior-system
subjects:
- kind: ServiceAccount
  name: sa-tomcat
  namespace: kior-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: r-tomcat-cluster

#. APPLY k8s deployment

# deployment_tomcat9.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kior-tomcat9
  namespace: kior-system
spec:
  replicas: 3
  selector:
    matchLabels:
      app: oss-tomcat
  template:
    metadata:
      labels:
        app: oss-tomcat
    spec:
      serviceAccountName: sa-tomcat
      containers:
      - name: tomcat
        image: kior-system-oss-tomcat9:v107
        imagePullPolicy: Never
        ports:
        - containerPort: 8080          # HTTP
        env:
            - name: KUBERNETES_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace

⚙️ Prompt

# 이미지 생성

# namespace 생성
  KIOR  k create ns kior-system
namespace/kior-system created

# serviceAccout + RBAC 생성
  KIOR  k apply -f sa-rbac.yaml
serviceaccount/sa-tomcat created
role.rbac.authorization.k8s.io/r-tomcat-cluster created
rolebinding.rbac.authorization.k8s.io/rb-tomcat-cluster created

# deployment
  KIOR  k apply -f deployment-tomcat9.yaml
deployment.apps/kior-tomcat9 created

세션 복제 확인

[CloudMembership-memberAdded] 스레드가 동작함을 확인할 수 있습니다.

# POD list 확인
  KIOR  k get po
NAME                           READY   STATUS    RESTARTS   AGE
kior-tomcat9-c999b64ff-2rq82   1/1     Running   0          2m26s
kior-tomcat9-c999b64ff-bx4lp   1/1     Running   0          2m26s
kior-tomcat9-c999b64ff-xhn2r   1/1     Running   0          2m26s

# Tomcat 로그 확인
 ✘   KIOR  k logs kior-tomcat9-c999b64ff-2rq82
(... 생략)

16-Jul-2025 08:37:16.518 INFO [main] org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal Cluster is about to start
16-Jul-2025 08:37:16.616 INFO [main] org.apache.catalina.tribes.transport.ReceiverBase.bind Receiver Server Socket bound to:[/10.244.0.26:4000]
16-Jul-2025 08:37:17.801 INFO [Tribes-Task-Receiver[Catalina-Channel]-1] org.apache.catalina.tribes.io.BufferPool.getBufferPool Created a buffer pool with max size:[104857600] bytes of type: [org.apache.catalina.tribes.io.BufferPool15Impl]
16-Jul-2025 08:37:18.193 INFO [CloudMembership-memberAdded] org.apache.catalina.ha.tcp.SimpleTcpCluster.memberAdded Replication member added:[org.apache.catalina.tribes.membership.MemberImpl[tcp://10.244.0.25:4000,10.244.0.25,4000, alive=8687, securePort=-1, UDP Port=-1, id={-85 -79 -12 -111 43 48 -7 16 -58 -19 -22 -1 -45 -92 -26 101 }, payload={}, command={}, domain={}]]
16-Jul-2025 08:37:18.195 INFO [CloudMembership-memberAdded] org.apache.catalina.ha.tcp.SimpleTcpCluster.memberAdded Replication member added:[org.apache.catalina.tribes.membership.MemberImpl[tcp://10.244.0.24:4000,10.244.0.24,4000, alive=8687, securePort=-1, UDP Port=-1, id={-107 -44 66 28 -54 -35 97 -23 -100 -90 -87 -90 93 -35 86 -54 }, payload={}, command={}, domain={}]]

(...생략)
16-Jul-2025 08:37:24.293 INFO [main] org.apache.catalina.ha.session.JvmRouteBinderValve.startInternal JvmRouteBinderValve started
16-Jul-2025 08:37:24.303 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
16-Jul-2025 08:37:24.317 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [8222] milliseconds

`<distributable/>` 반드시 추가

<distributable/> 태그는 세션 복제를 위한 필수 조건입니다.

Tomcat 클러스터가 아무리 잘 설정되어 있더라도, web.xml에 이 태그가 누락되면 세션 복제는 절대 수행되지 않습니다.

✅ 왜 필요한가?

Tomcat은 <distributable/> 태그가 있는 WAR 파일만 세션 공유 대상으로 간주합니다.
태그가 없으면 BackupManager 또는 DeltaManager가 있어도 복제가 이루어지지 않습니다.
이는 J2EE 명세와 Tomcat 클러스터 정책에 따른 것입니다.

✅ 예시: `web.xml` 설정

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

  <!-- 세션 복제를 활성화하기 위한 필수 태그 -->
  <distributable/>

  <session-config>
    <session-timeout>30</session-timeout>
  </session-config>

  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

</web-app>

Java 11 이상에서 발생할 수 있는 TLS 1.3 프로토콜의 handshake 호환성 문제

Caused by: javax.net.ssl.SSLHandshakeException: extension (5) should not be presented in certificate_request

원인 분석

CloudMembershipService는 내부적으로 HttpsURLConnection을 이용해 Kubernetes API에 접근합니다.

이때 Java11 이상에서는 기본적으로 TLS 1.3을 사용함으로 Kubernetes 일부 API 서버와 호환이 안될 수 있습니다.

✅ 방법: TLS 1.2로 강제 다운그레이드 (가장 간단하고 효과적)

Tomcat 실행 시 Java 옵션에 TLS 버전 제한을 추가합니다.

-Djdk.tls.client.protocols=TLSv1.2

✅ 결론

Tomcat 9 이상에서는 Kubernetes 환경에서 클러스터링을 구성할 때 CloudMembershipService를 사용하는 것이 공식 권장 방식입니다.

Kubernetes 환경에서의 Tomcat 세션 클러스터링은 고가용성과 무중단 서비스를 구현하는 데 중요한 요소입니다.

분명한 제한점은 있지만 유용하게 사용할 수 있습니다.