[월간 기록] 2026년 1월

Sijun Yang — Sat, 31 Jan 2026 00:00:00 +0000

이번 달에는 정규표현식 내부 구조, 비동기 모델, 스레드 메모리 위치 같은 기술 관련 내용을 파봤다. 기술 관련 글을 읽다가 궁금해진 것들이다. 그리고 여러 개인, 기업, 교육기관에서 AI 활용 능력을 다룬 글들이 많이 눈에 띄었다.

시간 데이터를 올바르게 다루는 방법

Sijun Yang — Mon, 12 Jan 2026 00:00:00 +0000

프로그래밍을 어느 정도 해봤다면, 시간 관련 버그를 한 번쯤은 겪거나 들어보았을 것이다. 서버 환경을 바꾸니 시간이 9시간 밀린다거나, 로컬에서는 잘 되던 게 배포만 하면 시간이 이상하게 보인다거나.

[월간 기록] 2025년 12월

Sijun Yang — Wed, 31 Dec 2025 00:00:00 +0000

RDB 기반 큐로 회사 내부에 문제 많던 코드를 개선했는데, 만족스러운 경험이였다. 나중에 기회가 되면 다뤄볼까 한다. 또한 새로운 블로그 글도 작성했는데, 이 두 작업에 이번 달의 대부분을 투자했다.

[월간 기록] 이전 자료 모음

Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000

월간 기록을 시작했는데, 이전에 정리한 자료 중에서도 좋은게 많다.

"월간 기록"이라고 볼 순 없지만 버리기는 아까워, 최근 몇 개월 동안 모아두었던 기록 중에 다시 찾아볼 만한 것들을 정리했다.

[월간 기록] 시리즈 소개

Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000

평소 관심 가는 여러 자료를 수집하고 학습하는데, 관심사가 자주 바뀌다 보니 시간이 지나면 흩어지거나 까먹곤 한다.

자잘한 활동을 기록하고 공유도 할 겸 유용한 자료, 회고, 일상, 학습 기록 등을 한곳에 남겨두는 "월간 기록" 시리즈를 만들었다.

