리닝's reframe

이번 프로젝트에서는 외부 시스템에서 MQTT로 메세지를 받아서 처리하는 로직을 개발하게 되었다.

처음에는 메세지 포맷을 XML로 할지, JSON으로 할지 팀 내에서 고민을 꽤 했다.
각자 장단점이 있어서 쉽게 결정을 못 했지만, 최종적으로는 JSON을 선택하게 되었다.

그 과정에서 정리해본 JSON vs XML 비교 내용을 간단히 공유해본다.
(개발하면서 꽤 자주 부딪히는 주제라 정리해두면 나중에 또 쓸 일이 있을 듯.)

✅ JSON의 장점

1. 가볍고 간결하다
JSON은 불필요한 태그 없이 딱 필요한 데이터만 담을 수 있어서
메시지 크기를 줄이기에 좋다.
→ MQTT처럼 네트워크 효율이 중요한 환경에 유리

2. 파싱이 쉽고 빠르다
대부분의 언어에서 기본적으로 지원되는 JSON 파서 덕분에
별다른 설정 없이 바로 객체로 변환해서 사용할 수 있다.

3.가독성이 좋다
구조가 단순해서 눈으로 봤을 때 이해하기 쉽고,
디버깅이나 로그 확인 시에도 편리하다.

📄 XML의 장점

1. 스키마 기반의 명확한 구조 정의 가능
XSD를 이용해 구조를 엄격하게 정의할 수 있어서
서로 다른 시스템 간 데이터 계약이 확실해진다.

2. 속성과 값을 구분할 수 있다
JSON은 key-value 형태뿐이지만,
XML은 <태그 속성="값">처럼 더 다양한 표현이 가능하다.

3. 복잡한 데이터 구조 표현에 강하다
중첩 구조나 반복되는 항목 등 복잡한 계층적 구조를 표현하기에 XML이 더 직관적일 수 있다.

4. 레거시 시스템과의 호환성
정부 시스템이나 오래된 기업 시스템은 아직도 XML을 표준 포맷으로 사용하는 경우가 많다.

✅ 그럼에도 우리가 JSON을 선택한 이유

• 실시간으로 빠르게 메세지를 주고받아야 했고
• 메시지 크기는 작을수록 좋았고
• 복잡한 구조보다는 간단한 key-value 위주 데이터였고
• 양쪽 시스템 모두 JSON 파싱에 문제 없었기 때문에
• 이후 해당 데이터를 가지고 검색을 할 경우 훨씬 간단하게 데이터 탐색이 가능해

결국 JSON이 가장 적합한 선택이었다.

물론 상대 시스템에서 XML만 지원했으면 다른 선택을 했겠지만,
이번엔 유연하게 결정할 수 있었기 때문에 효율적인 JSON을 사용하는 쪽으로 정리되었다.

💬 마무리

이런 선택의 상황은 프로젝트마다 자주 나타나는 것 같다.
정답은 없고, 상황에 맞는 적절한 포맷을 고르는 게 중요하다고 느꼈다.

혹시 비슷한 고민을 하고 있다면,
이 정리가 참고가 되었으면 좋겠다!

우연히 유지보수 하는 업체에서 암호화를 해야한다며 요청이 왔다(공공기관) 

당연히 우리는 흔히 사용하는 ARIA 나 AES 를 사용하고 있는 줄 알았는데 

 솔루션이 버젼업 하면서 새로운 암호화를 채택했다고 하여 정리한다!

1. Threefish 개요

Threefish는 2008년, NIST SHA-3 해시 함수 공모전을 위해 설계된 해시 함수인 Skein의 핵심 블록 암호입니다. 일반적인 블록 암호와 달리 Threefish는 비트 조작 기반 구조로 되어 있으며, 특히 고속 처리와 단순한 구조, 그리고 암호학적 강인성을 목표로 설계되었습니다.

Threefish는 독립적으로도 사용할 수 있지만, 보통은 Skein 해시 함수의 내부에서 블록 암호로 동작합니다.

2. 주요 특징

3. ARX 구조란?

Threefish는 S-box 없이, 아래 3가지 연산만으로 구성됩니다:

• Add: 모듈로 덧셈 (+ mod 2^64)
• Rotate: 비트 회전
• XOR: 배타적 논리합

이런 구조는 다음과 같은 장점을 가집니다:

