영암사는 승경이네

개요

 최근 사내망에서의 SSL Certification 오류가 발생하거나, SSL 인증서를 갱신하는 작업을 하면서 SSL 인증서가 도대체 어떤 녀석이길래 '신뢰할 수 있는 사이트'라는 타이틀을 쥐어주는지, 암호화는 어떻게 가능한지에 대한 의구심이 들었다. SSL 인증서의 메커니즘을 알아보기 전 HTTPS와 암호화 방식에 대해 알아보고, 왜 굳이 CA 기관을 통해 SSL 인증서를 발급받아야하는지도 분석해보았다.

HTTPS 란?

HTTP는 Hypertext Transfer Protocol의 약자로 웹서비스에 데이터를 전송하는 통신 규약을 말한다.

HTTPS는 HTTP에 보안을 더한 프로토콜로 암호화 기반의 프로토콜인 SSL(Secure Socket Layer) 이 적용된 프로토콜을 말한다. 즉, HTTPS는 HTTP에 대한 암호화 기반의 데이터 통신규약을 말한다.

암호화? 우리가 아는 암호화??

맞다. 네트웤 구간에 떠다닐 우리의 요청, 응답 데이터들을 공격자가 알아볼 수 없는 형태로 암호화하는 것이다. 그럼 잠깐 암호화에 대해 알아보자.

대칭키?! 비대칭키?! 공개키?! 개인키??!! 😱

 암호화는 데이터를 특정한 키 기준으로 연산하는 것을 말한다. 또 키를 이용해 복호화한다. 동일한 키로 암호화와 복호화를 둘다 할 수 있는 방식을키가 대칭된다 하여 대칭키 방식이라한다. 반대로 암호화하는 키와 복호화하는 키가 다른 방식을 비대칭키 방식이라 한다.

암호화 키와 복호화 키 중 어느 키가 더 중요할까? 

당연히 복호화 키가 더 중요하다! 암호화 키가 유출되어 모든 사람들이 갖게된다고 하여도, 복호화 키가 없다면 그 누구도 암호화된 데이터를 볼 수 없기 때문이다.

대칭키는 암호화 키와 복호화 키가 똑같으니 모두 공개되어서는 안된다. 그럼 비대칭키는 어떨까? 공개되어도 되는 암호화 키와, 공개되어선 안되는 복호화키로 구성된다고 했다. 여기서 공개되어도 되는 키를 '공개키', 공개되어선 안되는 키를 '개인키'라고 한다. 그럼 HTTPS에 사용되는 암호화 방식은 대칭키일까? 비대칭키일까?

HTTPS에 사용되는 암호화 키 방식은 대칭키 인가요...? 🧐

대칭키 방식이라고 가정하고 생각해보자. 요청을 하는 클라이언트에서는 요청 데이터를 암호화해야한다. 즉, 키가 필요하다. 이 키는 서버로부터 전달받아야 한다. 그럼 최초 통신(핸드 쉐이크) 단계에서 서버가 클라이언트에게 키를 전달해야한다.

그런데 만약 이 과정에서 공격자가 요청을 가로챈다면, 그리고 이 대칭키를 탈취한다면 어떨까? 클라이언트와 서버간 대칭키 암호화를 통해 데이터를 주고 받더라도 공격자는 탈취한 키를 이용해 복호화를 할 것이고, 데이터를 감청할 수 있게 된다. 즉, 단순 비대칭키 방식을 사용하는 것은 네트웤 통신 관점에서는 매우 위험한 방식이다.

아! 그럼 비대칭키 방식이군요?! 😏

비대칭키를 사용하면 클라이언트로 전달되는 키, 즉 공개키가 공격자에게 탈취당해도 괜찮다. 복호화를 하지 못하기 때문이다. 하지만 여기서도 큰 문제가 있다. 바로 데이터를 응답할때 암호화가 불가능한 점이다. 예를들어 로그인에 성공 시 클라이언트에게 액세스 토큰을 전달하는 상황을 가정해보자. 액세스 토큰도 마찬가지로 암호화를 해야하는데, 현재 서버는 복호화를 할수있는 개인키밖에 없는 상황이다. 암호화를 위한 키가 없는 상황인 것이다.

서버도 자신이 사용할 공개키를 발급한 후 암호화하면 되잖아? 😏

그럼 서버의 응답 데이터는 암호화 되겠지만 클라이언트는 서버에서 준 데이터를 복호화 하지 못한다. 클라이언트는 복호화를 할 수 있는 개인키가 없기 때문이다

클라이언트에게 개인키를 주면 되잖아? 😏

그럼 대칭키를 사용했을 때의 문제 상황과 마찬가지로 공격자가 개인키를 가로챌 수 있는 상황에 처한다. 또한 비대칭키 방식은 대칭키보다 암/복호화 복잡도가 높고 속도도 수 천배 느리다. 즉, 속도와 시스템 자원 낭비 문제를 안게 된다.

키를 대체할 수 있는 값을 활용하면 되지 않아? 😏

클라이언트에서 키를 대체할 수 있는 랜덤 값을 생성하고, 이 값을 서버의 공개키로 암호화하는것이다. 그럼 서버에서 개인키로 이를 복호화하여 랜덤 값을 얻고, 서버와 클라이언트가 이 값을 대칭키로 삼아 암/복호화 하는것이다. 대칭키 방식이니 클라이언트, 서버 모두 암/복호화 할 수 있고, 키가 되는 랜덤 값을 전달할 때에는 서버의 공개키로 암호화해서 전달할 것이기 때문에 공격자에게 탈취되도 문제되지 않는다.

위에서 말한대로 위 구조에서는 공격자는 클라이언트에서 생성한 대칭키(랜덤 값)를 획득하지 못한다. 서버의 공개키로 암호화됐기에 서버의 개인키로만 복호화되기 때문이다. 

 이제 문제가 없어보일 수 있으나, 이 구조에서도 보안 이슈가 존재한다. 바로 서버가 클라이언트에게 전달하는 공개키를 공격자의 공개키로 바꿔치는 것이다. 이를 중간자 공격이라 한다.

중간자 공격 (Man-in-the-middel attack)
공격자가 공개키를 가로채어 변경하고 상대방에게 전달하여 신뢰를 잃게 만드는 방식.

서버가 공개키를 전달할 때를 캐치하여 서버의 공개키 대신 공격자의 공개키를 주면, 클라이언트는 공격자의 공개키로 생성한 대칭키를 암호화할것이다.

 그 후 클라이언트가 전달한 암호화된 대칭키를 공격자가 가로채 공격자의 개인키로 복호화한다. 대칭키를 탈취한 것이다. 탈취한 대칭키를 서버가 사용하도록 만들어야하므로 4번과정에서 획득한 서버의 공개기로 대칭키를 암호화 한 후 서버로 전달한다. 서버는 아무것도 모르고 이를 복호화할것이고 대칭키로 사용할 것이다. 이제 데이터가 암호화되더라도 공격자가 복호화할 수 있게 되었다.

신뢰할 수 있는 기관을 끼자! 🏢

 위처럼 중간에 공개키가 위변조되는 것을 막는 방법은 위변조를 못하도록 보안을 강화하면 된다. 보안을 위한 여러 프로세스들과 보안 장비를 붙이고, 취약점이 발생할때마다 수시로 업데이트해주며, 모니터링도 철저히 하는 것이다.

그렇다... 배보다 배꼽이 더 커진다.

 서비스 운용 비용보다 보안을 위한 비용과 기술력이 훨씬 많이 필요할것이다. 그럼 서비스 운용자가 아닌, 믿을 수 있는, 매우 높은 보안성을 갖는 기관에게 서버의 공개키를 전달받으면 어떨까?

 브라우저가 신뢰하는 기관, 신뢰할 수 있는 공개키를 제공하는 기관, 이 기관이 바로 CA이다.

CA (Certificate Authority)
인증기관이라 부르며, 다른 곳에서 사용하기 위한 디지털 인증서를 발급하는 곳.

CA도 털린적...이 있답니다 :)

실제로 2011년 DigiNotar 이라는 CA 가 해킹당해 Google과 Facebook 등 수많은 사이트가 피해를 입었다. 때문에 브라우저가 신뢰할 수 있는 CA 는 매우 깐깐한 조건으로 선별된다고 한다.

이제 본론으로 들어가 실제 CA와 서버, 클라이언트(브라우저)가 어떻게 상호작용하며 데이터를 암/복호화하는지 알아보자.

SSL 인증서 발급부터 통신까지의 과정을 알아보자! ✏️

1. SSL 인증서 발급 요청

SSL 프로토콜을 적용하고 싶다면 먼저 CA 에게 SSL 인증서 발급을 요청해야한다. 중요한 점은 서버의 공개키를 함께 전달하는 것이다.

2. 발급된 SSL 인증서 전달 및 SSL 프로토콜 적용

CA 로부터 SSL 인증서를 전달받으면 사용하는 웹 서비스(웹서버 또는 AWS ALB 등) 에 맞게 SSL 인증서를 적용시킨다.

3. Client Hello (Handshake-1)

클라이언트로부터 요청이 들어온다면 바로 요청/응답 데이터를 주고받지 않는다. 핸드쉐이크 과정을 거치는데, 첫번째 과정을 Client Hello 라고 하며, 클라이언트는 서버에게 '클라이언트 랜덤 값(편의를 위해 C Random이라 칭함)'과 클라이언트가 지원 가능한 암호화 메서드 리스트 등을 전달한다. 

* 암호화 메서드 리스트들은 왜 전달하나요? 🤔

핸드쉐이크 과정에서 주고받는 데이터들에 대한 암호화 방식을 설정하기 위함이다. 핸드쉐이크 과정에서도 키 교환, 대칭키 암호화, PRF 알고리즘 적용과 같은 프로세스가 발생하는데, 이 때 서버와 클라이언트 모두 지원하는 암호화 방식을 사용해야하기 때문이다.

4. Server Hello (Handshake-1)

두번째 과정을 Server Hello 라 하며, '서버 랜덤 값(편의를 위해 S Random이라 칭함)'과 클라이언트에서 전달한 암호화 메서드 리스트 중 채택한 암호화 메서드, SSL 인증서를 전달한다.

5-6-7. SSL 인증서 확인 및 서버 공개키 획득

클라이언트는 SSL 인증서를 전달받으면 인증서를 발급한 CA 기관을 확인한다. 그리고 이 기관이 브라우저에 저장되어 있는지를 확인한다. 저장되어 있지 않다면 '신뢰할 수 없는 인증서'라는 경고가 발생할것이고, 저장되어 있다면 함께 저장된 해당 CA 의 공개키를 가져온다.

 공개키를 통해 복호화(SSL 인증서 전자서명 검증)에 성공한다면 공인하는 CA로부터 발급된 위변조 없는 SSL 인증서라는 것을 알게 된다.

그리고 SSL 인증서에 포함되어있던 서버의 공개키를 획득한다.