I/O 모델</th>	Blocking/Non-blocking</th>	Sync/Async</th>	1단계 Block</th>	2단계 Block</th></tr></thead>
Blocking I/O</td>	Blocking</td>	Synchronous</td>	Yes</td>	Yes</td></tr>
Non-blocking I/O</td>	Non-blocking</td>	Synchronous</td>	No (폴링)</td>	Yes</td></tr>
I/O Multiplexing</td>	Blocking</td>	Synchronous</td>	Yes</td>	Yes</td></tr>
Signal-driven I/O</td>	Non-blocking</td>	Synchronous</td>	No (신호)</td>	Yes</td></tr>
Asynchronous I/O</td>	Non-blocking</td>	Asynchronous</td>	No</td>	No</td></tr> </tbody></table> 앞의 네 가지 모델은 모두 데이터 복사 단계(2단계)에서 block된다. 따라서 POSIX 정의상 모두 synchronous다. 오직 asynchronous I/O만이 두 단계 모두에서 block되지 않는다.</p> 왜 select()</code>는 synchronous인가?</h3> 자료조사 과정에서 본 여러 자료에서 select()</code>를 asynchronous로 설명하는 경우를 많이 보았다.</p> select()</code>는 여러 I/O를 동시에 처리할 수 있어서 비동기처럼 보이지만, 실제로는 다음과 같이 동작한다:</p> 프로세스가 감시할 파일 디스크립터 집합을 준비한다.</li> select()</code>는 각 파일 디스크립터가 I/O를 수행해도 블로킹되지 않을 상태인지를 알려준다.</li> 준비된 파일 디스크립터에 대해 애플리케이션이 read()</code>를 직접 호출한다.</li> </ol> 이때 read()</code> 호출은 시스템 콜이 완료될 때까지 호출자를 반환하지 않으며, POSIX 정의상 요청한 프로세스를 블로킹하므로 synchronous가 된다.</p> 멀티스레드 환경에서도 마찬가지다. I/O를 수행하는 스레드는 시스템 콜이 완료될 때까지 블로킹되며, POSIX 정의에 따르면 이는 동기 I/O다. 스레드 분리는 애플리케이션 레벨의 동시성 전략일 뿐이다. 커널의 I/O 모델을 바꿀 수는 없다.</p> Linux man page도 select</code>를 "synchronous I/O multiplexing"으로 명시하고 있다.^{7</a></sup> 반면 io_uring</code>8</a></sup>이나 POSIX aio_</code>6</a></sup> 함수들은 "Asynchronous I/O"로 구분한다.</p>} 커널 I/O 개념과 프로그래밍 모델의 혼동</h2> IBM의 글은 리눅스 커널 레벨 I/O를 다루는 기술 문서다. 커널 레벨에서 이 용어들은 POSIX 표준에 따라 엄밀하게 정의된다. 반면 애플리케이션 레벨에서는 동일한 용어가 더 느슨하고 범용적인 의미로 사용된다. (커널은 프로세스의 실행 흐름을 정확히 제어해야 하므로 용어가 엄밀하게 정의되지만, 수많은 라이브러리와 프레임워크가 독립적으로 개발되는 애플리케이션 레벨의 라이브러리/프레임워크, 언어 등은 용어 통일이 현실적으로 불가능하다.)</p> 하지만 IBM의 글이 널리 인용되면서 두 가지 문제가 발생했다.</p> 첫째, 분류 방식이 POSIX 표준 정의와 정확히 일치하지 않았다. 커널 API를 다루는 글임에도 커널이 따르는 표준과 다른 기준을 사용했고, 이 설명이 반복 인용되면서 표준과 다른 내용이 사실처럼 확산되었다. 둘째, 이후 수많은 블로그와 기술 문서들이 이 2×2 매트릭스를 인용하면서 원래의 맥락을 잃었다. 커널 레벨 I/O를 설명하기 위한 용어가 애플리케이션 레벨의 프로그래밍 모델이나 아키텍처의 설명까지 무분별하게 적용되었다.</p> 대표적인 오해는 Node.js + MySQL 드라이버의 예시다.</p> “Node.js + MySQL은 Blocking + Async의 예시다. Node.js는 비동기인데 MySQL 드라이버가 블로킹이라서…”</p> </blockquote> 이 설명은 서로 다른 레벨의 개념을 혼합한 것이다.</p> Node.js의 비동기: 이벤트 루프 기반의 프로그래밍 모델</li> MySQL 드라이버의 블로킹: 라이브러리 차원의 API 구현 방식</li> </ul> 이는 커널 레벨의 I/O 동작과는 직접적인 관련이 없으며, 애초에 IBM 문서가 다루던 맥락과도 다르다. 이처럼 추상화 레벨이 다른 개념들을 구분 없이 동일한 용어로 설명하다 보니, 개념적 혼란이 발생할 수밖에 없다.</p> 프로그래밍 모델로서의 비동기과 내부 구현</h2> 많은 비동기 프로그래밍 모델을 제공하는 프레임워크들이 내부 구현에선 동기 시스템 콜을 사용한다.</p> Netty는 "asynchronous event-driven" 프레임워크를 표방하지만9</a></sup>, 실제로는 epoll()</code>이나 kqueue</code> 같은 I/O multiplexing을 사용한다. 이들은 POSIX 정의상 synchronous다. Node.js도 마찬가지다. libuv를 통해 플랫폼별로 최적화된 I/O multiplexing을 사용하거나, 파일 시스템 작업의 경우 별도 스레드 풀에서 blocking I/O를 수행한다.10</a></sup> 이것이 잘못된 설명이나 구현은 아니다. 애플리케이션 개발자 입장에서는 비동기 프로그래밍 모델을 제공받는 것이 중요하지, 내부적으로 어떤 시스템 콜을 사용하는지는 중요하지 않다.</p> 결론</h2> POSIX 표준에 따르면 I/O 모델은 본질적으로 세 가지로 구분할 수 있다.</p> Blocking Synchronous - 전통적인 blocking I/O와 I/O multiplexing</li> Non-blocking Synchronous - non-blocking I/O와 signal-driven I/O</li> Asynchronous - 진정한 비동기 I/O (POSIX aio, io_uring)</li> </ol> 따라서 Blocking + Async라는 조합은 정의상 존재할 수 없다. Asynchronous는 정의상 어떤 단계에서도 block되지 않기 때문이다.</p> 물론 애플리케이션 레벨에서는 이 구분이 덜 엄격하다. 프로그래밍 모델로서의 비동기와 시스템 콜 레벨의 비동기는 다른 개념이며, 이를 명확히 구분해야 한다. Netty나 Node.js 같은 프레임워크가 비동기를 표방하는 것은 애플리케이션 개발자에게 제공하는 프로그래밍 모델을 지칭하는 것이지, POSIX I/O 모델의 정의를 따르는 것이 아니다.</p> 중요한 것은 맥락이다. OS나 커널 레벨의 I/O를 논할 때와 애플리케이션 레벨의 프로그래밍 패턴을 논할 때, 같은 용어가 다른 의미를 가질 수 있다. 이러한 차이를 인지하고 명확히 구분해서 사용해야 불필요한 혼란을 피할 수 있다.</p> 나는 어떻게 구분하는가</h2> 커널 I/O 레벨에선 표준의 정의를 따른다.</p> 동기 / 비동기: I/O 작업이 완료될 때까지 요청 프로세스가 블로킹되는지 여부</li> 블로킹 / 논블로킹: 요청한 동작을 즉시 완료할 수 없을 때 함수 호출이 대기하는지 여부</li> </ul> 다만 시스템 레벨 개발을 주로 하지 않기 때문에, 이 용어를 쓸 일은 많지 않다. 이 레벨에서는 추상적인 용어보다 select, epoll, io_uring 같은 구체적인 시스템 콜 이름으로 대화하는 것이 더 명확하다고 생각한다.</p> 어플리케이션 레벨에선 다음 기준으로 구분한다.</p> 동기 / 비동기: 애플리케이션 레벨에서의 프로그래밍 모델, 전체 실행 흐름</li> 블로킹 / 논블로킹: 함수 호출이나 개별 작업 단위에서의 동작</li> </ul> 일반적으로 이 관점에서 이야기한다. 이렇게 구분하면 아키텍처를 설명하거나 문제를 분석할 때 명확하게 생각할 수 있다. 예를 들어, “비동기 모델 환경에서 블로킹 호출을 사용해 전체 실행 흐름에 영향을 주었다.”, “동기 환경이더라도 오래 걸리는 I/O를 논블로킹으로 처리해 효율을 높일 수 있다.” 와 같이 모델과 동작을 분리해서 생각할 수 있다.</p> 부록</h2> "Boost application performance using asynchronous I/O" 를 포함한 IBM Developer의 오래된 글이 아카이브되어 원래 작성 시점을 알 수 없었는데, 저자의 사이트에서 원본 자료가 링크된 글</a>을 보고 2006년 작성되었다고 추정했다.</p> IBM의 설명이 한국에만 퍼진 이야기는 아닌 듯 하다. 영어, 중국어나 일본어로 작성된 자료에서도 2x2 매트릭스를 사용해 구분하는 글을 찾아볼 수 있었다.</p> 조사 과정에서 참고한 자료들이다. 높은 신뢰성을 가지는 문서는 아니지만 개념을 이해하는 데 도움이 되어 남겨두었다.</p> Asynchronized I/O vs Multiplexing I/O 토론 - Linux Questions</a></li> Comparing Two High-Performance I/O Design Patterns</a></li> 비동기 프로그래밍, 비동기 I/O, 비동기 커뮤니케이션 - 쉬운코드 (YouTube)</a></li> Blocking-NonBlocking-Synchronous-Asynchronous - 뒤태지존의 끄적거림</a></li> Tokio와 Compio의 차이: 비동기 모델(epoll vs io_uring) - Reddit</a></li> 기초 탄탄! 독하게 시작하는 Java Part 3(하) : 소켓과 파일 I/O 강의 \| 널널한 개발자 - 인프런</a></li> </ul> References</h2> M. Tim Jones, "Boost application performance using asynchronous I/O"</a>, IBM Developer, 2006. ↩</a></p> </li> IEEE Std 1003.1-2024, "The Open Group Base Specifications Issue 8"</a>, IEEE and The Open Group, 2024. ↩</a></p> </li> IEEE Std 1003.1-2004, "The Open Group Base Specifications Issue 6"</a>, IEEE and The Open Group, 2004. ↩</a></p> </li> W. Richard Stevens, Bill Fenner, Andrew M. Rudoff, "Unix Network Programming, Volume 1: The Sockets Networking API", 3rd Edition, Addison-Wesley, 2003. ↩</a></p> </li> 예를 들면, I/O Multiplexing과 Non-blocking I/O 모델을 함께 사용할 수도 있다. select()</code> 함수는 기본적으로 이벤트가 올때까지 wait하는 blocking 함수인데, fb에 O_NONBLOCK</code> 플래그를 활성화 해서 Non-blocking 함수로 동작하게 할 수 있다. 이 경우, 여러 fb를 동시에 감시하면서 데이터의 준비 여부와 무관하게 즉시 반환된다. ↩</a></p> </li> Linux man pages, "aio(7) - POSIX asynchronous I/O overview"</a> ↩</a> ↩2</a></p> </li> Linux man pages, "select(2) - synchronous I/O multiplexing"</a> ↩</a></p> </li> Linux man pages, "io_uring(7) - Asynchronous I/O facility"</a> ↩</a></p> </li> Netty Project, "Netty v4.2 README"</a>, GitHub ↩</a></p> </li> libuv documentation, "Design overview"</a> ↩</a></p> </li> </ol> </section> Java 배열 인덱스 접근은 정말 O(1)인가? Sijun Yang — Wed, 21 May 2025 00:00:00 +0000 누군가 개발 커뮤니티에 이런 질문을 올렸다.</p> Java 배열의 인덱스 접근이 O(1)이라는데, 공식 문서에서 찾을 수가 없어요. 어디서 확인할 수 있나요?</p> </blockquote> 나도 당연히 O(1)이라고 생각했지만, 막상 "어디에 그렇게 쓰여 있냐"고 물으면 대답하기 어려웠다.</p> Java 배열 인덱스 접근의 내부 동작</h3> 실제로 확인해보자. 다음과 같은 간단한 Java 코드가 있다.</p> public static void</span> array</span>() {</span></span> int</span>[] intArr</span> = {</span>1</span>,</span> 2</span>,</span> 3</span>,</span> 4</span>,</span> 5</span>,</span> 6</span>,</span> 7</span>,</span> 8</span>,</span> 9</span>,</span> 0</span>};</span></span> int</span> intA</span> = intArr[</span>0</span>];</span></span> int</span> intB</span> = intArr[</span>9</span>];</span></span> }</span></span></code></pre> 자바에서 배열이나 사칙연산 같은 기본 기능은 자바 코드 레벨에서 내부 동작을 확인할 수 없다. java.util.ArrayList</code> 같이 자바 언어로 구현된 표준 라이브러리와 달리, 언어 사양에 의해 동작이 정의되는 더 저수준의 영역이기 때문이다. 그렇다면 배열의 동작을 확인하기 위해선 무엇을 봐야 할까?</p> 먼저 자바 언어 명세(JLS)의 배열 접근 문서1</a></sup>를 확인했다. 배열을 어떻게 사용할 수 있는지만 서술하고 있다. 구체적인 구현 방식이나 시간복잡도에 관한 요구사항은 없다.</p> 다음으로 JVM 명세(JVMS)를 확인했다. JVMS에서는 배열 인덱스 접근 시 어떤 바이트코드가 사용되는지 명시한다. 실제로 사용되는지 확인해보자.</p> 잠깐 바이트코드에 대해 설명하면, Java는 컴파일 시 바이트코드로 변환되고 JVM이 이를 실행한다. JVM은 스택 기반 가상 머신으로2</a></sup>, 값을 스택에 쌓고 명령어가 꺼내 연산하는 방식이다. 따라서 자바 프로그램의 실제 동작을 더 확실하게 알기 위해선 바이트코드를 보아야 한다.</p> 위 자바 코드를 컴파일하면 배열 인덱스 접근은 다음과 같은 바이트코드로 변환된다.3</a></sup></p> // intArr[0] 접근</span></span> ALOAD 0 // 배열 참조를 스택에 푸시</span></span> ICONST_0 // 정수 0을 스택에 푸시 (인덱스)</span></span> IALOAD // 스택에서 배열과 인덱스를 꺼내 해당 요소를 읽음</span></span> </span> // intArr[9] 접근</span></span> ALOAD 0 // 배열 참조를 스택에 푸시</span></span> BIPUSH 9 // 정수 9를 스택에 푸시 (인덱스)</span></span> IALOAD // 스택에서 배열과 인덱스를 꺼내 해당 요소를 읽음</span></span></code></pre> JVMS의 명령어 문서4</a></sup>를 보면, IALOAD</code> 명령어는 스택에서 배열 참조와 인덱스를 꺼내 해당 요소를 읽어 스택에 푸시한다고 설명한다. 어떤 스택 조작을 하는지만 서술되어 있다. 어떻게 접근해야 하는지, 시간복잡도가 어떠해야 하는지는 명시하지 않는다.</p> 따라서 JLS와 JVMS 어디에도 "배열 인덱스 접근은 O(1)이어야 한다"는 요구사항은 없다. 이제 남은 건 실제 JVM 구현체를 확인하는 것이다.</p> OpenJDK를 선택했다. Java SE의 공식 레퍼런스 구현체이며, 대부분의 JVM 구현이 이를 기반으로 하기 때문이다. OpenJDK는 C++로 구현되어 있다. objArrayOop.hpp</code>와 objArrayOop.inline.hpp</code>5</a></sup>6</a></sup>를 보면 배열 인덱스 접근의 내부 동작을 알 수 있다.</p> 다음과 같은 순서로 동작한다.</span></span> 1. base_offset_in_bytes() -> 배열 헤더 크기</span></span> 2. sizeof(T) * index -> 요소 크기 × 인덱스</span></span> 3. base() + offset -> 실제 메모리 주소 계산</span></span> 4. oop_load_at(offset) -> 해당 주소에서 값 로드</span></span></code></pre> 핵심은 (여타 CS 책에서 배열의 구현 방식을 설명할 때처럼) 포인터 산술 연산이다. 배열의 시작 주소에 오프셋을 더해 직접 메모리에 접근한다. 요소의 개수와 무관하게 상수 시간에 동작한다. 따라서 OpenJDK에서는 O(1)이 맞다.</p> 그러나 Java 언어 명세(JLS)나 JVM 명세(JVMS) 어디에도 "배열 인덱스 접근은 O(1)이어야 한다"는 요구사항은 없었다. OpenJDK는 O(1)로 동작하지만, 그건 특정 구현체의 선택일 뿐 언어의 보장이 아니다. 다른 JVM 구현체가 같은 방식을 사용한다는 보장은 명세에 없다. (물론 현실적으로 다른 방식을 쓸 이유는 없다. 배열의 특성상 거의 모든 구현체가 O(1)일 것이다.)</p> 명세와 구현의 구분</h3> 프로그래밍 언어는 크게 두 레벨로 나뉜다.</p> 명세(Specification): 언어가 어떻게 동작해야 하는지 정의한 문서. 문법, 타입 시스템, 의미론 등을 규정한다.</li> 구현(Implementation): 명세를 실제로 실행 가능하게 만든 컴파일러나 런타임. 명세가 정의하지 않은 부분은 구현체가 자유롭게 결정한다.</li> </ul> Java의 명세는 JLS(Java Language Specification), JVMS(Java Virtual Machine Specification)이다. 구현은 OpenJDK, Amazon Corretto, Azul Zulu 등이 존재한다. 다양한 JDK 종류의 차이를 알아보려면 Which Version of JDK Should I Use?</a>를 참고하자.7</a></sup></p> 대부분의 성능과 관련된 부분은 명세가 아닌 구현이 결정한다. 흔히 알고리즘 문제에서의 시간 복잡도, 공간 복잡도와 같은 것들은 구현이 결정하게 된다.</p> 프로그래밍 언어의 이러한 점은 Database의 질의형 언어(Query Language)와도 비슷한 점이라고 생각하는데, 내부 구현을 명세에 숨김으로써 자유롭게 기존 동작을 유지하면서 런타임의 최적화를 할 수 있기 때문이다. 예시로 Java는 GC 알고리즘이 계속 발전하고 있으며, Netflix는 Java의 버전을 8에서 17로 업그레이드하면서 약 20%의 CPU 사용률을 향상할 수 있었다.8</a></sup> 또한 언어 명세의 수정 없이 Virtual Thread가 도입되기도 했다.</p> "(OpenJDK의) Java 배열 인덱스 접근이 O(1)이다" 라는 말에서 OpenJDK나 다른 구현체의 이름이 빠진다면 정확하지 않은 말이다. 하지만 이런 내용을 일일이 지적하는 건 소모적인 일이다.</p> 대부분의 개발자가 표준이나 사실상(de facto) 표준인 구현체를 사용한다. Java 개발자가 OpenJDK 계열을 쓰고, 거의 모든 Python 개발자가 CPython을 쓴다. 따라서 일상적인 상황에서는 암묵적으로 가장 표준에 가까운 구현체를 의미한다고 이해해도 무방할 것이다.</p> 그럼에도 다른 런타임이나 구현체 간 차이를 분석하거나 이해하기 위해선 이러한 사실을 알고 있어야 한다.</p> C는 이 구분이 특히 중요한 언어다. 다양한 하드웨어에서 동작해야 하고, 수십 개의 컴파일러 구현체가 존재한다. C 표준은 Undefined Behavior (UB), Unspecified Behavior (UsB), Implementation-defined Behavior (IdB)를 구분한다.9</a></sup> 이 때문에 GCC에서 잘 돌던 코드가 Clang에서 다르게 동작하거나, 최적화 옵션에 따라 결과가 달라질 수 있다. (이처럼 C는 문법에서 많은 함정을 가지고 있는데, 관심이 있다면 C/C++를 가르치기 전에 생각해 보기 - finalchild</a>를 한 번 읽어보는걸 추천한다.)</p> 반면 C 이후에 설계된 현대 언어들은 명세가 훨씬 엄격하다. 그래도 여전히 이 구분이 필요한 순간들이 있다. Node.js의 대항마로 Bun이 등장했을 때, "Bun이 Node.js와 뭐가 다른가?"라는 질문에 답하려면 명세와 구현의 구분이 필요하다. JavaScript(ECMAScript)는 언어 명세고, Node.js와 Bun은 그 구현체다. 이벤트 루프나 파일 시스템 API는 JavaScript 명세가 아니라 런타임 구현이다. Bun이 빠른 이유는 JavaScript 언어가 달라서가 아니라, 런타임 구현이 다르기 때문이다.</p> Python도 비슷하다. PyPy는 CPython과 달리 JIT 컴파일을 제공해 CPU Bound 작업에서 유리하다. 심지어 JVM 위에서 실행되는 Jython이라는 런타임도 있다. 이러한 차이는 Python 명세가 실행 환경을 규정하지 않기 때문에 가능하다. Java의 GraalVM Native Image를 사용하면 JVM 없이 네이티브 바이너리로 컴파일할 수 있다.10</a></sup> 이 경우 JVM의 동작을 전제로 한 코드(리플렉션 등)가 제한될 수 있다는 점을 예측할 수 있고, 실제로도 그렇다.</p> 또한 프로그래밍 언어의 구현체는 OS와 런타임 버전에 따라 동작이 달라질 수 있다.11</a></sup> 보안 취약점 문서나 버그 리포트에서 환경 명시가 필수인 이유다.</p> 이처럼 명세와 구현은 다르다. 프로그래밍 언어와 런타임의 성능/특징을 올바르게 논하기 위해서는 이를 이해하는 것이 필요하다.12</a></sup></p> References</h2> Oracle, "JLS 15.10.3 - Array Access Expressions"</a>, Java Language Specification SE 25 ↩</a></p> </li> Oracle, "JVMS 2.5 - Run-Time Data Areas"</a>, Java Virtual Machine Specification SE 25 ↩</a></p> </li> 전체 코드는 Gist에 올려두었다</a>. ↩</a></p> </li> Oracle, "JVMS 6.5 - Instructions"</a>, Java Virtual Machine Specification SE 25 ↩</a></p> </li> OpenJDK, "objArrayOop.hpp"</a> 및 "objArrayOop.inline.hpp"</a>, GitHub ↩</a></p> </li> 코드에서 oop</code>는 Ordinary Object Pointer의 약자로, "일반적인 객체를 가리키는 포인터"라는 뜻이다. OpenJDK 코드에는 이 설명이 없어서 OpenJDK 개발자였던 Aleksey Shipilëv의 블로그에서 의미를 확인했다. Aleksey Shipilëv, "JVM Anatomy Quarks #23: Compressed References"</a> 및 "Java Objects Inside Out"</a> ↩</a></p> </li> 다양한 JDK 종류의 차이를 알아보려면 Which Version of JDK Should I Use?</a>를 참고하자. ↩</a></p> </li> InfoQ, "Netflix Adopts Java 17"</a>, InfoQ Presentations ↩</a></p> </li> Stack Overflow, "Undefined, unspecified and implementation-defined behavior"</a> ↩</a></p> </li> Oracle, "GraalVM Native Image"</a>, GraalVM Documentation ↩</a></p> </li> 같은 소스코드라도 컴파일러, OS, 런타임에 따라 다른 결과물이 만들어진다. 그리고 컴파일러와 OS 자체도 프로그래밍 언어로 작성된 프로그램이므로 환경마다 구현이 다를 수 있다. ↩</a></p> </li> 개인적으로 이런 저수준 동작에 대한 호기심이 있었다. 이 과정에서 간단한 책을 보거나 토이 프로젝트를 진행했었다. 특히 SICP: JavaScript Edition</a>를 읽으며, 겉보기에는 동일한 언어라도 평가 전략이나 실행 모델과 같은 구현 선택에 따라 동작이 달라질 수 있다는 점이 인상 깊었다. 이런 관점에서 보면 Java 배열 인덱스 접근의 시간복잡도 또한 구현에 의해 결정될 가능성이 크다고 보았고, 이런 실제하는 예시를 통해서 언어의 명세와 구현을 구분하는 시야에 대해서 공유하고 싶었다. ↩</a></p> </li> </ol> </section> Nand to Tetris 강의 수강 후기: 컴퓨터의 근본 원리 이해하기 Sijun Yang — Tue, 11 Jun 2024 00:00:00 +0000 몇 달 전에, Nand to Tetris 라는 강의를 수강</a> 완료했다. 간단한 소개와 느낀점에 대해 공유해보고자 한다.</p> Teach Yourself Computer Science</a>라는 인터넷에서 혼자서 CS를 학습하기 위한 커리큘럼을 소개해주는 사이트에 추천해줘서 수강하게 되었다.</p> Nand to Tetris 소개</h2> 시몬 쇼켄(Simon Schocken) 및 노암 니산(Noam Nisan)이 만들었다. 컴퓨터의 작동원리를 실습을 통해 이해할 수 있는 프로젝트이다. 간단한 논리 연산자인 Nand부터 시작해서 GUI 프로그램을 동작시킬 수 있는 범용 컴퓨터를 만든다. 하드웨어 및 소프트웨어를 순서대로 만들어 보면서 컴퓨터 과학의 주요 지식을 이해할 수 있다.</p> 진행 준비물</h3> The Elements of Computing Systems(한국어 번역본: 밑바닥부터 만드는 컴퓨팅 시스템)이라는 도서와 Coursera</a>에 있는 강의를 함께 들어가면서 진행했다. 나는 밑바닥부터 만드는 컴퓨팅 시스템</em> 과 Coursera 강의를 함꼐 수강하였다. Coursera에서 실습 과제를 제출하고 평가받을 수 있어 학습에 도움을 준다. 강의나 책 중 하나만 보아도 문제는 없어 보이지만, 둘 다 함께 보는 것을 추천한다. ( Coursera의 강의를 전부 수료하면 수료증</a>도 준다. )</p> 느낀점</h2> 컴퓨터의 기본 원리 이해</h4> 강의를 통해 고수준 언어를 컴파일하면서 C++이나 Java에서 다루는 객체지향이 내부적으로 함수와 구조체로 구성된다는 것을 깨달았다. 저수준 언어에서는 명령어를 위에서부터 아래로 순차적으로 실행하며, 가끔 Jump하면서 함수나 분기, 반복문을 구현한다. CPU와 RAM은 논리 게이트의 집합으로 구성되며, (기본적인) CPU는 생각보다 단순한 역할을 수행한다.</p> 프로그래밍에 대한 더 열린 사고</h4> 모든 프로그래밍 언어는 결국 기계어로 수행된다는 사실을 깨달았다. 각 언어는 해결하고자 하는 문제나 특화된 부분이 다를 수 있지만, 결국 기계어 입장에서는 동일하게 수행된다. 이 사실을 알고 나서, 새로운 것을 받아들이는 데 더 열린 자세를 갖게 되었다. 나는 잘 모르는 분야나 한 번도 해본 적 없는 것들에 대한 묘한 두려움이 있었다. 특히 나에게 익숙한 Java와 Spring을 주로 사용하고, 다른 기술에 대해서는 폐쇄적인 태도를 가지고 있었다. 하지만 열린 사고를 가진 지금은 NodeJS 기반의 서버 개발이나 프론트엔드 개발에도 관심을 가지고 있고, 기존에 사용해보지 않는 기술 스택을 사용해서 토이 프로젝트 개발을 기획하고 있다.</p> 실습의 중요성</h4> 강의에서 다루는 많은 내용을 알고는 있었지만, 실제로 이해하지 못하고 있었다는 것을 깨달았다. 단순히 아는 것과 이해하는 것은 다르며, 직접 결과물을 만들어보는 것을 통해 더 잘 이해할 수 있었다.</p> 그래서 자료구조를 더 이해하기 위해 C 언어를 배워서 직접 자료구조를 구현해보고 있다. 이후에는 소켓 네트워크 구현과 같이 CS의 기초적인 부분을 실습해보고 싶다.</p> 아쉬운 점</h2> 개인적으로 프로젝트를 진행하면서 아쉬운 점은 다음과 같다. 특히 프로젝트의 구현과 실제 구현이 차이가 있는건 납득 가능한 부분이지만, 실제 구현과 비교하지 않는 것은 아쉽다.</p> 인터럽트에 대한 설명 부재</h4> 프로젝트에서 만드는 CPU에서 인터럽트 자체가 없어서 실제 OS나 컴퓨터를 이해하는데 중요한 인터럽트의 설명이 누락되어 있다.</p> OS에 대한 설명 부족</h4> 강의는 컴퓨팅 시스템에 대한 이해를 중점으로 한다. 리눅스처럼 현대 OS의 동작을 기대했다면 실망할 수 있다.</p> 2부 실습 난이도 여려움</h4> 강의의 2부로 넘어가면서 난이도가 급격히 올라갔다는 느낌을 받았다. 1부까지는 외부 자료를 거의 참고하지 않고 구현할 수 있었는데, 2부 넘어가고부터 내 실력으론 구글링 없이는 문제 해결이 불가능했다. 복잡한 요구사항을 구현해본 경험이 적은 사람에게는 어려울 수 있을 것 같다.</p> 실제 구현에 대한 비교 부족</h4> 강의에서 다룬 내용이 실제 구현과 어떤 차이가 있는지 설명해주지 않아 아쉬웠다.</p> 한국어 번역 문제</h4> 심각한 부분은 아니지만, 종종 오타/오역이 보인다. 원서를 무리없이 읽을 수 있다면, 원서를 보고 진행하는 걸 추천한다. (여타 책들이 다 그렇겠지만)</p> 마무리</h2> Nand to Tetris 강의를 통해 컴퓨터 시스템, 특히 컴퓨터와 프로그래밍 언어의 동작 원리를 이해할 수 있는 귀중한 경험이였다. 실습을 통해 이론적 지식을 실제로 구현해 보면서 얻은 인사이트는 다른 학습 방법으로 대체할 수 없다고 생각한다. 특히, 새로운 기술에 대한 열린 자세와 프로그래밍에 대한 더 넓은 시각을 얻은게 된 것이 나에게 중요한 성취 중 하나였다. 앞으로는 다양한 분야와 기술에 도전하며, 배운 내용을 바탕으로 더욱 성장해 나갈 것이다.</p>