• 구현이 간단하다
• 병렬화가 쉽다
• 하드웨어에서 빠르다
• 분석이 어렵다 (암호학적 강인성)

4. Threefish의 구성

Threefish는 다음과 같은 순서로 작동합니다:

1. 입력 분할: 입력 메시지를 64비트 단위로 나눔
2. 라운드 반복:
   • 각 라운드에서 Mix 연산 수행 (두 단어를 add, rotate, xor)
   • 몇 라운드마다 Subkey를 주입
3. 최종 출력: 마지막 라운드 후 상태를 결합해 출력

5. Threefish의 보안성

Threefish는 다음과 같은 공격에 대한 강한 저항성을 가지고 있습니다:

• 차분 공격
• 선형 공격
• 관련 키 공격
• Meet-in-the-middle 공격

또한, 설계 당시 많은 전문가들이 분석했지만 심각한 취약점이 발견되지 않았습니다.

6. 왜 Threefish인가?

Threefish는 다음과 같은 이유로 주목받았습니다 :)

• 해시 함수 Skein의 핵심 구성요소로 사용
• 대용량 데이터 암호화에 적합한 1024비트 블록
• 단순하고 빠른 구조
• 포스트-SHA2 시대의 대안 블록 암호 후보

🔄 AES vs ARIA vs Threefish 비교

가장 많이 쓰는 암호화 함수들과 비교해본다! 

🔍 좀 더 쉽게 요약하면...

💬 어느 걸 써야 할까?

📝 마무리 요약

• AES: 글로벌 스탠다드. 빠르고 검증됨.
• ARIA: 국내 전용 AES. 공공 프로젝트에서 필수.
• Threefish: S-box 없이 단순하지만 강력한 구조. Skein 해시와 함께 사용됨.

💡 참고: Skein은 최종 SHA-3 해시로 선택되진 않았지만, Threefish의 설계 철학과 구조는 이후 여러 연구에 영감을 주었습니다.

  참고 자료

• Skein 공식 문서: https://www.schneier.com/academic/skein/
• NIST SHA-3 공모전 자료
• Wikipedia - Threefish: https://en.wikipedia.org/wiki/Threefish

📘 스레드 풀(Thread Pool)을 왜 지정해야 할까?

서버에서 여러 사용자의 요청을 동시에 처리하려면 "스레드"라는 일꾼들이 필요해요.
이 일꾼들을 하나씩 매번 새로 만드는 건 비효율적이기 때문에, 보통은 **“스레드 풀”**이라는 개념을 써서 미리 여러 스레드를 만들어두고, 필요할 때 꺼내 쓰고 다시 돌려줍니다.

하지만 중요한 문제는…

❗ “그럼 도대체 스레드를 몇 개 만들어야 하지?”

스레드를 너무 적게 잡으면 응답이 느려지고,
너무 많이 잡으면 서버가 버벅거리거나 죽을 수도 있어요.

그래서 적절한 스레드 수를 지정하는 과정이 꼭 필요합니다.

🧩 스레드 수를 지정할 때 알아야 하는 것들

1️⃣ CPU 코어 수

💡 컴퓨터(서버)의 뇌! 동시에 몇 개의 일을 진짜로 할 수 있는지 알려줘요.

• CPU 코어가 4개면 → 동시에 4개까지 계산 작업을 제대로 할 수 있어요.
• 스레드 수가 코어 수보다 너무 많으면 → 스레드끼리 기계 차지하려고 서로 싸움 (성능 저하)

👉 **CPU 중심 작업(CPU-bound)**일 경우엔
스레드 수 ≒ 코어 수 + 1~2개 정도가 일반적인 기준이에요.

2️⃣ 작업의 성격: CPU-bound vs I/O-bound

👉 대부분의 웹 서비스는 I/O-bound가 많아요!
그래서 100명 요청 → 100개 스레드도 크게 문제 없을 수 있어요.

📏 스레드 수를 지정할 때 해야 하는 일들

✅ 1. 적당한 기본값 설정

너무 작지도, 너무 크지도 않게 시작해요

예:

Tomcat maxThreads: 200  
Spring @Async pool size: 20~50

✅ 2. 서버 상태 모니터링

서버가 얼마나 열심히 일하고 있는지를 봐야 해요.

• CPU 사용률
• 스레드 풀의 활성 스레드 수
• 큐에 쌓인 요청 수 (대기 중인 작업)