브라우저에 저장된 CA는 브라우저가 신뢰하는 CA
위에서 말했듯이 CA 는 매우 깐깐한 기준으로 선별된다. 브라우저 내에 저장되어 관리되며, CA 리스트와 CA 공개키를 함께 관리한다.
만약 CA 리스트에 대한 업데이트가 발생한다면, 브라우저 업데이트를 통해 진행된다.

8. C + S 값 생성

C Random 값과 S Random 값을 조합한 C + S 값(제가 편의를 위해 칭한 이름입니다.) 을 생성한다.

9-10. Pre Master Secret 생성 및 전달

C + S 값을 서버에게 전달하기 위해 서버의 공개키로 암호화한다. 암호화된 C + S 값을 Pre Master Secret 이라한다.

이 값을 서버로 전달한다.

11. 서버측 C + S 값 획득

Pre Master Secret은 서버의 공개키로 암호화됐기에 서버는 자신의 개인키로 복호화하여 내장된 C + S 값을 획득한다.

12. 서버측 Master Secret 생성

획득한 C + S 값과 Pre Master Secret, PRF 알고리즘을 조합하여 Master Secret 을 생성한다.

PRF(Pesudo-Random Function)
특정 입력에 대해 항상 동일한 출력을 주는 랜덤 함수.

13. 대칭키 발급

Master Secret 을 기반으로 데이터를 암/복호화 하기 위한 대칭키를 발급한다. 여러 대칭키를 발급하는데, 실제 암/복호화에 사용하는 대표적인 키는 Session Key와 Mac Key이다.

Session Key
실 데이터를 암/복호화할때 사용하는 키.

Mac Key
데이터에 대한 HMAC 값을 구할 때 사용하는 키.
송신자 측에서 Mac Key를 사용해 데이터의 HMAC 값을 계산하여 암호화된 데이터와 함께 전달하면, 수신자측에서는 데이터를 전달받아 Session Key로 복호화한 후, Mac Key를 통해 데이터의 HMAC 값을 구한다. 송신자가 전달한 HMAC 값과 수신자가 연산한 HMAC 값이 동일하면 메시지가 변조되지 않았다는 것을 검증하게 되는 것이다.

HMAC
해시 함수와 공유 비밀 키를 사용하여 해시화하여 메시지의 무결성을 확인하는 메시지 인증 코드(MAC)의 한 종류.

14. 클라이언트측 Master Secret 생성

클라이언트에서도 12 번 단계에서 사용했던 것과 동일한 C+S 값과 Pre Master Secret, PRF 값을 조합하여 Master Secret을 생성한다. 여기서 중요한 점은 위 세개 값들을 서버로부터 다시 전달받는게 아닌, 자신이 이미 갖고 있던 값들을 사용한다는 것이다.

15. 대칭키 발급 

13번 과정과 마찬가지로 Master Secret 을 기반으로하여 데이터를 암/복호화 하기 위한 대칭키를 발급한다. 서버와 마찬가지로 Session Key, Mac Key 등을 생성한다.

16. 대칭키 암호화 기반 통신 시작!

이 후 서버와 클라이언트간 통신 시 각자 갖고있는 Session Key와 Mac Key를 사용해 데이터를 암/복호화하여 통신한다!

서버와 클라이언트가 갖고있는 Session Key와 Mac Key 동일하므로 대칭키 암호화 기반으로 통신이 된다!

회고

 이 글을 보는 독자들이 SSL 프로토콜의 내부 동작과 CA 의 SSL 인증서를 연결시켜 이해할 수 있길 바란다. 이 글에 적진 않았지만, 중간자 공격의 메커니즘을 이해한다면 사내망에서 SSL Certification 이슈가 발생하는 이유와 조치 방안도 이해할 수 있을 것이다!

개요

개발 시 무료 버전의 ChatGPT를 사용하곤 한다. 다만 보안 이슈로 인해 실제 프로젝트의 코드 일부분을 발췌하여 질문하긴 힘들다. 우회책으로 코드에 대한 설명을 하거나, 비지니스와 관련된 코드들을 모두 제거한 후 껍데기 형태의 코드를 제공하는 형태로 질의를 했었다.

 그러던 와중, ollama를 사용해 LLM 모델을 로컬 환경에 다운로드받고, 로컬 환경에서 질의하는 방법을 접하게 되었다. 최대의 장점은 보안. 로컬에서 동작하는 방식이다보니 프라이빗하게 사용할 수 있었다. 또한 이러한 방식을 Intellij IDE Plugin 에서 제공한다는 사실을 알게되었다. Plugin을 일주일정도 사용해보고 느낀점들을 리뷰해보도록 하겠다. 2025년 2월 12일 기준, 플러그인 중 Continue와 CodeGPT에 대한 리뷰를 하려했으나, 갑자기 CodeGPT에 대한 플러그인이 삭제되어 Continue만 리뷰한다.

먼저 Continue 뭔지에 대해 한번 알아보자.

Continue 란 무엇인가요? 

오픈소스 기반의 AI 코드 어시스턴트이다. 다양한 LLM 모델을 지원하며, 자동 완성, 코드 수정, LLM과의 채팅 기능을 제공한다. Intellij Continue Plugin의 공식문서 내용 기반으로 기능들을 테스트 한 후 현업에서 사용해보았다.

https://plugins.jetbrains.com/plugin/22707-continue

Chat 기능

 IDE 를 벗어나지 않고 LLM 에게 질의할 수 있는 가장 기본적인 기능이다. Plugin 설치 시 우측에 Continue 아이콘이 생기는데, 클릭하면 위와 같은 채팅 UI가 나타난다. 단순 채팅 뿐 아니라, IDE에 있는 코드나 파일, 폴더를 단축키 기반으로 손쉽게 참조시킬 수 있다.

 Continue 설정 통해 API 기반 LLM 서비스로 질의를 보내게 할수도 있지만, 로컬 환경에서 실행되는 ollama 서버의 LLM 모델과 연동도 가능하다. 필자의 경우 로컬 환경의 ollama 서버와 연동하여 채팅 기능을 사용하고 있다. 모델 선택도 간단하다. 로컬 ollama 서버와 연동만 되면 모델들이 자동으로 조회된다. 원하는 모델을 선택하기만 하면 된다.

특정 코드블럭을 LLM 질의 내용에 참조시키고싶다면 IDE 상에서 블럭씌운 후 [ Command + J ] 단축키를 통해 추가할 수 있다.

 참조된 코드는 프롬프트와 함께 질의 가능하며, 응답받은 코드를 실제 코드에 적용하고 싶다면, 우측 상단의 'insert at cursor' 버튼을 누르면 된다. IDE 상에 위치한 커서로 코드가 복사된다.

 파일 참조도 가능하다. 프롬프트 입력창에 '@' 입력 후 베이스가 되는 파일 명을 입력하면 된다. 코드에 대한 리뷰 및 리팩토링이 필요할 경우 좋은 옵션으로 사용될 수 있을 것으로 기대된다.

Auto Complete

 자동완성 기능을 제공한다. 활성화를 위해 IDE 설정 > Continue > Enable Tab Autocomplete 옵션을 활성화해야한다는데, 필자의 경우 해당 옵션을 활성화해도 자동완성 기능이 활성화되지 않았다. Intellij 의 자체 자동완성 기능을 비활성화해도 마찬가지였다.

 기능을 직접 경험해보면 좋았겠지만, 사실 지원하지 않아도 크게 아쉽진 않았다. IDE 자체에서도 준수한 수준의 자동완성을 제공해주기때문이다.

Code Edit

 LLM 질의 결과로 코드를 리턴받고, 이를 UI 기반으로 편하게 수정 할 수 있는 기능이다. LLM 에서 제안한 코드는 diff 형식으로 IDE 상에 표시되며 개발자가 판단 후 적용할 수 있다. 이 기능은 별도의 설명 없이 수정할 '코드'만 출력되기 때문에 몇번의 대화가 오가는 수준의 질의가 아닌 단순한 메서드를 만들거나, 가벼운 리펙토링, 로깅처리, 예외처리 등 정형화되고 표준화된 부분에 효과적으로 사용 가능할 것 같다.

 사용법은 대상 코드 블럭 지정 후 [ Command + i ] 단축키를 누르면 코드 바로 위에 프롬프트 입력 창이 뜬다. 원하는 내용을 입력하면 코드 수정 제안이 diff 형식으로 나타난다. 기존 코드는 빨간색, 제안 코드는 파란색으로 표시되며, 제안 코드로 변경을 원할경우 우측 Y를, 거절할 경우 우측 N 클릭을 통해 가능하다. Rejcet All, Accept All 버튼을 통해 일괄 처리도 가능하다.

아래는 메서드 명을 리팩토링해달라는 요청이었는데, 메서드 명명 규칙에 맞게 동사, 카멜케이스 형태로 자동 리팩토링 한 것을 확인할 수 있다.

일주일간의 사용 후기

 당연한 얘기긴 하지만 일단 답변 품질에서의 차이는 기존 API 기반 LLM 서비스와 차이가 없었다. 개발 전용 IDE에 연동되었기에 품질에서도 뭔가 다르지 않을까라는 조그만 기대를 했던것같다. 답변받은 코드들에 대해 개발자의 자체 검증 과정은 기존 LLM 서비스를 사용했을때와 같이 필요했다. 해서 LLM 품질이 아닌 다른 영역에서 느꼈던 부분들을 정리해보았다.

* 코드 유출, 외부 학습의 위험이 없다.

API 기반 LLM 서비스를 사용할 경우 질의한 코드를 모델이 학습할 우려와 인터넷망을 거친다는 점에서 코드 유출 위험을 우려했는데, 로컬 ollama 를 연동할 경우 인터넷 연결 없이 로컬 환경에서 사용 가능하다는 점에서 위 우려가 해소되었다. 코드에 대해 질의가 필요할 경우 설명으로 대체하는 케이스가 많았는데, 코드를 그대로 질의할 수 있다는 점이 좋았다.

 또한 IDE와 연동이 되어있어 빠르고 편리하게 리소스를 참조시킬 수 있었다. 보다 쉽고 빠른 질의가 가능했다.

* 자유롭고 빠른 모델선택

 모델마다 특화된 역량이 있다. 때문에 모델을 바꿔가며 질의하는 경우가 있었는데 모델 변경 방식도 매우 간단했다. 필자는 ollama 3.1, qwen2.5-coder, deepseek-r1 모델을 주로 사용했는데 이중 qwen2.5-coder 모델은 코드 기반의 답변을, deepseek는 도출 과정 기반의 답변을 받을 수 있었다. (참고로 qwen2.5-coder 모델은 코딩과 수학에 특화된 모델이다.)

qwen2.5-coder Description 일부 발췌

이 분야의 전문화된 전문가 모델 덕분에 코딩 과 수학 에 대한 지식이 상당히 많아 지고 역량이 크게 향상되었습니다 .

qwen2.5-coder 모델과 deepseek-r1 모델에게 메서드 명에 대한 리팩토링 질의를 해본 결과,

qwen2.5-coder 모델은 아래와 같이 리팩토링 코드와 간단한 설명만 존재했고, (코드적으로 설명이 필요하거나 새로운 개념이 등장할 경우에는 친절하게 설명해준다.)