동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나

Sijun Yang — Thu, 11 Dec 2025 00:00:00 +0000

여러 개발 관련 글에서 Blocking/Non-blocking과 Sync/Async를 설명할 때면 항상 등장하는 2x2 매트릭스가 있다. 4개의 조합으로 나누어 설명하는 이 표를 한 번쯤은 보았을 것이다.

이 매트릭스에서 가장 이해하기 어려운 부분은 Blocking + Async 조합이다. 많은 블로그에서 이 조합을 설명하려고 시도하지만, 나는 대부분 억지스러운 설명이라는 인상을 받았다.

최근 이 개념을 다시 공부하다가 이러한 설명은 올바르지 않다는 사실을 알게 되었다. 우리가 그동안 별 의심없이 받아들였던 이 설명이 잘못된 이유를 말해보고자 한다.

잘못된 설명의 출처</h2>
이러한 매트릭스 기반의 설명의 시작은 IBM Developer의 2006년 글 "Boost application performance using asynchronous I/O"인 것으로 보인다.1</a>

IBM의 글은 리눅스 커널의 AIO(Asynchronous I/O) API를 소개하면서 sync/async와 blocking/non-blocking을 조합해 4가지로 구분했다.
그러나 이 글의 구분은 POSIX 표준 정의와는 다르다. 이 글에선 `select</code>/poll</code>를 blocking + async의 조합으로 소개하지만, POSIX 표준 정의에는 이런 조합이 등장할 수 없다.`
`IBM의 글은 리눅스 커널의 AIO API를 소개하는 글이다. 리눅스 커널은 POSIX 표준을 구현하므로, 커널 레벨 I/O를 논한다면 POSIX 정의와 일관되어야 한다. 그러나 IBM의 분류는 POSIX 표준과 일치하지 않는다.`