👉 스레드가 늘 부족하다면 → 수를 늘려야
👉 스레드는 많은데 CPU가 90% 이상이면 → 오히려 줄이거나 서버를 나눠야

✅ 3. 부하 테스트 진행

“실제 사용자가 많이 몰리면 어떻게 될까?”를 미리 테스트해 봐야 해요.

• JMeter, k6 같은 도구로 요청 몰아보기
• 응답 시간, 실패율, CPU 그래프 확인
• 스레드 수를 바꿔가며 성능 차이 비교

✅ 4. 숫자를 조정하고 반복 테스트

“한 번에 끝내는 게 아니라” 계속 조절해나가야 해요.

• 너무 느리면 → 스레드 수 늘림
• CPU가 터지면 → 줄이거나 서버 나누기
• 상황에 따라 동적으로 풀 크기 조정도 고려 (Spring은 지원됨)

💬 한 줄 요약

스레드 풀은 ‘서버의 일꾼 수’이며, 무작정 많거나 적으면 성능 문제가 생긴다.
그러니 서버 성능, 작업 성격, 테스트 데이터를 기반으로 “적절한 숫자”를 찾고 계속 조정하는 과정이 필요하다.

📌 실무 팁 모음

✅ 한 줄 정의

**스레드(Thread)**는 CPU가 작업을 처리하는 최소 단위이며,
하나의 프로그램(프로세스) 안에서 여러 작업을 동시에 처리할 수 있게 해줍니다.

🔍 쉽게 풀어서 설명하면…

🎭 예: 배우(프로세스)와 대사(스레드)

• 프로세스: 연극 무대에서 한 명의 배우
• 스레드: 배우가 하는 각 장면의 대사 흐름
  → 한 배우가 동시에 여러 대사를 수행할 수 있다면? 바로 멀티스레드!

"스레드 방식으로 실행된다" 라는 말은
"이 작업은 누군가(스레드)에게 맡겨져서, 다른 작업과 동시에 실행된다" 라는 뜻!

---

🔍 조금 더 쉽게 비유해서 설명해볼게요

📦 예시: 택배 회사

• 한 명의 택배 기사 = 1개의 스레드
• 회사(프로그램)는 여러 건의 택배(작업)를 처리해야 해요

👉 "스레드 방식으로 실행된다" =
작업 하나하나를 택배 기사(스레드)에게 맡겨서 동시에 여기저기 보내는 구조!

✅ 실제 예제: 웹 서버에서 스레드가 쓰이는 상황

1. 사용자가 브라우저로 HTTP 요청 보냄
2. 톰캣이 이 요청을 처리하기 위해 "스레드 하나"를 생성 or 할당
3. 그 스레드가 서블릿을 실행하여 응답 생성
4. 완료되면 스레드는 풀로 돌아감

🧠 스레드가 중요한 이유

⚙️ 스레드는 어디서 나올까?

1. 운영체제 차원에서 관리되는 구조
2. Java에서는 Thread, Runnable, ExecutorService 등으로 사용
3. WAS (Tomcat, Jetty 등)에서는 **스레드 풀(thread pool)**이 있어
   • 요청마다 새로 만들지 않고
   • 미리 만들어둔 스레드를 재사용함

🔁 스레드와 요청의 관계

❗ 스레드 주의점

✅ 요약

Web Server vs WAS( Web Application Server) 

두 시스템 모두 HTTP 를 사용하지만, 웹 서버는 “파일 전송”에 특화, WAS는 “비즈니스 로직 수행”에 특화돼 있습니다. 

1️⃣ 동작 흐름 이해하기

브라우저 ──► [1] Web  Server (Apache HTTP / Nginx)
             │   ├─ 정적 파일이면 바로 응답
             │   └─ 동적 URL이면 WAS 로 프록시
             ▼
             [2] WAS (Tomcat / WebLogic / WildFly)
             ├─ 서블릿·Spring 실행
             └─ DB·외부 API 호출 후 결과 HTML·JSON 생성
             ▲
브라우저 ◄── 최종 응답

• 요청이 정적이면 ① 단계에서 바로 끝.
• 동적이면 ①이 요청을 ②로 넘기고, ②가 서블릿(SPRING) 로직을 수행해 응답을 돌려줍니다.

2️⃣ 왜 둘을 분리할까?

3️⃣ 제품별 특징 요약