deepseek-r1 모델은 최종 결과 코드에 대한 도출 과정이 자초지종 설명되어 있다. 아래는 답변에 대해 부분 번역 것인데, 구구절절한 느낌이 없지않아 있다. 이 외에도 코드 리뷰를 요청했는데, 마찬가지로 코드에 대한 도출 과정들을 매우 길게 설명했다. 실제로 모든 응답을 받기까지 5분 이상 걸렸었다. 개발을 시작한지 얼마 되지 않았거나, 과정을 이해하고싶은 개발자들에게는 좋은 옵션이 될 수 있을것같다.

enterRoom 내부의 각 줄을 통과하겠습니다. 먼저 ValidAteChattingroom (룸메이트)이 있습니다. 그것은 간단 해 보이지만 어쩌면 더 설명 적으로 만들 수 있습니다. 그것이 검증되기 때문에 아마도 그대로 유지하거나 가능하면 더 나은 동사를 찾으십시오.
...(중략)
어쩌면 "검증"이 여기에서 최고 일 것입니다.

다음은 KickoutDuplicationUserInsameroom (룸메이트, 이메일)입니다. 복제라는 단어는 철자가 잘못 될 수 있습니다. 중복되어야합니다.
...(중략)
어쩌면 "제거"가 더 나을 것입니다. 따라서 삭제 된 UplyserInsameroom 또는 그와 비슷한 것으로 변경하십시오.

그런 다음 SessionUser.of (SessionId, 이메일, 룸메이트)가 있습니다. ()의 메소드 이름은 공장 방법에 맞으므로 다른 곳에 다른 이름 지정 규칙이 없다면이를 변경할 필요가 없다고 생각합니다.

다음 줄은 CachingUsersessionTosessionStore (SessionUser)입니다. 흠, 캐싱은 여기서 올바른 동사가 아닐 수도 있습니다. 저장 또는 저장에 대한 것입니다.
...(중략)
아마도 SavessessionUserInsessionStore가 더 나을 것입니다.

...(중략)
So putting it all together, I'll go through each method call and adjust the names accordingly:
validateChattingRoom(roomId) → keep as is since "validate" is a verb.kickOutDuplicationUserInSameRoom(...) → change to removeDuplicateUserFromRoom or something similar, but maybe better phrased as ensureSingleSessionPerRoom to make it more proactive.cachingUserSessionToSessionStore(sessionUser) → saveSessionUserToSessionStorecachingUserSessionToRoomStore(sessionUser) → saveSessionUserToRoomStoresendRoomStatusToRedis(roomId) → updateRoomStatusOnRedis or sendRoomStatusUpdateToRedissendRoomEnterAlarmToRedis(email, roomId) → notifyRoomEntryToRedis

따라서 최종 리팩토링된 메서드 호출은 다음과 같을 것이라고 생각합니다.

validateChattingRoom(roomId);
ensureSingleSessionPerRoom(roomId, email);
sessionUser = SessionUser.of(...);
saveSessionUserToSessionStore(sessionUser);
saveSessionUserToRoomStore(sessionUser);
sendRoomStatusUpdateToRedis(roomId);
notifyRoomEntryToRedis(email, roomId);

이것은 각 메소드 이름을 Camelcase의 동사로 만들고 각각의 행동을 명확하게 설명합니다.

  public void enterRoom(EnterRoomDto.Request request, String email, String sessionId) {
        Long roomId = request.getRoomId();

        validateChattingRoom(roomId);
        ensureSingleSessionPerRoom(roomId, email);

        SessionUser sessionUser = SessionUser.of(sessionId, email, roomId);
        saveSessionUserToSessionStore(sessionUser);
        saveSessionUserToRoomStore(sessionUser);
        sendRoomStatusUpdateToRedis(roomId);
        notifyRoomEntryToRedis(email, roomId);
    }

* 리팩토링, 코드리뷰 활용

 리팩토링과 코드리뷰에 잘 활용될 수 있을것이라 생각한다. 필자의 경우 비지니스 클래스에 대한 코드 리뷰를 요청했더니, 실제로 문제가 될 수 있는 부분에 대한 개선을 제안받았다. 병렬 처리가 필요한 부분에서 SingleThread 를 계속 생성해나가는 방식을 채택했었는데, Thead Pool 방식으로의 개선을 제안받았고, 제안받은 코드도 정상적으로 돌아갔다. 참고로 모델은 qwen2.5-coder 모델을 사용했다.

* 다국어 대화 지원 여부 파악 필요

 필자는 영어와 친하지 않아 주로 한글로 질의했다. qwen2.5-coder나 ollama 3.1 모델은 한글로 질의할 경우 한글 답변을 줬는데, deepseek-r1 모델의 경우 영어 답변을 줘서 번역기를 돌려야하는 불편함이 있었다. ollama 공식 사이트에 접속하여 모델 정보를 읽어보니 qwen2.5-coder나 ollama 3.x의 경우 모델 설명 부분에 '다국어를 지원한다', '다국어 대화가 가능하다' 등의 내용이 있는데 반해, deepseek-r1 모델은 다국어 관련 내용이 존재하지 않았다. 영어를 잘 못하는 사람들은 모델에 명시된 다국어 지원 여부를 잘 살펴보는것이 좋을것같다.
(deepseek도 프롬프트에 한국어로 답변해달라고 추가하면 한글 답변이 나오긴 하지만, 추가하는걸 자꾸 까먹...)

ollama 3.1 Description 일부 발췌

8B 및 70B 모델의 업그레이드된 버전은 다국어이며 128K의 상당히 긴 컨텍스트 길이, 최첨단 도구 사용 및 전반적으로 더 강력한 추론 기능을 갖추고 있습니다. 이를 통해 Meta의 최신 모델은 장문 텍스트 요약, 다국어 대화 에이전트 및 코딩 어시스턴트와 같은 고급 사용 사례를 지원할 수 있습니다.

qwen2.5-coder Description 일부 발췌

중국어, 영어, 프랑스어, 스페인어, 포르투갈어, 독일어, 이탈리아어, 러시아어, 일본어, 한국어, 베트남어, 태국어, 아랍어 등 29개 이상의 언어에 대한 다국어 지원을 제공합니다 .

참고로 잠깐 사용했던 CodeGPT는 모델과 별개로 시스템 프롬프트 설정이 가능했는데, 한글로 답변해달라는 내용을 추가하니 deepseek-r1 모델 또한 한글 답변을 주긴 했었다. continue에도 이러한 설정이 있다면 좋을것같다.

* 시스템 리소스에 따른 모델 규모 선택

 아무래도 로컬 환경에 설치된 LLM 모델이 동작하는 거라 시스템 리소스를 많이 먹는다. 필자의 컴퓨터 메모리가 18GB인데, 14b 규모의 모델을 사용할 경우 컴퓨터가 심하게 버벅거린다. 7b 규모로 낮추니 버벅거림이 많이 사라졌다. 

 규모가 클수록 더 좋은 답변을 받을 수 있겠지만 본인의 PC 사양을 고려하여 모델 규모를 설정하는 것이 필요해보인다. 모델 크기는 GB 기준 메모리의 절반을 넘지 않는 것이 바람직해보인다. 메모리가 18GB라면 모델 크기는 9B를 넘지 않는것이 정신건강에 좋았다.

회고

 일주일동안 현업에 적용하려고 시도해보았으나, LLM의 답변 내용을 검증하기 위해, 또는 믿지못해서 구글링을 하는 자신을 볼 수 있었다. 사용 초기엔 무지성 채팅 기능만 사용했는데, 공식문서를 읽어보니 꽤나 유용한 기능이 있음에 놀랐다. 특히 Edit 기능이 매우 매력적이라 생각됐다.

 사용 기간이 길지 않았고, 기능 경험, 사용 부분에 초점이 맞춰져서인지, 다양하고 구체적인 현업 적용 아이디어는 도출해내지 못했다. 계속해서 현업에 활용하면서 유의미한 포인트를 찾아봐야겠다.

1. 개요

 리두로그와 언두로그를 공부하려했더니 Buffer Pool 이라는 개념이 등장했다. 테이블을 메모리에 캐싱해두는 개념인데, 단순 개념만 알고있기에는 중요한 내용이기에 정리하였다.

2. InnoDB Buffer Pool이 뭐에요?

말 그대로 InnoDB 엔진에서 제공하는 버퍼 풀인데, 이녀석의 역할은 바로 캐싱이다.

테이블이나 인덱스를 캐싱한다고 한다. 그럼 정확히 어떤 형태로 캐싱을 하고, 실제 환경에서 어떻게 사용되는지 알아보자.

3. Buffer Pool 은 '페이지'들이 캐싱되어 있어요

 버퍼 풀에는 '페이지'들이 저장되어 있다. InnoDB 엔진에서의 페이지란 데이터베이스에서 데이터를 저장 단위이다. I/O를 통해 디스크로부터 페이지 단위로 데이터를 조회하면, Buffer Pool에 이를 그대로 저장한다. 페이지 하나의 크기는 16KB이다. (수정 가능하다)

 페이지들은 버퍼 풀에 차곡차곡 쌓이는게 아니다. 버퍼 풀은 데이터를 효율적으로 캐싱하기 위해 LRU 리스트, Flush 리스트, Free 리스트 라는 3개의 리스트로 구성되어 있으며, 이 중 LRU 리스트에 어떤 규칙에 따라 저장되게 된다.

3.1. Free 리스트

비어있는 페이지들의 목록이다. 사용자의 쿼리가 디스크의 데이터 페이지를 읽어와야 하는 경우 사용된다. 

3.2. Flush 리스트

디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(== 더티 페이지)들의 목록이다. 즉, 디스크에서 데이터 페이지를 읽은 후 변경이 가해진 데이터 페이지들의 목록이다. 데이터가 변경되면 해당 페이지는 Flush 리스트에서 관리됨과 동시에 변경 내용을 리두 로그에 기록하고, 버퍼 풀에도 변경 내용을 반영한다. 그 후 특정 시점에 리두 로그가 디스크로 기록된다.

3.3. LRU (+MRU) 리스트

MySQL InnoDB 에서는 변형된 LRU 방식을 채택하고 있다. 바로 LRU와 MRU(Most Recently Used)가 결합된 하이브리드 방식이다. 참고로 LRU와 MRU는 캐시 알고리즘이다.

* LRU (Least Recently Used)
가장 최근에 사용되지 않은 페이지를 교체하는 알고리즘. 가장 오래된 캐시를 제거한다.

* MRU (Most Recently Used)
가장 최근에 사용된 페이지를 교체하는 알고리즘. 가장 최근에 사용된 캐시를 제거한다.

4. 가장 오래된 페이지와 가장 최근의 페이지를 제거한다고??

위 두 캐시 알고리즘이 버퍼 풀에 적용되어 있는 구조이다. 이해가 잘 되지 않는다면 어떻게 동작하는지에 대한 메커니즘을 그려나가보면 이해할 수 있을것이다.

아래는 변형된 LRU, 즉 LRU와 MRU가 결합된 형태의 리스트이다.