`POSIX 표준의 실제 정의</h2>`POSIX 표준2</a>3</a>과 리처드 스티븐스(W. Richard Stevens)의 책 Unix Network Programming4</a>을 살펴보면 명확한 정의를 찾을 수 있다. Synchronous I/O: I/O 작업이 완료될 때까지 요청 프로세스가 blocked</li> Asynchronous I/O: 요청 프로세스가 blocked되지 않음</li> Blocking: 요청한 동작이 완료될 때까지 함수 호출이 대기</li> Non-blocking: 요청한 동작을 즉시 완료할 수 없으면 지연 없이 반환</li> </ul> 여기서 중요한 점은 I/O 작업 완료의 의미다. Unix I/O 모델의 두 단계</h2> I/O 작업은 일반적으로 두 단계로 이루어진다: 데이터 준비 단계 - 디스크에서 데이터를 읽거나 네트워크에서 패킷이 도착하기를 기다린다. 데이터가 준비되면 커널 버퍼로 복사된다.</li> 데이터 복사 단계 - 커널 버퍼에서 애플리케이션 버퍼로 데이터를 복사한다.</li> </ol> 스티븐스는 Unix에서 사용 가능한 5가지 I/O 모델을 다음과 같이 구분한다. 이 모델은 커널이 I/O 준비와 수행을 어떻게 관여하느냐에 따른 대표적인 분류이다. 상호 배타적인 조합표를 의미하지 않는다.5</a> 1. Blocking I/O</h3> 가장 흔한 I/O 모델이다. read()</code> 시스템 콜을 호출하면 데이터가 준비되고 복사가 완료될 때까지 프로세스가 block된다. 2. Non-blocking I/O</h3> O_NONBLOCK</code> 플래그를 설정하면 데이터가 준비되지 않았을 때 EAGAIN</code> 에러와 함께 즉시 반환한다. 하지만 데이터가 준비되면 복사하는 동안은 여전히 block된다. 3. I/O Multiplexing</h3> select()</code>나 poll()</code>을 사용해 여러 file descriptor를 동시에 감시한다. 준비된 fd에 대해 read()</code>를 호출할 때 여전히 block된다. 4. Signal-Driven I/O</h3> SIGIO</code> 신호를 등록하고 데이터가 준비되면 신호를 받는다. 신호를 받은 후 read()</code>를 호출하면 여전히 block된다. 5. Asynchronous I/O</h3> 진정한 비동기 I/O다. aio_read()</code>6</a>는 즉시 반환되고, 커널이 백그라운드에서 두 단계를 모두 처리한 후 완료를 통지한다. Synchronous vs Asynchronous의 핵심</h2> 스티븐스는 Unix Network Programming에서 이 모델들의 동기/비동기 여부를 명확하게 구분한다. POSIX defines these two terms as follows: A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes. An asynchronous I/O operation does not cause the requesting process to be blocked. Using these definitions, the first four I/O models (blocking, nonblocking, I/O multiplexing, and signal-driven I/O) are all synchronous because the actual I/O operation (recvfrom) blocks the process. Only the asynchronous I/O model matches the asynchronous I/O definition. </blockquote> 다음과 같이 번역할 수 있다. POSIX는 이 두 용어를 다음과 같이 정의한다: 동기 I/O(synchronous I/O) 작업은 해당 I/O 작업이 완료될 때까지 요청한 프로세스를 블로킹한다. 비동기 I/O(asynchronous I/O) 작업은 요청한 프로세스를 블로킹하지 않는다. 이 정의에 따르면, 처음 네 가지 I/O 모델(블로킹 I/O, 논블로킹 I/O, I/O 멀티플렉싱, 시그널 기반 I/O)은 모두 동기 I/O에 해당한다. 실제 I/O 연산인 recvfrom</code> 호출이 프로세스를 블로킹하기 때문이다. 오직 비동기 I/O 모델만이 POSIX에서 정의한 비동기 I/O에 해당한다. </blockquote> 5가지 I/O 모델의 동기/비동기 분류</h3> I/O 모델</th> Blocking/Non-blocking</th> Sync/Async</th> 1단계 Block</th> 2단계 Block</th></tr></thead> Blocking I/O</td> Blocking</td> Synchronous</td> Yes</td> Yes</td></tr> Non-blocking I/O</td> Non-blocking</td> Synchronous</td> No (폴링)</td> Yes</td></tr> I/O Multiplexing</td> Blocking</td> Synchronous</td> Yes</td> Yes</td></tr> Signal-driven I/O</td> Non-blocking</td> Synchronous</td> No (신호)</td> Yes</td></tr> Asynchronous I/O</td> Non-blocking</td> Asynchronous</td> No</td> No</td></tr> </tbody></table> 앞의 네 가지 모델은 모두 데이터 복사 단계(2단계)에서 block된다. 따라서 POSIX 정의상 모두 synchronous다. 오직 asynchronous I/O만이 두 단계 모두에서 block되지 않는다. 왜 select()</code>는 synchronous인가?</h3> 자료조사 과정에서 본 여러 자료에서 select()</code>를 asynchronous로 설명하는 경우를 많이 보았다. select()</code>는 여러 I/O를 동시에 처리할 수 있어서 비동기처럼 보이지만, 실제로는 다음과 같이 동작한다: 프로세스가 감시할 파일 디스크립터 집합을 준비한다.</li> select()</code>는 각 파일 디스크립터가 I/O를 수행해도 블로킹되지 않을 상태인지를 알려준다.</li> 준비된 파일 디스크립터에 대해 애플리케이션이 read()</code>를 직접 호출한다.</li> </ol> 이때 read()</code> 호출은 시스템 콜이 완료될 때까지 호출자를 반환하지 않으며, POSIX 정의상 요청한 프로세스를 블로킹하므로 synchronous가 된다. 멀티스레드 환경에서도 마찬가지다. I/O를 수행하는 스레드는 시스템 콜이 완료될 때까지 블로킹되며, POSIX 정의에 따르면 이는 동기 I/O다. 스레드 분리는 애플리케이션 레벨의 동시성 전략일 뿐이다. 커널의 I/O 모델을 바꿀 수는 없다. Linux man page도 select</code>를 "synchronous I/O multiplexing"으로 명시하고 있다.^{7</a> 반면 io_uring</code>8</a>이나 POSIX aio_</code>6</a> 함수들은 "Asynchronous I/O"로 구분한다.} 커널 I/O 개념과 프로그래밍 모델의 혼동</h2> IBM의 글은 리눅스 커널 레벨 I/O를 다루는 기술 문서다. 커널 레벨에서 이 용어들은 POSIX 표준에 따라 엄밀하게 정의된다. 반면 애플리케이션 레벨에서는 동일한 용어가 더 느슨하고 범용적인 의미로 사용된다. (커널은 프로세스의 실행 흐름을 정확히 제어해야 하므로 용어가 엄밀하게 정의되지만, 수많은 라이브러리와 프레임워크가 독립적으로 개발되는 애플리케이션 레벨의 라이브러리/프레임워크, 언어 등은 용어 통일이 현실적으로 불가능하다.) 하지만 IBM의 글이 널리 인용되면서 두 가지 문제가 발생했다. 첫째, 분류 방식이 POSIX 표준 정의와 정확히 일치하지 않았다. 커널 API를 다루는 글임에도 커널이 따르는 표준과 다른 기준을 사용했고, 이 설명이 반복 인용되면서 표준과 다른 내용이 사실처럼 확산되었다. 둘째, 이후 수많은 블로그와 기술 문서들이 이 2×2 매트릭스를 인용하면서 원래의 맥락을 잃었다. 커널 레벨 I/O를 설명하기 위한 용어가 애플리케이션 레벨의 프로그래밍 모델이나 아키텍처의 설명까지 무분별하게 적용되었다. 대표적인 오해는 Node.js + MySQL 드라이버의 예시다. “Node.js + MySQL은 Blocking + Async의 예시다. Node.js는 비동기인데 MySQL 드라이버가 블로킹이라서…” </blockquote> 이 설명은 서로 다른 레벨의 개념을 혼합한 것이다. Node.js의 비동기: 이벤트 루프 기반의 프로그래밍 모델</li> MySQL 드라이버의 블로킹: 라이브러리 차원의 API 구현 방식</li> </ul> 이는 커널 레벨의 I/O 동작과는 직접적인 관련이 없으며, 애초에 IBM 문서가 다루던 맥락과도 다르다. 이처럼 추상화 레벨이 다른 개념들을 구분 없이 동일한 용어로 설명하다 보니, 개념적 혼란이 발생할 수밖에 없다. 프로그래밍 모델로서의 비동기과 내부 구현</h2> 많은 비동기 프로그래밍 모델을 제공하는 프레임워크들이 내부 구현에선 동기 시스템 콜을 사용한다. Netty는 "asynchronous event-driven" 프레임워크를 표방하지만9</a>, 실제로는 epoll()</code>이나 kqueue</code> 같은 I/O multiplexing을 사용한다. 이들은 POSIX 정의상 synchronous다. Node.js도 마찬가지다. libuv를 통해 플랫폼별로 최적화된 I/O multiplexing을 사용하거나, 파일 시스템 작업의 경우 별도 스레드 풀에서 blocking I/O를 수행한다.10</a> 이것이 잘못된 설명이나 구현은 아니다. 애플리케이션 개발자 입장에서는 비동기 프로그래밍 모델을 제공받는 것이 중요하지, 내부적으로 어떤 시스템 콜을 사용하는지는 중요하지 않다. 결론</h2> POSIX 표준에 따르면 I/O 모델은 본질적으로 세 가지로 구분할 수 있다. Blocking Synchronous - 전통적인 blocking I/O와 I/O multiplexing</li> Non-blocking Synchronous - non-blocking I/O와 signal-driven I/O</li> Asynchronous - 진정한 비동기 I/O (POSIX aio, io_uring)</li> </ol> 따라서 Blocking + Async라는 조합은 정의상 존재할 수 없다. Asynchronous는 정의상 어떤 단계에서도 block되지 않기 때문이다. 물론 애플리케이션 레벨에서는 이 구분이 덜 엄격하다. 프로그래밍 모델로서의 비동기와 시스템 콜 레벨의 비동기는 다른 개념이며, 이를 명확히 구분해야 한다. Netty나 Node.js 같은 프레임워크가 비동기를 표방하는 것은 애플리케이션 개발자에게 제공하는 프로그래밍 모델을 지칭하는 것이지, POSIX I/O 모델의 정의를 따르는 것이 아니다. 중요한 것은 맥락이다. OS나 커널 레벨의 I/O를 논할 때와 애플리케이션 레벨의 프로그래밍 패턴을 논할 때, 같은 용어가 다른 의미를 가질 수 있다. 이러한 차이를 인지하고 명확히 구분해서 사용해야 불필요한 혼란을 피할 수 있다. 나는 어떻게 구분하는가</h2> 커널 I/O 레벨에선 표준의 정의를 따른다. 동기 / 비동기: I/O 작업이 완료될 때까지 요청 프로세스가 블로킹되는지 여부</li> 블로킹 / 논블로킹: 요청한 동작을 즉시 완료할 수 없을 때 함수 호출이 대기하는지 여부</li> </ul> 다만 시스템 레벨 개발을 주로 하지 않기 때문에, 이 용어를 쓸 일은 많지 않다. 이 레벨에서는 추상적인 용어보다 select, epoll, io_uring 같은 구체적인 시스템 콜 이름으로 대화하는 것이 더 명확하다고 생각한다. 어플리케이션 레벨에선 다음 기준으로 구분한다. 동기 / 비동기: 애플리케이션 레벨에서의 프로그래밍 모델, 전체 실행 흐름</li> 블로킹 / 논블로킹: 함수 호출이나 개별 작업 단위에서의 동작</li> </ul> 일반적으로 이 관점에서 이야기한다. 이렇게 구분하면 아키텍처를 설명하거나 문제를 분석할 때 명확하게 생각할 수 있다. 예를 들어, “비동기 모델 환경에서 블로킹 호출을 사용해 전체 실행 흐름에 영향을 주었다.”, “동기 환경이더라도 오래 걸리는 I/O를 논블로킹으로 처리해 효율을 높일 수 있다.” 와 같이 모델과 동작을 분리해서 생각할 수 있다. 부록</h2> "Boost application performance using asynchronous I/O" 를 포함한 IBM Developer의 오래된 글이 아카이브되어 원래 작성 시점을 알 수 없었는데, 저자의 사이트에서 원본 자료가 링크된 글</a>을 보고 2006년 작성되었다고 추정했다. IBM의 설명이 한국에만 퍼진 이야기는 아닌 듯 하다. 영어, 중국어나 일본어로 작성된 자료에서도 2x2 매트릭스를 사용해 구분하는 글을 찾아볼 수 있었다. 조사 과정에서 참고한 자료들이다. 높은 신뢰성을 가지는 문서는 아니지만 개념을 이해하는 데 도움이 되어 남겨두었다. Asynchronized I/O vs Multiplexing I/O 토론 - Linux Questions</a></li> Comparing Two High-Performance I/O Design Patterns</a></li> 비동기 프로그래밍, 비동기 I/O, 비동기 커뮤니케이션 - 쉬운코드 (YouTube)</a></li> Blocking-NonBlocking-Synchronous-Asynchronous - 뒤태지존의 끄적거림</a></li> Tokio와 Compio의 차이: 비동기 모델(epoll vs io_uring) - Reddit</a></li> 기초 탄탄! 독하게 시작하는 Java Part 3(하) : 소켓과 파일 I/O 강의 | 널널한 개발자 - 인프런</a></li> </ul> References</h2> M. Tim Jones, "Boost application performance using asynchronous I/O"</a>, IBM Developer, 2006. ↩</a> </li> IEEE Std 1003.1-2024, "The Open Group Base Specifications Issue 8"</a>, IEEE and The Open Group, 2024. ↩</a> </li> IEEE Std 1003.1-2004, "The Open Group Base Specifications Issue 6"</a>, IEEE and The Open Group, 2004. ↩</a> </li> W. Richard Stevens, Bill Fenner, Andrew M. Rudoff, "Unix Network Programming, Volume 1: The Sockets Networking API", 3rd Edition, Addison-Wesley, 2003. ↩</a> </li> 예를 들면, I/O Multiplexing과 Non-blocking I/O 모델을 함께 사용할 수도 있다. select()</code> 함수는 기본적으로 이벤트가 올때까지 wait하는 blocking 함수인데, fb에 O_NONBLOCK</code> 플래그를 활성화 해서 Non-blocking 함수로 동작하게 할 수 있다. 이 경우, 여러 fb를 동시에 감시하면서 데이터의 준비 여부와 무관하게 즉시 반환된다. ↩</a> </li> Linux man pages, "aio(7) - POSIX asynchronous I/O overview"</a> ↩</a> ↩2</a> </li> Linux man pages, "select(2) - synchronous I/O multiplexing"</a> ↩</a> </li> Linux man pages, "io_uring(7) - Asynchronous I/O facility"</a> ↩</a> </li> Netty Project, "Netty v4.2 README"</a>, GitHub ↩</a> </li> libuv documentation, "Design overview"</a> ↩</a> </li> </ol> </section> Java 배열 인덱스 접근은 정말 O(1)인가? Sijun Yang — Wed, 21 May 2025 00:00:00 +0000 누군가 개발 커뮤니티에 이런 질문을 올렸다. Java 배열의 인덱스 접근이 O(1)이라는데, 공식 문서에서 찾을 수가 없어요. 어디서 확인할 수 있나요? </blockquote> 나도 당연히 O(1)이라고 생각했지만, 막상 "어디에 그렇게 쓰여 있냐"고 물으면 대답하기 어려웠다. Java 배열 인덱스 접근의 내부 동작</h3> 실제로 확인해보자. 다음과 같은 간단한 Java 코드가 있다. public static void array() { int[] intArr = {1, 2, 3, 4, 5, 6, 7, 8, 9, 0}; int intA = intArr[0]; int intB = intArr[9]; }</code></pre> 자바에서 배열이나 사칙연산 같은 기본 기능은 자바 코드 레벨에서 내부 동작을 확인할 수 없다. java.util.ArrayList</code> 같이 자바 언어로 구현된 표준 라이브러리와 달리, 언어 사양에 의해 동작이 정의되는 더 저수준의 영역이기 때문이다. 그렇다면 배열의 동작을 확인하기 위해선 무엇을 봐야 할까? 먼저 자바 언어 명세(JLS)의 배열 접근 문서1</a>를 확인했다. 배열을 어떻게 사용할 수 있는지만 서술하고 있다. 구체적인 구현 방식이나 시간복잡도에 관한 요구사항은 없다. 다음으로 JVM 명세(JVMS)를 확인했다. JVMS에서는 배열 인덱스 접근 시 어떤 바이트코드가 사용되는지 명시한다. 실제로 사용되는지 확인해보자. 잠깐 바이트코드에 대해 설명하면, Java는 컴파일 시 바이트코드로 변환되고 JVM이 이를 실행한다. JVM은 스택 기반 가상 머신으로2</a>, 값을 스택에 쌓고 명령어가 꺼내 연산하는 방식이다. 따라서 자바 프로그램의 실제 동작을 더 확실하게 알기 위해선 바이트코드를 보아야 한다. 위 자바 코드를 컴파일하면 배열 인덱스 접근은 다음과 같은 바이트코드로 변환된다.3</a> // intArr[0] 접근 ALOAD 0 // 배열 참조를 스택에 푸시 ICONST_0 // 정수 0을 스택에 푸시 (인덱스) IALOAD // 스택에서 배열과 인덱스를 꺼내 해당 요소를 읽음 // intArr[9] 접근 ALOAD 0 // 배열 참조를 스택에 푸시 BIPUSH 9 // 정수 9를 스택에 푸시 (인덱스) IALOAD // 스택에서 배열과 인덱스를 꺼내 해당 요소를 읽음</code></pre> JVMS의 명령어 문서4</a>를 보면, IALOAD</code> 명령어는 스택에서 배열 참조와 인덱스를 꺼내 해당 요소를 읽어 스택에 푸시한다고 설명한다. 어떤 스택 조작을 하는지만 서술되어 있다. 어떻게 접근해야 하는지, 시간복잡도가 어떠해야 하는지는 명시하지 않는다. 따라서 JLS와 JVMS 어디에도 "배열 인덱스 접근은 O(1)이어야 한다"는 요구사항은 없다. 이제 남은 건 실제 JVM 구현체를 확인하는 것이다. OpenJDK를 선택했다. Java SE의 공식 레퍼런스 구현체이며, 대부분의 JVM 구현이 이를 기반으로 하기 때문이다. OpenJDK는 C++로 구현되어 있다. objArrayOop.hpp</code>와 objArrayOop.inline.hpp</code>5</a>6</a>를 보면 배열 인덱스 접근의 내부 동작을 알 수 있다. 다음과 같은 순서로 동작한다. 1. base_offset_in_bytes() -> 배열 헤더 크기 2. sizeof(T) * index -> 요소 크기 × 인덱스 3. base() + offset -> 실제 메모리 주소 계산 4. oop_load_at(offset) -> 해당 주소에서 값 로드</code></pre> 핵심은 (여타 CS 책에서 배열의 구현 방식을 설명할 때처럼) 포인터 산술 연산이다. 배열의 시작 주소에 오프셋을 더해 직접 메모리에 접근한다. 요소의 개수와 무관하게 상수 시간에 동작한다. 따라서 OpenJDK에서는 O(1)이 맞다. 그러나 Java 언어 명세(JLS)나 JVM 명세(JVMS) 어디에도 "배열 인덱스 접근은 O(1)이어야 한다"는 요구사항은 없었다. OpenJDK는 O(1)로 동작하지만, 그건 특정 구현체의 선택일 뿐 언어의 보장이 아니다. 다른 JVM 구현체가 같은 방식을 사용한다는 보장은 명세에 없다. (물론 현실적으로 다른 방식을 쓸 이유는 없다. 배열의 특성상 거의 모든 구현체가 O(1)일 것이다.) 명세와 구현의 구분</h3> 프로그래밍 언어는 크게 두 레벨로 나뉜다. 명세(Specification): 언어가 어떻게 동작해야 하는지 정의한 문서. 문법, 타입 시스템, 의미론 등을 규정한다.</li> 구현(Implementation): 명세를 실제로 실행 가능하게 만든 컴파일러나 런타임. 명세가 정의하지 않은 부분은 구현체가 자유롭게 결정한다.</li> </ul> Java의 명세는 JLS(Java Language Specification), JVMS(Java Virtual Machine Specification)이다. 구현은 OpenJDK, Amazon Corretto, Azul Zulu 등이 존재한다. 다양한 JDK 종류의 차이를 알아보려면 Which Version of JDK Should I Use?</a>를 참고하자.7</a> 대부분의 성능과 관련된 부분은 명세가 아닌 구현이 결정한다. 흔히 알고리즘 문제에서의 시간 복잡도, 공간 복잡도와 같은 것들은 구현이 결정하게 된다. 프로그래밍 언어의 이러한 점은 Database의 질의형 언어(Query Language)와도 비슷한 점이라고 생각하는데, 내부 구현을 명세에 숨김으로써 자유롭게 기존 동작을 유지하면서 런타임의 최적화를 할 수 있기 때문이다. 예시로 Java는 GC 알고리즘이 계속 발전하고 있으며, Netflix는 Java의 버전을 8에서 17로 업그레이드하면서 약 20%의 CPU 사용률을 향상할 수 있었다.8</a> 또한 언어 명세의 수정 없이 Virtual Thread가 도입되기도 했다. "(OpenJDK의) Java 배열 인덱스 접근이 O(1)이다" 라는 말에서 OpenJDK나 다른 구현체의 이름이 빠진다면 정확하지 않은 말이다. 하지만 이런 내용을 일일이 지적하는 건 소모적인 일이다. 대부분의 개발자가 표준이나 사실상(de facto) 표준인 구현체를 사용한다. Java 개발자가 OpenJDK 계열을 쓰고, 거의 모든 Python 개발자가 CPython을 쓴다. 따라서 일상적인 상황에서는 암묵적으로 가장 표준에 가까운 구현체를 의미한다고 이해해도 무방할 것이다. 그럼에도 다른 런타임이나 구현체 간 차이를 분석하거나 이해하기 위해선 이러한 사실을 알고 있어야 한다. C는 이 구분이 특히 중요한 언어다. 다양한 하드웨어에서 동작해야 하고, 수십 개의 컴파일러 구현체가 존재한다. C 표준은 Undefined Behavior (UB), Unspecified Behavior (UsB), Implementation-defined Behavior (IdB)를 구분한다.9</a> 이 때문에 GCC에서 잘 돌던 코드가 Clang에서 다르게 동작하거나, 최적화 옵션에 따라 결과가 달라질 수 있다. (이처럼 C는 문법에서 많은 함정을 가지고 있는데, 관심이 있다면 C/C++를 가르치기 전에 생각해 보기 - finalchild</a>를 한 번 읽어보는걸 추천한다.) 반면 C 이후에 설계된 현대 언어들은 명세가 훨씬 엄격하다. 그래도 여전히 이 구분이 필요한 순간들이 있다. Node.js의 대항마로 Bun이 등장했을 때, "Bun이 Node.js와 뭐가 다른가?"라는 질문에 답하려면 명세와 구현의 구분이 필요하다. JavaScript(ECMAScript)는 언어 명세고, Node.js와 Bun은 그 구현체다. 이벤트 루프나 파일 시스템 API는 JavaScript 명세가 아니라 런타임 구현이다. Bun이 빠른 이유는 JavaScript 언어가 달라서가 아니라, 런타임 구현이 다르기 때문이다. Python도 비슷하다. PyPy는 CPython과 달리 JIT 컴파일을 제공해 CPU Bound 작업에서 유리하다. 심지어 JVM 위에서 실행되는 Jython이라는 런타임도 있다. 이러한 차이는 Python 명세가 실행 환경을 규정하지 않기 때문에 가능하다. Java의 GraalVM Native Image를 사용하면 JVM 없이 네이티브 바이너리로 컴파일할 수 있다.10</a> 이 경우 JVM의 동작을 전제로 한 코드(리플렉션 등)가 제한될 수 있다는 점을 예측할 수 있고, 실제로도 그렇다. 또한 프로그래밍 언어의 구현체는 OS와 런타임 버전에 따라 동작이 달라질 수 있다.11</a> 보안 취약점 문서나 버그 리포트에서 환경 명시가 필수인 이유다. 이처럼 명세와 구현은 다르다. 프로그래밍 언어와 런타임의 성능/특징을 올바르게 논하기 위해서는 이를 이해하는 것이 필요하다.12</a> References</h2> Oracle, "JLS 15.10.3 - Array Access Expressions"</a>, Java Language Specification SE 25 ↩</a> </li> Oracle, "JVMS 2.5 - Run-Time Data Areas"</a>, Java Virtual Machine Specification SE 25 ↩</a> </li> 전체 코드는 Gist에 올려두었다</a>. ↩</a> </li> Oracle, "JVMS 6.5 - Instructions"</a>, Java Virtual Machine Specification SE 25 ↩</a> </li> OpenJDK, "objArrayOop.hpp"</a> 및 "objArrayOop.inline.hpp"</a>, GitHub ↩</a> </li> 코드에서 oop</code>는 Ordinary Object Pointer의 약자로, "일반적인 객체를 가리키는 포인터"라는 뜻이다. OpenJDK 코드에는 이 설명이 없어서 OpenJDK 개발자였던 Aleksey Shipilëv의 블로그에서 의미를 확인했다. Aleksey Shipilëv, "JVM Anatomy Quarks #23: Compressed References"</a> 및 "Java Objects Inside Out"</a> ↩</a> </li> 다양한 JDK 종류의 차이를 알아보려면 Which Version of JDK Should I Use?</a>를 참고하자. ↩</a> </li> InfoQ, "Netflix Adopts Java 17"</a>, InfoQ Presentations ↩</a> </li> Stack Overflow, "Undefined, unspecified and implementation-defined behavior"</a> ↩</a> </li> Oracle, "GraalVM Native Image"</a>, GraalVM Documentation ↩</a> </li> 같은 소스코드라도 컴파일러, OS, 런타임에 따라 다른 결과물이 만들어진다. 그리고 컴파일러와 OS 자체도 프로그래밍 언어로 작성된 프로그램이므로 환경마다 구현이 다를 수 있다. ↩</a> </li> 개인적으로 이런 저수준 동작에 대한 호기심이 있었다. 이 과정에서 간단한 책을 보거나 토이 프로젝트를 진행했었다. 특히 SICP: JavaScript Edition</a>를 읽으며, 겉보기에는 동일한 언어라도 평가 전략이나 실행 모델과 같은 구현 선택에 따라 동작이 달라질 수 있다는 점이 인상 깊었다. 이런 관점에서 보면 Java 배열 인덱스 접근의 시간복잡도 또한 구현에 의해 결정될 가능성이 크다고 보았고, 이런 실제하는 예시를 통해서 언어의 명세와 구현을 구분하는 시야에 대해서 공유하고 싶었다. ↩</a> </li> </ol> </section> Nand to Tetris 강의 수강 후기: 컴퓨터의 근본 원리 이해하기 Sijun Yang — Tue, 11 Jun 2024 00:00:00 +0000 몇 달 전에, Nand to Tetris 라는 강의를 수강</a> 완료했다. 간단한 소개와 느낀점에 대해 공유해보고자 한다. Teach Yourself Computer Science</a>라는 인터넷에서 혼자서 CS를 학습하기 위한 커리큘럼을 소개해주는 사이트에 추천해줘서 수강하게 되었다. Nand to Tetris 소개</h2> 시몬 쇼켄(Simon Schocken) 및 노암 니산(Noam Nisan)이 만들었다. 컴퓨터의 작동원리를 실습을 통해 이해할 수 있는 프로젝트이다. 간단한 논리 연산자인 Nand부터 시작해서 GUI 프로그램을 동작시킬 수 있는 범용 컴퓨터를 만든다. 하드웨어 및 소프트웨어를 순서대로 만들어 보면서 컴퓨터 과학의 주요 지식을 이해할 수 있다. 진행 준비물</h3> The Elements of Computing Systems(한국어 번역본: 밑바닥부터 만드는 컴퓨팅 시스템)이라는 도서와 Coursera</a>에 있는 강의를 함께 들어가면서 진행했다. 나는 밑바닥부터 만드는 컴퓨팅 시스템 과 Coursera 강의를 함꼐 수강하였다. Coursera에서 실습 과제를 제출하고 평가받을 수 있어 학습에 도움을 준다. 강의나 책 중 하나만 보아도 문제는 없어 보이지만, 둘 다 함께 보는 것을 추천한다. ( Coursera의 강의를 전부 수료하면 수료증</a>도 준다. ) 느낀점</h2> 컴퓨터의 기본 원리 이해</h4> 강의를 통해 고수준 언어를 컴파일하면서 C++이나 Java에서 다루는 객체지향이 내부적으로 함수와 구조체로 구성된다는 것을 깨달았다. 저수준 언어에서는 명령어를 위에서부터 아래로 순차적으로 실행하며, 가끔 Jump하면서 함수나 분기, 반복문을 구현한다. CPU와 RAM은 논리 게이트의 집합으로 구성되며, (기본적인) CPU는 생각보다 단순한 역할을 수행한다. 프로그래밍에 대한 더 열린 사고</h4> 모든 프로그래밍 언어는 결국 기계어로 수행된다는 사실을 깨달았다. 각 언어는 해결하고자 하는 문제나 특화된 부분이 다를 수 있지만, 결국 기계어 입장에서는 동일하게 수행된다. 이 사실을 알고 나서, 새로운 것을 받아들이는 데 더 열린 자세를 갖게 되었다. 나는 잘 모르는 분야나 한 번도 해본 적 없는 것들에 대한 묘한 두려움이 있었다. 특히 나에게 익숙한 Java와 Spring을 주로 사용하고, 다른 기술에 대해서는 폐쇄적인 태도를 가지고 있었다. 하지만 열린 사고를 가진 지금은 NodeJS 기반의 서버 개발이나 프론트엔드 개발에도 관심을 가지고 있고, 기존에 사용해보지 않는 기술 스택을 사용해서 토이 프로젝트 개발을 기획하고 있다. 실습의 중요성</h4> 강의에서 다루는 많은 내용을 알고는 있었지만, 실제로 이해하지 못하고 있었다는 것을 깨달았다. 단순히 아는 것과 이해하는 것은 다르며, 직접 결과물을 만들어보는 것을 통해 더 잘 이해할 수 있었다. 그래서 자료구조를 더 이해하기 위해 C 언어를 배워서 직접 자료구조를 구현해보고 있다. 이후에는 소켓 네트워크 구현과 같이 CS의 기초적인 부분을 실습해보고 싶다. 아쉬운 점</h2> 개인적으로 프로젝트를 진행하면서 아쉬운 점은 다음과 같다. 특히 프로젝트의 구현과 실제 구현이 차이가 있는건 납득 가능한 부분이지만, 실제 구현과 비교하지 않는 것은 아쉽다. 인터럽트에 대한 설명 부재</h4> 프로젝트에서 만드는 CPU에서 인터럽트 자체가 없어서 실제 OS나 컴퓨터를 이해하는데 중요한 인터럽트의 설명이 누락되어 있다. OS에 대한 설명 부족</h4> 강의는 컴퓨팅 시스템에 대한 이해를 중점으로 한다. 리눅스처럼 현대 OS의 동작을 기대했다면 실망할 수 있다. 2부 실습 난이도 여려움</h4> 강의의 2부로 넘어가면서 난이도가 급격히 올라갔다는 느낌을 받았다. 1부까지는 외부 자료를 거의 참고하지 않고 구현할 수 있었는데, 2부 넘어가고부터 내 실력으론 구글링 없이는 문제 해결이 불가능했다. 복잡한 요구사항을 구현해본 경험이 적은 사람에게는 어려울 수 있을 것 같다. 실제 구현에 대한 비교 부족</h4> 강의에서 다룬 내용이 실제 구현과 어떤 차이가 있는지 설명해주지 않아 아쉬웠다. 한국어 번역 문제</h4> 심각한 부분은 아니지만, 종종 오타/오역이 보인다. 원서를 무리없이 읽을 수 있다면, 원서를 보고 진행하는 걸 추천한다. (여타 책들이 다 그렇겠지만) 마무리</h2> Nand to Tetris 강의를 통해 컴퓨터 시스템, 특히 컴퓨터와 프로그래밍 언어의 동작 원리를 이해할 수 있는 귀중한 경험이였다. 실습을 통해 이론적 지식을 실제로 구현해 보면서 얻은 인사이트는 다른 학습 방법으로 대체할 수 없다고 생각한다. 특히, 새로운 기술에 대한 열린 자세와 프로그래밍에 대한 더 넓은 시각을 얻은게 된 것이 나에게 중요한 성취 중 하나였다. 앞으로는 다양한 분야와 기술에 도전하며, 배운 내용을 바탕으로 더욱 성장해 나갈 것이다.