모든 WAS 는 Servlet API(이제 jakarta.servlet.*)를 구현하므로, 같은 WAR/서블릿이 서로 다른 WAS 에서 동일하게 동작합니다. 단, Spec 버전(javax.* vs jakarta.*)은 맞춰야 해요. docs.oracle.comopenlogic.com

4️⃣ “웹 서버 + WAS” 가 합쳐진 현대적 형태

• Spring Boot: 내장 Tomcat/Jetty 를 포함한 java -jar 한 프로세스 ⇒ 실제로는 웹 서버 + WAS 가 한 JVM 에 같이 존재.
• Nginx Unit, Node.js, Go Fiber 등: 애플리케이션 서버가 HTTP 처리까지 직접 수행.
  → “웹과 WAS 구분”은 아키텍처적인 개념이고, 구현체는 필요에 따라 합치거나 분리합니다.

5️⃣ 기억하면 좋은 포인트 3가지

1. 웹 서버가 없이도 Tomcat 단독으로 서비스 가능하지만,
   대규모·보안·멀티스택 환경에서는 보통 둘을 분리합니다.
2. 동적 로직이 필요한 순간부터는 WAS 가 필수—Java 에선 서블릿·Spring MVC·JSP 가 그 진입점입니다.
3. 제품을 선택할 땐 필요 스펙(Jakarta EE 전체? / 서블릿만?) 과 운용 비용을 먼저 고려하세요.

🔑 정리 한 줄
Web Server = 정적 파일 전담, WAS = 동적 비즈니스 로직 전담.
구조는 분리·통합 모두 가능하지만, “역할” 자체는 언제나 이 두 층으로 나뉜다!

✅ 핵심 한 줄 요약

Spring은 내부적으로 DispatcherServlet이라는 서블릿을 사용해서 모든 웹 요청을 처리합니다.

🔷 구조적으로 어떻게 되는가?

Spring MVC의 요청 흐름은 다음과 같아요:

브라우저 요청
    ↓  (HTTP 요청)
Tomcat (서블릿 컨테이너)
    ↓
DispatcherServlet (Spring이 만든 서블릿)
    ↓
Controller (@Controller or @RestController)
    ↓
Service, Repository 등 비즈니스 로직 처리
    ↓
DispatcherServlet
    ↓
응답 반환

🧩 DispatcherServlet이 뭐야?

🔍 DispatcherServlet = Spring이 만든 서블릿

• HttpServlet을 상속받은 일반적인 서블릿
• web.xml이나 ServletInitializer에서 /* 모든 요청을 가로채도록 등록됨
• 그 후 내부에서 어떤 Controller가 이 요청을 처리할지 판단하고 실행함

즉, 서블릿인데 우리가 직접 만들 필요 없이 Spring이 대신 관리해주는 고급 서블릿이에요.

Spring 의 경우 web.xml 에 이렇게 등록했어요 : 

<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

🔧 예: DispatcherServlet 등록 (Spring Boot가 자동으로 해줌)

public class MyWebAppInitializer implements WebApplicationInitializer {
    @Override
    public void onStartup(ServletContext container) {
        AnnotationConfigWebApplicationContext context =
            new AnnotationConfigWebApplicationContext();
        context.setConfigLocation("com.example.config");

        ServletRegistration.Dynamic dispatcher =
            container.addServlet("dispatcher", new DispatcherServlet(context));
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/");
    }
}

⚙️ 요청 처리 순서 (좀 더 자세히)

1. 사용자가 /hello에 접속
2. Tomcat은 이 요청을 서블릿에게 전달
3. DispatcherServlet이 요청을 가로챔
4. 등록된 HandlerMapping을 통해 어떤 @Controller가 처리할지 찾음
5. 그 @Controller의 메서드 실행 (@RequestMapping, @GetMapping 등)
6. 리턴값(View 또는 JSON 등)을 ViewResolver나 HttpMessageConverter를 통해 변환
7. 응답 객체에 담아 사용자에게 전송

💡 핵심 클래스 요약

📦 DispatcherServlet도 결국 HttpServlet이다!

public class DispatcherServlet extends FrameworkServlet {
    // FrameworkServlet은 HttpServlet을 상속
}

👉 즉, DispatcherServlet도 결국 HttpServlet이기 때문에
Tomcat이 서블릿을 실행하는 구조 그대로 동작합니다.

✅ 요약 정리