InnoDB에서의 페이지 캐시 메커니즘에 의해 New 서브리스트 자주 사용되는 페이지가 저장되는 영역, Old 서브리스트는 신규 혹은 자주 사용되지 않는 페이지가 저장되는 영역으로 사용될것이다. 편의상 New 서브 리스트가 존재하는 영역을 MRU 영역, Old 서브 리스트가 존재하는 영역을 LRU 영역이라 표현하겠다.

긴말 필요없이 바로 동작 메커니즘을 살펴보자

1) 필요한 레코드가 저장된 데이터 페이지가 버퍼 풀에 있는지 검사한다. [InnoDB 어댑티브 해시 인덱스 > 테이블 인덱스] 를 통해 페이지를 검색한다. 

* 어댑티브 해시 인덱스
B-Tree 의 성능 개선을 위해 InnoDB 에서 자동으로 추가하는 인덱스이다. 자주 읽히는 데이터 페이지의 키값을 이용해 해시 인덱스를 만들고, 필요할 때마다 해당 데이터 페이지로 즉시 찾아갈 수 있게 한다.
- LRU/MRU를 설명하는 글이므로 자세히 다루지 않겠다.

2) 버퍼 풀에 데이터 페이지가 있다면 MRU 영역 방향으로 승급한다. (MRU 리스트로 들어가는게 아닌 방향으로 승급이다.)

3) 버퍼 풀에 데이터가 없다면 디스크로부터 필요한 데이터 페이지를 버퍼 풀에 적재와 동시에 LRU 영역 Head 부분에 추가한다.

4) LRU 영역에 추가한 데이터 페이지가 조회되면 MRU 영역 방향으로 승급하고, 버퍼풀에 없다면 LRU Head 부분에 추가하는 과정을 반복한다.

5) 이때, 승급하는 데이터 페이지가 LRU 영역의 Head에 위치했을 경우, 바로 위인 MRU 영역의 Tail이 아닌 MRU 영역의 Head로 이동한다. (이부분이 핵심이다!)

6) 1,2,3,4,5 과정이 반복되면서 자주 사용되지 않는 데이터 페이지들은 자연스럽게 LRU 영역의 Tail 쪽으로 밀려난다. 끝까지 밀려난 데이터 페이지들은 버퍼 풀에서 제거된다.

7) 자주 사용되는 데이터 페이지의 경우 성능 향상을 위해 페이지의 인덱스 키를 '어댑티브 해시 인덱스'에 추가한다.

5. LRU, 오래된 데이터가 제거되는 것은 이해가는데.. MRU는?

LRU 알고리즘이 적용됐다는 것은 이해가 갈것이다. 그럼 최근에 사용된 데이터가 먼저 삭제된다는 MRU는 대체 어디에 적용된 것일까? 데이터 레코드를 버퍼 풀로 읽어오는 과정을 직접 그려보며 '최근 사용된 데이터가 먼저 삭제'되는 MRU 부분을 이해해보자.

1) 1시 30분, 디스크로부터 A 데이터 페이지를 읽어 버퍼 풀에 적재한다. 최초 버퍼 풀 적재시에는 LRU 영역 Head 부분에 저장된다.

2) 1시 32분, 디스크로부터 B 데이터 페이지를 읽어 버퍼 풀에 적재한다. LRU 영역 Head 부분에 저장됨과 동시에 기존 A 데이터 페이지는 Tail 쪽으로 밀려난다.

3) 2시 0분, 디스크로부터 C 데이터 페이지를 읽어 버퍼 풀에 적재한다. LRU 영역 Head 부분에 저장됨과 동시에 A, B 데이터 페이지는 Tail 쪽으로 밀려난다.

4) 2시 10분, 드디어 C 데이터 페이지를 찾는 쿼리가 실행됐고, C 데이터 페이지를 버퍼 풀에서 로드하게 된다. 이때 C 데이터 페이지는 LRU 영역의 Head에 위치했기 때문에 MRU 영역의 Head로 이동하게 된다.

5) 2시 20분, 디스크로부터 D 데이터 페이지를 읽어 버퍼 풀에 적재한다. LRU 영역 Head 부분에 저장됨과 동시에 A, B 데이터 페이지는 Tail 쪽으로 밀려난다.

6) 계속해서 신규 쿼리가 들어옴에 따라 디스크로부터 데이터 페이지를 읽어오게 되었다. E, F, G... X, Y, Z 까지, 다양한 데이터 페이지를 디스크로부터 로드하다보니 5시 30분이 되었다.

6. 최신의 데이터가 먼저 제거된다!

2시 10분에 저장한 C 데이터 페이지보다 최근에 사용했었던 E, F, G, H... 들의 데이터 페이지가 버퍼 풀에서 먼저 제거되었다. MRU 영역에서도 자주 사용되지 않은 데이터 페이지들은 Tail 쪽으로 밀려난다. 단, MRU 영역에 있는 C 데이터 페이지가 삭제되지 않은 이유는, 다른 데이터 페이지들이 여러번 재사용되지 않았고, 이로 인해 MRU 영역에서의 '경쟁'이 발생하지 않았기 때문이다. 

 '최근 사용된 데이터인 E,F,G,H 등의 데이터 페이지들이 먼저 삭제'된다는 점에서 MRU 알고리즘이 적용되었음을 알 수 있다.

7. 정리하면... InnoDB의 LRU + MRU 버퍼 풀

 InnoDB 버퍼 풀은 하이브리드 방식을 사용함으로써 단순 오래된 데이터 페이지 뿐 아니라, 자주 사용되지 않은 최신의 데이터 페이지들도 제거하고 있다. 만약 MRU 알고리즘이 적용되지 않았다면 어떨까? 최근 액세스한 데이터 페이지 들 중 자주 사용되지 않아 사실상 필요없는 데이터 페이지가 메모리에서 공간만 차지할것이고, 버퍼 풀이 가득 차서야 제거될것이다. 캐시 메모리를 최대한 활용하기 위해서는 자주 사용하는 데이터를 많이 저장하고, 최신의 데이터라할지라도 자주 사용하지 않은 데이터는 제거하는 것이 좋지 않겠는가?!

오늘은 InnoDB Buffer Pool에 대한 기본 구조와 InnoDB의 LRU + MRU 리스트에 대해 알아보았다. 다음은 리두 로그와 언두 로그에 대해 공부해보도록 하겠다!

1. 개요

 도커 클라이언트, 도커 호스트, 도커 레지스트리의 개념을 이해하고, 도커 기본 명령어를 알아보자.

2. 도커 전체 구조

앞서 말한 3개 개념은 도커 전체 구조에 대한 개념이다. 도커는 클라이언트, 호스트, 레지스트리라는 기본 구조를 갖는다.

2.1. 도커 클라이언트

 도커에 명령을 내릴 수 있는 CLI 도구이다. 도커 이미지 다운로드, 컨테이너 실행, 중지, 조회 등 도커를 관리할 수 있는 다양한 명령어를 제공한다.

2.2. 도커 호스트

도커를 설치한 서버 혹은 가상 머신을 말한다. 현재 내 PC에 도커를 설치했다면, 도커 호스트는 내 PC이다.

2.3. 도커 레지스트리

 도커 이미지를 저장하거나 배포하는 시스템이다. 만약 이미지가 필요하다면 도커 레지스트리로부터 다운받게 된다. 대표적으로 DockerHub(http://hub.docker.com)가 있다. 도커 이미지계의 깃허브라 할 수 있다.

위 홈페이지에 들어간 후 검색창에 원하는 도커 이미지를 검색하고,

상세 정보를 통해 도커 이미지를 다운받을 수 있는 명령어(ex. docker pull redis)를 확인할 수 있다. 이 명령어를 도커 클라이언트를 통해 입력하면 도커 레지스트리를 통해 이미지를 다운받게 된다. 명령어는 도커 호스트에 위치한 도커 데몬이 처리하게 된다.

* 도커 데몬

 도커와 관련된 리소스를 관리하는 백그라운드 프로세스이다. 이미지 다운로드 명령어가 입력될 경우 도커 호스트(도커가 설치된 서버)에  도커 이미지 존재 여부를 체크한 후, 이미지가 없을 경우 도커 레지스트리로부터 이미지를 다운받게 된다.

* 도커 이미지

 컨테이너 형태로 소프트웨어를 배포하기 위해 필요한 모든 요소(코드, 라이브러리, 설정 등)를 실행할 수 있는 빌드된 패키지이다. 도커 이미지는 독립적이기때문에 의존성을 고려할 필요가 없다.

* 도커 컨테이너

 도커 이미지를 실행할 수 있는 인스턴스를 말한다. 도커 컨테이너는 도커 이미지로부터 생성된다. 도커 컨테이너는 자체 파일 시스템을 갖으며 외부와 시스템 리소스를 공유하지 않고 독립적으로 실행된다. 단, OS는 공유한다!

3. 도커 기본 명령어

도커 이미지 다운로드

docker image pull {이미지 이름:태그 이름}

도커 이미지 목록 확인

 docker image ls

도커 컨테이너 실행

docker container run {이미지명}

실행중인 도커 컨테이너 리스트 조회

docker container ls

** 컨테이너를 실행했는데 컨테이너 리스트에서 조회가 되지 않아요

docker container run 명령어를 통해 컨테이너를 실행했을때, 해당 컨테이너 내에서 실행되는 프로세스나 서비스가 없을 경우, 컨테이너가 자동으로 종료되기 때문이다. 대표적으로 ubuntu 컨테이너가 이에 해당하며, 컨테이너 내에서 프로세스 실행을 유지시키기 위해 /bin/bash 와 같은 명령어를 함께 입력한다.

이에반에 Redis나 MySQL의 경우 컨테이너 실행 시 백그라운드 서비스가 돌아가기 때문에 자동으로 종료되지 않는다.

모든(정지 상태 포함) 도커 컨테이너 리스트

docker container ls -a

컨테이너 종료

docker container stop {컨테이너 ID}

컨테이너 강제 종료

docker container kill {컨테이너 ID}

컨테이너 삭제

docker container rm {컨테이너 ID}

이미지 삭제

docker image rm {이미지 ID}

개요

InnoDB의 잠금에 대해 알아보기 전 비관적 잠금과 낙관적 잠금에 대해 알아보았다.

낙관적 잠금

각 트랜잭션이 같은 레코드를 변경할 가능성이 낮다고 낙관적으로 가정하는 상황에서의 잠금이다. 리소스를 잠그지 않고 데이터를 업데이트 한 후, 마지막 커밋 시 충돌을 확인하는 방식이다.

충돌이 감지되면(트랜잭션이 시작되고 끝나는 사이, 다른 트랜잭션이 데이터를 수정) 트랜잭션이 롤백되고 오류를 반환한다.

충돌을 어떻게 확인할까?

테이블에 수정 시점을 추적할 수 있는 버전 필드 또는 타임스탬프를 추가하는 것이다.

버전 필드 (Version Field)
낙관적 잠금에서 각 데이터 레코드에 추가되는 필드로, 해당 레코드가 마지막으로 수정된 시점을 추적하는 용도로 사용된다. 레코드가 업데이트 될 때마다 이 버전 번호가 증가하는 형태이다.

트랜잭션이 데이터를 읽을 때 버전 필드를 함께 읽고, 트랜잭션이 커밋할 때 버전 번호를 확인하여 일치하는지를 확인한다. 만약 버전 필드 값이 달라졌다면, 다른 트랜잭션에서 데이터를 수정한 것이라 판단하고 트랜잭션을 롤백 또는 재시작한다.

 타임스탬프를 사용할 경우 해당 레코드의 수정 시간을 기재한다. 마찬가지로 트랜잭션이 시작, 종료될 때 레코드의 수정 시간이 달라졌다면 롤백을, 같다면 커밋을 하는 방식이다.

-- 1. 데이터 읽을 때 버전 정보도 함께 읽음
SELECT product_id, product_name, price, version
FROM products
WHERE product_id = 1;

-- 2. 수정 시 버전 확인
UPDATE products
SET price = 200.00, version = version + 1
WHERE product_id = 1 AND version = 2;  -- '2'는 읽은 버전 번호

낙관적 잠금 장단점

자원에 대한 잠금이 없기때문에, 대기 시간이 짧고, 처리 속도가 향상될 수 있다. 특히 데이터 충돌이 드문 경우에는 트랜잭션이 빠르게 처리된다. 또한 여러 트랜잭션이 동시에 데이터를 읽고 수정할 수 있으므로, 데이터 충돌이 발생하는 상황이 적다면 그만큼 높은 동시성을 유지하게된다.

하지만 데이터 충돌이 발생할 경우 트랜잭션을 다시 시도해야 한다.  충돌이 자주 발생하거나 처리 비용이 높은 트랜잭션이라면, 재시도 비용도 증가하게 된다. 또한 충돌에 대한 예외 로직이 필요하다. 변경을 다시 시도하거나, 사용자에게 알림을 주는 등의 별도 처리가 필요하다. 이러한 예외 코드를 잘못 구현하기라도 한다면 데이터 무결성이 손상될수 있으므로 주의해야한다.

비관적 잠금

각 트랜잭션이 같은 레코드를 변경할 가능성이 높다고 비관적으로 가정하는 상황에서의 잠금이다.즉, 하나의 트랜잭션이 데이터를 조회하는 시점에 락을 걸고, 트랜잭션이 끝날때까지 유지한다.

조회 시점에 잠금을 획득하는 대표적인 방법은 SELECT FOR UPDATE 이다.

비관적 잠금의 장단점

트랜잭션의 동시 접근을 확실하게 방지할 수 있기에 데이터의 무결성이 보장된다.

하지만 동시성이 떨어져 처리 속도가 느리다. 트랜잭션이 각각의 자원을 점유하는 상태에서 서로의 자원을 요청한다면, 데드락이 발생하게 된다.

비관적 잠금 데드락 재현

1) 1번 트랜잭션이 users 테이블의 id = 1인 레코드에 대해 비관적 잠금을 설정한다. 트랜잭션은 끝나지 않고, 다른 작업들을 처리하고 있다.