원칙 2: Exact Time은 UTC로 저장하고, 타임존은 별도 관리하라</h3>
Exact Time 데이터는 저장, 직렬화/역직렬화, 송수신 등 모든 과정에서 UTC 또는 Unix timestamp로 처리한다.</p>

Temporal API 소개</h2>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

awesome-for-me</a></h3>
개인적으로 유용하다고 생각하는 자료들을 정리한 저장소.</p>
지금은 개인 디스코드나 월간 기록으로 자료 관리 방식을 바꿔서 더 이상 업데이트하지는 않고 있음.</p>

Java 배열 인덱스 접근은 정말 O(1)인가?

Nand to Tetris 강의 수강 후기: 컴퓨터의 근본 원리 이해하기

아쉬운 점</h2>
개인적으로 프로젝트를 진행하면서 아쉬운 점은 다음과 같다. 특히 프로젝트의 구현과 실제 구현이 차이가 있는건 납득 가능한 부분이지만, 실제 구현과 비교하지 않는 것은 아쉽다.</p>

인터럽트에 대한 설명 부재</h4>
프로젝트에서 만드는 CPU에서 인터럽트 자체가 없어서 실제 OS나 컴퓨터를 이해하는데 중요한 인터럽트의 설명이 누락되어 있다.</p>

OS에 대한 설명 부족</h4>
강의는 컴퓨팅 시스템에 대한 이해를 중점으로 한다. 리눅스처럼 현대 OS의 동작을 기대했다면 실망할 수 있다.</p>

실제 구현에 대한 비교 부족</h4>
강의에서 다룬 내용이 실제 구현과 어떤 차이가 있는지 설명해주지 않아 아쉬웠다.</p>

한국어 번역 문제</h4>
심각한 부분은 아니지만, 종종 오타/오역이 보인다. 원서를 무리없이 읽을 수 있다면, 원서를 보고 진행하는 걸 추천한다. (여타 책들이 다 그렇겠지만)</p>

Sijun Yang

[월간 기록] 2026년 2월

수집</h2>
흥미롭거나 유용했던 자료들</p>

TODO</h3>

그 외 수집한 글</h3>

TODO</li> </ul>
작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>
TODO</h3>
짧은 생각</h2>
근황과 요즘 하는 생각</p>
TODO</p>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

TODO</h3>

짧은 생각</h2>
근황과 요즘 하는 생각</p>
TODO</p>

[월간 기록] 2026년 1월

수집</h2>
흥미롭거나 유용했던 자료들</p>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

시간 데이터를 올바르게 다루는 방법

[월간 기록] 2025년 12월