select * from users where id = 1 FOR UPDATE;

2) 도중 2번 트랜잭션이 시작되었고, users 테이블의 id = 10인 레코드에 대해 비관적 잠금을 설정한다. 마찬가지로 트랜잭션은 끝나지 않고, 다른 작업들을 처리하고 있다.

select * from users where id = 10 FOR UPDATE;

3) 1번 트랜잭션의 작업 중 유저 정보 일괄 수정 위해 업데이트 쿼리가 나갔지만, 2번 트랜잭션에서 id = 10인 레코드에 대한 잠금으로 인해 '대기상태'에 들어간다.

update users set name = '이름';

4) 2번 트랜잭션에서도 마찬가지로 유저 정보 일괄 수정 위해 업데이트 쿼리가 나갔지만, 1번 트랜잭션에서 id = 1인 레코드에 대한 잠금으로 인해 '대기상태'에 들어간다.

5) 트랜잭션 1, 2번은 데드락 상태에 빠지게 된다.

하지만 실제 테스트를 해보니 무기한 데드락이 걸리지 않고 한쪽 트랜잭션을 롤백시키는 것을 볼 수 있는데, 이는 InnoDB에서 제공하는 자동 데드락 탐지 기능에 의해 한쪽 트랜잭션이 롤백되는 것이다.

또한 락에 대한 타임아웃도 설정되어있기에, 락이 걸린 자원을 획득하지 못한다면 무한정 대기상태에 들어가지 않고, 에러 및 롤백 후 트랜잭션 재시작을 시도한다.

잠금에 대한 대기 시간 변수는 innodb_lock_wait_timeout이며 , 기본 50초로 설정되어 있다.

개요

  도커를 이해하기 위해서 필요한 사전지식인 운영체제, 프로그램, 스레드, 네임스페이스의 개념을 알아보자. 

운영체제

 컴퓨터는 하드웨어와 소프트웨어로 구성된다. 좁은 의미에서 하드웨어는 기계, 소프트웨어는 프로그램들을 말하는데 소프트웨어에는 '운영체제'라 부르는 시스템 소프트웨어가 존재한다. 운영체제는 하드웨어와 소프트웨어 자원을 관리하고, 프로그램이 실행될 수 있는 환경을 제공하는 역할을 한다.

프로그램

 실행 가능한 명령어의 집합을 의미한다. 디스크에 저장되어 있으나, 메모리에는 올라가지 않은 정적인 상태로 존재한다. 컴퓨터에 설치된 게임, 파워포인트, 우리가 개발하여 jar로 빌드한 파일 모두 프로그램이다.

프로세스

 실행중인 프로그램을 의미한다. 프로그램이 실행되면 메모리에 올라간다. 즉, 프로세스는 메모리에 올라간 상태로 존재한다.

스레드

 프로세스 내에 실행되는 여러 흐름의 단위를 의미한다. 예를들어 워드 프로그램을 실행시킨다면, 하나의 스레드는 화면상에 글자를 보여주는 일을, 다른 스레드는 사용자의 키 입력에 대응하는 일을, 또 다른 스레드는 오탈자와 문법을 확인하는 일을 한다.

정리하면, 컴퓨터를 구성하는 소프트웨어 중 '프로그램을 실행할 수 있는 환경을 제공'하는게 운영체제이고, '프로그램을 실행하면 프로세스'가 되며, '프로세스 내부에서 여러 스레드들이 동작' 하며 기능들을 수행한다.

네임스페이스

 프로세스를 실행할 때 시스템 리소스를 분리해서 실행할 수 있도록 도와주는 기능을 의미한다. 예를들어 여러 프로세스를 실행했을때, 각각의 프로세스가 모든 파일 시스템에 접근할 수 있는게 아닌, 첫번째 프로세스는 A 디렉토리에만, 두번째 프로세스는 B 디렉토리에만 접근할 수 있도록 하면 어떨까? 각각의 프로세스 입장에서 보면 하나는 A 디렉토리, 다른 하나는 B 디렉토리만을 할당받은 체로 동작하게 된다. 즉, 네임 스페이스를 잘 활용하면 같은 운영체제 내에 실행되는 프로세스들이 논리적으로 분리된 환경에서 실행 될 수 있는 것이다.

개념적으로는 이해되나, 네임스페이스들이 어떻게 상호작용하는지는 따로 공부가 필요할 것 같다. 잘 알려진 네임스페이스는 다음과 같다.

도커란?

 운영체제 수준의 가상화 방식을 통해 소프트웨어를 배포하는 가상환경을 제공하는 소프트웨어이다. 사용자 입장에서는 OS 까지의 가상 환경을 제공받아 어플리케이션만 관리/배포하면 되니 도커를 PaaS 제품이라고도 부른다.

 운영체제 수준의 가상화 방식은 뭘까? 운영체제가 가상화 즉, '논리적으로 분리된 환경'을 제공하는 방식을 말한다. 운영체제가 논리적으로 분리된 환경을 제공할 수 있을까? 있다! 시스템 리소스들을 분리한 후 환경별로 다른 시스템 리소스들을 제공하면 된다. 네임스페이스들을 통해서 말이다. 

위와 같이 운영체제에서 네임 스페이스를 통해 시스템 리소스들을 분리한 후, 서로 다른 네임 스페이스를 도커가 띄운 프로세스에게 제공하는 것이다. 그럼 이 프로세스는 운영체제 위에서 다른 프로세스들과는 격리된 환경으로 구성된 하나의 '패키지' 역할을 하게 되는데, 바로 이를 컨테이너라 한다.

컨테이너란?

 컨테이너는 소프트웨어를 배포할 때 필요한 코드, 라이브러리, 환경 설정 파일들을 한데 모아 격리시킨 후, 실행 가능한 패키지로 만든 것을 의미한다. 

1. 개요

 readObject 메서드의 역할을 이해하고, 방어적으로 작성해야하는 이유를 알아보자.

2. 직렬화, 역직렬화 예제

 일반적으로 Object를 직렬화할 땐 ObjectOutputStream을, 역직렬화 할땐 ObjectOutputStream 인스턴스 인스턴스를 사용하고, 각각 writeObject(), readObject() 메서드를 호출하여 실제 데이터를 처리한다. 간단한 예제를 통해 직렬화와 역직렬화의 흐름을 먼저 이해해보자.

1) Period 인스턴스에 대한 직렬화

public final class Period implements Serializable {

   private Date start;
   private Date end;

   public Period(Date start, Date end) {
       this.start = new Date(start.getTime()); // 방어적 복사
       this.end = new Date(end.getTime());
       if (this.start.compareTo(this.end) > 0) { // 유효성 검사
           throw new IllegalArgumentException(start + " after " + end);
       }
   }

   public Date start() {
       return new Date(start.getTime());
   }

   public Date end() {
       return new Date(end.getTime());
   }
}

SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
Date startDate = df.parse("2024-11-14");
Date endDate = df.parse("2024-11-15");
try(
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(baos)){

    oos.writeObject(new Period(startDate, endDate));

    byte[] serialized = baos.toByteArray();
    for(byte b : serialized){
        System.out.print(b +" ");
    }
}

결과화면은 다음과 같다.

2) 직렬화된 byte[] 데이터에 대한 역직렬화

    public static void main(String[] args) throws IOException, ParseException {

        SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
        Date startDate = df.parse("2024-11-14");
        Date endDate = df.parse("2024-11-15");
        try(
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                ObjectOutputStream oos = new ObjectOutputStream(baos)){

            oos.writeObject(new Period(startDate, endDate));  // 직렬화

            byte[] serialized = baos.toByteArray();

            Period period = deserializePeriod(serialized); // 역직렬화
            System.out.println(period.start());
            System.out.println(period.end());
        }
    }
    
    public static Period deserializePeriod(byte[] bytes) throws IOException {

        try(
                ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
                ObjectInputStream ois = new ObjectInputStream(bais)){

                Object object = ois.readObject();
                return (Period) object;
        } catch (ClassNotFoundException e) {
            throw new RuntimeException(e);
        }
    }

결과 화면은 다음과 같다.

3. readObject() 메서드의 문제 #1

readObject() 메서드가 수행하는 역할을 보면 byte[] 데이터를 기반으로 인스턴스를 생성하는 역할을 한다. 즉, 생성자의 역할을 하는 것이다. 일반적으로 생성자에는 validation을 통해 데이터의 불변식을 보장한다. 하지만 바이트 데이터가 조작되어 불변식이 깨진 Object에 대한 byte[] 데이터가 들어온다면 readObject() 메서드를 호출했을 때 별다른 validation 체크를 하지 않기때문에 불변식을 보장하지 못하게 된다.

public class BogusPeriod {
    
    // 정상적이지 않은 바이트스트림
    private static final byte[] serializedForm = {
        (byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x06,
        0x50, 0x65, 0x72, 0x69, 0x6f, 0x64, 0x40, 0x7e, (byte)0xf8,
        0x2b, 0x4f, 0x46, (byte)0xc0, (byte)0xf4, 0x02, 0x00, 0x02,
        0x4c, 0x00, 0x03, 0x65, 0x6e, 0x64, 0x74, 0x00, 0x10, 0x4c,
        0x6a, 0x61, 0x76, 0x61, 0x2f, 0x75, 0x74, 0x69, 0x6c, 0x2f,
        0x44, 0x61, 0x74, 0x65, 0x3b, 0x4c, 0x00, 0x05, 0x73, 0x74,
        0x61, 0x72, 0x74, 0x71, 0x00, 0x7e, 0x00, 0x01, 0x78, 0x70,
        0x73, 0x72, 0x00, 0x0e, 0x6a, 0x61, 0x76, 0x61, 0x2e, 0x75,
        0x74, 0x69, 0x6c, 0x2e, 0x44, 0x61, 0x74, 0x65, 0x68, 0x6a,
        (byte)0x81, 0x01, 0x4b, 0x59, 0x74, 0x19, 0x03, 0x00, 0x00,
        0x78, 0x70, 0x77, 0x08, 0x00, 0x00, 0x00, 0x66, (byte)0xdf,
        0x6e, 0x1e, 0x00, 0x78, 0x73, 0x71, 0x00, 0x7e, 0x00, 0x03,
        0x77, 0x08, 0x00, 0x00, 0x00, (byte)0xd5, 0x17, 0x69, 0x22,
        0x00, 0x78
    };

    public static void main(String[] args) {
        Period p = (Period) deserialize(serializedForm);
        System.out.println(p);
    }
    
    static Object deserialize(byte[] sf) {
        try {
            return new ObjectInputStream(new ByteArrayInputStream(sf)).readObject();
        } catch (IOException | ClassNotFoundException e) {
            throw new IllegalArgumentException(e);
        }
    }
}

출력하면 다음과 같이 start보다 end가 더 이르다는 것을 확인할 수 있다. 생성자를 사용하지 않기 때문에 validation 체크가 이루어지지 않고, 최종적으로 생성된 Period 객체는 불변식이 깨져버렸다.

4. readObject() 메서드 커스텀

이를 해결하기 위해 readObject() 메서드를 생성해야한다. 역직렬화할 클래스 내에 private 접근 제어자로 readObject() 메서드가 정의되어 있을 경우 ObjectInputStream.readObject() 메서드 호출 시 새로 정의한 메서드를 호출하기 때문이다. (리플렉션 기반)

 단, 반드시 privcate 접근 제어자로 선언해야하고, 메서드 내에서 defaultWriteObject(),  defaultReadObject()와 같은 기본 직렬화, 역직렬화 메서드를 한번 호출해줘야한다.

public final class Period implements Serializable {
    private Date start;
    private Date end;

    public Period(Date start, Date end) {
        this.start = new Date(start.getTime()); // 방어적 복사
        this.end = new Date(end.getTime());
        if (this.start.compareTo(this.end) > 0) { // 유효성 검사
            throw new IllegalArgumentException(start + " after " + end);
        }
    }

    public Date start() {
        return new Date(start.getTime());
    }

    public Date end() {
        return new Date(end.getTime());
    }

    private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException{
        s.defaultReadObject();
        if (this.start.compareTo(this.end) > 0) { // 유효성 검사
            throw new InvalidObjectException(start + " after " + end);
        }
    }
}

그 후, 불변식이 깨진 byte[] 데이터를 넣어 역직렬화를 해보면 유효하지 않는 오브젝트로 판단하여 역직렬화에 대한 예외를 발생시킨다.

5. readObject() 메서드의 문제 #2

하나의 문제가 더 있다. 직렬화된 스트림에 객체 참조 관련 바이트코드를 추가하면, 가변 Period 인스턴스를 만들 수 있다. Period 인스턴스를 가변 인스턴스로 사용할 수 있게 하는 MutablePeriod 클래스를 만든다.

public class MutablePeriod {
   public final Period period;

   public final Date start;

   public final Date end;

   public MutablePeriod() {
       try {
           ByteArrayOutputStream bos = new ByteArrayOutputStream();
           ObjectOutputStream out = new ObjectOutputStream(bos);

           // 불변식을 유지하는 Period 를 직렬화.
           out.writeObject(new Period(new Date(), new Date()));

           /*
            * 악의적인 start, end 로의 참조를 추가.
            */
           byte[] ref = { 0x71, 0, 0x7e, 0, 5 }; // 악의적인 참조
           bos.write(ref); // 시작 필드
           ref[4] = 4; // 악의적인 참조
           bos.write(ref); // 종료 필드

           // 역직렬화 과정에서 Period 객체의 Date 참조를 훔친다.
           ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray()));
           period = (Period) in.readObject();
           start = (Date) in.readObject();
           end = (Date) in.readObject();
       } catch (IOException | ClassNotFoundException e) {
           throw new AssertionError(e);
       }
   }

여기서 직렬화한 바이트 코드에 [0x71, 0, 0x7e, 0, 5], [0x71, 0, 0x7e, 0, 4] 코드를 추가한다. 이 값은 Java 직렬화 프로토콜에서 객체 참조를 나타내는 바이트 코드이다.

    public static void main(String[] args) {
        MutablePeriod mp = new MutablePeriod();
        Period mutablePeriod = mp.period; // 불변 객체로 생성한 Period
        Date pEnd = mp.end; // MutablePeriod 클래스의 end 필드
        
        pEnd.setYear(78); // MutablePeriod 의 end 를 바꿨는데 ?
        System.out.println(mutablePeriod.end()); // Period 의 값이 바뀐다.
        
        pEnd.setYear(69);
        System.out.println(mutablePeriod.end());
    }

결과적으로 이러한 방법을 사용하게 되면, 불변 객체로 생성되어야할 Period 인스턴스의 end 값이 수정됨을 알 수 있다.

이를 해결하기 위해서는 readObject() 메서드 재정의 시 방어적 복사 코드를 추가해야한다.

private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
   s.defaultReadObject();

   // 방어적 복사를 통해 인스턴스의 필드값 초기화
   start = new Date(start.getTime());
   end = new Date(end.getTime());

   // 유효성 검사
   if (start.compareTo(end) > 0)
       throw new InvalidObjectException(start +" after "+ end);
}

정리

 이런 문제는 누군가 고의적으로 바이트코드를 위조한 상황을 가정했을 때 발생하는 문제들이다. 직렬화한 코드를 아무나 접근할 수 있는 외부 서비스에 보냈을 때 불변식이 깨지고, 객체 참조까지 되는 것을 확인할 수 있다.

 앞선 챕터에서 Serializable은 신중하게 작성하라라는 내용이 있었다. 직렬화된 클래스가 외부로 나갔을 때 발생할 수 있는 여러 문제들이 있기 때문이다.

 이번 챕터 역시 이러한 문제를 겪지 않으려면 직렬화를 신중히 하고, 만약 직렬화가 필요하다면, 외부에서 접근할 수 없는 환경에 저장하고, 로드할 수 있도록 하는 것이 중요하다는 것을 다시 한번 느끼게 되었다.

1. 개요

직렬화(Serializable)의 개념을 이해하고, Serializable을 구현할 때 주의해야할 점을 알아보자.

2. 직렬화(Serializable)란?

인스턴스 >> Byte

인스턴스를 Byte로 변환하는 것을 말한다. 간혹 클래스를 Byte로 변환하는 것이라고도 하는데 목적 측면에서 보거나, 일반적으로 사용하는 방식을 보면 인스턴스를 직렬화하는게 더 맞는 표현이라고 생각한다.

3. 직렬화를 하는 이유

그렇다면 직렬화를 하는 이유는 뭘까? 도대체 뭘 위해서 직렬화를 하는걸까?

바로 인스턴스를 저장하거나, 전송하기 위함이다.

그럼 인스턴스를 저장하거나 전송하는 이유는 뭘까?

객체의 상태를 저장해야할 상황이 있기 때문이다. 아래 예시를 통해 알아보자.

4. 객체의 상태를 저장해야할 상황 

1) HTTP 세션 관리

 Spring 웹 어플리케이션에서는 HTTP 세션을 사용해 사용자 상태를 유지한다. 사용자의 ID나 이름, 국적 등과 같은 '상태값'을 세션에 저장해두고 필요할때마다 가져온다.

 만약 세션 클러스터링 환경이라면 어떨까? 세션을 다른 서버와 공유해야한다. 정확히 말하면 상태값을 갖고 있는 인스턴스를 다른 서버에 전달해야한다. 이를 위해 직렬화하고, Byte 데이터를 Stream 방식으로 전달하는 것이다.

2) 인메모리 저장소 활용(ex. Redis)

spring Session이나 캐싱기능을 위해 저장소로 Redis를 사용하고자 한다면, Redis에 저장할 인스턴스의 클래스에 Serializable을 구현했을 것이다. 상태 값을 가진 인스턴스를 Redis라는 외부 저장소에 전달해야하기 때문이다. 이때도 마찬가지로 외부로 전달하기 위해 직렬화를 한다.

3) 영속적인 저장 / 데이터 복원

 HTTP 세션, 클러스터링 환경, 인메모리 저장소는 서버가 재시작되면 저장된 데이터가 날아간다. 서버가 재시작되도 상태값을 유지하고 싶다면 상태 값을 필드로 구분하여 DB에 저장하는 방법도 있지만, 인스턴스 자체를 DB에 저장하는 방법도 있다. 디스크에 저장하는 방식이다. 이 경우 서버에 문제가 생기거나 재시작이 되어도 데이터를 쉽게 복원할 수 있다.

5. Serializable 주의사항

1) 릴리스 한 뒤에는 수정이 어렵다.

클래스가 Serializable을 구현하면 직렬화된 바이트 스트림 인코딩도 하나의 공개 API가 된다. 누군가 역직렬화를 하면 클래스 구조와 상태값들을 확인할 수 있기 때문이다. 그래서 이 클래스가 널리 퍼지게 된다면, 그 직렬화 형태도 영원히 지원해야 한다. 만약 특정 필드를 제거하거나, 타입을 바꾸는 등의 수정을 한다면, 타 시스템의 역직렬화 과정에서 에러가 발생할 수 있기 때문이다.

직렬화 가능 클래스를 만들고자 한다면, 길게 보고 수정이 일어나지 않는 형태로 주의해서 설계해야한다.