수집</h2>
흥미롭거나 유용했던 자료들</p>

[월간 기록] 이전 자료 모음

수집</h2>
흥미롭거나 유용했던 자료들</p>

[월간 기록] 시리즈 소개

동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나

Sijun Yang

[월간 기록] 2026년 2월

수집</h2> 흥미롭거나 유용했던 자료들</p>

TODO</h3>

그 외 수집한 글</h3> TODO</li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>TODO</h3> 짧은 생각</h2> 근황과 요즘 하는 생각</p> TODO</p>

작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>

TODO</h3>

짧은 생각</h2> 근황과 요즘 하는 생각</p> TODO</p>

[월간 기록] 2026년 1월

수집</h2> 흥미롭거나 유용했던 자료들</p>

작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>

DB Hub</a>를 사용한 MCP Server 사용</h3> 추가 — 2026/02/03</strong></p>

시간 데이터를 올바르게 다루는 방법

저장 포맷</h4> 각 타입에 적합한 저장 포맷을 사용해야 한다.</p> Exact Time:</p> Unix timestamp (밀리초 또는 초 단위 정수)</li> PostgreSQL의 TIMESTAMPTZ</code></li>

타입 객체 선언 시점 주의사항</h4> 대부분의 시간 관련 버그는 코드에서 시간 타입을 생성할 때 발생하므로 주의 깊게 보아야 한다.</p>