2) 버그와 보안 구멍

객체는 생성자를 사용해 만드는게 기본이다. 역직렬화는 기본 방식을 우회하는 생성 기법이다. 마치 숨은 생성자와 같다. 생성자를 우회한다는건 객체 초기화에 필요한 모든 내부 코드를 무시한다는 측면에서 버그를 유발 가능성을 재기한다.

 또한 공격자가 객체 내부를 들여다 볼 수 있다면, 직렬화된 코드를 조작하여 서버로 전달할 수 있다. 해당 서버에서 조작된 메서드를 호출이라도 한다면 공격자가 의도한 작업을 서버 내에서 실행하게 될것이다.

따라서 공격자가 이러한 데이터를 볼 수 없는 환경, 즉 private한 환경에서 사용해야한다.

3) 신버전을 릴리스할 때 테스트가 늘어난다.

 직렬화 가능 클래스가 수정되면 신버전 인스턴스를 직렬화 한 후 구버전으로 역직렬화할 수 있는지, 그 반대도 가능한지 테스트 해야한다. 직렬화 가능 클래스의 수가 많을수록 테스트할 횟수도 증가한다.

4) 상속용으로 설계된 클래스나 인터페이스는 Serializable을 구현하거나 확장해선 안된다.

해당 클래스를 클래스를 상속하거나 구현하는 모든 클래스는 앞선 문제들에 위험을 안고가게 된다.

그런데... 직렬화 클래스를 수정하면 역직렬화가 무조건 실패하는게 아닐까? 필자의 경우도 그랬던 기억이 있었다. 

6. 직렬화 클래스를 수정하면 역직렬화가 무조건 실패하는거 아냐?

직렬화 클래스를 수정해도 구버전 데이터를 역직렬화할 수 있는 조건이 있다. 아래 두 조건을 모두 만족해야한다.

첫째, SerialVersionUID 가 일치할때

 클래스가 변경되었지만 serialVersionUID가 동일하다면 역직렬화가 가능하다. 클래스 구조가 약간 달라져도 serialVersionUID가 같다면 역직렬화를 시도할 수 있다.

둘째, 새로운 필드가 추가되거나 제거됐을 때

 - 직렬화된 클래스에 신규 필드를 추가할 경우, 역직렬화 시 해당 필드는 기본값 (null, 0, false) 등으로 설정된다.

 - 기존 필드가 삭제되어도 역직렬화가 가능하다. 역직렬화 시 해당 필드는 무시된다.

위 두 조건을 만족하면 직렬화 클래스가 수정되도 역직렬화가 가능하다.

단, 클래스의 인터페이스 혹은 상속 구조를 변경하거나, 필드 타입, 클래스 이름이 변경되면 역직렬화에 실패하게 된다.

serialVersionUID
클래스의 직렬 버전을 나타내는 ID 로 모든 직렬화된 클래스는 이 값을 부여받는다. 만약 필드에 명시한다면 그 값이 ID가 되겠지만, 명시하지 않는다면 클래스의 정보를 기반으로 해시함수를 적용해 UID가 자동으로 부여된다.

즉, 추후 조금의 수정 가능성을 염두해둔다면 SerialVersionUID의 값을 지정해주는 것이 좋다.

7. 정리

 Serializable은 구현하기는 아주 쉽지만, 주의해야할 사항이 많다. 때문에 클래스의 여러 버전이 상호작용할 일이 없고, 서버가 신뢰할 수 없는 데이터에 노출될 가능성이 없는 등, 보호된 환경에서만 쓰일 클래스가 아니라면 Serializable 구현은 아주 신중하게 이뤄져야한다. 상속할 수 있는 클래스라면 주의사항이 더욱 많아진다.

그럼 2만

1. 개요

 우리가 설치하고, 쿼리를 작성하는 MySQL 서버는 크게 두 엔진으로 구성된다. 하나는 MySQL 엔진, 하나는 스토리지 엔진. 스토리지 엔진은 데이터를 저장하는 하드웨어와 관련된 엔진이고, MySQL 엔진은 그 외 알쏭달쏭한 모든것이라고 생각하면 된다. 

뭔 개소린가 싶겠지만 일단은 이렇게 이해하고 시작해보도록 하자. 이게 정신건강에는 좋은것같다.

2. MySQL 전체 구조 핥아보기

 상당히 친해보이는 두 엔진이 MySQL 어디에 속하는지 알아보자. 아래는 Real MySQL8.0 에 기재된 MySQL 서버 구조이다.

 우리의 몸에 여러 기관들이 있듯이 하나의 엔진에도 여러 요소들이 존재한다. 각 요소들을 살펴보기 전에 그림에 나온 MySQL 서버의 전체 구조를 이해해보자.

3. MySQL 서버 전체 구조

MySQL 서버 전체 구조는 크게 프로그래밍 API, MySQL 서버, 운영체제 하드웨어로 나뉜다.

1) 프로그래밍 API 

MySQL 서버로 들어오는 요청에 대한 API를 말한다. Java 진영의 백엔드 개발자 입장에서는 JPA, MyBatis 를 사용해 MySQL 서버로 연동하는 부분이라 생각하면 된다.

2) MySQL 서버

우리가 배워야할 MySQL 엔진과 스토리지 엔진으로 구성된 서버이다. 생소한 용어들이 대부분이나 InnoDB는 뭔가 익숙하다. 일단 넘어가자.

3) 운영체제 하드웨어

DB 데이터는 운영체제 내 디스크에 저장된다. 단순 DB 데이터 뿐 아니라 로그파일도 저장된다.

4. MySQL 엔진 요소

1) 커넥션 핸들러 

 MySQL을 설치하고 가장 먼저 MySQL 서버에 접속한다. 접속에 성공하면 MySQL 서버와 접속한 클라이언트 간 커넥션이 생성된다. 커넥션 핸들러는 이러한 커넥션을 생성하고 클라이언트의 쿼리 요청, 즉, 커넥션에 관한 처리들을 핸들링한다.

 여기서 중요한건 '쿼리 요청을 핸들링'하는 것이다. 커넥션 핸들러가 쿼리를 분석하여 '처리'하진 않는다. 쿼리 요청이 오면 쿼리를 처리하는 어떤 녀석에게 "select 쿼리 처리해주세요!, insert 쿼리 처리해주세요!" 처럼 요청할 뿐이다.

2) SQL 인터페이스

DML, DDL, 프로시져, 뷰, 커서, 트리거, 함수 등의 지원을 위한 인터페이스를 말한다.

3) 쿼리 파서 (SQL 파서)

 커넥션 핸들러로부터 들어온 요청을 처리하며, 요청받은 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조로 만들어준다. 이러한 트리형태의 데이터를 '파서 트리'라고 하며, 이 과정에서 문법 오류를 체크한다.

4) SQL 옵티마이저

 파서 트리를 효율적으로 처리하기 위한 실행 계획을 결정한다. 여기서 결정된 실행 계획에 따라 쿼리 처리 속도나 비용이 달라지게 된다. MySQL 뿐만 아니라 모든 DBMS에서도 쿼리의 실행계획을 수립하는 옵티마이저를 갖고 있다. 실행 계획에 대해 잘 이해하여 쿼리의 불합리한 부분을 찾아낸다면 옵티마이저의 최적화에 도움을 줄 수 있을것이다.

 추후 실행계획에 대해서 공부한 후 포스팅하도록 하겠다.

5) 캐시

MySQL 에서는 InnoDB Buffer Pool, Table Open Cache, Thread Cache 캐시가 사용된다. 캐시에 대한 자세한 내용은 다음에 다루도록 하겠다.

* 제거된 쿼리 캐시
 MySQL 8.0 부터 쿼리 캐시 기능이 제거됐다. 쿼리 캐시는 빠른 응답을 필요로 하는 웹 기반의 응용 프로그램에서 매우 중요한 역할을 담당했었다. SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환하도록 동작했다. 하지만 테이블의 데이터가 변경되면 캐시에 저장된 결과 중에서 변경된 테이블과 관련된 것들을 모두 삭제해야 했다. 이는 심각한 동시 처리 성능 저하, 버그를 유발해 결국 제거됐다.

6) 버퍼

Join, Order By, Group By, Select 등의 쿼리 실행 시 사용되는 임시 메모리 공간을 의미한다. 종류로 Sort Buffer, Join Buffer, Read Buffer 가 있다. 각각에 대해 알아보자.

- Sort Buffer

 ORDER BY나 GROUP BY를 사용할 때 사용되는 버퍼로, 정렬에 필요한 데이터를 메모리에 저장하고, 이 안에서 정렬을 수행한다. 만약 정렬할 데이터가 Sort Buffer에 담기지 않을 경우 일부 데이터를 디스크의 임시 파일에 저장하고, 메모리와 디스크를 함께 사용해 정렬한다.

* ORDER BY 시 Select 절에는 꼭 필요한 컬럼만 기재하자
Order By 사용 시 Select 절 "*" 를 넣거나 굳이 필요없는 컬럼 추가한다면 Sort Buffer 의 사이즈를 초과할 수 있다. 이 경우 디스크에 임시 파일 형태로 데이터들이 저장될것이고 많은 I/O 비용을 들이는 메모리&디스크 정렬이 수행되기 때문이다.

- Join Buffer

인덱스가 없는 조인 작업을 수행할 때 사용하는 버퍼이다. 두 테이블을 조인할 때 보다 작은 테이블의 데이터를 Join Buffer에 저장하고, 큰 테이블의 데이터를 반복해서 비교하는 방식이다. 만약 테이블의 데이터가 Join Buffer에 담기지 않을 경우 여러번에 나누어 조인을 수행한다. 이는 성능 저하를 초래한다.

* Join Buffer에 의존하기보단 인덱스 기반 조인을 사용하자
일반적으로 Join Buffer에 의존한 조인보다 인덱스 기반의 조인이 성능면에서 우수하다. 키나 인덱스로 설정되지 않는 컬럼에 대한조인 시, 속도가 느리다면 Join Buffer를 추가하는것보다 인덱스 설정을 고려하자. 

- Read Buffer

 테이블의 데이터를 순차적(Full Scan)으로 읽을 때 사용되는 버퍼이다. 규모가 큰 테이블일수록 버퍼의 효율이 높아진다.

* 규모가 클수록 효율이 높은 이유
 Full Scan이 발생하면 MySQL은 디스크에서 테이블 데이터를 한번에 읽어오는게 아닌 조금씩 읽어온다. 이 과정에서 I/O 작업이 발생하는데, 읽어야할 테이블의 데이터가 많을 수록 I/O 작업은 늘어나게 된다. Buffer를 사용하게 된다면 조금씩이 아닌 버퍼 사이즈만큼 읽어올 수 있으므로 버퍼의 효율이 높은것이다. read_buffer_size 옵션으로 조절 가능하며 기본 값은 128KB이다.

5. MySQL 쿼리 실행 구조

스토리지 엔진을 알아보기 전 MySQL 엔진에서 일어나는 쿼리 실행 프로세스에 대해 알아보자. 여기서 사용되는 개념은 앞선 MySQL 서버 전체 구조의 요소에 중복된 내용이 있을 수 있으니 복습한다 생각하고 참고하도록 하자.