원칙 2: Exact Time은 UTC로 저장하고, 타임존은 별도 관리하라</h3> Exact Time 데이터는 저장, 직렬화/역직렬화, 송수신 등 모든 과정에서 UTC 또는 Unix timestamp로 처리한다.</p>

Temporal API 소개</h2>

[월간 기록] 2025년 12월

수집</h2> 흥미롭거나 유용했던 자료들</p>

작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>

[월간 기록] 이전 자료 모음

수집</h2> 흥미롭거나 유용했던 자료들</p>

작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>네트워크에서 MAC과 IP가 분리된 이유</h3> "Rust in Action" p.345를 보고 궁금해져서 찾아본 내용.</p> IP와 MAC은 다른 용도를 가지고 서로 다른 단체에 의해 다른 연도에 만들어졌다:</p>

네트워크에서 MAC과 IP가 분리된 이유</h3> "Rust in Action" p.345를 보고 궁금해져서 찾아본 내용.</p> IP와 MAC은 다른 용도를 가지고 서로 다른 단체에 의해 다른 연도에 만들어졌다:</p>

[월간 기록] 시리즈 소개

동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나

프로그래밍 모델로서의 비동기과 내부 구현</h2> 많은 비동기 프로그래밍 모델을 제공하는 프레임워크들이 내부 구현에선 동기 시스템 콜을 사용한다.</p>

Java 배열 인덱스 접근은 정말 O(1)인가?

Java 배열 인덱스 접근의 내부 동작</h3> 실제로 확인해보자. 다음과 같은 간단한 Java 코드가 있다.</p>

명세와 구현의 구분</h3> 프로그래밍 언어는 크게 두 레벨로 나뉜다.</p>

Nand to Tetris 강의 수강 후기: 컴퓨터의 근본 원리 이해하기

아쉬운 점</h2> 개인적으로 프로젝트를 진행하면서 아쉬운 점은 다음과 같다. 특히 프로젝트의 구현과 실제 구현이 차이가 있는건 납득 가능한 부분이지만, 실제 구현과 비교하지 않는 것은 아쉽다.</p>

인터럽트에 대한 설명 부재</h4> 프로젝트에서 만드는 CPU에서 인터럽트 자체가 없어서 실제 OS나 컴퓨터를 이해하는데 중요한 인터럽트의 설명이 누락되어 있다.</p>

OS에 대한 설명 부족</h4> 강의는 컴퓨팅 시스템에 대한 이해를 중점으로 한다. 리눅스처럼 현대 OS의 동작을 기대했다면 실망할 수 있다.</p>

실제 구현에 대한 비교 부족</h4> 강의에서 다룬 내용이 실제 구현과 어떤 차이가 있는지 설명해주지 않아 아쉬웠다.</p>

한국어 번역 문제</h4> 심각한 부분은 아니지만, 종종 오타/오역이 보인다. 원서를 무리없이 읽을 수 있다면, 원서를 보고 진행하는 걸 추천한다. (여타 책들이 다 그렇겠지만)</p>

수집</h2>
흥미롭거나 유용했던 자료들</p>

그 외 수집한 글</h3>

TODO</li> </ul>
작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>
TODO</h3>
짧은 생각</h2>
근황과 요즘 하는 생각</p>
TODO</p>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

짧은 생각</h2>
근황과 요즘 하는 생각</p>
TODO</p>

수집</h2>
흥미롭거나 유용했던 자료들</p>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

원칙 2: Exact Time은 UTC로 저장하고, 타임존은 별도 관리하라</h3>
Exact Time 데이터는 저장, 직렬화/역직렬화, 송수신 등 모든 과정에서 UTC 또는 Unix timestamp로 처리한다.</p>

수집</h2>
흥미롭거나 유용했던 자료들</p>

작업</h2>
학습, 개발, 실험 등 직접 손댄 것들</p>

수집</h2>
흥미롭거나 유용했던 자료들</p>

아쉬운 점</h2>
개인적으로 프로젝트를 진행하면서 아쉬운 점은 다음과 같다. 특히 프로젝트의 구현과 실제 구현이 차이가 있는건 납득 가능한 부분이지만, 실제 구현과 비교하지 않는 것은 아쉽다.</p>

인터럽트에 대한 설명 부재</h4>
프로젝트에서 만드는 CPU에서 인터럽트 자체가 없어서 실제 OS나 컴퓨터를 이해하는데 중요한 인터럽트의 설명이 누락되어 있다.</p>

OS에 대한 설명 부족</h4>
강의는 컴퓨팅 시스템에 대한 이해를 중점으로 한다. 리눅스처럼 현대 OS의 동작을 기대했다면 실망할 수 있다.</p>

실제 구현에 대한 비교 부족</h4>
강의에서 다룬 내용이 실제 구현과 어떤 차이가 있는지 설명해주지 않아 아쉬웠다.</p>

한국어 번역 문제</h4>
심각한 부분은 아니지만, 종종 오타/오역이 보인다. 원서를 무리없이 읽을 수 있다면, 원서를 보고 진행하는 걸 추천한다. (여타 책들이 다 그렇겠지만)</p>