1) 클라이언트 접속

 클라이언트가 MySQL 서버에 접속하기 위해 ID/PW를 입력한다. 입력하는 시점에  MySQL 네이티브 프로토콜을 통해 MySQL 서버와 TCP/IP 기반의 커넥션이 맺어지게 된다. 이때 커넥션이 생성된다는 뜻인데, 정확히는 '임시 커넥션'이 생성되며, ID/PW 인증이 성공할 경우 완전한 커넥션이 맺어지게 된다.

2) 쿼리 요청 처리

 클라이언트가 쿼리를 입력하면 커넥션 핸들러가 쿼리 요청을 처리하기 위해 쿼리를 쿼리 파서에게 전달한다.

3) 파서 트리 생성 및 문법 오류 체크

 쿼리 파서는 받은 쿼리를 토큰으로 분리해 파서 트리를 생성한다. 추가로 이 과정에서 문법 오류를 체크한다. 문법에 이상이 없으면 전처리기에게 파서 트리를 전달한다.

4) 개체 검사 및 권한 체크

 전처리기는 파서 트리를 분석해 쿼리 문장에 구조적인 문제점이 있는지 확인한다. 각 토큰을 테이블 명, 컬럼 명, 내장 함수 명 등과 같은 개체에 매핑하여 유효성을 검사하고, 접근 권한을 확인한다. 실제 존재하지 않거나, 권한 상 접근할 수 있는 개체의 토큰은 이 단계에서 체크한다. 그 후 옵티마이저에게 전달한다.

5) 실행 계획 수립

 옵티마이저는 쿼리를 분석해 실행 계획을 수립한다. 하지만 계획을 할당하고, 이행하는 주체는 따로 있다. 실행 엔진과 핸들러인데, 이들의 관계를 회사로 비유하면 아래와 같다.

 - 옵티마이저 : 회사의 경영진 (회사의 계획 수립)

 - 실행 엔진 : 중간 관리자 (계획을 받아 업무를 할당)

 - 핸들러 : 실무자 (업무를 이행)

 이 단계에서는 옵티마이저가 실행 엔진에게 실행 계획을 전달한다.

6) 핸들러에게 처리 요청

 실행 엔진은 (옵티마이저가 만든) 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러의 요청의 입력으로 연결하는 역할을 수행한다.

7) 핸들러의 작업 처리

 핸들러는 MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하거나 읽어 오는 역할을 담당한다. 즉, 핸들러는 스토리지 엔진을 의미하며, MyISAM 테이블을 조작하는 경우에는 핸들러가 MyISAM 스토리지 엔진이 되고, InnoDB 테이블을 조작하는 경우에는 핸들러가 InnoDB 스토리지 엔진이 된다.

1. 개요

 하나의 자바 프로세스 안에서 여러 스레드이 동작한다. 이 스레드들은 스레드 스케줄러에 실행된다. 그렇다면 프로그램의 동작을 스레드 스케줄러에 기대지 말라는 뜻이 뭘까?

스레드 스케줄러
운영체제가 프로세스 내 스레드들 사이에서 CPU 시간을 어떻게 분배할지를 결정하는 주체이다. 자바 코드 레벨에서 스레드를 생성해도 마찬가지이다. 스레드 스케줄러의 정책에 따라 실행된다. 정책으로는 라운드 로빈 방식, 우선순위 기반 방식, 최소 남은 시간 우선 방식 등이 있다.

2. 운영체제마다 다른 스케줄링 정책

 스레드 스케줄러의 정책은 운영체제마다 다를 수 있다. 프로그램의 동작이 스레드 스케줄러에 기댄다면 운영체제의 스케줄링 정책에 영향을 받게 되는것이다. 즉, '스레드 스케줄러에 기대는 프로그램은 정확성이나 성능이 운영 체제에 따라 달라지게 된다' 는 점에서 프로그램을 다른 플랫폼에 이식하기 어렵게 된다.

3. 스레드 스케줄러에 영향을 받지 않으려면 어떻게하나요?

1) 실행 가능한 스레드의 수를 지나치게 만들지 않기

실행 가능한 스레드
실행 가능한 스레드는 스레드 큐에 위치하여 언제든 CPU의 선택을 받을 수 있는 스레드를 말한다.

 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 프로세서는 CPU인데, 멀티쓰레드를 지원하는 JVM 에서 스레드 수를 프로세서 수보다 지나치게 많아지지 않도록 하라는 게 무슨 의미인지 이해되지 않았다. 예를들어 필자의 컴퓨터는 멀티코어로 두개의 CPU가 있다. 그럼 스레드 수를 2개보다 지나치게 많아지지 않도록해라? 아무리 생각해도 100개의 스레드는 지나치게 많은 개수같은데, 일반적으로 JVM 스레드가 100개를 넘는 일은 허다하지 않나라는 의문이 들었다.

 위 내용에 대해 고민을 많이 했는데, 책을 다시 보니 필자가 핀트를 잘못 짚은것이었다. 실행 가능한 스레드의 수가 많으면 좋지 않다는게 아니라 단순히 스레드 스케줄러의 영향을 받지 않는 방법을 명시한 것이었다.  스레드 개수가 적어 스케줄러가 고민할 거리가 줄어든다면 정책의 영향을 덜받지 않겠는가. 당연한 얘기였다.

 다시 돌아가 필자의 컴퓨터는 한 코어에 6개의 스레드를 동작시킬 수 있다. 멀티 코어이니 최대 12개의 스레드를 동시처리 할 수 있다. 이보다 지나치게 많아졌을 때 스레드 스케줄러에 의해 스레드들이 제어될것이고, 이 프로그램이 '스레드 스케줄러에 기대도록' 구현이 되어있다면 문제가 생길 수 있다는 것이 포인트였다.

2) 스레드는 맡은 작업을 완료할 때까지 계속 실행되도록 하자

 스레드가 작업을 완료하기 전에 대기 상태로 가는 코드가 없도록 코드를 작성해야한다. 대기한다는 뜻은 곧 스레드 스케줄러의 정책에 의해 제어된다는 의미이기 때문이다. 또한 스레드는 당장 처리해야할 작업이 없다면 실행되게 해서도 안된다.

4. 당장 처리해야할 작업이 없다면 실행되게 해선 안된다?

 당장 처리할 작업이 없다면 대기 상태에 들어갈것이다. 그리고 다시 실행되기 위해 지속적인 상태체크를 한다. 즉, 스레드가 바쁜 대기(busy waiting) 상태가 되는것이다.

 당장 처리해야할 작업이 없지만 상태를 검사하기 위해 스레드가 실행된다. 의미없이 CPU를 선점하고 있는 격이기에 의미있는 작업을 맡은 스레드들이 당장 실행될 기회를 박탈당하게 된다.

5. Busy Waiting 예시

CountDownLatch 클래스의 기능을 가진 커스텀 클래스를 만들었다. Busy Waiting 상태가 나타나는 코드로CountDownLatch 클래스를 삐딱하게 구현한 코드이다.

await() 메서드 내 while(true)에 의해 해당 스레드는 계속해서 CPU를 점유할것으로 보이지만, 실제로는 스케줄링 정책에 대기/실행 상태를 왔다갔다하며 다른 스레드들도 중간 중간 실행될것이다. 그런데 이 메서드가 하는 일이 뭔가? 그냥 대기하는것이다. while 문에 의해 count 값만 계속 체크하는 로직인데, countDown()을 수행하는 스레드와 바쁘게 경쟁하게 된다. 경쟁자가 많다보니 컨텍스트 스위칭이 빈번하게 일어날테고, countDown() 호출이 늦어지는 결과를 초래하게 된다.

 이런 프로그램이 프로그램의 동작을 스레드 스케줄러에게 기댄 코드라고 할 수 있다.

1) SlowCountDownLatch.java

public class SlowCountDownLatch {

    private int count;

    public SlowCountDownLatch(int count){
        if(count < 0){
            throw new IllegalArgumentException(count + " < 0");
        }
        this.count = count;
    }

    public void await(){
        while(true){
            synchronized (this){
                if (count == 0)
                    return;
            }
        }
    }

    public synchronized void countDown(){
        if (count != 0){
            count --;
        }
    }
}

1) Main.java

public static void main(String[] args) {

    SlowCountDownLatch ready = new SlowCountDownLatch(1000);
    SlowCountDownLatch start = new SlowCountDownLatch(1);
    SlowCountDownLatch end = new SlowCountDownLatch(1000);
    ExecutorService executorService = Executors.newFixedThreadPool(1000);

    for(int i =0; i< 1000; i++){
        executorService.submit(() -> {
            ready.countDown();

            start.await();
            System.out.println("끼요옥");

            end.countDown();
        });
    }
    ready.await();
    System.out.println("준비완료. 시작!");
    start.countDown();
    long StartNanos = System.nanoTime();
    end.await();
    System.out.println("걸린시간 : " + ( System.nanoTime() - StartNanos));
}

스레드 1000개를 생성하여 SlowCountDownLatch를 테스트한 결과, Java에서 제공하는 CountDownLatch보다 2, 3배 느린 것을 확인할 수 있었다. 책에서는 약 10배가 느렸다고 한다.

6. 실행을 양보한다면?

그럼 await() 내 상태 체크가 실패했을 경우 현재 스레드를 해제하고 다른 스레드가 작업할 수 있도록 '양보'하는 건 어떨까? 현재는 운영체제의 스레드 스케줄링 정책에 의해 대기상태로 가고 있는데, 당장 스레드 큐로 보내버리는 것이다.

 Thread.yield() 메서드를 이용하면 현재 스레드를 실행 가능한 상태로 보낼 수 있다.

public void await(){
    while(true){
        synchronized (this){
            if (count == 0)
                return;
            else{
                Thread.yield();
            }
        }
    }
}

 여기서 중요한 점은 Thread.yield()는 무작정 양보 되는 것이 아니라, 운영체제에게 '요청'하는 메서드이다. 운영체제의 스레드 스케줄러가 이를 무시할 수 있다. 거절당할 수 있는 것이다. 또한, 운영체제마다 yield()의 동작이 달라질 수도 있다는 점에서 OS에 대한 이식성이 좋지 않으며. 호출이 너무 많아지면 컨텍스트 스위칭이 많아져 성능 저하를 초래할 수 있다. 좋지 않은 방법이다.

 스레드의 우선순위를 조절하는 것도 방법인데, 이것도 OS에 대한 이식성이 좋지 않다. 특히 심각한 문제를 스레드 우선순위로 해결하려는 시도는 합리적이지 않다.

7. 정리

 프로그램의 동작을 스레드 스케줄러에 기대지 말자. 성능과 속도, 이식성을 모두 해치는 행위이다. 같은 이유로 Thread.yield() 와 스레드 우선순위에 의존해서도 안된다.

 스레드 우선순위는 이미 잘 동작하는 프로그램의 서비스 품질을 높이기 위해 드물게 쓰일 수는 있지만, 간신히 동작하는 프로그램을 '고치는 용도'로 사용해서는 안된다.