특성</th>	뮤텍스</th>	세마포어</th></tr></thead>
내부 값</td>	0 또는 1</td>	임의의 정수 N</td></tr>
소유권</td>	lock한 스레드만 unlock 가능</td>	아무 스레드나 post 가능</td></tr>
용도</td>	상호 배제</td>	상호 배제 + 순서 제어 + 리소스 카운팅</td></tr> </tbody></table> 소유권 차이가 중요하다. 뮤텍스는 lock한 스레드가 반드시 unlock해야 한다. 세마포어는 스레드 A가 wait하고 스레드 B가 post할 수 있다. 이 특성 때문에 스레드 간 순서 제어</strong>(signaling)가 가능하다.</p> 개념적 구현:</strong></p> typedef struct</span> {</span></span> int</span> value;</span></span> int</span> guard;</span> // 내부 스핀락</span></span> queue_t</span> wait_queue;</span></span> }</span> sem_t</span>;</span></span> </span> void</span> sem_wait</span>(</span>sem_t</span> </span>s) {</span></span> while</span> (</span>test_and_set</span>(</span>&</span>s</span>-></span>guard</span>))</span></span> ;</span></span> s</span>-></span>value</span>--</span>;</span></span> if</span> (</span>s</span>-></span>value</span> <</span> 0</span>) {</span></span> queue_push</span>(</span>&</span>s</span>-></span>wait_queue</span>, current_thread);</span></span> s</span>-></span>guard</span> =</span> 0</span>;</span></span> park</span>();</span> // sleep</span></span> }</span> else</span> {</span></span> s</span>-></span>guard</span> =</span> 0</span>;</span></span> }</span></span> }</span></span> </span> void</span> sem_post</span>(</span>sem_t</span> </span>s) {</span></span> while</span> (</span>test_and_set</span>(</span>&</span>s</span>-></span>guard</span>))</span></span> ;</span></span> s</span>-></span>value</span>++</span>;</span></span> if</span> (</span>s</span>-></span>value</span> <=</span> 0</span>) {</span></span> unpark</span>(</span>queue_pop</span>(</span>&</span>s</span>-></span>wait_queue</span>));</span> // 대기자 깨움</span></span> }</span></span> s</span>-></span>guard</span> =</span> 0</span>;</span></span> }</span></span></code></pre> 이 구현은 OSTEP Chapter 31의 Zemaphore를 기반으로 단순화한 것.</p> </blockquote> 용도 1: 이진 세마포어 = 뮤텍스처럼 사용 (초기값 1)</strong></p> sem_t</span> mutex;</span></span> sem_init</span>(</span>&</span>mutex,</span> 0</span>,</span> 1</span>);</span> // 초기값 1</span></span> </span> sem_wait</span>(</span>&</span>mutex);</span> // lock</span></span> // critical section</span></span> sem_post</span>(</span>&</span>mutex);</span> // unlock</span></span></code></pre> 초기값이 1이므로 한 스레드만 진입 가능. 기능적으로 뮤텍스와 동일하지만, 소유권 검사가 없으므로 다른 스레드가 post할 수도 있다 (이건 보통 버그).</p> 용도 2: 순서 제어 (초기값 0)</strong></p> 스레드 간 실행 순서를 강제할 때 사용. 뮤텍스로는 이걸 직접 할 수 없다.</p> sem_t</span> order;</span></span> sem_init</span>(</span>&</span>order,</span> 0</span>,</span> 0</span>);</span> // 초기값 0</span></span> </span> // 스레드 A (먼저 실행되어야 할 작업)</span></span> void </span>thread_a</span>(</span>void </span>arg) {</span></span> printf</span>(</span>"A: 작업 완료</span>\n</span>"</span>);</span></span> sem_post</span>(</span>&</span>order);</span> // "나 끝났어" 시그널</span></span> return</span> NULL</span>;</span></span> }</span></span> </span> // 스레드 B (A가 끝난 후 실행되어야 할 작업)</span></span> void </span>thread_b</span>(</span>void </span>arg) {</span></span> sem_wait</span>(</span>&</span>order);</span> // A가 post할 때까지 여기서 대기</span></span> printf</span>(</span>"B: A 이후 작업 시작</span>\n</span>"</span>);</span></span> return</span> NULL</span>;</span></span> }</span></span></code></pre> B가 먼저 실행되더라도 sem_wait()</code>에서 블록된다. A가 sem_post()</code>를 호출해야 B가 진행된다. 이것이 "외부에서 값 반환이 가능하므로 순서 보장 시 사용"이라고 했던 것의 정확한 의미다.</p> 용도 3: 리소스 카운팅 (초기값 N)</strong></p> 동시에 N개까지 접근을 허용. 대표적 예: 커넥션 풀, bounded buffer.</p> // bounded buffer (생산자-소비자 문제)</span></span> #define</span> BUFFER_SIZE</span> 10</span></span> </span> sem_t</span> empty;</span> // 빈 슬롯 수</span></span> sem_t</span> full;</span> // 찬 슬롯 수</span></span> sem_t</span> mutex;</span> // 버퍼 접근 보호</span></span> </span> int</span> buffer</span>[BUFFER_SIZE];</span></span> int</span> fill </span>=</span> 0</span>, use </span>=</span> 0</span>;</span></span> </span> void</span> init</span>() {</span></span> sem_init</span>(</span>&</span>empty,</span> 0</span>, BUFFER_SIZE);</span> // 처음엔 전부 비어있음</span></span> sem_init</span>(</span>&</span>full,</span> 0</span>,</span> 0</span>);</span> // 처음엔 아무것도 없음</span></span> sem_init</span>(</span>&</span>mutex,</span> 0</span>,</span> 1</span>);</span></span> }</span></span> </span> void </span>producer</span>(</span>void </span>arg) {</span></span> for</span> (</span>int</span> i </span>=</span> 0</span>; i </span><</span> 100</span>; i</span>++</span>) {</span></span> sem_wait</span>(</span>&</span>empty);</span> // 빈 슬롯 하나 확보</span></span> sem_wait</span>(</span>&</span>mutex);</span> // 버퍼 접근 lock</span></span> buffer</span>[fill]</span> =</span> i;</span></span> fill </span>=</span> (fill </span>+</span> 1</span>)</span> %</span> BUFFER_SIZE;</span></span> sem_post</span>(</span>&</span>mutex);</span> // 버퍼 접근 unlock</span></span> sem_post</span>(</span>&</span>full);</span> // 찬 슬롯 하나 증가</span></span> }</span></span> return</span> NULL</span>;</span></span> }</span></span> </span> void </span>consumer</span>(</span>void </span>arg) {</span></span> for</span> (</span>int</span> i </span>=</span> 0</span>; i </span><</span> 100</span>; i</span>++</span>) {</span></span> sem_wait</span>(</span>&</span>full);</span> // 찬 슬롯 하나 확보</span></span> sem_wait</span>(</span>&</span>mutex);</span></span> int</span> val </span>=</span> buffer</span>[use];</span></span> use </span>=</span> (use </span>+</span> 1</span>)</span> %</span> BUFFER_SIZE;</span></span> sem_post</span>(</span>&</span>mutex);</span></span> sem_post</span>(</span>&</span>empty);</span> // 빈 슬롯 하나 증가</span></span> printf</span>(</span>"consumed: </span>%d</span>\n</span>"</span>, val);</span></span> }</span></span> return</span> NULL</span>;</span></span> }</span></span></code></pre> empty</code>와 full</code> 세마포어가 생산자와 소비자 간 흐름 제어를 담당한다. 버퍼가 꽉 차면 생산자가 블록되고, 비면 소비자가 블록된다.</p> 이 패턴은 Dijkstra(1965)가 세마포어를 처음 제안할 때의 핵심 예제이며, OSTEP Chapter 31에서도 동일하게 다룬다.</p> </blockquote> 정리</h4> 스핀락:</span></span> - 구현: atomic instruction + busy-wait loop</span></span> - 대기 방식: CPU를 소모하며 반복 확인 (spinning)</span></span> - 사용처: 커널 내부, 짧은 critical section, sleep 불가능한 컨텍스트</span></span> </span> 뮤텍스:</span></span> - 구현: 내부 스핀락 + OS sleep/wakeup (futex 등)</span></span> - 대기 방식: lock 못 잡으면 sleep → unlock 시 wakeup</span></span> - 소유권: lock한 스레드만 unlock</span></span> - 사용처: 유저스페이스 상호 배제의 기본</span></span> </span> 세마포어:</span></span> - 구현: 정수 카운터 + 내부 스핀락 + OS sleep/wakeup</span></span> - 대기 방식: 카운터 ≤ 0이면 sleep</span></span> - 소유권: 없음 (아무나 post 가능)</span></span> - 사용처: 상호 배제, 순서 제어, 리소스 카운팅</span></span></code></pre> 참고 문헌:</p> Arpaci-Dusseau, R. & Arpaci-Dusseau, A. Operating Systems: Three Easy Pieces (OSTEP)</em>. Chapters 28–31.</li> Herlihy, M. (1991). "Wait-free synchronization." ACM TOPLAS</em>, 13(1).</li> Dijkstra, E. W. (1965). "Cooperating Sequential Processes." Technical Report EWD-123.</li> Love, R. (2010). Linux Kernel Development</em>, 3rd ed. Addison-Wesley.</li> </ul> </blockquote> Week 02: 컴퓨팅 사고로의 전환 Sijun Yang — Thu, 12 Mar 2026 00:00:00 +0000 핵심 역량 목표</h2> 문제해결: 주어진 문제를 정의하고 논리적으로 해결하는 능력</strong> 알고리즘 문제의 입력/출력/제약 조건을 정확히 파악하고, 실버~골드 수준의 백준 문제를 스스로 분석하여 해결 전략을 수립할 수 있다.</li> </ul> </li> 설계: 효율적이고 확장 가능한 시스템 구조를 기획</strong> 시간 복잡도를 이해하고, 사용한 알고리즘과 구현의 시간 복잡도를 올바르게 평가할 수 있다.</li> </ul> </li> 구현: 설계된 내용을 실제로 동작하는 코드로 작성</strong> 정렬, 정수론 등의 기초 알고리즘을 직접 구현하고, 재귀 함수와 백트래킹 문제를 올바르게 구현할 수 있다.</li> </ul> </li> 품질: 버그 없는 안정적인 코드 및 테스트 작성</strong> 제약 조건의 엣지 케이스에 대한 예외 처리를 고려하여 코드를 작성할 수 있다.</li> </ul> </li> 유지보수: 가독성이 좋고 수정이 용이한 코드 작성</strong> 함수 단위로 로직을 분리하고, 직관적으로 이해 가능한 네이밍을 사용한다.</li> </ul> </li> 협업: 팀원과 소통하며 시너지를 내는 과정</strong> 데일리 스크럼으로 목표와 진행 상황을 공유하고, 매일 푼 과제를 공유/리뷰하며 지식을 나눈다.</li> </ul> </li> 태도: 자기주도적인 학습과 과제에 대한 몰입(집요함)</strong> 문제를 풀고 넘어가는 게 아닌, 여러 번 반복하여 체화한다. 특히, 틀린 문제는 2번 이상 반복 풀이한다.</li> </ul> </li> 비즈니스 이해: 서비스의 가치와 사용자 입장을 고려하는 시각</strong> 알고리즘 복잡도가 실제 서비스 성능(응답 시간, 메모리 사용)에 미치는 영향을 이해하고 설명할 수 있다.</li> </ul> </li> AI 활용: AI 도구를 활용하여 생산성을 극대화하는 능력</strong> AI는 이론 공부와 풀이 피드백 용도로만 사용한다.</li> [공부 - AI 활용] → [풀이 - AI 금지] → [1차 피드백 - AI 금지] → [2차 피드백 - AI 활용]</code></li> </ul> </li> 학습 민첩성: 새로운 기술이나 개념을 빠르게 습득하는 능력</strong> 정수론과 백트래킹 관련 개념을 4일 내에 습득하고 설명할 수 있을 정도로 공부한다.</li> </ul> </li> </ol> WIL (What I Learned)</h2> 목표 1. 정수론/재귀/백트래킹 문제풀이 역량 확보</h3> 자신 없는 정수론/재귀/백트래킹 문제를 중급 난이도까지 풀 수 있는 이론 지식, 문제 풀이 능력을 가지기.</p> 접근</h4> 이번 주 과제 중 중급 난이도 이하의 모든 문제를 일요일까지 풀기. 제한시간 30분.</li> 못 푼 문제를 리스트업하고 해당 문제의 개념을 공부 후, 2번 이상 복습.</li> 비슷한 요구사항의 문제를 찾아 더 풀이하기.</li> </ol> 과정</h4> 백트래킹 문제의 대표적인 순열/조합 유형 구현 방법을 복습하기 위해 AI를 활용해 정리 자료를 생성</a></li> 2026/03/09 - Recursion 특강 정리</a></li> 하노이의 탑 정리</a></li> 난이도 중 이하 모든 문제 2번 이상 반복 풀이</li> </ul> 결과</h4> 정수론은 출제 빈도와 응용 범위를 고려해 우선순위를 낮게 두었고, 그만큼 아직 부족한 부분이 남아 있다. 확장 유클리드 호제법은 이해조차 못했다.</del></p> 하노이의 탑, 완전탐색, 순열/조합, N-Queen 등의 백트래킹/재귀 문제를 풀 수 있게 되었다. 반복 풀이를 통해 재귀/백트래킹의 공통 패턴과 구현 방식을 체득한 것이 이번 주차의 가장 큰 성과다.</p> 문제 조건 분석과 접근 방식 선택(base case 설정 등)은 아직 미숙하지만, 충분한 시간이 주어지면 구현 자체에서 실수하는 경우는 거의 없어졌다.</p> 목표 2. 과제 공유/리뷰를 통한 팀 성장</h3> 팀원들과 공유하여 더 빠른 성장을 돕고, 다른 관점의 풀이를 보며 함께 성장하기.</p> 접근</h4> 첫 스크럼에서 매일 푼 문제를 슬랙에 올리고 서로 리뷰하자고 제안했다.</li> 여러 유용한 자료를 찾거나 준비하여 팀에게 전달했다. 코테 준비 노트 (기존에 정리했던 것)</a></li> 학습 계획 (신규 정리)</a></li> 파이썬 + 프로그래밍 강의 추천 (링크)</a></li> </ul> </li> </ol> 과정</h4> 매일 스크럼 시 슬랙을 통해 풀이 내역이 담긴 커밋 링크를 공유했다.</p> 2주차 커밋 내역 링크</a></p> 코어타임에 문제 풀이를 공유하고, 팀원과 헷갈리는 개념에 대해 대화를 나눴다.</p> 결과</h4> 예상보다 각자의 알고리즘 문제 풀이에 많은 시간이 소요되었다.</p> 그로 인해 팀원 간 공유나 협력이 원활하지 않았다.</p> 다만 공유한 자료들은 팀 내에서 유용하게 활용되고 있는 것으로 보인다.</p> 회고</h2> 역량 달성률</h3> 초기 목표를 얼마나 달성했는지를 기준으로 상/중/하로 구분. 단, 해당 주차와 관련이 없거나 평가가 어려운 경우 N/A로 표기.</p> 어느 정도 주관적인 판단이 포함될 수 있음.</p> #</th> 역량</th> 달성률</th> 설명</th></tr></thead> 1</td> 문제해결</td> 중</td> 골드 수준의 문제 분석 및 전략 수립은 아직 어려움.</td></tr> 2</td> 설계</td> 상</td> 대략적으로나마 시간 복잡도를 유추할 수 있음.</td></tr> 3</td> 구현</td> 상</td> 개념을 이해한 경우, 구현 자체에는 문제 없었음.</td></tr> 4</td> 품질</td> 하</td> 동일 문제를 반복 풀이하는 데 집중한 탓에 엣지케이스 판단 능력을 키우지 못했음.</td></tr> 5</td> 유지보수</td> N/A</td> 2주차 내용과 관련성이 낮음.</td></tr> 6</td> 협업</td> 하</td> 예상보다 잘 되지 않음. (후기에서 후술함)</td></tr> 7</td> 태도</td> 중</td> 문제 공유나 협업 측면에서는 잘 수행했으나 전반적으로 기대에 미치지 못함.</td></tr> 8</td> 비즈니스 이해</td> N/A</td> 2주차 내용과 관련성이 낮음.</td></tr> 9</td> AI 활용</td> 중</td> 잘 활용했지만, 힌트를 받는 방식이 더 좋았음. 처음 의도와 달라짐.</td></tr> 10</td> 학습 민첩성</td> 중</td> 빠르게 학습하긴 했지만, 한 문제에 지나치게 시간을 소비하여 전체 진도가 느렸음.</td></tr> </tbody></table> 후기</h3> 이번 주 활동에 대한 평가</h4> 전반적으로 높은 목표를 설계했다는 느낌을 받았다. 또 시간 관리도 부족하다고 느꼈다.</p> 협업도 예상보다 쉽지 않았다. 리뷰하기에는 본인 과제를 풀이하기에도 시간이 않지 않았다. 의도적으로 시간을 할당하는 등의 의식적인 노력이 필요할거 같음.</p> 나에게는 준비 없는 구두 설명이 어려웠다. 자료 공유 방식이 더 효과적이였던 것 같음.</p> 다음 주에 시도해 볼 것</h4> 문제당 시간 제한을 두고, AI 해설을 적극 활용하여 더 많은 유형에 노출되는 방식으로 전환한다. 난이도를 올리기보다는 중급(실버~골드) 수준을 유지하면서 유형 폭을 넓히는 데 집중한다.</p> 팀 기여 방식은 구두 설명보다 자료 공유가 더 효율적이고 내 강점에도 맞으므로, 자료 공유를 더 적극적으로 한다.</p> WIL의 형식에 대한 후기</h4> 다른 사람들의 제출을 보니, 너무 핵심 역량 목표에 집중된 듯한 느낌을 받음.</p> 별개로 나누어서 해야 할거 같음. 힉심 역량 파트를 줄이고, WIL은 말 그대로 배운 것들의 리스트가 나와야 할 듯.</p> 추가 — 03/12 운영진 티타임</h3> Q&A: 핵심 역량 목표의 의미</h4> Q</strong>: 핵심 역량 10가지에 대해 목표를 세우게 되는데, 알고리즘 주차의 경우 유지보수나 비즈니스 이해와 직접적 관련이 없어 보인다. 10개를 모두 작성해야 하는가? 어떤 항목을 중심으로 써야 할까?</p> A: 이동석 코치님</strong></p> 10가지를 모두 작성할 필요는 없다. 특정 주차에는 상대적으로 덜 중요한 역량이 있을 수 있다.</p> 다만 모든 핵심 역량은 중요하므로 각 역량과의 연결점을 고민해보면 좋겠다. 여기서 배우는 것들은 실제 현장에서 필요한 역량이고, 어떤 식으로든 현실과 연결되는 부분이 있다.</p> A: 김현수 코치님</strong></p> 핵심 역량 목표를 도입한 배경은, 이전 기수들이 많은 활동을 했음에도 이력서에 잘 드러나지 않는 점이 아쉬웠기 때문이다.</p> 따라서 몇 가지 역량에 집중해서 계획을 세우고 발전 과정을 기록하여, 성과가 가시적으로 드러나도록 하려는 의도다.</p> 예를 들어, 알고리즘 주차를 완료했다고 해서 문제 해결 능력이 뛰어난 것은 아니다. 하지만 알고리즘 주차에서 문제 해결을 위한 구체적 목표를 세우고 달성한 기록이 있다면, 문제 해결 능력을 어필할 수 있다. 이력서 활용뿐 아니라, 목표가 있으면 스스로의 성장에도 도움이 될 것이다.</p> 항상 전부 채울 필요는 없지만, 이런 의도를 이해해주면 좋겠다.</p> 생각: 핵심 역량 목표를 어떤 식으로 세워야 할까?</h4> 이 답변과 Week2 WIL 작성 시의 생각을 종합했을 때 다음과 같은 결론을 세웠다.</p> 최소 2~3개 이상의 핵심 역량 목표를 정한다.</li> 수치화하거나 이전 상태와 비교 가능한 형태로 목표를 설정한다.</li> 선택하는 역량은 한 영역에 치우치지 않고, 개인 역량과 협업 역량에서 각각 최소 1개 이상 포함한다.</li> </ul> 수치화/비교 가능한 목표의 예:</strong></p> 저번 주차 미해결 골드 문제를 이번 주차에 30분 내 독립 풀이. 전/후 소요시간 기록.</li> 엣지케이스 체크리스트 도입, Week 02 대비 1차 제출 정답률 비교 기록.</li> 팀원 피드백 시간을 별도로 할당하여 N회 이상 실행. 팀 프로젝트 시 머지 컨플릭을 잘 해결하는 Skill.md 도입 등.</li> </ul> 정글 에세이: 퇴사하고 정글에 온 이유 Sijun Yang — Fri, 06 Mar 2026 00:00:00 +0000 첫 번째 회사에서 약 1년 8개월의 일을 마무리하고 정글에 참여하게 되었다.</p> 크래프톤 정글에 가야겠다고 다짐한 이유</h2> 나는 광주소프트웨어마이스터고등학교를 다녔다. 학교에서는 팀 프로젝트 위주의 자습이 대부분이였고 이론이나 CS를 깊게 배우기 어려운 환경이었다.</p> 이런 아쉬움에 개인적으로 OS나 CS 자료를 찾아 공부했는데, 어렵게 찾은 개념을 잘 정리해둔 글이 크래프톤 정글을 다니면서 쓴 글이라는 걸로 정글을 처음 알게 되었다.</p> 정글을 찾아보니, 합숙 방식과 CS 위주의 커리큘럼이 매력적이었다. 특히 고등학교에서 기숙사 생활과 팀 프로젝트를 통해 빠르게 성장한 경험이 있어서 더 공감할 수 있었다.</p> 고등학교 졸업 후 바로 정글에 지원하고 싶었지만, 길어진 취준 생활이 두려워 도피성으로 부트캠프를 찾는 건 아닌지 의심이 들어 취업에 집중했다. 운이 좋게도 2025년 7월에 강남의 작은 스타트업에서 백엔드 개발자로 일을 시작했다.</p> 그럼에도 CS 공부에 대한 욕심은 사라지지 않았다. 단순 구현만 가능한 개발자가 아니라, CS와 기본기를 바탕으로 빠른 기술 적응과 의사 결정이 가능한 개발자가 되어야 한다는 생각은 변하지 않았다. 특히 AI의 발전으로 이 생각은 더 강해졌다.</p> 5개월 동안 얻고 싶은 것</h2> 1. 기본기</h3> CS나 자료구조 같은 기본기는 항상 필요하다고 생각하지만, 당장 티가 나는 지식이 아니다 보니 일하면서 공부하기 어려웠다. 이 기회에 확실하게 집중해서 학습하고자 한다.</p> 커리큘럼 중 자료구조, 알고리즘, 운영체제와 컴퓨터 시스템은 더 집중해서 배울 생각이다.</p> 2. 여러 사람들과 팀 프로젝트 경험</h3> 소마고를 다니면서 팀 프로젝트를 해보았지만, 거의 정해진 팀원과 개발했고 시간 여유도 많았다.</p> 정글에선 더 높은 난이도의 과제를 팀원들과 협력해보고, 만나보지 못했던 다양한 나이대와 배경의 사람들을 만나보고 싶다. 특히 운영체제나 기본기에 관심이 많았지만 이야기할 사람이 없었는데, 여기서는 함께 이야기하면서 학습할 수 있어서 기대된다.</p> 참여하는 태도</h2> AI를 적극적으로 사용하면서 학습 능력의 저하를 많이 체감했다. 최대한 AI 없이, 고통스럽더라도 스스로 고민하며 학습하는 방식을 시도해 볼 생각이다.</p> 원래 이런 방식을 선호하지만, 시간과 효율을 이유로 실천하지 못했다. 첫 주차 미니 프로젝트를 하면서 하루 15시간 이상을 순수 작업에 쏟을 수 있는 환경이라는 걸 체감했고, 이 시간적 여유를 활용해 최대한 삽질을 많이 해볼 생각이다. 이때가 아니면 언제 가능하겠나 싶다.</p> 협업 관점에서는 실무/개발 경험을 가진 사람이 많지 않아(최소한 이번 기수, 나의 반에서는) 이런 경험으로 알게 된 지식을 기반으로 많이 도움을 줄 수 있을 것 같다. 머신러닝이나 딥러닝도 커리큘럼에 있는데, 전혀 해본 적이 없어서 이 파트에선 오히려 도움받는 입장이 되지 않을까 싶다.</p> 정글이 끝난 후의 나</h2> CS 기초가 탄탄하게 쌓여서 새로운 개념들을 쉽게 공부하고 배워나갈 수 있는 사람이 되었으면 좋겠다.</p> 이를 기반으로 오픈소스에 기여하거나 난이도 있는 토이 프로젝트를 진행하며 개발 능력을 높여가고자 한다. (그리고 가능하면 취업에도 성공하고</del>)</p> [월간 기록] 2026년 2월 Sijun Yang — Sat, 28 Feb 2026 00:00:00 +0000 이번 달의 큰 이벤트는 크래프톤 정글 SW 12기 합격과 참여를 위한 첫 번째 회사의 퇴사이다. 인수인계와 시험 준비에 많은 시간을 소요하여 자료 수집과 작업을 많이 하지 못했다.</p> 수집</h2> 흥미롭거나 유용했던 자료들</p> LLM을 칩 위에 '인쇄'하는 Taalas의 방식</a> \| GeekNews</a></h3> Taalas라는 스타트업이 Llama 3.1 8B 모델의 가중치를 하드웨어 칩의 트랜지스터로 직접 구현했다.</p> 원래 X에서</a> 먼저 알았는데 GeekNews에도 올라왔다. TokenPost 기사</a>도 참고.</p> 처음 보고 모델을 칩에 고정한다는 발상이 신선했는데, 생각해 보면 비슷한 사례가 이미 있다.</p> 부동소수점 연산은 원래 소프트웨어로 처리하다가 CPU에 내장되었다. ARM도 JavaScript의 부동소수점→정수 변환을 하드웨어 명령어(FJCVTZS</a>)로 넣었다.</p> 자주 쓰이는 연산을 하드웨어에 옮기는 건 반복되어 온 패턴이지만, LLM이 가능할 거라고는 직관적으로 생각하지 못했던 부분이다.</p> 속도가 비교도 안 되게 빠르다. 데모 사이트</a>에서 직접 대화해 보면 체감할 수 있다.</p> 바이브코딩의 보안 문제: MoltBook 해킹</a> (GeekNews</a>) \| OpenClaw 마크다운 악성코드</a> (GeekNews</a>)</h3> MoltBook이 Supabase 설정 오류로 150만 개의 API 키, 35,000개 이상의 이메일, 비공개 메시지가 노출되었다. RLS(Row Level Security)가 비활성화되어 누구나 전체 DB에 접근 가능한 상태였다.</p> OpenClaw 에이전트의 마크다운 악성코드 문제도 있었다. ClawHub의 인기 스킬이 마크다운 문서에 위장된 악성 링크를 포함하고 있었는데, 사람들이 마크다운 파일을 위험하다고 인식하지 않는 점을 노린 것이다. 이제는 텍스트 자체가 취약점이 될 수 있다는 사실을 인지해야 한다.</p> 다만 두 사례는 별개의 이슈다. MoltBook의 사례를 예시로 OpenClaw가 위험하다는 식의 의견을 종종 보았는데, 이는 맞지 않는 말이다.</p> MoltBook은 기업가 Matt Schlicht가 코드를 직접 보지 않고 바이브코딩으로 만든 플랫폼이고, OpenClaw의 Peter Steinberger는 전 소프트웨어 엔지니어로 코드 구조를 설계하고 리뷰한다. OpenClaw의 악성코드 문제는 사칭 배포처에서 발생한 사건으로, 사람이 만든 소프트웨어라도 동일하게 발생할 수 있는 유형이다. 또한 OpenClaw 자체 구조상 플랫폼 내부에서 개인정보가 유출되는 문제와는 직접적인 관련이 없다. 다만 OpenClaw는 AI에게 강력한 권한을 부여하는 도구이기 때문에, 이런 문제는 자연스러운 특성에 가깝다.</p> 어쨌든 바이브코딩의 문제점을 잘 보여주는 사례다. 개인정보를 저장하고 관리하는 곳에 바이브코딩을 적용하는 게 올바른지는 확실히 고민해 봐야 한다. Andrej Karpathy도 보안 취약점/해킹/스팸/조작 등의 이유로 사용을 비추하면서도, 대규모(15만+) 에이전트 네트워크를 만들어낸 건 흥미롭다고 평가했다.</a></p> Rust 한국 디스코드 채널의 Rust-for-Linux 관련 글 \| Discord</a></h3> Linux Kernel v7.0-rc1 릴리즈와 함께 Rust 지원이 확대되었고, 실제 하드웨어 디바이스 지원을 위한 기능들이 추가되었다. Linux Plumbers Conference 2025 분위기도 Rust 중심이었으며, 커널 개발 쪽에서 Rust 채택 흐름이 강해지는 상황이다. 커널 개발에 관심 있는 사람이라면 지금 Rust 기반 커널 개발 흐름에 참여하는 것도 좋다는 의견이 나왔다.</p> 2026년, 그냥 Postgres를 쓰자</a> \| GeekNews</a></h3> 대부분의 기업은 PostgreSQL 하나로 충분하다는 주장이다.</p> AI 에이전트 시대에는 단일 DB 환경에서 빠르게 테스트하고 디버깅하는 것이 효율적이고, 백업/모니터링/보안 전략을 단일화하여 운영 비용을 줄일 수 있다.</p> PostgreSQL 확장 기능으로 검색(pg_textsearch), 벡터 검색(pgvector), 시계열(TimescaleDB), 문서(JSONB) 등을 전문 프로그램과 비교하여 거의 비슷한 성능을 낼 수 있다고 주장한다.</p> 실무에서도 그런 통계 결과가 나올지 모르겠지만, 실제 데이터 시연 결과를 보여주고 증명하는 점에서 테스트해 보고 도입해 볼 만한 것 같다.</p> Stop Forwarding Errors, Start Designing Them</a></h3> Rust에서 더 나은 에러 처리를 위해, 기계가 처리할 정보와 사람이 읽을 정보를 분리하자는 글.</p> 예를 들어 기계용 정보로는 ErrorKind</code> 열거형과 ErrorStatus</code>를 통해 처리 방법, 재시도 가능 여부 등을 명시하고, 사람용 정보로는 #[track_caller]</code>로 호출 위치를 자동으로 기록하며, 타입 시스템으로 모듈 경계에서 문맥 추가를 강제한다.</p> 액션베이스(Actionbase) – 좋아요, 최근 본, 팔로우를 위한 데이터베이스</a> \| GeekNews</a></h3> 좋아요, 팔로우, 최근 본 항목 등 "누가 무엇을 어떻게 했다"라는 관계형 기능을 위한 카카오의 오픈소스 DB이다. 쓰기 시점에 모든 데이터를 미리 계산하고 읽기는 단순 조회만 수행하여 빠르고 예측 가능한 성능을 제공한다. 카카오톡 선물하기 위시 등 프로덕션 환경에서 분당 100만 건 이상의 요청을 처리 중이라고 한다.</p> 회사에서 비슷한 걸 RDB로 만들어 본 적 있는데, 구현이나 유지보수가 어려웠다. 나중에 비슷한 기능을 구현하게 될 수도 있다고 생각하는데, 이 프로젝트의 코드나 원리를 뜯어보면 적용할 수 있을 것 같다.</p> 그 외 수집한 글</h3> Todd C. Miller – 30년 넘게 Sudo를 유지보수한 개발자</strong></a> (GeekNews</a>): sudo가 30년간 한 명이 유지보수해 온 프로그램이라는 사실. sudo가 별도 프로그램이라는 것도 새삼 인식하게 되었다.</li> Claude Skills 구축을 위한 완벽 가이드</strong></a> (GeekNews</a>): Anthropic이 제공하는 33쪽 가이드. 마크다운 번역본</a>도 정리해 두었다.</li> How I Assess Open Source Libraries</strong></a>: 오픈소스 보안 컨설팅 전문가가 라이브러리를 채택할 때의 평가 기준을 소개하는 글.</li> microgpt - 200줄 순수 파이썬으로 구현한 GPT 학습 및 추론</strong></a> (GeekNews</a>): Andrej Karpathy가 외부 의존성 없이 200줄로 GPT 전체를 구현한 교육용 프로젝트.</li> How I became a Linux Kernel Contributor</strong></a>: 한 커널 컨트리뷰터가 본인의 기여 여정을 소개하는 영상. 실제 커널 기여 시 전체적인 참여 흐름을 이해하는 데 도움이 될 듯하다.</li> 메모리 관련 자료 모음</strong></a>: "What Every Programmer Should Know About Memory" 요약 버전. 메모리 최적화 기법</a>도 함께 참고.</li> LLM이 만든 비밀번호가 위험한 이유, 100비트처럼 보이지만 실제론 27비트</strong></a> (GeekNews</a>): LLM은 근본적으로 토큰 생성기다. 따라서 인간과 마찬가지로 진정한 무작위성과는 거리가 있다.</li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p> 짧은 글: AI 시대의 학습과 올바른 사용에 대한 고민</h3> AI 시대에서의 학습 능력과 프로젝트 개발 의욕 저하</h4> Anthropic 연구</a> (GeekNews</a>)에 따르면, AI에 작업을 전적으로 맡긴 개발자들은 퀴즈에서 17% 낮은 점수를 기록했다. AI는 학습 측면에서는 그다지 도움이 되지 않을 수 있다.</p> "AI가 당신을 지루하게 만든다"</a> (GeekNews</a>)라는 글에서도 말하듯, AI 중심의 개발 방식은 금방 흥미를 잃게 만들 수 있다.</p> 나 역시 이 의견에 동의하는데, AI를 많이 사용할수록 결과물에 대한 애착이 줄어들고 장기적으로 이해도가 떨어진다는 느낌을 받았다.</p> 따라서 의도적으로 AI 없이 코드를 작성하고 학습하는 과정을 만들어야 한다고 생각하고 있다.</p> 어떻게 코드를 다루어야 할까?</h4> Node.js 메인테이너인 Matteo Collina</a> (GeekNews</a>)도 AI를 생산성 도구로 활용하되, 판단력과 책임은 포기하면 안 된다고 주장한다.</p> 요즘 해커뉴스나 긱뉴스, 여러 오픈소스 커뮤니티에서 AI Slop의 남발로 인한 문제는 심심치 않게 접할 수 있다.</p> 하지만 AI 활용이 긍정적인 사례도 분명히 있다. hwplibsharp 업스트림 관리</a>에서는 AI가 포팅 코드를 작성하고 리뷰만으로 유지보수하는 방식을 소개한다. 이전에 본 $5짜리 프롬프트로 $2,418짜리 취약점을 찾은 사례</a>도 좋은 영향을 주는 AI 활용 예시라고 생각한다.</p> 이런 식으로 AI를 사용하되, 피해나 부담을 주지 않으면서 긍정적으로 활용하려는 자세가 필요한 듯하다.</p> AI 개발의 3가지 조합</h4> X에서 본 글인데, 인간(의지/의도 주입) + LLM(코드 생성) + 정적분석(타입체커, 린터, 자동테스트)</a>을 조합하는 구성이 좋다는 의견이다. 좋은 패턴이라고 생각해서 시도해 볼 계획이다.</p> AI와 함께 개발한다면, 혼자가 아니라 다른 사람과 협업하는 것처럼 접근해야 한다. 코드를 작성하는 주체가 여럿이므로 이런 구성을 기본으로 사용하는 게 올바르다고 생각한다.</p> 짧은 글: Functor와 Monad가 무엇인가?</h3> 참고한 글:</p> 카테고리 이론으로 설명하는 프로그래머를 위한 글</a></li> TypeScript로 보는 Monad</a></li> 모나드는 포켓몬이다: 수학 없이 배우는 모나드 입문 - RosettaLens 번역본</a></li> </ul> 정리한 핵심 개념:</p> Functor</strong>: A => B</code>를 적용하면서 컨텍스트는 불변. 현실의 사이드이펙트나 별도 기능을 의미하는 컨테이너로 실제 값(타입)을 감싸는 것.</li> Monad</strong>: A => M[B]</code>를 적용하면서 컨텍스트를 합성. Monad는 Functor를 포함한다.</li> Context</strong>: 계산의 성격이나 값의 추가 정보. Option(있거나 없음), List(여러 개), Future(대기 중) 등.</li> Monad의 실용적 관점</strong>: 연산 중 컨테이너를 컨테이너로 감싸는 중첩 문제를 해결하기 위한 것.</li> Monad의 함수적 관점</strong>: 숫자에 0을 더해도 값이 변하지 않듯, 어떤 컨테이너를 pure</code>로 감싸고 다시 펴는 행위가 원래의 정보나 상태에 영향을 주지 않아야 한다.</li> Monad 종류</strong>: Option, Either, List, IO, Future, State, Reader 등. 구현을 바꾸면 패턴을 유지하면서 동작을 변경할 수 있다.</li> </ul> 사실 하스켈 같은 순수 함수형에 가까운 언어를 사용해 본 경험이 거의 없어서, 이런 식으로 정보만 접하는 게 올바른지는 모르겠지만, 모나드에 대해서 실용적으로 적용할 수 있을 정도는 이해한 것 같다.</p> zsh + starship 터미널 환경 세팅</h3> zsh + starship</a>을 사용해 봤다. oh-my-zsh 대신 플러그인 zsh-autosuggestions</code>, zsh-syntax-highlighting</code>를 설치한 기본 zsh에 적용하였다.</p> 스타일은 oh-my-zsh보다 취향에 맞아 만족하고 있다.</p> 참고한 자료: starship 가이드</a>, zsh 설정 참고</a>, dotfiles 예시</a></p> CS146S: The Modern Software Developer 강의 정리</h3> 1월에 소개했던 Stanford CS146S 강의</a>를 주차별로 정리했다.</p> 다만 3주차부터는 시간이 없어서 실습을 하지 못했고, 자료에 대한 요약을 훑어보기만 했다. (항상 이런 식으로 대충 마무리된다.</del>)</p> Week 1: 정리</a></li> Week 1 추가: Deep Dive into LLMs - Andrej Karpathy</a></li> Week 1 추가: AI Prompt Engineering - Anthropic</a></li> Week 2: 정리</a></li> Week 3: The AI IDE</a></li> Week 4: Coding Agent Patterns</a></li> Week 5: The Modern Terminal</a></li> Week 6: AI Testing and Security</a></li> Week 7: Code Review</a></li> Week 8: Automated UI and App Building</a></li> Week 9: Agents Post-Deployment</a></li> </ul> 노트: LLM 토큰 반복 루프 이해</h3> LLM 공부를 하다 보니 원리가 궁금해져서 예전에 본 뉴로사마 고장 영상</a>의 원인을 찾아보았다.</p> 어떤 이유로 "location"의 선택 확률이 비정상적으로 높아지면, 출력된 "location"이 컨텍스트 윈도우에 누적되고, 컨텍스트에 "location"이 많을수록 다음 토큰으로 "location"을 선택할 확률이 더 높아져서 피드백 루프가 발생한다.</p> 비달(개발자)은 뉴로(LLM 에이전트)에게 중립적인 단어를 계속 말하게 하여 컨텍스트 윈도우에서 "location"을 밀어내서 해결하였다.</p> 짧은 생각</h2> 근황과 요즘 하는 생각</p> 크래프톤 정글 SW 12기에 합격하였고, 참여를 위해 1년 8개월 정도 다닌 회사를 퇴사하게 되었다. 주위에서 주워들은 정보로 보면 충분히 안정적이고 성장 가능성 있는 회사라고 생각하지만, 개인적인 성장에 대한 욕심이 있어 퇴사하게 되었다.</p> 개발용으로 사용할 노트북을 중고로 저렴하게 구했다. 배터리 상태 100%인 MacBook M1 Pro, RAM 32GB / SSD 512GB 모델을 150만 원에 구매했다.</p> BongoCat</a>이라고 데스크톱에서 고양이가 마우스 위치와 타이핑을 따라하는 앱이 재미있고 귀여워 보여 설치했다. 가끔 유튜브에서 비슷한 기능을 버튜버들이 쓰는 걸 볼 수 있고, 나는 작게 우측 하단에 띄워놓으면서 쓰고 있다.</p> [월간 기록] 2026년 1월 Sijun Yang — Sat, 31 Jan 2026 00:00:00 +0000 이번 달에는 정규표현식 내부 구조, 비동기 모델, 스레드 메모리 위치 같은 기술 관련 내용을 파봤다. 기술 관련 글을 읽다가 궁금해진 것들이다. 그리고 여러 개인, 기업, 교육기관에서 AI 활용 능력을 다룬 글들이 많이 눈에 띄었다.</p> 수집</h2> 흥미롭거나 유용했던 자료들</p>The Missing Semester of Your CS Education</a></h3> MIT에서 진행하는 강의다. CS 수업과 달리 명령줄, 에디터, 버전 관리 시스템 등 개발자가 매일 사용하는 도구를 효율적으로 활용하는 방법에 초점을 둔다. 강의 자료와 영상은 인터넷에 공개되어 있어 외부 사용자도 자유롭게 학습할 수 있다.</p> Git, 디버깅, Shell 활용, dotfiles 관리, 기본적인 보안 개념 등 실무에서 알아두면 좋은 주제들을 넓고 얕게 정리해 준다. 관심 있는 주제만 골라서 봐도 이해하는 데 상관없어 부담 없이 볼 수 있다.</p> 2026년 강의는 현재 촬영 중이며, 2020년 이후 새롭게 공개되는 강의이다. LSP와 AI 기반 도구 관련 내용이 추가되고 Shell이나 Vim의 비중은 줄어드는 등, 개발 환경의 변화가 비교적 잘 반영되고 있는 듯하다.</p> 73 Programming Project Ideas to Inspire and Challenge You</a> \| HackerNews</a></h3> 직접 구현해볼 수 있는 73개의 프로그래밍 프로젝트 아이디어와 참고 자료를 정리한 글이다.</p> GitHub에서 유명한 build-your-own-x</a> 레포가 있는데, CodeCrafters에서 운영하고 있다.</p> CodeCrafters는 Redis, Git 같은 유명한 프로젝트를 직접 만들어보는 서비스를 제공한다. 관심 가는 프로젝트들이 있어서 시간 나면 시도해볼 생각이다.</p> Regular Expression Matching Can Be Simple And Fast</a> \| HackerNews</a></h3> 대부분의 프로그래밍 언어는 backreference, look-around 같은 확장 기능을 지원하기 위해 백트래킹 NFA를 사용하는데, 이 방식은 최악의 경우 지수 시간이 걸릴 수 있다. 반면 Thompson NFA는 이런 확장 기능을 지원하지 못하지만, 최악의 경우에도 O(mn) 시간을 보장한다. awk</code>, grep</code> 같은 전통적인 Unix 텍스트 처리 도구가 이 방식을 사용한다.</p> 정규표현식이 유한 상태 기계(Finite State Machine)로 구현된다는 사실은 들어봤는데, 실제 코드를 보니 더욱 흥미로웠다. 정규표현식과 FSM을 변환해주는 FSM2Regex</a>를 사용해보면 이해에 도움이 된다.</p> Why async Rust?</a> \| HackerNews</a></h3> Rust의 async가 왜 현재의 모습을 가지는지 핵심 기여자가 설명한 글.</p> 글 자체로도 좋지만, 다중 스레드의 생성 원리, 비동기 실행 모델과 Rust의 executor에 대한 궁금증이 생겨서 추가로 찾아보게 된 좋은 계기였다.</p> CS146S: The Modern Software Developer</a> \| 공식 한국어 번역본</a></h3> Stanford 강의와 공식 한국어 번역본이다. 강의에서 AI 기반 개발을 꽤 자세하게 다루는 것 같다. 번역하는 팀</a>을 봤는데 시니어/리더급 엔지니어 분들이다.</p> AI 기반 번역이고 검수가 되지 않은 듯한 부분에서 누락/오역 등의 문제가 있어 원문과 비교하면서 보는 걸 추천한다.</p> Use The Index, Luke</a></h3> "Introduction to PostgreSQL Indexes" 해커뉴스 글</a>의 댓글에서 추천받아 알게 되었다.</p> 목차까지만 보았는데 SQLP 준비할 때 배웠던 내용과 겹치는 부분이 많아서 잘 구성된거 같고, 여러 DBMS를 다루고 있어서 기억해두려고 한다.</p> AI 시대, 리팩터링은 더 이상 노가다가 아니다</a> \| GeekNews</a></h3> 레거시 컴포넌트들이 코드베이스에 혼재하는 문제를 AI와 Codemod로 해결한 사례를 설명한 글이다. AI를 매우 잘 사용한 좋은 예시가 될 수 있겠다.</p> 이런 자동화 관련된 사례가 많이 보이는데, 이제 AI를 사용해서 대규모, 엣지 케이스가 있는 작업도 자동화가 쉽게 가능해진 것 같다.</p> 비슷한 글: Claude Skills로 GitLab 업그레이드 자동화하기</a></p> 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄여주는 고수들의 행동패턴 따라하기</a></h3> 실력 있는 개발자들의 디버깅 패턴을 정리한 글. 핵심은 원인 파악에 시간을 투자하고, 정상 동작에 대한 심적 표상(머릿속에 구축된 지식 구조)를 쌓아야 한다는 말.</p> 이전에 읽고 실천했을 때 효과가 좋았고, 오랜만에 봐도 좋은 내용이라고 생각한다.</p> MoltBot 제작자: “나는 읽지 않은 코드를 배포한다” \| GeekNews</a></h3> 창업자 출신인 Peter Steinberger의 개인 프로젝트지만 많은 관심을 받고 있는 Moltbot</a>은 메신저를 인터페이스로, 로컬 머신을 실행 환경으로 사용하는 LLM 에이전트 게이트웨이다. 로컬에서 지속적으로 실행되며 개인용 AI 에이전트로 활용할 수 있다.</p> 개발 워크플로우를 다룬 인터뮤가 공개되었는데, AI 에이전트를 적극 활용한 개발 방식을 사용한다. 코드 자체보다 프롬프트를 보고 결과물을 평가하는 접근이 인상적이였다.</p> 물론 책임 소재가 사용자에게 있는 오픈소스에 개인 프로젝트라서나 가능한 방식이고, 회사 환경에서는 책임 소재나 검증 문제로 그대로 적용하기 어려울 거 같다.</p> 에이전트 기반 개발의 한 방향성으로 참고할 만하다.</p> 성공하는 언어의 조건, C를 계속 배워야 하는 이유에 대한 의견</a></h3> 간단한 토이프로젝트를 만드려고 했는데 애플이 제공하는 C 라이브러리를 사용해야 했다. Rust는 FFI가 필요해서, C 라이브러리를 바로 쓸 수 있는 Zig로 해볼까 검색하며 찾아보는 흥미로운 의견을 발견헀다.</p> Zig는 성공하는 언어의 기준에 맞지 않아 성공하기 어렵고 C는 여전히 필요하다는 흥미로운 의견을 발견했다. 극단적이긴 하지만, 언어가 기업의 선택을 받고 성공하는 기준에 대해 그럴듯하고 공감가는 의견이라 기록해둔다.</p> 그 외 수집한 글</h3> AI 시대의 소스코드 품질 - akwiki</strong></a>: AI로 작업하면서 품질 하락을 막기 위한 구체적인 도구들을 소개한다.</li> 타입 시스템은 왜 증명처럼 동작하는가</strong></a>: 예전에 OCmal 공부할 때 Hindley-Milner, Curry-Howard 같은 타입 이론을 들어봤는데, TypeScript를 이런 Curry-Howard 이론 관점에서 설명한다. 언어를 Curry-Howard 이론으로 설명하는게 무용하다는 의견</a>도 있다.</li> Sylvain Kerkour의 블로그</strong></a>: Rust, 보안에 대한 내용을 다룬다. Dev Containers</a>, 오류 처리</a>, Rust, Axum, SQLx 스택</a>, 대규모 코드베이스 권장사항</a>, 아키텍처</a> 등을 다룬다. 다만 웹 개발/보안 쪽에 치우쳐져 있고 동의하지 않는 주장도 있어 주의하기.</li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>"시간 데이터를 올바르게 다루는 방법"</a> 블로그 작성</h3> 원래는 핵심 원칙만 간단히 정리할 생각이었지만, 쓰다 보니 시간 처리의 역사나 참고한 Temporal API까지 추가하는 게 이해하기 좋을 것 같아 내용이 대폭 늘었다. 그 과정에서 글의 완성도를 신경 쓰다 보니 시간이 많이 들었다.</p> 다음에 블로그를 쓸 때는 머릿속으로 구조를 완성해두고 명확히 잡는 편이 좋을 것 같다. 이번 글은 아직 하나의 글로 마무리하기에는 준비가 덜 된 주제여서 많은 시간이 걸렸다.</p> Thompson NFA 구현 이해하기</h3> Regular Expression Matching Can Be Simple And Fast</a> (한국어 번역</a>) 글을 보고 Python 코드로 바꿔가며 이해를 높이려고 했다.</p> 정리한 Gist 글</a>. AI를 쓰기도 했고, 실제로 여러 번 따라 쳐본 건 아니라 확실하게 이해했다고 하기엔 무리지만, 일단 이 정도면 충분한 것 같다.</p> 정규표현식이 어떻게 오토마타로 구현되는지, 백트래킹 방식과 Thompson 알고리즘의 차이가 무엇인지 코드를 통해 이해할 수 있었다.</p> The Missing Semester of Your CS Education 강의 학습</h3> 위에서 소개한 MIT 강의를 2020년 버전 위주로 영상과 스크립트를 훑어보았다. 깊이는 얕지만 무엇을 공부해야 할지 폭넓게 다뤄서 좋았다. 모르는 내용도 꽤 있었고, 2026년 강의에서 AI 관련 내용이 추가되는 것 같아 그것도 나중에 볼 예정이다.</p> 강의 노트</a>는 메모하고 AI로 내용 요약한 정도라 기억에 오래 남진 않을 것 같다. 필요할 때 찾아보는 정도로 쓸 듯.</p> AI로 탐색: 비동기 모델과 메모리 구조 정리</h3> "Why async Rust?"</a>를 읽다가 궁금해진 부분을 파고들다 보니 비동기나 스레드의 메모리 위치에 대한 사실들을 알게 되었다. Gist에 정리하였다.</p> Rust 비동기 실행 모델의 내부 원리</a></li> Linux 스레드와 메모리 구조</a></li> Stackful 비동기의 동작 방식 & 비동기 실행 모델의 분류</a></li> </ul> DB Hub</a>를 사용한 MCP Server 사용</h3> 추가 — 2026/02/03</strong></p> 어제(02/02) OpenAI가 Mac용 Codex App을 출시했다.</a> 이를 활용하면 별도 채팅 UI를 구축할 필요가 없고, 인증/설정에 필요한 env 기반 Bearer token과 Headers를 지원하므로 OAuth Provider 서버를 구축할 필요도 없어졌다. key-value 기반의 액세스 키만 발급/관리 기능만 만들면 가볍게 사용하기 충분하다. 가이드 문서를 제공하여 비개발 직군도 손쉽게 DB 분석 환경을 사용할 수 있게 되었다.</p> </blockquote> 추가 — 2026/02/12</strong></p> 최근에 MCP 서버를 공부하다가 알게 되었는데, OAuth Provider를 Auth0 같은 별도 서비스를 통해 직접 만들지 않고, mcp-auth-proxy와 같은 프록시를 사용하면 Github이나 Google 같은 외부 Provider를 사용해도 된다.</a> Google 기반을 사용하면 조직 도메인 등으로 검증할 수 있어 세세한 권한 제어가 필요없는 작은 규모의 조직에서는 좋아보인다.</p> </blockquote> 회사에서 비개발 직군도 회사 DB에 접근할 수 있게 하는 것이 목적이었는데, 관리 비용과 보안 문제로 실패했다. 결국 몇몇 분에게만 VSCode + Codex 환경을 임시로 세팅해 드렸다.</p> 대신 개발 쪽에서 아주 유용하게 쓰고 있다.</p> 팁: 레거시로 인해 스키마/컬럼명이 명확하지 않다면, Comment를 함께 전달하도록 tool을 작성하면 AI가 컨텍스트를 더 정확히 파악한다.</p> 문제 배경: 회사 DB 접근 MCP 서버를 비개발자도 안전하게 사용하게 하려면?</span></span> </span> MCP 연동 방식별 특성:</span></span> - 로컬 개발 도구 (Codex, Claude Code 등): 로컬에서 직접 MCP 서버 호출 → IP 화이트리스트 적용 가능</span></span> - 로컬 데스크톱 앱 (Claude 앱 등): 외부 MCP 서버 연결 기능 미지원</span></span> - 웹 서비스 (GPT, Claude 웹): AI 회사 서버 경유 → 우리 측 IP 제한 불가</span></span> </span> 선택지:</span></span> </span> 1. 외부 IP 노출 안 함</span></span> ├─ a. 로컬 개발 도구 사용 (Codex, Claude Code 등)</span></span> │ → 문제: 비개발자 사용 어려움, UX 목적과 불일치</span></span> │</span></span> └─ b. 자체 중간 서버 구축 (LLM API + MCP 연동)</span></span> → 문제: 별도 개발/운영 필요</span></span> 별도 채팅 UI/서버 필요 (슬랙 연동 등으로 UI 대체가 가능하나 자유로운 대화가 제한)</span></span> API Key 비용 발생</span></span> → 장점: IP 화이트리스트 유지 가능</span></span> </span> 2. 외부 IP 노출함</span></span> ├─ a. OAuth Provider 서버 구축 → 자체 인증</span></span> │ → 배경: 웹 환경의 Claude/GPT MCP 커넥터는 OAuth 인증 외에 다른 인증은 지원하지 않음</span></span> │ → 문제: OAuth Provider 인프라 개발 필요</span></span> │ → 장점: GPT/Claude 웹에서 바로 사용, UX 최적, 사용자 관리 가능(IP보다 세밀한 제어 가능)</span></span> │</span></span> └─ b. 퍼블릭 개방</span></span> → 제외 (보안 불가)</span></span></code></pre>AI로 인한 학습과 성장 방향성에 대한 생각</h3> 요즘 해커뉴스나 긱뉴스를 보면 AI와 개발자 커리어에 대한 글이 자주 올라온다.</p> 극단적인 의견도 있지만, 대부분의 의견은 이렇다. AI로 인한 변화는 피할 수 없고, 시니어급 개발자들이 보기에도 기존 개발 작업 대다수를 대신할 수 있을 정도로 발전했다.</p> 관련한 의견들을 보면서 정리한 생각은, 앞으로 주니어가 성장해야 할 방향에는 크게 3가지 능력이 필요하고 이를 키우기 위해 노력해야 한다는 것이다.</p> 올바른 의사결정을 위한 CS 및 기초 지식 기초 지식은 개발뿐 아니라 도메인도 해당될 수 있다. 다만 주니어에게 도메인까지 기대하긴 어렵다.</li> 프레임워크 기반 개발을 하던 과거에도 기초 지식은 중요했다. AI 시대가 되어도 이건 바뀌지 않는다.</li> </ul> </li> AI 활용과 도구 선택 능력 AI를 적절한 영역에 사용하고, 자동화/프롬프팅/에이전트 활용을 통해 효과적으로 동작하게 하는 능력이 중요하다.</li> 동시에 AI가 잘 못하는 부분은 다른 도구로 보완할 수 있어야 한다.</li> </ul> </li> 넓은 범위의 학습/적용 능력 T자 인재의 필요성은 여전하다. 과거에는 신입에게 하나를 제대로 하거나 기초만 있어도 충분했다.</li> 그러나 AI로 인해 다른 영역으로 확장하기 쉬워졌으므로, 주니어도 그 능력을 키워야 한다.</li> </ul> </li> </ol> 관련되서 이번 달에 보았던 글을 정리해두었다.</p> LLMs and your career</a> \| GeekNews</a></li> Andrej Karpathy(OpenAI 공동 창립자)의 Claude 코딩 경험</a> \| GeekNews</a> \| HackerNews</a></li> Don't fall into the anti-AI hype - antirez(Redis 창시자)</a> \| HackerNews</a></li> The Next Two Years of Software Engineering</a> \| GeekNews</a></li> XP, TDD, 그리고 바이브 코딩: Kent Beck(TDD/XP 창시자)의 인터뷰 번역</a></li> </ul> 짧은 생각</h2> 근황과 요즘 하는 생각</p> 요즘에 AI 활용을 더 적극적으로 시도해보려고 하고 있다. 세계 상위권 대학들이 AI 관련 내용을 커리큘럼에 빠르게 추가하는 걸 보면, 교육 현장에서도 이런 능력이 중요하다고 판단하는 것 같다.</p> 시간 데이터를 올바르게 다루는 방법 Sijun Yang — Mon, 12 Jan 2026 00:00:00 +0000 프로그래밍을 어느 정도 해봤다면, 시간 관련 버그를 한 번쯤은 겪거나 들어보았을 것이다. 서버 환경을 바꾸니 시간이 9시간 밀린다거나, 로컬에서는 잘 되던 게 배포만 하면 시간이 이상하게 보인다거나.</p> 이런 버그가 종종 보이는 이유는 단순한 문자열1</a></sup>이나 정수형 타입과 다르게 시간 데이터의 다루는 데 생각보다 많은 주의사항이 존재하기 때문이다2</a></sup>.</p> 이 글에서는 시간 데이터의 두 가지 타입과 관련 문제들을 살펴본 뒤, 내가 사용하는 두 가지 원칙을 소개한다. 마지막으로 이 원칙에 영향을 준 JavaScript Temporal API를 간단히 다룬다.</p> 익숙한 Java/JavaScript 생태계를 중심으로 설명하지만, 모든 언어에 적용 가능하다.</p> 시간의 2가지 타입</h2> 시간 데이터는 크게 두 종류로 나눌 수 있다.</p> Exact Time(물리적 순간)</strong>: 유일한 하나의 시점을 가리킨다. "2024-01-01T00:00:00+00:00"는 전 세계 어디서든 같은 순간이다. Unix timestamp나 UTC 오프셋을 포함한 ISO 8601 형식(예: 2024-01-01T00:00:00Z)이 여기에 해당한다. Wall-clock Time(벽시계 시간)</strong>: 특정 시점이 아니라 날짜와 시간 값 자체를 의미한다. "12월 25일"은 뉴욕 시간이나 한국 시간처럼 특정 지역의 시간을 의미하지 않는다.</p> JavaScript의 Temporal API가 이 개념을 잘 설명해서, 이 글에서도 Temporal의 용어를 차용하여 설명한다.</p> 시간 데이터를 다룰 때 주의해야 할 점</h2> 타임존 정보 손실</h3> Java의 LocalDateTime</code>은 Local-</code>로 시작하는 이름에서 유추할 수 있듯이 타임존 정보를 저장하지 않는다. 하지만 LocalDateTime.now()</code>를 호출하면 시스템의 기본 타임존을 사용해서 현재 시각을 가져온다3</a></sup>. Python의 datetime.now()</code>나 C#의 DateTime.Now</code>도 비슷하게 절대 시점을 저장하지 않는다.</p> 이러한 함수를 보았을 때 타임존 변환이 일어났는지 알기 어렵다. 또한 내부 구현에서 타임존 정보를 유지하지 않는다. 객체 생성하는 도중 타임존을 사용해서 변환은 했지만, 결과 객체에선 어떤 타임존이었는지는 저장하지 않는 것이다. 그래서 이 값을 직렬화하거나 저장하면 어느 지역의 시간인지 알 수 없게 된다. 직렬화할 때 로컬의 시간대 정보를 함께 보내면 되지 않나 싶지만, now()</code> 호출 시 타임존을 직접 지정하는 것도 가능하기 때문에 선언 시점을 제외하면 어떤 타임존이었는지 알 방법이 없다.</p> 특히 요즘의 서비스에선 아주 많은 "로컬"이 존재할 수 있다. 클라이언트와 서버만 있는 간단한 웹 서비스도 2개의 노드가 존재한다. MSA 서비스라면 LB, DB, Redis, 모니터링 등 서버만 수십 개가 넘어갈 수도 있다. 이때 타임존 없는 시간 문자열을 주고받으면, 원래 어떤 타임존이었는지 복구할 방법이 없다.</p> 여러 기술의 함정</h3> 다양한 기술 스택에서 타임존 처리와 관련된 함정들이 존재한다. 직렬화 라이브러리, ORM, DB 등에서 타임존 관련 기본 설정이나 옵션이 직관적이지 않아 의도하지 않은 동작을 유발할 수 있다. 몇가지 예시를 살펴보자.</p> Jackson</h4> DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE</code>4</a></sup>은 기본적으로 true로 설정되어 있는데, 이 옵션이 활성화되어 있으면 ZonedDateTime</code>이나 OffsetDateTime</code>을 역직렬화할 때 원본 타임존을 컨텍스트 타임존(기본값 UTC)으로 변환한다. 이 과정에서 시점 정보는 유지되지만, 원래 타임존 정보를 잃어버린다 (이 옵션은 Jackson 3버전 부터 DateTimeFeature</code> 객체로 이관되었다5</a></sup>).</p> ANSI SQL의 TIMESTAMP WITH TIME ZONE</h4> ANSI SQL 표준의 TIMESTAMP WITH TIME ZONE</code> 데이터 타입은 이름과 달리 타임존 정보를 유지해야 한다는 요구사항이 없다6</a></sup>. 그래서 Oracle의 경우 타임존 정보를 저장하는 반면, PostgreSQL은 타임존 정보를 저장하지 않는 등 제각각의 구현이 존재한다.</p> PostgreSQL을 자세하게 설명해보자면, 데이터 타입 timestamp</code>(timestamp without time zone</code>)는 문자열로 Wall-clock Time 정보를 저장한다. 그래서 시간 비교 등의 연산에서 취약하다7</a></sup>. Exact Time을 저장하려면 timestamptz</code>(timestamp with time zone</code>)를 사용해야 하는데, UTC로 변환되어 저장되고 타임존 정보는 유지되지 않는다. 또한 조회 시 세션의 타임존에 의존하여 시간 결과를 반환한다.</p> JPA와 Hibernate</h4> Hibernate는 6.0 이후부터 LocalDateTime</code>은 TIMESTAMP</code>, Instant</code>는 TIMESTAMP_UTC</code>로 매핑된다8</a></sup>. TIMESTAMP_UTC</code>는 저장 시 값을 UTC로 정규화하지만, TIMESTAMP</code>는 변환 없이 그대로 저장된다. 즉, 두 타입을 Exact Time 표현용과 Wall-clock Time 표현용으로 구분하고 있다.</p> Hibernate는 LocalDateTime</code>을 DB에 저장할 때 JVM 기본 타임존을 기준으로 java.sql.Timestamp</code>로 변환한 뒤 UTC로 정규화한다. 이 과정에서 원본 타임존 정보가 사라진다. 여러 DB 접근 라이브러리를 함께 사용하는 환경에서는 각 라이브러리의 타임존 설정 차이로 인해 시간 오차가 발생할 수 있다9</a></sup>.</p> Spring Data 개발자 Jens Schauder 역시 LocalDateTime</code>은 타임라인 상의 특정 순간을 표현할 수 없으므로 Instant</code>를 사용하는 것이 바람직하다고 설명한다10</a></sup>.</p> 그럼에도 불구하고 많은 코드에서 여전히 Exact Time 데이터를 LocalDateTime</code>으로 선언해 사용하고 있다 (예: spring-boot-java-template BaseEntity의 createdAt, updatedAt</a>).</p> 시간 데이터를 다루는 2가지 원칙</h2> 나는 시간 데이터를 다룰 때 두 가지 원칙을 기준으로 삼고 있다.</p> 이걸 꼭 따라야 한다는 말은 아니다. 하지만 "모든 노드(클라이언트, 서버, DB, 캐시 등)에서 시간 데이터에 대한 해석이 일관되어야 한다."는 조건을 만족하려면 이 원칙과 비슷한 결론에 도달할 것이다.</p> 원칙 1: Exact Time과 Wall-clock Time을 명확히 구분하라</h3> 시간 데이터가 특정 시점을 나타내는지, 아니면 단순한 날짜/시간 값인지 먼저 판단해야 한다.</p> 로그 타임스탬프, 결제 완료 시각, 이벤트 발생 시각처럼 "언제 일어났는가"가 중요한 데이터는 Exact Time으로 저장한다. Exact Time이 아니면 정확한 시점을 알 수 없기 때문이다. LocalDateTime.now()</code>처럼 타임존 정보가 사라지는 방식으로 저장하면, 나중에 원래 시점을 복구할 방법이 없다.</p> 생일, 기념일, 공휴일처럼 특정 시점이라는 개념 자체가 없는 데이터는 Wall-clock Time으로 저장해서 날짜/시간 값 자체만 저장한다. 이런 데이터를 Exact Time으로 다루면 오히려 문제가 생길 수 있다.</p> 단, 이 기준은 도메인에 따라 달라진다. 산부인과 병원 시스템이라면 출생아의 생일이 출생 시점(Exact Time)으로 관리되어야 할 수 있다.</p> 저장 포맷</h4> 각 타입에 적합한 저장 포맷을 사용해야 한다.</p> Exact Time:</p> Unix timestamp (밀리초 또는 초 단위 정수)</li> PostgreSQL의 TIMESTAMPTZ</code></li> ISO 8601 with offset (예: 2024-01-01T00:00:00Z</code>)</li> </ul> Wall-clock Time:</p> DATE</code> 타입 (예: 2024-12-25</code>)</li> TIME</code> 타입 (예: 14:30:00</code>)</li> 문자열 (예: "2024-12-25"</code>, "14:30"</code>)</li> </ul> 타입 객체 선언 시점 주의사항</h4> 대부분의 시간 관련 버그는 코드에서 시간 타입을 생성할 때 발생하므로 주의 깊게 보아야 한다.</p> Exact Time이 필요한 곳에서 LocalDateTime.now()</code>를 쓰고 있지는 않은지 확인한다. Instant.now()</code> 또는 System.currentTimeMillis()</code>를 사용해야 한다.</li> Wall-clock Time이 필요한 곳에서 UTC 변환을 하고 있지는 않은지 확인한다. LocalDate.of(2024, 12, 25)</code>처럼 날짜 값 자체만 저장해야 한다.</li> </ul> 원칙 2: Exact Time은 UTC로 저장하고, 타임존은 별도 관리하라</h3> Exact Time 데이터는 저장, 직렬화/역직렬화, 송수신 등 모든 과정에서 UTC 또는 Unix timestamp로 처리한다.</p> 타임존이 필요한 경우</h4> 비행기 출발 시각, 회의 시간처럼 특정 지역의 시간 표현이 필요한 경우에는 Exact Time과 타임존을 별도 필드로 관리한다.</p> 내부적으로는 UTC(Unix timestamp)로 저장하고, 사용자에게 보여줄 때만 해당 타임존으로 변환한다.</p> 이렇게 하면 시간 비교나 집계 등의 계산이 편리해진다. 저장된 값 자체가 바뀌지 않기 때문이다. 앞서 말했듯 타임존 타입의 지원이 아직 완전하지 않거나 주의해야 하는 시스템이 존재하기 때문에^{11</a></sup>, 모든 곳에서 타임존을 UTC로 고정하거나 타임존 정보가 없는 Exact Time인 Unix timestamp 형태로 관리하는 것이 안전하다.</p>} 전송/저장 시점 주의사항</h4> DB 저장, API 직렬화 등의 과정에서 정보가 손실되는지 확인해야 한다. 명시적인 포맷이나 타입 계약이 없다면, 동일한 값이라도 시스템마다 다르게 해석될 수 있다.</p> DB 데이터 타입, gRPC 같은 스키마 기반 통신 처럼 포맷(타입) 계약이 존재하면 이를 그대로 따른다. JSON이나 텍스트 기반 통신처럼 계약이 없거나 범용 포맷이 필요한 경우, Unix timestamp 또는 UTC 오프셋을 포함한 ISO 8601을 사용한다.</p> ISO 8601는 가독성이 높고, 대부분의 직렬화 라이브러리에서 기본 지원된다. Unix timestamp는 숫자 자체가 절대 시각이므로 해석 오류 여지가 없고, 저장 공간도 적다. 다만 자동 변환을 지원하지 않는 환경에서는 추가 처리가 필요하다.</p> DST와 정책 변경 대응</h4> 타임존과 시간대 정보가 포함된 데이터를 다루는 경우, 여러 가지 모호한 상황(Ambiguity)이 발생할 수 있다. 이와 관련된 구체적인 예시는 "Temporal Time Zones and Resolving Ambiguity - Temporal Proposal Documentation"</a>에서 찾을 수 있다12</a></sup>.</p> DST 시작/종료 같은 일시적 Offset 이동으로 인해서 동일한 벽시계 시간이 두 번 발생(fall back)하거나 존재하지 않는 시간(spring forward)이 생길 수 있다.</li> 정책 변경으로 TimeZone 정의가 변경되어 기존에 저장된 미래 시점의 값과 새로운 규칙 간 충돌이 발생할 수 있다.</li> </ul> 지금 설명중인 2가지 원칙들을 따르면 이러한 문제 대부분을 피할 수 있다.</p> UTC로 저장하면 DST 영향을 받지 않는다. DST는 특정 타임존의 오프셋이 변경되는 것이지, UTC 자체가 바뀌는 것이 아니기 때문이다.</li> 타임존 ID를 별도 필드로 저장하면 정책 변경 시에도 올바른 현지 시간을 계산할 수 있다. IANA 타임존 데이터베이스가 업데이트되면 새로운 규칙이 자동으로 적용된다.</li> </ul> Temporal API 소개</h2> 역사적 배경</h3> 1996년 Java 1.0에서 java.util.Date</code>가 도입됐다. 이는 많은 문제가 있는 구현이였는데, 월이 0부터 시작하고 연도는 1900을 빼서 저장하고 객체가 mutable해서 언제든 값이 바뀔 수 있었다13</a></sup>.</p> JavaScript가 만들어질 때, Java의 Date 구현을 거의 그대로 가져왔다14</a></sup>. Java는 이후 개선을 시도한 반면, Date는 거의 30년이 지난 지금까지 사용되고 있다. (그래서 프로덕션 환경에선 별도의 시간 라이브러리를 많이 쓴다.)</p> 2002년 Stephen Colebourne이 Java Date의 문제를 보완한 Joda-Time 라이브러리를 만들었다. Joda-Time은 큰 성공을 거뒀고, 2014년 Java 8의 공식 java.time</code> 패키지(JSR-310)로 이어졌다15</a></sup>.</p> JavaScript에서는 Date의 문제를 해결하기 위해 Temporal API 제안이 진행되었고, TC39(ECMAScript 기술위원회)에서 이 제안은 Stage 3(명세가 확정되어 구현을 진행) 상태에 있다.</p> Temporal의 설계</h3> Temporal은 Exact Time과 Wall-clock Time의 구분을 타입 시스템에서 강제한다.</p> 원본 링크</a></p> 위 다이어그램에서 왼쪽은 Exact Time(물리적 순간)을 아는 타입들이고, 오른쪽은 Wall-clock Time(벽시계 시간)을 아는 타입들이다.</p> Temporal.Instant</code>는 물리적 순간만 표현한다. 타임존이나 캘린더 없이 절대 시점만 저장한다. Temporal.ZonedDateTime</code>은 물리적 순간에 타임존과 캘린더를 더해서 양쪽에 걸쳐 있다. 반면 Plain-</code> 접두사가 붙은 타입들(PlainDateTime</code>, PlainDate</code>, PlainTime</code> 등)은 타임존 정보가 없다.</p> 원본 링크</a></p> 이 다이어그램은 각 타입이 문자열로 직렬화될 때 어떤 정보가 포함되는지 보여준다. Instant</code>는 UTC 시간만, ZonedDateTime</code>은 오프셋과 타임존 ID까지, Plain</code> 타입들은 날짜/시간 정보만 포함된다.</p> Plain vs Local</h3> 여기서 "Plain"이라는 네이밍이 중요하다. java.time의 "Local"은 이름에서 위치를 암시하지만, "Plain"은 타임존에 대한 어떤 가정도 없다는 것을 명확히 보여준다. 단순하게 날짜와 시간 값 자체만을 표현한다는 의미가 더 직관적으로 드러난다. Temporal의 설계자들 역시 이러한 의도를 가지고 Plain이라는 이름을 선택했다16</a></sup>17</a></sup>.</p> Temporal.Now의 분리</h3> Temporal은 "now"를 다루는 방식이 기존의 일반적인 라이브러리와 다르다. Temporal.Now</code>라는 별도 객체가 존재해서, Temporal.Now.instant()</code>나 Temporal.Now.plainDateTimeISO()</code> 같은 형태로 사용한다. 현재 시각 조회를 별도 API로 분리해서 타임존 정보 손실이 발생할 수 있다는 것을 API 표면에서 명확하게 알려준다. 반면 java.time에서는 LocalDateTime.now()</code>처럼 각 타입에 now 메서드가 붙어 있어 정보 손실이 발생 가능하다는 것이 명확하지 않다.</p> 애매모호한 상황 처리</h3> Temporal은 Plain 타입에서 Exact 타입으로 변환할 때 발생하는 모호함을 다루는 방법을 개발자가 선택할 수 있게 한다12</a></sup>.</p> 앞서 제시한 원칙을 따르면 이런 기능이 필요한 상황 자체가 드물어진다. 다만 레거시 데이터 마이그레이션이나 사용자 입력 처리 같은 예외 상황에서는 유용하므로, 어떤 옵션을 제공하는지 알아두면 좋다.</p> References</h2> 사실 문자열도 그렇게 단순하지는 않다. 유니코드, 인코딩, 정규화 등 고려해야 할 사항이 많다. 이와 관련해서는 The Absolute Minimum Every Software Developer Must Know About Unicode in 2023</a>, UTF-8 Everywhere</a>, 아�니 이 글자 왜 들어간 거예요?</a> 같은 글을 읽어보는 걸 추천한다. ↩</a></p> </li> 여기서 다루는 내용과 별개지만, 시간 데이터의 정확성 자체도 완벽하지 않다. 분산 시스템에서 "정확한 시간"을 정의하는 것 자체가 매우 어려운 문제다. 이와 관련해서는 "Designing Data-Intensive Applications"</a>, Chapter 8: 'Unreliable Clocks'를 읽어보는 것을 추천한다. ↩</a></p> </li> OpenJDK, "LocalDateTime.java source code"</a>, GitHub. ↩</a></p> </li> Jackson, "DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE"</a>, JavaDoc. ↩</a></p> </li> Jackson 3.0.3, "DateTimeFeature"</a>, JavaDoc. ↩</a></p> </li> SQL-92 Standard, Section 4.5 "Datetimes and intervals" - Modern SQL</a>, Full Draft</a>. ↩</a></p> </li> PostgreSQL Wiki, "Don't Do This"</a>. ↩</a></p> </li> Hibernate ORM, "Instant mapping changes"</a>, Migration Guide, Version 6.0. ↩</a></p> </li> jOOQ GitHub, "LocalDateTime param binding handled differently by hibernate"</a>, Issue #11753, 2021. ↩</a></p> </li> Jens Schauder, "Don't use LocalDateTime"</a>, Schauderhaft Blog, 2018. ↩</a></p> </li> Hibernate ORM Discussion, "Support timestamp with timezone/offset"</a>, GitHub. ↩</a></p> </li> TC39, "Temporal Time Zones and Resolving Ambiguity"</a>, Temporal Proposal Documentation. ↩</a> ↩2</a></p> </li> Oracle, "Legacy Date-Time Code"</a>, The Java Tutorials. ↩</a></p> </li> Allen Wirfs-Brock, Brendan Eich, "JavaScript: The First 20 Years"</a>, Proceedings of the ACM on Programming Languages, Volume 4, June 2020 (비공식 한국어 번역</a>). ↩</a></p> </li> Oracle, "Java Date Time APIs"</a>, Java Platform, Standard Edition 8; JSR 310 Expert Group, "JSR 310: Date and Time API"</a>, Java Community Process. ↩</a></p> </li> TC39 Temporal Proposal, "What should be the long-term name of LocalDateTime?"</a>, GitHub Issue #707. ↩</a></p> </li> 여러 시간 라이브러리에서 사용되는 Local-</code> 네이밍은 C언어의 localtime()</code></a> 함수에서 유래했을 것으로 추측한다. 표준처럼 굳어진 용어를 바꾸자는 주장에 마냥 동의하지는 않지만, Local-</code>의 의미가 명확하지 않은 것은 사실이라 이 경우에는 이름을 바꾸는 결정이 합리적이라고 본다. ↩</a></p> </li> </ol> </section> [월간 기록] 2025년 12월 Sijun Yang — Wed, 31 Dec 2025 00:00:00 +0000 RDB 기반 큐로 회사 내부에 문제 많던 코드를 개선했는데, 만족스러운 경험이였다. 나중에 기회가 되면 다뤄볼까 한다. 또한 새로운 블로그 글도 작성했는데, 이 두 작업에 이번 달의 대부분을 투자했다.</p> 수집</h2> 흥미롭거나 유용했던 자료들</p>Lobsters - 해커뉴스와 비슷하지만 초대제로 운영되는 커뮤니티</a> \| GeekNews</a></h3> 기본적으로 해커뉴스를 더 많이 보긴 하는데, 여기에도 재미있거나 유익한 내용이 많다. 업로드 가능한 사람이 제한적이라 그런지 올라오는 글이 해커뉴스와 잘 겹치지 않는 것 같다.</p> SQLite는 어떻게 테스트되는가</a> \| GeekNews</a></h3> SQLite의 테스트 방법론에 대한 공식 문서이다.</p> SQLite가 최근 서버 쪽에서도 사용하자는 의견이 종종 보여서 찾아보다가 알게 되었다. 로컬에서 돌려도 될 만큼 가볍고, 생각보다 높은 성능과, 수많은 기기에서 쓰일만큼 높은 신뢰도가 마음에 든다.</p> 토이프로젝트에서 서버를 만들어야 한다면 Rust, SQLite를 사용해 만들어보고 싶다는 생각을 하고 있다.</p> SQLite의 알려지지 않은 이야기 \| GeekNews</a>나 Quality Management</a>도 함께 보면 좋다.</p> Wide Events: 로깅의 새로운 패러다임</h3> Wide Events 소개 \| GeekNews</a></li> Logging Sucks - Wide Events 공식 사이트</a></li> HackerNews 토론</a></li> </ul> 기존 로깅 방식의 근본적인 문제를 해결하려는 새로운 접근법. 요청당 수십 줄의 분산된 로그 대신, 하나의 포괄적인 구조화된 이벤트를 발행하자는 의견이다.</p> 공감하는 사람들도 많을거라 생각하는데, 서비스의 로그를 분석하다 보면 불편한 상황이 많이 생긴다. 필요한 정보를 주는 로깅이 없다거나, 연결된 로그를 찾기 어렵다거나 등등.</p> 실제 운영을 통한 평가를 받아봐야 확실해지겠지만, 이 기법을 사용한다면 문제 해결이 쉬워지지 않을까 싶다.</p> 나날이 발전하고픈 개발자를 위한 AI 활용법</h3> 발표 자료 (PDF)</a></li> 유튜브 영상</a> X</a></li> </ul> </li> </ul> 관심 가는 거만 메모했다. 빠진부분이 많다.</p> 조언 AI는 변화가 빨라서 몇 개월만 지나도 지식이 outdated됨</li> 학습 모드(Study Mode) 등 LLM이 제공하는 새로운 기능들을 시도해봐야 함</li> 여전히 가장 중요한 인사이트(고객, 지식)는 사람으로부터 나온다</li> AI 관련 무료 공식 자료가 풍부함: Anthropic Prompt Engineering</a>, Google Prompt Engineering</a>, OpenAI Prompt Engineering Guide</a>, Anthropic Courses</a>, deeplearning.ai</a> (메모: 요즘엔 Vercel의 React 프롬프트, Supabase의 PostgreSQL 프롬프트 같이 프롬프트 공유도 많이 하는 듯)</li> </ul> </li> </ul> </li> 코딩 관점 What + Why를 효과적으로 주는 프롬프팅: STICC</a></li> 여전히 일부 분야에서 How가 필요: CTA(Cognitive Task Analysis, 인지 작업 분석)필요. AI와 반복적인 학습을 통한 이해. AI가 메타 평가.</li> MCP는 다양한 기능이 있지만 대부분 툴 기능만 사용됨, 켰다 껐다 가능하므로 필요할때만 써서 토큰 아끼기</li> 정적 타입 검사, 린터 등 Validator 활용하기, AI보다 정확함: AI 시대의 소스코드 품질</a></li> 디버깅 마인드셋</a>, 인프콘 2014 발표</a></li> Kent Beck의 TDD와 AI 관련 내용: XP, TDD, 그리고 바이브 코딩: Kent Beck의 Programmatic Engineer 인터뷰 일부 번역</a></li> </ul> </li> 제품 개발 관점 문제 정의(누구를 위해, 왜, 무엇을)에서부터 시작함</li> LLM/에이전트가 항상 정답은 아님: 비용을 지불하는 건 문제 해결이지 AI 자체가 아님</li> 미국 VC가 언급한 지금 AI로 창업하기 어려운 분야들</a></li> MVP, MMP, MLP 개념과 올바른 이해: MVP, MMP, MLP, MDP, MAP 스타트업 단계 가이드 : r/startups</a>, MVP, MMP or MLP. What's best?</a>, MVP에 대한 정확한 해석에 대한 의견</a></li> </ul> </li> </ul> 그 외</h3> 시궁쥐(Rat)에게 DOOM 학습시키기</a></strong>: 그냥 순수하게 재미있는 프로젝트. 지금도 진행중인 듯</a>하다.</li> AWS ECS의 리버스 프록시 사이드카 패턴 \| Containers on AWS</a></strong>: AWS 직원들이 운영중인 비공식 블로그의 글. 가끔 보이는 패턴인데 명확한 이유를 찾기 어려워 궁금했던 내용. 주요 이점은 작업 분담(압축), 효율적인 트래픽 처리이다.</li> 오픈 소스 어플리케이션의 아키텍쳐 \| GeekNews</a></strong>: 인사이트 출판사에서 1권 번역본을 샀었는데, 원서</a>는 무료로 공개되어 있다. 많은 오픈소스 프로젝트의 핵심 기여자들이 프로젝트의 설계 철학을 말해준다.</li> Tokio와 Compio의 차이 - 비동기 모델 비교 \| Reddit</a></strong>: epoll vs io_uring 기반 비동기 런타임의 차이점. IGGY의 주요 개발자가 답글을 달았는데 쉽게 설명해준다.</li> 태그로 돌아본 웹의 30년 \| GeekNews</strong></a>: 웹 생태계의 진화 과정을 다룬 글. 프론트엔드뿐 아니라 백엔드 개발자도 알면 유익한 내용. 관련 글: JavaScript의 간략한 역사 \| GeekNews</a></li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>RDB 기반 큐를 사용해보기</h3> DB의 작업 성공과 함께 사이드이펙트나 추가 처리(알림, 비동기 처리)가 필요한 경우, MQ가 유용하다. 하지만 당장 고트래픽 처리와 확장성이 필요 없다면 DB 기반 스케줄러를 쓰는 게 더 좋다. (90% 이상의 경우 여기에 해당할 것이다.)</p> 회사에서 db-scheduler</a>를 사용하여 별도 인프라 추가 없이 단계별로 복구 가능한 Task를 만들 수 있었고, 기존의 여러 문제를 해결하는 만족스러운 결과를 얻었다. 이에 대한 건 따로 블로그를 써볼 예정이다.</p> 우아한형제들 기술블로그에서도 유사한 패턴을 직접 구현한 사례</a>가 있다. (왜 직접 만들었는지는 모르겠지만)</p> Rust에는 apalis</a>가 제일 유명한 거 같다.</p> 블로그 글 "동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나</a>" 작성</h3> X에서 개발 관련 포스팅을 보면서 시간을 때우곤 하는데, 동기/비동기 관련 사분면이 잘못되었다는 글</a>을 보게 되었다.</p> 명확하게 설명은 못했지만 저런 사분면으로 나눠서 설명하는 것이 뭔가 이상하다는 생각을 가지고 있던 터라, AI를 활용해 여러 자료를 찾아보았다. 이런 사분면 설명은 잘못된 설명이라는 걸 알게 되어 글을 작성했다.</p> 요즘엔 AI를 사용하면 이전에 비해 자료 검색 속도가 말도 안 되게 빨라졌다. 정확한 자료를 빠르게 찾아볼 수 있어서 좋다.</p> 짧은 생각</h2> 근황과 요즘하는 생각</p> 기존에 오픈소스 기여에 관심을 가지고 더 깊이 있는 부분에 참여하고 싶었지만, 아직 많이 부족함을 느끼고 있다. 기초적인 능력 향상에 집중하기 위해 한동안은 쉴 예정이다.</p> AI를 개발과 자료조사에 적극 활용하면서, 공식문서나 개념을 쉽게 풀어쓴 블로그 글을 볼 필요가 없어졌다. 이제는 전문성 있는 글이나 개인적인 시선이 담긴 글 위주로 보고, 나도 그런 글을 쓰려고 하고 있다. (어떻게 보면 AI가 저품질 글을 대체했다고 볼 수 있을까?)</p> [월간 기록] 이전 자료 모음 Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000 월간 기록을 시작했는데, 이전에 정리한 자료 중에서도 좋은게 많다.</p> "월간 기록"이라고 볼 순 없지만 버리기는 아까워, 최근 몇 개월 동안 모아두었던 기록 중에 다시 찾아볼 만한 것들을 정리했다.</p> 수집</h2> 흥미롭거나 유용했던 자료들</p>Computer Networks: A Systems Approach (무료 원서)</a></h3> 나는 한글 번역본을 책으로 가지고 있는데, 영어 원서는 무료로 공개되어 있다. 네트워크를 제대로 공부하고 싶을 때 참고하면 좋을 듯.</p> Interactive SICP JS</a></h3> SICP의 설명을 Scheme 대신 기능이 제한된 JS로 대체한 에디션이다. 인터넷에서 무료로 볼 수 있고 실행 환경을 구축할 필요 없이 웹사이트에서 실습할 수 있다.</p> 원문 또한 검색하면 공식적으로 무료로 풀려있고, 원문과 SICP in JS의 내용을 비교하고 싶다면 여기의 비교판</a>에서 볼 수 있다.</p> SICP(Structure and Interpretation of Computer Programs, 컴퓨터 프로그램의 구조와 해석)는 전 MIT 입문 프로그래밍 교재</a>로, Scheme(Lisp 방언)을 사용해 추상화, 재귀, 데이터 구조, 인터프리터/컴파일러 구현 등 컴퓨팅의 본질적 개념을 다룬다.</p> </blockquote> 나는 특히 3장에서 substitution model에서 environment model로 전환하는 것과 4장에서 겉보기에는 동일한 언어라도 평가 전략이나 실행 모델과 같은 구현 선택에 따라 동작이 달라질 수 있다는 점이 인상 깊었다.</p> Cloudflare 한국에서의 망 연동 문제</h3> Cloudflare는 망 사용료로 인한 비용 문제로 CDN 사용 시 국외의 노드와 연결된다. 한국에 ICN(인천) 리전이 있지만, Enterprise 플랜을 사용해야만 고정이 가능하다.</p> CDN 뿐만 아니라 R2나 다른 기능들에서도 한국 리전이 사용되지 않는 듯 하나 확실하진 않다.</p> 이에 대한 공식적인 내용을 찾아보기는 어렵지만, 사실 상 망 사용료로 인한 문제임이 확실한 것 같다.</p> 클라우드플레어 임원 "한국 망 사용료가 비슷하다고? 20배 이상 비싸"</a></li> 관련 블로그 글</a></li> 나무위키</a>, 가온위키(처음 보는 위키인데 내용이 많아서 링크)</a></li> </ul> SQL과 관계형 모델</a></h3> 관계형 모델의 이론과 RDB를 연관지어 설명한다.</p> 실제 DM 사용 경험이 적다곤 하지만, 이런 관점의 글은 본 적 없고 인상깊었다.</p> 아마 블로그 글 저자가 컴파일러나 언어학에 관심이 있어서 이런 관점의 글이 나온거 같음.</p> 템플릿 콜백 패턴과 스프링 트랜잭션 관리 방법</a></h3> 고등학교 후배의 포트폴리오 프로젝트 코드를 보다가 궁금해져서 찾아본 내용. 라이브러리 사용자가 Context를 알지 않아도 실행 가능하게 하는 편리한 패턴이라고 생각된다.</p> 전역이 아닌 별도의 생명 주기를 가지는 Context는 어떤 식으로 관리되는지 생각해볼 수 있었다.</p> $5짜리 프롬프트로 $2,418짜리 취약점 찾은 썰</a> \| GeekNews</a></h3> 내용이 좋다. 실제로 LLM을 사용한 긍정적이고 효과적인 방법이라고 볼 수 있을 듯. 오픈소스 기여나 학습 측면에서 이런 시도가 나오고 있다는건 좋은 것 같다.</p> 하지만 이와 반대로 LLM이 오픈소스 생태계 유지에 악영향을 줄 수 있을 것 같아 걱정이다. FFmpeg, cURL, Spring</a> 같은 여러 오픈소스에서도 AI Slop이 많아져 불만을 표하는 글을 보기도 했고.</p> SQLite 창시자가 제안한 "CRLF 그만 보내기" 선언 (그리고 철회)</a> \| HackerNews</a></h3> 이런 역사적 잔재는 생각보다 많다. tty, base64 등. 지금 당연하게 쓰는 관행이 사실은 수십 년 전 하드웨어 제약의 흔적인 경우가 많다.</p> SQLite 창시자 Richard Hipp이 "이제 CR은 그만 보내자"는 선언문을 작성했다가 철회했다. 주장이 과격했고, 호환성 문제가 있었기 떄문이다. 실제로 SQLite 관련 코드를 수정했다가 다른 서비스나 언어 구현에서 처리가 안 되어 깨지는 사례가 발생했다.</p> 그럼에도 HN 토론에서 많이 언급됐듯이, 이런 레거시는 언젠가 정리해야 한다는 의견에 동의한다.</p> Railway Oriented Programming (ROP)</h3> Railway Oriented Programming (ROP)</a> Railway Oriented Programming이란? (Medium)</a></p> Rust의 Result</code>, Kotlin의 Result</code> 도 이 패턴을 사용한다. try-catch와 달리 예외 흐름을 선형적으로 처리할 수 있다.</p> Spring 트랜잭션 같은 기존 패턴과는 잘 맞지 않아서 실무에서 자주 쓰진 않았다. 실패 경로를 명시적으로 다뤄야 할 때 써본 적은 있지만, 돌이켜보면 크고 복잡한 코드의 레거시를 갈아엎지 못하던 상황에서 나온 코드였다.</p> ROP 자체는 좋다고 생각하지만, JVM 생태계는 프레임워크/라이브러리가 예외 기반이라, 제한된 영역이 아니라면 ROP 스타일이 잘 맞지 않아 보인다.</p> 좋은 디자인이란? - 게슈탈트와 밀도로 알아보기</h3> 색이나 예쁜 걸 말하는 게 아니라 레이아웃이나 어떻게 정보를 전달할 것인가를 다루는 내용들.</p> UI Density (Matthew Ström)</a></li> HackerNews 토론</a></li> 게슈탈트 심리학과 UI</a></li> </ul> 레이아웃을 잘 꾸미고, 서비스 특성에 따라 밀도를 조절하기</p> Frameworkless Frontend Development 스터디</a></h3> 프레임워크 없이 프론트엔드 개발하기. 내용은 괜찮은데 책으로 보면 불편할 듯. 블로그로 원서를 찾아보거나 직접 구현 분석하는 게 더 나을 것 같다.</p> 원본 코드 (GitHub)</a></p> (아래 작업 파트에 누가 스터디한 레포 포크해서 개인적으로 정리한 레포를 적어둠.)</p> 최적화를 위한 알고리즘</a></h3> GeekNews</a></li> Jupyter Notebook 버전</a></li> </ul> 최적화 문제를 다루는 알고리즘 책. 무료로 공개되어 있고, Julia 언어로 구현되어 있다. (Julia</a> 나무위키)</p> 다만 이런 의견도 있음을 주의하고 보기.</p> 책에 Firefly, Cuckoo Search 같은 메타휴리스틱이 포함된 걸 보고 놀람. 이 알고리즘들은 학계에서 신뢰받지 못하고, ITOR 논문에서도 비판받았음</p> </blockquote> Top GitHub Users in South Korea</a></h3> 깃헙 유저들 나라 별 기여/팔로워 순 순위를 모아놓은 레포에서 한국인끼리 모아둔 페이지.</p> 내리다 보면 아는 사람이나 유명한 블로그 쓰는 사람들이 종종 보인다.</p> 내 계정도 있는데, 팔로워, 기여 수 조건이 있어 아슬아슬하게 들어가있다. 기여는 학교에서 안 공개 프로젝트 덕에 높게 나오는거 같다.</p> OOP의 35년 실수 - Casey Muratori 발표영상 In BSC 2025</a></h3> Claude AI 요약</a></p> Casey Muratori가 OOP의 구조적 문제점을 지적한 강연. 논쟁적이지만 생각해볼 거리를 많이 던져준다.</p> ECS, Fat Struct 같은 패턴이 이전부터 있었고, 특정 상황에서는 이게 더 적절하다는 것.</p> 현재의 OOP가 범용 대규모 프로그래밍에 유리하다는 인식과 달리 초기에는 제한된 도메인(분산 시스템)의 소규모 팀에서 탄생한 개념이라는게 인상깊었음.</p> 선언적 프로그래밍에 대한 착각과 오해</a></h3> 선언형 프로그래밍이 무엇인지, 왜 오해받는지에 대한 깊이 있는 분석.</p> What Every Programmer Should Know About Memory</a></h3> 공식 PDF (114페이지)</a></li> 구글 검색하기</a></li> </ul> 메모리 계층 구조, 캐시, NUMA 등 하드웨어 수준의 메모리 동작 원리를 다룬 유명한 글. 114페이지의 방대한 분량이라 모든 내용을 알아야 하는 건 아니라는 주장이 HN에서 꾸준히 나온다. (오래된 글이라 그런지 인용이 너무 많이 되서 해커뉴스 링크들를 주기보다는 그냥 구글에 검색하는게 나을 정도) 그럼에도 일부 핵심 개념은 성능 최적화를 할 때 중요하므로, 필요할 때 참고하면 좋을 듯.</p> Thread dump — the simple tool for debugging Java-applications in production \| by Gustav Karlsson</a></h3> 프로덕션 환경에서 Java 애플리케이션의 성능 문제나 데드락을 진단하는 실용적인 방법. Thread dump를 어떻게 수집하고 분석하는지 단계별로 설명한다.</p> 내가 만든 방어 유틸 함수 5종 세트 \| 포프머신</a></h3> 서버에서 유용한 커스텀 Assert 함수 패턴. 로깅, 슬랙 알림, 에러 로그, 심지어 사이렌 등으로 알리고, 중요도에 따라 다르게 구성한다.</p> 코드로써 의미가 명확하고 가독성이 좋다. 테스트까진 아니지만 효율적이고 그에 준하는 효과 (가정이 깨지는 순간 파악, 의도적인 범위/제한 명시)를 가진다.</p> 좋아보인다. 도입해볼만한 가치가 있을 듯.</p> Reflections on Trusting Trust - Ken Thompson</a></h3> 한국어 AI 번역 (Gist)</a></p> Ken Thompson의 유명한 튜링상 수상 강연. 컴파일러에 백도어를 심어도 소스 코드 검사만으로는 발견할 수 없다는 걸 보여준 논문."신뢰를 어디까지 확장할 수 있는가?"라는 근본적인 보안 질문을 던진다.</p> The Surprising Truth About Pixels and Accessibility</a></h3> px, em, rem 단위를 언제 어떻게 사용해야 하는지에 대한 실용적인 가이드. 특히 사용자의 접근성 관점에서 설명함.</p> 대부분 상황: rem. 사용자 기본 폰트 크기 설정(=사용자가 의도한 크기)에 따라 크기가 바뀌기 떄문</li> 부모/자신의 font-size에 비례해야 할 때: em</li> 고정된 크기: px</li> </ul> You no longer need JavaScript</a> \| HackerNews</a></h3> 현대 CSS와 HTML만으로 대부분의 웹 기능을 구현할 수 있다는 점을 보여주는 글.</p> 지금 이 글을 보여주는 개인 블로그를 만들 때 사용한 css 작성 스타일에도 영향을 주었다.</p> Hypermedia Systems</a></h3> htmx 제작자 Carson Gross가 쓴 책이다. REST 아키텍처의 원래 의도를 설명하고, SPA 프레임워크 없이 hypermedia(HTML) 기반으로 웹 애플리케이션을 구축하는 방법을 다룬다.</p> 무료로 온라인에서 읽을 수 있다.</p> 추가: Single HTML로 만드는 코드 - Gist</a></p> 관련해서 잘 정리된 글: 웹은 왜 복잡해졌나? -모던 웹의 복잡성과 하이퍼미디어 시스템</a></p> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들</p>네트워크에서 MAC과 IP가 분리된 이유</h3> "Rust in Action" p.345를 보고 궁금해져서 찾아본 내용.</p> IP와 MAC은 다른 용도를 가지고 서로 다른 단체에 의해 다른 연도에 만들어졌다:</p> MAC: LAN 내부 하드웨어의 통신용</li> IP: 네트워크 간 통신용, 먼저 만들어졌다.</li> </ul> 두 가지를 연결하기 위해 ARP가 등장했다. 참고로 MAC과 IP가 항상 같이 쓰이는 건 아니다. (MAC 주소 개념을 사용하지 않거나, IP 주소 ↔ 링크 주소 매핑이 다른 방식으로 처리되는 경우도 있음)</p> Perplexity 검색 결과</a></li> 정리 Gist</a></li> </ul> Frameworkless Frontend Development 구현 연습</a></h3> 원본 스터디 레포</a>를 fork해서 직접 구현해본 프로젝트. 프레임워크 없이 순수 JavaScript로 프론트엔드 애플리케이션을 만들면서 라우팅, 상태 관리, 컴포넌트 시스템 등의 기본 원리를 학습했다.</p> 프레임워크가 내부적으로 어떻게 동작하는지 이해하고, 실제로 직접 구현해보면서 웹 플랫폼의 기초를 다질 수 있었다.</p> CHIP-8 에뮬레이터 (C 언어)</a></h3> C 언어로 CHIP-8 에뮬레이터를 구현한 프로젝트.</p> CPU 명령어 해석, 메모리 관리를 직접 만들면서 이해할 수 있었음.</p> awesome-for-me</a></h3> 개인적으로 유용하다고 생각하는 자료들을 정리한 저장소.</p> 지금은 개인 디스코드나 월간 기록으로 자료 관리 방식을 바꿔서 더 이상 업데이트하지는 않고 있음.</p> [월간 기록] 시리즈 소개 Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000 평소 관심 가는 여러 자료를 수집하고 학습하는데, 관심사가 자주 바뀌다 보니 시간이 지나면 흩어지거나 까먹곤 한다.</p> 자잘한 활동을 기록하고 공유도 할 겸 유용한 자료, 회고, 일상, 학습 기록 등을 한곳에 남겨두는 "월간 기록" 시리즈를 만들었다.</p> 포맷</h2> 매달 마지막 날을 기준으로 업로드하며, 다음과 같은 구성으로 이루어진다.</p> 수집</strong>: 그 달에 발견한 흥미롭거나 유용했던 자료들</li> 작업</strong>: 학습, 개발, 실험 등 직접 손댄 것들</li> 짧은 생각</strong>: 근황과 요즘 하는 생각</li> </ul> 내부 형식은 자유롭게 작성한다.</p> 목적</h2> 월간 기록을 시작한 이유는 활동 기록도 있지만, 자료 선별 목적도 있다.</p> 개인 디스코드 채널에 자료를 모아왔는데, 정리되어있지 않은데다가 3년이 넘으니 찾기 어려워졌다. 그래서 수집 방식은 유지하되, 월말에 참고할 만한 것만 선별해 따로 기록하기로 했다.</p> 동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나 Sijun Yang — Thu, 11 Dec 2025 00:00:00 +0000 여러 개발 관련 글에서 Blocking/Non-blocking과 Sync/Async를 설명할 때면 항상 등장하는 2x2 매트릭스가 있다. 4개의 조합으로 나누어 설명하는 이 표를 한 번쯤은 보았을 것이다.</p> </p> 이 매트릭스에서 가장 이해하기 어려운 부분은 Blocking + Async 조합이다. 많은 블로그에서 이 조합을 설명하려고 시도하지만, 나는 대부분 억지스러운 설명이라는 인상을 받았다.</p> 최근 이 개념을 다시 공부하다가 이러한 설명은 올바르지 않다는 사실을 알게 되었다. 우리가 그동안 별 의심없이 받아들였던 이 설명이 잘못된 이유를 말해보고자 한다.</p> 잘못된 설명의 출처</h2> 이러한 매트릭스 기반의 설명의 시작은 IBM Developer의 2006년 글 "Boost application performance using asynchronous I/O"인 것으로 보인다.1</a></sup></p> </p> IBM의 글은 리눅스 커널의 AIO(Asynchronous I/O) API를 소개하면서 sync/async와 blocking/non-blocking을 조합해 4가지로 구분했다.</p> 그러나 이 글의 구분은 POSIX 표준 정의와는 다르다. 이 글에선 select</code>/poll</code>를 blocking + async의 조합으로 소개하지만, POSIX 표준 정의에는 이런 조합이 등장할 수 없다.</p> IBM의 글은 리눅스 커널의 AIO API를 소개하는 글이다. 리눅스 커널은 POSIX 표준을 구현하므로, 커널 레벨 I/O를 논한다면 POSIX 정의와 일관되어야 한다. 그러나 IBM의 분류는 POSIX 표준과 일치하지 않는다.</p> POSIX 표준의 실제 정의</h2> POSIX 표준2</a></sup>3</a></sup>과 리처드 스티븐스(W. Richard Stevens)의 책 Unix Network Programming4</a></sup>을 살펴보면 명확한 정의를 찾을 수 있다.</p> Synchronous I/O: I/O 작업이 완료될 때까지 요청 프로세스가 blocked</li> Asynchronous I/O: 요청 프로세스가 blocked되지 않음</li> Blocking: 요청한 동작이 완료될 때까지 함수 호출이 대기</li> Non-blocking: 요청한 동작을 즉시 완료할 수 없으면 지연 없이 반환</li> </ul> 여기서 중요한 점은 I/O 작업 완료의 의미다.</p> Unix I/O 모델의 두 단계</h2> I/O 작업은 일반적으로 두 단계로 이루어진다:</p> 데이터 준비 단계 - 디스크에서 데이터를 읽거나 네트워크에서 패킷이 도착하기를 기다린다. 데이터가 준비되면 커널 버퍼로 복사된다.</li> 데이터 복사 단계 - 커널 버퍼에서 애플리케이션 버퍼로 데이터를 복사한다.</li> </ol> 스티븐스는 Unix에서 사용 가능한 5가지 I/O 모델을 다음과 같이 구분한다. 이 모델은 커널이 I/O 준비와 수행을 어떻게 관여하느냐에 따른 대표적인 분류이다. 상호 배타적인 조합표를 의미하지 않는다.5</a></sup></p> 1. Blocking I/O</h3> </p> 가장 흔한 I/O 모델이다. read()</code> 시스템 콜을 호출하면 데이터가 준비되고 복사가 완료될 때까지 프로세스가 block된다.</p> 2. Non-blocking I/O</h3> </p> O_NONBLOCK</code> 플래그를 설정하면 데이터가 준비되지 않았을 때 EAGAIN</code> 에러와 함께 즉시 반환한다. 하지만 데이터가 준비되면 복사하는 동안은 여전히 block된다.</p> 3. I/O Multiplexing</h3> </p> select()</code>나 poll()</code>을 사용해 여러 file descriptor를 동시에 감시한다. 준비된 fd에 대해 read()</code>를 호출할 때 여전히 block된다.</p> 4. Signal-Driven I/O</h3> </p> SIGIO</code> 신호를 등록하고 데이터가 준비되면 신호를 받는다. 신호를 받은 후 read()</code>를 호출하면 여전히 block된다.</p> 5. Asynchronous I/O</h3> </p> 진정한 비동기 I/O다. aio_read()</code>6</a></sup>는 즉시 반환되고, 커널이 백그라운드에서 두 단계를 모두 처리한 후 완료를 통지한다.</p> Synchronous vs Asynchronous의 핵심</h2> </p> 스티븐스는 Unix Network Programming에서 이 모델들의 동기/비동기 여부를 명확하게 구분한다.</p> POSIX defines these two terms as follows:</p> 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.</p> </blockquote> 다음과 같이 번역할 수 있다.</p> POSIX는 이 두 용어를 다음과 같이 정의한다:</p> 동기 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에 해당한다.</p> </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되지 않는다.</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>에 있는 강의를 함께 들어가면서 진행했다. (강의는 유튜브로도 공개되어 있다.</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>

C에서의 자료구조 라이브러리 구현 알아보기

Sijun Yang — Tue, 07 Apr 2026 00:00:00 +0000

항상 궁금했던 게, C에서는 data structures(자료구조들)를 메모리에서 어떻게 관리하는지임.

크게 2가지인데, element(원소)의 관리와 data structure 자체의 관리임.

암튼 그걸 위해서 C의 참고용으로 쓸 만한 자료구조 라이브러리들을 찾아봤는데, 일단은 이것들로 찾아볼 듯? (+ 그리고 이해를 돕기 위한 Rust와의 비교)

glib</a> - docs</a></li>
c-algorithms</a></li>
Collections-C</a></li> </ul>
element와 data structure의 메모리 관리</h2>
element의 메모리 관리</h3>
문제</h4>
Rust와 비교하면 이해하기 좋을 거 같은데, Rust의 소유권을 대충이나마 알고 나서 C의 메모리 관리를 어떤 식으로 하는 게 (일반적으로) 좋은지 좀 더 이해하게 되긴 했는데
그래도 여전히 이해가 안 되는 게 있다면, element의 관리임. Rust야 소유권이 넘어가지만, C는 언어 차원에서 소유권 개념이 없으니 호출자와 data structure 자체 중 누가 관리하는지 정해야 하는데, 이게 어떻게 되는 건지?
예로 들어 특정 함수 내부에서 배열을 받아서 특정 인덱스의 element를 Rust처럼 “빌린다/넘긴다”로 구분해서 처리하는 게 아니라, C에서는 그냥 값이나 포인터를 다루는 것뿐이라 그 포인터가 가리키는 대상의 수명과 해제 책임이 코드만 보고는 바로 드러나지 않는다. 그래서 이게 빌리는 건지, 넘기는 건지, 지우는 건지도 명시가 없으면 되게 애매해지는 거 같음.
조사</h4>
AI와 실제 공식문서, 코드 약간 참고(전부는 아님)
C 범용 자료구조 라이브러리의 container 특징

pointer container(포인터 저장형 컨테이너), 기본 non-owning

포인터만 저장</li>
pointee(포인터가 가리키는 대상) 자체의 해제는 보통 호출자가 직접 관리</li> </ul> </li>
pointer container + destroy callback

여전히 Rust처럼 언어 차원의 ownership은 아님</li>
일부 라이브러리/data structure는 element 제거 또는 data structure 파괴 시 호출할 destroy callback을 지원</li>
개별 element에 연결된 정리 동작을 data structure 동작에 연결하는 방식</li> </ul> </li>
pointer container + free-all 계열 API

일부 라이브러리/data structure는 callback 대신</li>
destroy_free</code>, remove_all_free</code> 같은 식으로 전체 정리 시 포인터가 가리키는 대상까지 한꺼번에 free하는 API를 제공</li>
보통 개별 element 제거 시마다 자동으로 동작하는 방식과는 구분됨 (callback과 free-all 둘 다 제공할 수도 있음)</li> </ul> </li>
value-copy container(값 복사 저장형 컨테이너) 값을 복사해서 저장</li> 이 경우 container는 “복사해 둔 value(값)”의 storage(저장소)는 관리하지만, 그 값 안에 포인터가 있으면 그 내부까지 자동으로 관리하는 건 아님</li> 따라서 포인터 대상의 수명까지 포함한 deep copy/deep free 여부를 별도로 봐야 함</li> </ul> </li> </ol> 실제 라이브러리 기준으로 GLib GArray</code>: 값 저장형</li> GPtrArray</code>: 포인터 저장형, destroy callback을 붙여서 element 제거/파괴 시 정리 동작을 연결 가능</li> GList</code> / GQueue</code>: 기본적으로 data 포인터 저장형</li> GHashTable</code>: 기본 삽입은 복사 아님, 수명 관리를 사용자가 의식해야 함. 대신 key/value destroy function을 지정할 수 있음</li> </ul> </li> c-algorithms 공식문서</a>에서 모두 void *</code> 기반 포인터 저장형 container이라고 말함.</li> 일부 data structure는 free callback 등록으로 정리 동작을 연결 가능</li> </ul> </li> Collections-C pointer container와 value-copy 성격의 sized container가 분리</li> pointer container 쪽은 destroy_free</code>, remove_all_free</code> 같은 free-all 계열 API 제공</li> </ul> </li> </ol> 정리</h4> 정리해보자면 value-copy container의 경우 container가 자기 내부에 복사해 둔 value의 storage를 관리한다. 다만 이걸 Rust 식으로 “소유권이 container에게 있다”라고 그대로 말하면 약간 오해의 소지가 있는데, C에는 그런 언어 차원의 개념이 없고, 그냥 container가 복사본을 보관하고 그 복사본의 수명을 관리한다고 보는 편이 더 정확함. 그래서 이런 container는 포인터가 아닌 값 자체를 저장할 때 쓰는 경우가 자연스럽다. 따라서 container에서 element를 제거할 때는 그 복사되어 저장된 value가 들어 있던 slot(슬롯)이 자연스럽게 정리된다. C에서 stored value가 pointer인 경우, 처리가 더 까다로운데, Rust와 다르게 함수/타입 시스템 차원에서 ownership에 따라 다르게 처리해주지 않으므로, 필요에 따라 직접 free를 호출해야 함. 그렇지 않으면 메모리 누수가 발생할 수 있음. Rust와 달리 ownership 개념이 없으므로, element를 가져와 data structure에선 삭제하고 free하지 않고 남기는 경우도 있을 거라서 그럼. 따라서 이걸 포인터가 가리키는 대상의 메모리까지 해제하는 건지 아니면 그냥 빼오기만 하는 건지는 API 문서나 함수 의미로 직접 정해져 있어야 하고, 사용자가 그걸 의식하고 써야 함. 대신 remove나 replace가 많이 발생하는 data structure의 경우 (정확히는 data structure 조작이 일어날 때, 그 element가 가리키는 대상의 메모리도 같이 정리되어야 하는 상황)에서, 사용자의 실수 방지나 편의성 처리를 위해 destroy callback을 지원한다. 대표적으로 GLib의 GPtrArray</code>와 GHashTable</code>이 있다. data structure의 메모리 관리</h3> 문제</h4> 이제 element의 메모리 관리는 대충 이해했는데, data structure의 메모리 관리는 여전히 잘 모르겠음. contiguous memory(연속 메모리)를 사용하는 배열 기반 data structure는 비교적 이해하기 쉽다. 보통 size</code>와 capacity</code>를 기준으로 현재 사용 중인 element 수와 확보된 buffer(버퍼) 크기를 구분하면 되기 때문이다. 그런데 트리나 hash table처럼, 내부적으로 하나의 연속 buffer만으로 표현되지 않는 data structure는 이야기가 조금 다르다. 이런 구조는 node(노드), bucket(버킷), 보조 배열 같은 여러 단위의 메모리를 따로 관리해야 할 것 같은데, 실제로는 어떤 식으로 할당과 해제가 이루어지는지 잘 감이 오지 않았다. 매 삽입/삭제마다 node를 위한 메모리의 할당과 해제를 반복하는 건가? 아니면 일정한 관리 단위가 따로 있는 건가? 뭐 근데 생각해보면 같은 역할이어도 구현체마다 다를 수 있을거 같긴함. GC가 있으면 그냥 unreachable memory면 상관없는데, C는 포인터 연산에 주소 이동까지 가능해서 rc 기반의 커스텀 GC를 만들어서 추가할수도 없고, (제한된 범용 사용을 강제하면 될수도?) 그래서 이게 어떻게 관리되는가... 조사</h4> AI와 실제 공식문서, 코드 약간 참고(전부는 아님) C 범용 자료구조 라이브러리의 data structure 내부 메모리 관리 방식 contiguous buffer 기반 내부에 연속 메모리 buffer를 하나 두고 관리</li> 보통 size</code>, capacity</code> 개념이 있음</li> 배열 기반 data structure가 대표적임</li> </ul> </li> node 기반 element 하나당 node 하나를 두는 방식</li> 삽입 시 node 단위로 할당, 삭제 시 node 단위로 해제</li> linked list, tree 같은 구조가 여기에 해당</li> </ul> </li> buffer + node 혼합형 내부에 bucket/slot 배열 같은 연속 메모리를 두면서도</li> 구현 방식에 따라 별도 entry(엔트리)/node를 함께 관리할 수 있음</li> hash table이 대표적임</li> </ul> </li> custom allocator / memory pool 사용 가능 무조건 일반 malloc/free</code>만 쓰는 건 아님</li> 라이브러리에 따라 allocator를 교체하거나 pool을 붙일 수 있음</li> Collections-C는 memory pool을 별도 기능으로 제공하고, list 같은 data structure의 allocator를 pool allocator로 바꾸는 예제도 README에 있다.</li> </ul> </li> </ol> 자료구조별로 보면 배열 기반 data structure 비교적 단순함</li> 내부 buffer를 들고 있다가 capacity가 부족하면 재할당</li> value-copy / pointer container 둘 다 제공하는 경우 많음</li> </ul> </li> linked list 비연속 메모리 기반이지만 구조 자체는 비교적 단순한 편</li> list 본체와 각 node가 분리되어 있고</li> 삽입/삭제 시 node 단위 할당/해제가 일어남</li> 다만 저장되는 payload 자체는 보통 포인터라서, 메모리 배치 기준으로는 node 기반이고, element 저장 방식 기준으로는 pointer container인 경우가 많음</li> </ul> </li> tree 이것도 node 기반 (node 단위 할당/해제)</li> linked list보다 삭제/재연결 쪽이 더 복잡함</li> 저장 방식 기준으로는 key/value를 void *</code>나 포인터로 다루는 pointer container 계열이 많음</li> </ul> </li> hash table 구현에 따라 차이가 큼</li> open addressing이면 slot 배열 같은 연속 메모리 중심으로 관리할 수 있음</li> chaining이면 bucket 배열 + 체인용 node 구조가 섞일 수 있음</li> 따라서 내부 메모리 관리 기준으로는 contiguous buffer 성격과 node 성격이 섞일 수 있고, element 저장 방식 기준으로는 보통 key/value 포인터를 저장하는 pointer container에 가깝다</li> </ul> </li> </ol> 실제 non-contiguous / node 기반 자료구조를 라이브러리별로 보면 GLib GSList</code> / GList</code> / GQueue</code>: list 계열이고, data 포인터를 저장하므로 node 기반 + pointer container</li> GTree</code>: balanced tree 기반의 key/value container라서 node 기반 + pointer container</li> GHashTable</code>: key/value를 복사하지 않으므로 API 기준으로는 pointer container. 다만 내부 구현까지 단순 node 기반이라고 하긴 애매함</li> </ul> </li> c-algorithms 라이브러리 전반이 void *</code> 기반이라 모두 pointer container</li> list.h</code> / slist.h</code>: node 기반 + pointer container</li> avl-tree.h</code>: node 기반 + pointer container</li> hash-table.h</code>: key/value가 void *</code>이고 free function 등록도 가능해서, pointer container + free callback 연결 가능</li> </ul> </li> Collections-C README에서 pointer container와 sized container를 분리함</li> CC_List</code>, CC_SList</code>, CC_HashTable</code>, CC_TreeTable</code> 등은 pointer container</li> 이 중 리스트/트리 계열은 자연스럽게 node 기반 + pointer container로 볼 수 있음</li> </ul> </li> </ol> 대충 보면 - (사실 상 다 pointer container라고 봄.) non-contiguous / node 기반 자료구조는 대부분 pointer container GLib의 GList</code>, GSList</code>, GTree</code></li> c-algorithms의 linked list, AVL tree</li> Collections-C의 CC_List</code>, CC_SList</code>, CC_TreeTable</code></li> </ul> </li> value-copy container는 주로 contiguous array 쪽에 몰려 있음 GLib의 GArray</code></li> Collections-C의 CC_ArraySized</code></li> </ul> </li> hash table은 내부 메모리 관리 방식은 구현 따라 달라도, 외부 API 기준으로는 대체로 pointer container key/value를 복사하지 않고 포인터나 void *</code>를 저장하는 경우가 많음</li> 대신 destroy/free callback이나 free-all 계열 API를 붙여서 element 정리를 연결하는 방식이 흔함.</li> </ul> </li> </ol> 정리</h4> 대충 보면 contiguous 쪽은 value-copy / pointer container 둘 다 만들기 쉬운 반면, non-contiguous / node 기반 자료구조는 범용 라이브러리에서 대부분 pointer container로 제공된다. 이게 불가능해서라기보다는, generic C 라이브러리에서 value-copy 방식으로 만들었을 때 애매한 점이 많기 때문인 듯함. 삽입/삭제 자체만 보면 node 기반도 value-copy가 불가능한 건 아니다. node마다 값을 직접 넣고, 삽입 시 복사하고, 삭제 시 그 node를 해제하면 되니까 구현 자체는 가능함. 그리고 한 번 들어간 뒤의 재연결이나 이동은 보통 node 포인터만 바꾸면 되므로, 그 과정에서 값 복사가 계속 일어나는 것도 아님. 근데 조회와 반환 쪽에서 문제가 있다. contiguous 쪽은 내부가 연속된 buffer라서 특정 위치만 알면 곧바로 접근할 수 있다. 즉 value-copy를 하더라도 “연속된 저장소에 값을 복사해 넣고, offset으로 다시 접근한다”는 모델이 비교적 단순하다. 반면 non-contiguous / node 기반은 node 안에 값을 직접 저장한다고 해도, 그 값을 사용자에게 어떻게 돌려줄지가 애매하다. 포인터로 넘겨주기 node 내부 값의 주소를 넘겨주면 되긴 함</li> 근데 그러면 결국 사용자 입장에서는 포인터를 받아 쓰게 되므로, pointer container와 체감상 큰 차이가 줄어듦</li> </ul> </li> 값을 복사해서 넘겨주기 shallow copy면 값 안에 포인터가 있을 때 문제가 그대로 남음</li> deep copy면 복사 비용, 버퍼 관리, 타입별 정책 문제가 생김</li> </ul> </li> </ol> 즉 node 기반 value-copy container의 핵심 문제는 “삽입이 어렵다”가 아니라, generic한 조회/반환 API를 깔끔하게 만들기 어렵다는 쪽에 더 가까움. 게다가 non-contiguous / node 기반 자료구조는 원래도 node마다 포인터 필드 같은 오버헤드가 붙고, allocation/free가 자주 일어나고, cache locality도 좋지 않은 편이다. 그런데 여기에 value-copy 기반 API까지 얹으면 복사/반환 규칙까지 더 복잡해진다. (반대로 GArray</code>는 반환에서 memcpy같은 복사가 일어나지만, capacity가 충분하면 추가에서 할당이 일어나지 않고 매모리와 캐시 효율이 좋다.) 반면 void *</code>를 저장하는 pointer container는 구현도 단순하고, list / tree / hash table 전반에 공통적으로 적용하기도 쉽다. 그래서 node 기반 data structure에서도 value-copy 방식 자체는 가능하지만, 적어도 범용 C 라이브러리에서는 이런 특별한 사용 예시를 지원하지 않는 것 같다. 아마 그런 이유로 GLib, c-algorithms, Collections-C 같은 라이브러리들도 non-contiguous / node 기반 자료구조는 다 pointer container 쪽으로 제공하는 것 같음. custom allocator / memory pool 을 사용하는 이유</h2> 기본적으로 C 자료구조 구현은 내부 메모리를 malloc/free로 직접 관리하는 경우가 많다. 하지만 자료구조의 특성에 따라 allocation 패턴이 매우 자주 반복되거나, 작은 크기의 메모리를 대량으로 다루게 되면 일반 힙 할당만으로는 비효율적일 수 있다. 이럴 때 custom allocator나 memory pool을 붙여 내부 메모리 관리 방식을 바꾸기도 한다. 대표적으로 linked list, tree, chaining 기반 hash table처럼 node 단위 할당/해제가 자주 발생하는 자료구조에서 의미가 크다. memory pool은 이런 node들을 위해 미리 큰 메모리 덩어리를 확보해 두고, 그 안에서 같은 크기의 node를 재사용하는 방식으로 동작할 수 있다. 이 경우 매번 운영체제/일반 힙에 직접 요청하지 않고 pool 내부에서 빠르게 꺼내고 반납할 수 있다. 간단한 예시 // 이렇게 pool을 미리 할당해서 node 추가/삭제 시 할당이 발생하지 않게 한다. #define POOL_COUNT 1024 typedef struct Node { void *data; struct Node *next; } Node; typedef struct NodePool { Node storage[POOL_COUNT]; Node *free_list; } NodePool;</code></pre> Node 할당 평소: malloc(sizeof(Node))</li> pool 사용: pool_alloc(pool) → pool 안에서 Node 하나 꺼냄</li> </ul> </li> free 평소: free(node)</li> pool 사용: pool_free(pool, node) → OS에 반납 안 하고 pool의 빈 칸 목록으로 되돌림</li> </ul> </li> </ul> 사용 시 장점 작은 객체의 반복 할당/해제 비용 감소 node 기반 자료구조에서는 작은 크기의 allocation이 매우 자주 일어날 수 있다.</li> pool을 쓰면 이런 비용을 줄이기 쉽다.</li> </ul> </li> fragmentation 완화 가능 같은 크기의 node를 반복적으로 관리하면 일반 힙보다 메모리 배치가 단순해질 수 있다.</li> </ul> </li> allocation 패턴 제어 자료구조 내부 메모리를 어떤 방식으로 확보하고 반납할지 구현자가 통제하기 쉬워진다.</li> </ul> </li> 같은 수명의 메모리 묶음 관리 arena/pool 계열 allocator를 쓰면 특정 자료구조 인스턴스와 함께 내부 메모리를 한꺼번에 정리하는 전략도 가능하다. 사용 시 단점</li> </ul> </li> pool 고갈 처리 필요</li> variable-size payload에는 사용 불가능</li> 요소의 free 순서/소유권 문제는 여전함 (메모리풀은 node의 메모리 관리 문제만 보완해줌.)</li> 디버깅이 더 까다로울 수 있음 (실제로는 사용하는 상태라 use-after-free 문제를 OS나 분석 툴이 잡기 어려움)</li> </ol> 대표적인 C 자료구조 라이브러리 코드 분석하기</h2> 편의를 위해 GLib는 Gitlab에서 관리되지만, Github에 있는 미러 레포지토리로 봄. GLib - GArray</code></h3> garray.h</code></a>는 배열 관련 타입을 선언하는데, 헤더에선 최소한으로 노출하고, 실제 구현하는 구조체는 GRealArray</code>, GRealPtrArray</code> 같은 구조체를 쓴다. 여기에는 더 많은 필드가 내부에 들어있음. 예시</a> // garray.h - https://github.com/GNOME/glib/blob/2.88.0/glib/garray.h#L38-L59 struct _GArray { gchar *data; guint len; }; // garray.c - https://github.com/GNOME/glib/blob/2.88.0/glib/garray.c#L52-L73 struct _GRealArray { guint8 *data; guint len; guint elt_capacity; guint elt_size; guint zero_terminated : 1; guint clear : 1; gatomicrefcount ref_count; GDestroyNotify clear_func; };</code></pre> 인덱스 접근인 g_array_index(a,t,i)</code></a>의 경우 매크로로, 내부적으론 일반적인 배열의 접근과 동일하다. 따라서 해당 키워드로 수정과 조회가 다 가능하다. 포인터가 아니므로 변수에 받는 순간 값 복사가 일어난다. 따라서 그 복사본을 수정해도 배열 원본에는 반영되지 않는다. // 정의 #define g_array_index(a,t,i) (((t*) (void *) (a)->data) [(i)]) // 사용 예 Foo x = g_array_index(arr, Foo, 3); g_array_index(arr, Foo, 3) = new_value;</code></pre> 2가지 삭제 연산을 제공하는데, 일반적으론 memmove()</code>로 메모리를 이동함. (예: g_array_remove_index()</code>). g_array_remove_index_fast()</code>는 빠른 삭제로 마지막 원소를 삭제 위치에 memcpy()</code>로 덮어씀. 빠르지만 순서가 바뀜. 그 외에는 append, insert, update 류 연산을 제공하는데, 알고있는것과 크게 다르지 않음. GLib - GPtrArray</code></a></h3> GArray</code>와 유사하지만, 포인터를 저장하기 위한 배열. 포인터를 위한 여러 편의 기능을 제공한다. 말했던 destroy callback 함수 중 하나인 g_ptr_array_set_free_func()</code></a> g_ptr_array_steal()</code>는 노드를 삭제하지만 free callback를 호출하지 않고 호출자에게 포인터의 소유권을 넘긴다. g_ptr_array_new_null_terminated()</code>는ㄴ len과 별개로 끝에 NULL 센티넬을 유지하게 하는 생성자다. 실제로 쓰기 위한 설명은 아니니 이정도로만 찾아봄. GLib - GList</code> or GSList</code></h3> GList</code>는 내부 구조를 숨기지 않고 그대로 사용한다. // glist.h - https://github.com/GNOME/glib/blob/2.88.0/glib/glist.h#L39-L46 struct _GList { gpointer data; GList *next; GList *prev; };</code></pre> 특이한게 len</code>이나 별도 정보를 저장하는 컨테이너가 없고, 노드 하나가 리스트의 일부인 형태다. 다음과 같은 주의사항을 공식문서에서도 명시한다. The doubly-linked list does not keep track of the number of items and does not keep track of both the start and end of the list. If you want fast access to both the start and the end of the list, and/or the number of items in the list, use a GQueue instead. 이중 연결 리스트는 항목의 개수를 저장하지 않으며, 리스트의 시작과 끝 위치도 저장하지 않습니다. 리스트의 시작과 끝 위치, 그리고 항목 개수에 빠르게 접근해야 한다면 GQueue 를 사용하는 것이 좋습니다. Note that most of the GList functions expect to be passed a pointer to the first element in the list. The functions which insert elements return the new start of the list, which may have changed. GList 함수 대부분은 리스트의 첫 번째 요소에 대한 포인터를 인수로 받는다는 점에 유의하십시오. 요소를 삽입하는 함수는 리스트의 새로운 시작 위치를 반환하는데, 이 위치는 변경될 수 있습니다. doubly-linked-lists - 공식문서</a> </blockquote> 따라서 빈 리스트인 경우 NULL</code>이고, 연산의 결과로 head가 바뀔 수 있다. (리스트 구조가 바뀔 수 있는 연산은 대체로 GList *</code>를 반환하고, 그 반환값은 보통 처리 결과 리스트의 head라고 함.) 제거는 2종류인데, g_list_remove_link()</code>는 연결만 끊고 노드는 살려두고, g_list_remove()</code>는 노드까지 해제한다. 단, 둘 다 각 요소 data까지 free하지는 않으므로 직접 처리해야 한다. 노드의 추가/삭제에 따라서 노드의 할당과 해제가 발생하는 걸 볼 수 있다. g_list_append()</code></a>는 매크로나 여러 흐름을 타고 들어가면 최종적으로 g_slice_alloc()</code></a>를 호출한다. g_list_remove()</code></a>는 free 하는 함수를 호출한다. GSList</code>는 Singly Linked List로, 그 외의 특징은 동일하므로 생략. GLib - GHashTable</code></h3> GHashTable</code>는 open addressing 기반으로 구성되어 contiguous한 container(여기선 slot이라고 더 많이 부름)를 가진다. 이런 구조가 가능한 이유는 각 slot이 key/value 객체 본체가 아니라 pointer 표현을 저장하기 때문이다. 따라서 내부 저장소는 고정 크기 slot들의 배열로 관리된다. 즉, GHashTable</code>은 pointer 기반 container이며, key/value가 가리키는 실제 객체의 생명주기는 별도로 관리된다. 필요하면 g_hash_table_new_full()</code> 등으로 destroy callback을 등록해 remove/destroy 시 pointee 정리를 연결할 수 있다. _GHashTable</code></a> 정의를 보면, keys</code>, values</code>, hashes</code> 배열로 구성된다. hashes[i]</code>는 해당 slot의 상태 또는 hash 값(또는 UNUSED/TOMBSTONE 상태)을 저장하고, keys[i]</code>와 values[i]</code>는 그 slot의 key/value 표현을 저장한다. keys/values의 경우 포인터 크기(gpointer</code>)를 가지므로, 포인터 크기 이내의 값은 slot에 직접 저장하는 식으로 최적화 할 수 있다. GINT_TO_POINTER</code></a> 매크로를 사용한다. (이 때는 value에선 값이 저장된다고 볼 수도 있겠다.) 아래는 메모리와 별개지만 내부 해시 충돌 처리 로직이 궁금해서 찾아봄. g_hash_table_lookup_node()</code></a> 위에서 open addressing + tombstone 방식으로 구현되어있다고 말했다. 따라서 probe(충돌로 다음 버킷을 구하는 과정)이 여러 번 발생할 수 있다. 충돌나면 넘기다가 첫 tombstone을 만나면 기록해두고, key에 맞는 node를 못 찾으면 할당한다. UNUSED</code>: 한 번도 안 쓴 빈 칸</li> TOMBSTONE</code>: 예전에 썼다가 삭제된 칸</li> REAL HASH</code>: 현재 원소가 들어 있는 칸</li> </ul> 리사이즈 판단에는 noccupied</code>를 쓰는데, 이는 nnodes</code>(REAL HASH 엔트리 수) + tombstone</code> 수이다. (사이즈 확장 기준은 0.94 이상 일 때인데, Separate Chaining 방식 대비 더 작음. 이건 1 이상도 가능) Collections-C - list</code> / hash table</code></h3> (Glib만 봐도 충분히 공통점이 보여서 다음 내용은 AI 답변을 정리하고 대충 확인만 했다.) Collections-C도 전반적으로 pointer container 중심이다. CC_List</code></a>는 node 기반 리스트이고, CC_HashTable</code></a>도 key/value 포인터를 저장하는 형태라 원소 수명 관리는 호출자가 의식해야 한다. 대신 destroy_free</code>, remove_all_free</code> 같은 free-all 계열 API와 memory pool 활용 여지가 있다. c-algorithms - list</code> / avl</code> / hash</code></h3> (Glib만 봐도 충분히 공통점이 보여서 다음 내용은 AI 답변을 정리하고 대충 확인만 했다.) c-algorithms는 라이브러리 전반이 void *</code> 기반 pointer container다. list</code></a>와 avl</code></a>은 node 기반 자료구조이고, hash</code></a>도 key/value 포인터 저장형이며 일부 구조에서는 free callback으로 정리 동작을 연결할 수 있다. arraylist</code></a>도 있는데, 이건 Glib의 GPtrArray</code>와 비슷하게 포인터를 저장하는 배열이다.

CS 공부 내용 정리

Sijun Yang — Mon, 16 Mar 2026 00:00:00 +0000

CSAPP, OSTEP를 읽으면서 이론적 지식을 공부하는 것도 좋지만, 실제 세계에서 어떤 식으로 동작하는가... 도 많이 궁금해하는 편이라 같이 메모하려고 함.

CSAPP</h1>

1.2 - 목적파일은 어떻게 연결되는가? 링커는 어떻게 동작하는가?</h3>
근데 이거 7장에 나오는 듯? 너무 딥하게 팔 필요는 없고 이런 이미지 정도로만 생각하고 있어도 충분해보임.
출처: CASS</a>
관련 자료

[CSAPP 7장 완전 정복] 7.12 공유 라이브러리의 핵심 기술 - PIC, GOT, PLT</a></li>
Position Independent Code (PIC) in shared libraries - Eli Bendersky's website</a></li>
Library order in static linking - Eli Bendersky's website</a></li> </ul>
1.4 - 컴퓨터/CPU는 실제로 어떻게 생겼는가?</h3>

이런 구조는 많이 보는데, 그래서 실제로 어떻게 생겼나?
컴퓨터</h4>
I/O Bridge가 나온 모델은 상대적으로 현대적인 모델이라 볼 수는 없었고, 단순한 Ben Eater를 보면 도움이 된다.
실제 구현해보려면 하드웨어를 만지는 것보다는 코드로 구현하는 Nand2Tetris를 하는게 좋을 듯 하다.
출처</a>
Word 크기가 CPU의 처리 단위에 의해 결정된다는 점이 실물에서도 그대로 드러난다. 8-bit CPU이므로 한 번에 8-bit만 처리할 수 있고, 메모리 주소 공간도 그에 맞게 제한된다.
명령어 역시 8-bit로 구성되어 있다. "ben eater 8 bit computer instruction set"으로 검색하면 확인할 수 있다.
한 클럭에 하나의 신호만 전송하므로, 위 이미지의 버스 배선도 실제로 8개의 선으로 이루어져 있다. 이 원리 자체는 현대 프로세서에서도 동일하다(버스 폭이 넓어졌을 뿐이다).
관련 자료

Ben Eater의 8-bit 컴퓨터 영상.</a></li>
다른 사람이 구현한 Ben Eater 컴퓨터의 simulation도 있다. 영상</a>, LOGISIM 시뮬레이터 파일 소개</a></li>
Nand2Tetris 개인적으로 정리한 자료</a></li>
Nand2Tetris ALU 회로 예시 출처</a></li> </ul>
컴퓨터는 아주 간단하게 보면 정해진대로 전기 회로를 보내면, 클럭마다 메모리(레지스터,RAM)에 값을 쓰는걸 반복할 뿐인 기계이다.
CPU</h4>
실제 8bit의 CPU는 이렇게 생겼다. 버스도 8개 사용하는거 볼 수 있음.

출처</a>
visual6502.org</a>에서 JS로 시뮬레이션도 가능하다.
버스, I/O Bridge</h4>
CPU의 내부 데이터 경로는 기본적으로 워드 크기(32-bit, 64-bit 등)에 맞춰져 있지만, 외부 I/O 버스(PCIe, USB, SPI 등)는 독자적인 데이터 폭과 프로토콜을 가진다.
I/O Bridge(버스 컨트롤러)가 이 차이를 변환한다. 복잡한 버스 컨트롤러는 펌웨어가 있는 경우도 있음.
컴퓨터는 왜 2진수인가? 하드웨어와 관련해서</h4>
최근 CSAPP를 읽다가 하드웨어 관련 내용을 보면서 예전에 봤던 영상이 떠올랐다.
CD가 어떤 방식으로 동작하는지 간단하게 설명하는 영상이다.</a> CD 표면에는 pit(홈)과 land(평면) 구조가 있는데, 레이저가 이를 지나가면 반사되는 빛의 세기가 달라진다. 이 차이를 센서가 감지해 전기 신호로 변환한다.
CD가 대부분 일회용인 이유도 여기에 있다. 기록할 때 물리적으로 구조를 바꿔버리기 때문이다. HDD도 비슷하게 물리적 상태를 이용하지만 방식은 다르다. 디스크 표면에 자기장을 부여해 그 방향으로 0과 1을 구분하고, 이를 다시 바꿀 수 있기 때문에 여러 번 읽고 쓰기가 가능하다.
이 이야기는 결국 왜 컴퓨터가 2진수를 사용하는가를 설명하는 현실적인 비유로도 볼 수 있다. 컴퓨터가 다루는 수학은 이진수지만, 실제 물리 세계의 신호는 연속적인 값이다.
문제는 현실 세계의 하드웨어(전압, 물리적 디스크 등)에는 항상 노이즈(noise)가 존재한다는 점이다. 그래서 이를 안정적으로 처리하기 위해 여유 구간(noise margin)을 두고 신호를 구분한다. 이때 상태 수가 많아질수록 구분이 어려워지기 때문에, 두 상태로 나누는 방식이 가장 안정적이고 단순한 설계가 된다.
즉 다른 방식이 물리적으로 불가능한 것은 아니지만, 공학적으로 효율이 떨어지기 때문에 대부분의 컴퓨터가 2진 시스템을 사용한다고 볼 수 있다.
1.7 - 운영체제는 하드웨어를 관리한다.</h3>
추상화 레이어</h4>

기존에는 그림 1.10처럼 단순한 구조로만 이해하고 있었는데, 그림 1.11의 관점이 더 인상적이었다.
운영체제는

I/O 장치를 파일(file)로,</li>
가상 메모리를 파일(I/O 장치) + 물리 메모리로,</li>
프로세스(process)는 프로세서와 가상 메모리(메모리 + I/O)로 추상화한다.</li> </ul>
이걸 단순한 계층 구조로도 볼 수 있지만, 추상화 레이어로 해석할 수도 있다.
가상 메모리는 파일과 메모리를 합쳐서 메모리가 무한한 것처럼 추상화하고, 프로세스는 프로세서와 가상 메모리를 사용하여 무한한 독립된 공간인 것처럼 추상화된다.
이런 적으로 생각해본 적 없었는데 이게 인상 깊었다.
장치 파일</h4>
커널이 하드웨어와 유저레벨 중간에서 추상화를 제공해준다는 것의 좋은 예시.
라즈베리파이는 GPIO, I2C, SPI 같은 하드웨어에 `/sys</code>, /dev</code> 같은 값을 쓰면, 바로 LED가 켜지고 꺼지는 등의 반응을 볼 수 있다.`
보안 관점</h4> 운영체제는 유저 레벨과 커널 레벨을 분리하여 역할을 나눈다. 이는 시스템 안정성과 보안을 확보하기 위한 구조이다. 이러한 구조의 중요성을 보여주는 사례로 2024년 CrowdStrike 장애가 있다. 해당 사건은 커널 모드에서 동작하는 보안 드라이버가 자동 업데이트 과정에서 오류를 포함하게 되면서 발생하였다. 그 결과 해당 소프트웨어를 사용하는 다수의 Windows 시스템이 동시에 다운되며 전산망이 마비되었다. 이 사례는 커널 레벨 코드에 문제가 발생할 경우 시스템 전체에 치명적인 영향을 줄 수 있음을 보여주며, 따라서 일반 프로그램이 커널에 직접 접근하지 못하도록 분리하는 것이 왜 중요한지 설명해준다. OSTEP</h1> POSIX, glibc 알아보기</h3> UNIX는 Bell Labs에서 시작됨</li> 이후 여러 회사/기관이 각자 UNIX 변형을 만듦 → 호환성 문제 발생</li> 이를 해결하려고 IEEE가 POSIX라는 표준을 정의</li> Linux는 UNIX가 아니라 Unix-like OS이며 POSIX를 따르는 방향으로 설계됨 Linux는 POSIX를 완전히 준수하지 않지만, glibc 등을 통해 POSIX 호환 환경을 제공한다.</li> </ul> </li> POSIX는 API, 동작 방식, 규칙을 명세한다. (정확한 명세를 위한 용어 정의도 있다.)</li> </ol> glibc(글립씨, GNU C Library)는 C 표준 라이브러리이면서 POSIX API를 구현하고 GNU 확장 기능까지 포함한다. </li> 거의 대부분의 GNU/Linux 배포판에서 glibc를 사용한다. </li> macOS는 Unix 계열(OS X/Darwin 기반)이며 POSIX를 상당 부분 준수하지만 완전한 호환은 아니다. 따라서 glibc를 사용하지 않고, 자체 libc(libSystem)를 사용한다. </li> 그래서 glibc는 유저레벨의 구현이고, pthread_create 같은 함수는 시스템 콜이 아니다. </li> pthread_create는 내부적으로 clone() 시스템 콜을 사용하여 스레드를 생성하고, 필요 시 mmap() 등을 이용해 스택 메모리를 할당한다. </li> </ul> 원자연산, 스핀락, 뮤텍스, 세마포 알아보기</h3> AI로 정리된 내용임. 시간 관계상 다듬지는 못했는데, 나중에 시간나면 다듬기. </blockquote> atomic instruction</h4> atomic instruction: 하드웨어가 제공하는 원자적 연산. 실행 도중 다른 코어가 끼어들 수 없음을 하드웨어 레벨에서 보장한다. 대표적인 것들: test-and-set (TAS): 메모리 값을 1로 세팅하면서 이전 값을 리턴. x86의 xchg</code>가 이에 해당.</li> compare-and-swap (CAS): 메모리 값이 expected와 같을 때만 new로 교체. x86의 lock cmpxchg</code>.</li> load-linked / store-conditional (LL/SC): ARM, RISC-V 계열. 두 명령어 쌍으로 atomicity를 보장.</li> fetch-and-add (FAA): 값을 atomic하게 증가. x86의 lock xadd</code>.</li> </ul> 전부 결국 이 하드웨어 atomic instruction 위에 쌓여 있다. OSTEP이 여러 가지를 나열하는 이유는 각각의 표현력(expressive power)과 성능 특성이 다르기 때문이다. 예를 들어 TAS로 스핀락은 쉽게 만들지만, lock-free 큐 같은 건 CAS 없이는 사실상 못 만든다. CAS가 TAS보다 표현력이 강하다. 그리고 LL/SC는 ABA 문제에서 CAS보다 유리하다. OSTEP이 이걸 다 보여주는 건 "종류가 많아서"가 아니라, 각각이 풀 수 있는 문제의 범위가 다르기 때문이다. Lock-based vs Lock-free에서의 차이: Lock-based: TAS든 CAS든 뭘 쓰든 상관없다. 어차피 lock 잡고 → critical section → unlock 패턴이니까, TAS 하나로 충분하다.</li> Lock-free: CAS가 사실상 필수다. 이유는 lock-free의 핵심 패턴이 "현재 상태를 읽고, 새 상태를 계산하고, 바뀌지 않았을 때만 반영"이기 때문이다. 이 조건부 쓰기가 CAS다. TAS는 조건 없이 무조건 덮어쓰니까 이 패턴을 표현할 수 없다.</li> </ul> 전형적인 lock-free 패턴: do { old = load(ptr); new = compute(old); } while (!CAS(ptr, old, new)); // 실패하면 재시도</code></pre> TAS로는 이 "old가 아직 유효한지 확인"하는 부분을 표현할 방법이 없다. 이론적 근거는 Herlihy (1991)의 consensus number 개념이다. TAS의 consensus number는 2로, 2개 스레드까지만 wait-free consensus를 풀 수 있다. CAS는 consensus number가 ∞여서 임의의 N개 스레드에 대해 lock-free/wait-free 자료구조를 구현할 수 있다. 이게 CAS가 근본적으로 더 강력한 연산인 이유다. 참고: Herlihy, M. (1991). "Wait-free synchronization." ACM Transactions on Programming Languages and Systems, 13(1), 124–149. </blockquote> 스핀락, 뮤텍스, 세마포</h4> 계층 구조: 하드웨어 atomic instructions (TAS, CAS, LL/SC, FAA) ↓ 이걸로 구현 스핀락 ↓ 이걸로 구현 (+ OS sleep/wakeup 메커니즘) 뮤텍스 / 세마포어 ↓ 이걸로 구현 고수준 동기화 (condition variable, barrier, rwlock 등)</code></pre> 1. 스핀락 (Spinlock)</h5> 가장 기본적인 lock. atomic instruction 하나로 구현 가능하다. lock을 못 잡으면 busy-wait(무한루프)하면서 계속 시도한다. TAS 기반 스핀락 (가장 단순한 형태): typedef struct { int flag; // 0 = 사용 가능, 1 = 잠김 } spinlock_t; void spin_lock(spinlock_t lock) { while (test_and_set(&lock->flag) == 1) ; // 이전 값이 1이면 누가 잡고 있는 것 → 재시도 } void spin_unlock(spinlock_t lock) { lock->flag = 0; // store만 하면 됨 (atomic store) }</code></pre> test_and_set(&flag)</code>은 flag를 1로 세팅하고 이전 값을 리턴한다. 이전 값이 0이었으면 내가 lock을 잡은 것이고, 1이었으면 누군가 이미 잡고 있는 것이다. x86 실제 구현 (GCC inline asm): void spin_lock(spinlock_t lock) { while (__sync_lock_test_and_set(&lock->flag, 1)) ; // GCC built-in: xchg 명령어로 컴파일됨 } void spin_unlock(spinlock_t lock) { __sync_lock_release(&lock->flag); // flag = 0 + memory barrier }</code></pre> CAS 기반 스핀락: void spin_lock(spinlock_t lock) { while (!__sync_bool_compare_and_swap(&lock->flag, 0, 1)) ; // flag가 0일 때만 1로 바꾸기 시도 } void spin_unlock(spinlock_t lock) { __sync_lock_release(&lock->flag); }</code></pre> CAS로도 스핀락을 만들 수 있지만, TAS로 충분하다. CAS를 쓴다고 스핀락이 더 좋아지지 않는다. 스핀락의 문제점: CPU 낭비: lock을 못 잡으면 while 루프를 돌면서 CPU 사이클을 소모한다.</li> 단일 코어에서 최악: lock을 잡은 스레드가 스케줄링되어야 unlock할 수 있는데, 대기 스레드가 CPU를 점유하고 있으면 그게 안 된다.</li> 공정성 없음: 어떤 스레드가 먼저 lock을 잡을지 보장이 없다. starvation 가능.</li> </ol> 그럼 언제 쓰나? critical section이 매우 짧을 때 (수십~수백 나노초)</li> 멀티코어 환경에서 context switch 비용보다 spinning이 싼 경우</li> 인터럽트 핸들러 등 sleep할 수 없는 컨텍스트 (커널 내부)</li> </ul> Linux 커널은 스핀락을 광범위하게 사용한다. spin_lock()</code> / spin_unlock()</code> 함수가 그것. 참고: Love, R. Linux Kernel Development, 3rd ed. Chapter 10. </blockquote> 개선: ticket lock 기본 스핀락의 공정성 문제를 해결한 변형. 은행 번호표 시스템과 동일하다. typedef struct { int next_ticket; // 다음 번호표 int now_serving; // 현재 서비스 중인 번호 } ticket_lock_t; void ticket_lock(ticket_lock_t lock) { int my_ticket = fetch_and_add(&lock->next_ticket, 1); // 번호표 뽑기 while (lock->now_serving != my_ticket) ; // 내 차례 올 때까지 대기 } void ticket_unlock(ticket_lock_t lock) { lock->now_serving++; // 다음 번호 호출 }</code></pre> FIFO 순서가 보장되므로 starvation이 없다. 2. 뮤텍스 (Mutex)</h5> 스핀락 + OS의 sleep/wakeup 메커니즘. lock을 못 잡으면 busy-wait 대신 스레드를 재운다 (sleep queue에 넣는다). lock이 풀리면 OS가 대기 스레드를 깨운다. 핵심: 뮤텍스 내부에서도 sleep queue를 조작하는 부분은 임계 영역이다. 이 부분은 짧은 스핀락으로 보호한다. 즉, 뮤텍스 내부에 스핀락이 있다. 개념적 구현: typedef struct { int flag; // 0 = 사용 가능, 1 = 잠김 int guard; // 내부 스핀락 (flag와 queue 조작 보호용) queue_t wait_queue; // 대기 스레드 큐 } mutex_t; void mutex_lock(mutex_t m) { while (test_and_set(&m->guard)) // 내부 스핀락 획득 ; if (m->flag == 0) { m->flag = 1; // lock 획득 성공 m->guard = 0; // 내부 스핀락 해제 } else { queue_push(&m->wait_queue, current_thread); m->guard = 0; // 내부 스핀락 해제 park(); // OS 호출: 현재 스레드를 재움 } } void mutex_unlock(mutex_t m) { while (test_and_set(&m->guard)) ; if (queue_empty(&m->wait_queue)) { m->flag = 0; // 대기자 없으면 그냥 해제 } else { unpark(queue_pop(&m->wait_queue)); // 대기자 깨움 // flag는 1 유지 — 깨어난 스레드가 lock을 이어받음 } m->guard = 0; }</code></pre> 이 구조가 OSTEP Chapter 28에서 설명하는 park()</code>/unpark()</code> 기반 lock이다. Solaris의 실제 메커니즘을 단순화한 것. 왜 내부 스핀락(guard)이 필요한가? "sleep하면 되지, 왜 안에 스핀락이 또 있나?"라는 의문이 생길 수 있다. 이유는 뮤텍스 자체의 상태(flag, wait_queue)를 조작하는 코드가 그 자체로 임계 영역이기 때문이다. guard 없이 구현하면 어떤 일이 벌어지는지 보자. guard 없는 잘못된 구현: void mutex_lock_broken(mutex_t m) { if (m->flag == 0) { // ① flag 확인 m->flag = 1; // ② flag 세팅 } else { queue_push(&m->wait_queue, current_thread); // ③ 대기 큐에 등록 park(); // ④ sleep } }</code></pre> Race 1: flag 확인과 세팅 사이에 끼어들기 (두 스레드가 동시에 lock 획득) 스레드 A 스레드 B ───────── ───────── ① flag == 0 확인 (true) ← 여기서 컨텍스트 스위치 → ① flag == 0 확인 (true) ② flag = 1 (lock 획득) ② flag = 1 (lock 획득)</code></pre> 둘 다 flag가 0인 것을 보고 둘 다 lock을 잡는다. 상호 배제 실패. "그러면 flag를 CAS로 바꾸면 되지 않나?" → flag 자체는 해결되지만, 그다음 문제가 있다. Race 2: lost wakeup — 깨우기 신호가 허공으로 날아간다 Race 1은 CAS로 해결했다. 하지만 CAS가 실패한 후 "큐에 등록하고 잠드는" 과정에 또 다른 틈이 있다. void mutex_lock_still_broken(mutex_t m) { if (CAS(&m->flag, 0, 1)) { // flag는 atomic하게 처리 return; // lock 획득 } // CAS 실패 — 누군가 lock을 잡고 있으므로 잠들어야 한다 queue_push(&m->wait_queue, current_thread); // ③ 큐에 등록 // ← 아직 잠들지 않았다! 이 틈이 문제다 park(); // ④ 실제로 잠듦 }</code></pre> 핵심은 ③과 ④ 사이의 틈이다. 큐에 이름을 올렸지만 아직 park()</code>는 호출하지 않은 순간이 존재한다. 스레드 A (lock 시도) 스레드 B (unlock) ───────────────── ────────────── CAS 실패 (flag == 1) queue_push(A) ← 큐에 등록됨 ← 여기서 컨텍스트 스위치 → queue에서 A를 pop unpark(A) ← 깨우기 신호 전송! 하지만 A는 아직 안 잠들었다. 신호는 허공으로 사라진다. flag = 0 park() ← A가 이제야 잠듦 깨워줄 스레드는 이미 지나갔다. → A는 영원히 잠든다</code></pre> B가 unpark(A)</code>를 호출한 시점에 A는 아직 park()</code>를 호출하지 않은 상태다. unpark()</code>는 잠들어 있지 않은 스레드에게는 효과가 없으므로 신호가 유실된다. 이후 A가 park()</code>를 호출하면 다시 깨워줄 스레드가 없으므로 영원히 블록된다. 이것이 lost wakeup 문제다. "CAS 실패 확인 → 큐 등록 → sleep" 이 세 단계 사이에 다른 스레드가 끼어들 수 있기 때문에 발생한다. 그래서 이 세 단계를 하나의 원자적 구간으로 묶어야 하고, 그 역할을 하는 것이 guard 스핀락이다. guard가 하는 일을 정리하면: guard가 보호하는 구간 (mutex_lock): ┌─ flag 확인 │ flag 세팅 또는 │ queue에 현재 스레드 추가 └─ guard 해제 (→ 이후 park) guard가 보호하는 구간 (mutex_unlock): ┌─ queue 확인 │ queue에서 스레드 pop + unpark 또는 │ flag = 0 └─ guard 해제</code></pre> lock과 unlock 양쪽 모두에서 guard를 잡으므로, lock 측의 "flag 확인 + queue 추가"와 unlock 측의 "queue pop + unpark"가 겹칠 수 없다. Race 1과 Race 2가 모두 차단된다. guard 스핀락은 왜 문제가 안 되나? guard가 보호하는 구간은 flag 확인 + queue 조작뿐이라 매우 짧다 (수십 나노초). 이 짧은 구간에서만 spinning하니까 CPU 낭비가 사실상 없다. 실제 critical section(사용자 코드)에서는 sleep한다. 즉 뮤텍스의 spinning은 "사용자의 critical section"에 대한 것이 아니라, "뮤텍스 자체의 내부 상태 조작"에 대한 것이다. 이 구간은 고정적으로 짧으므로 스핀락의 단점(CPU 낭비)이 사실상 발생하지 않는다. Linux의 futex 기반 뮤텍스: 실제 Linux에서 pthread_mutex_lock()</code>은 futex (fast userspace mutex) 위에 구현된다. fast path는 유저스페이스에서 CAS 한 번으로 끝나고, contention이 있을 때만 커널로 진입해서 sleep한다. pthread_mutex_lock() 동작: 1. CAS(&mutex->state, 0, 1) 시도 ← 유저스페이스, 시스템콜 없음 2. 성공 → lock 획득. 끝. 3. 실패 → futex(FUTEX_WAIT) 시스템콜 → 커널이 스레드를 재움 4. 나중에 unlock에서 futex(FUTEX_WAKE) → 커널이 깨움</code></pre> contention이 없으면 시스템콜이 아예 발생하지 않는다. 이것이 futex가 빠른 이유. 참고: Franke, H., Russell, R., & Kirkwood, M. (2002). "Fuss, Futexes and Furwocks: Fast Userlevel Locking in Linux." Ottawa Linux Symposium. </blockquote> POSIX pthread 뮤텍스 사용 예시: #include <pthread.h> #include <stdio.h> pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; int shared_counter = 0; void worker(void arg) { for (int i = 0; i < 100000; i++) { pthread_mutex_lock(&lock); shared_counter++; // critical section pthread_mutex_unlock(&lock); } return NULL; } int main() { pthread_t t1, t2; pthread_create(&t1, NULL, worker, NULL); pthread_create(&t2, NULL, worker, NULL); pthread_join(t1, NULL); pthread_join(t2, NULL); printf("counter = %d\n", shared_counter); // 항상 200000 return 0; }</code></pre> 뮤텍스 없이 shared_counter++</code>를 하면 race condition으로 200000보다 작은 값이 나온다. counter++</code>는 load → add → store 3단계이므로 원자적이지 않다. 3. 세마포어 (Semaphore)</h5> 뮤텍스의 일반화. 내부에 정수 카운터를 가지고, 이 값이 0 이하면 대기한다. sem_wait()</code> (= P 연산, down): 카운터 감소. 0 이하면 sleep.</li> sem_post()</code> (= V 연산, up): 카운터 증가. 대기 스레드가 있으면 깨움.</li> </ul> 뮤텍스와의 핵심 차이: 특성</th> 뮤텍스</th> 세마포어</th></tr></thead> 내부 값</td> 0 또는 1</td> 임의의 정수 N</td></tr> 소유권</td> lock한 스레드만 unlock 가능</td> 아무 스레드나 post 가능</td></tr> 용도</td> 상호 배제</td> 상호 배제 + 순서 제어 + 리소스 카운팅</td></tr> </tbody></table> 소유권 차이가 중요하다. 뮤텍스는 lock한 스레드가 반드시 unlock해야 한다. 세마포어는 스레드 A가 wait하고 스레드 B가 post할 수 있다. 이 특성 때문에 스레드 간 순서 제어(signaling)가 가능하다. 개념적 구현: typedef struct { int value; int guard; // 내부 스핀락 queue_t wait_queue; } sem_t; void sem_wait(sem_t s) { while (test_and_set(&s->guard)) ; s->value--; if (s->value < 0) { queue_push(&s->wait_queue, current_thread); s->guard = 0; park(); // sleep } else { s->guard = 0; } } void sem_post(sem_t s) { while (test_and_set(&s->guard)) ; s->value++; if (s->value <= 0) { unpark(queue_pop(&s->wait_queue)); // 대기자 깨움 } s->guard = 0; }</code></pre> 이 구현은 OSTEP Chapter 31의 Zemaphore를 기반으로 단순화한 것. </blockquote> 용도 1: 이진 세마포어 = 뮤텍스처럼 사용 (초기값 1) sem_t mutex; sem_init(&mutex, 0, 1); // 초기값 1 sem_wait(&mutex); // lock // critical section sem_post(&mutex); // unlock</code></pre> 초기값이 1이므로 한 스레드만 진입 가능. 기능적으로 뮤텍스와 동일하지만, 소유권 검사가 없으므로 다른 스레드가 post할 수도 있다 (이건 보통 버그). 용도 2: 순서 제어 (초기값 0) 스레드 간 실행 순서를 강제할 때 사용. 뮤텍스로는 이걸 직접 할 수 없다. sem_t order; sem_init(&order, 0, 0); // 초기값 0 // 스레드 A (먼저 실행되어야 할 작업) void thread_a(void arg) { printf("A: 작업 완료\n"); sem_post(&order); // "나 끝났어" 시그널 return NULL; } // 스레드 B (A가 끝난 후 실행되어야 할 작업) void thread_b(void arg) { sem_wait(&order); // A가 post할 때까지 여기서 대기 printf("B: A 이후 작업 시작\n"); return NULL; }</code></pre> B가 먼저 실행되더라도 sem_wait()</code>에서 블록된다. A가 sem_post()</code>를 호출해야 B가 진행된다. 이것이 "외부에서 값 반환이 가능하므로 순서 보장 시 사용"이라고 했던 것의 정확한 의미다. 용도 3: 리소스 카운팅 (초기값 N) 동시에 N개까지 접근을 허용. 대표적 예: 커넥션 풀, bounded buffer. // bounded buffer (생산자-소비자 문제) #define BUFFER_SIZE 10 sem_t empty; // 빈 슬롯 수 sem_t full; // 찬 슬롯 수 sem_t mutex; // 버퍼 접근 보호 int buffer[BUFFER_SIZE]; int fill = 0, use = 0; void init() { sem_init(&empty, 0, BUFFER_SIZE); // 처음엔 전부 비어있음 sem_init(&full, 0, 0); // 처음엔 아무것도 없음 sem_init(&mutex, 0, 1); } void producer(void arg) { for (int i = 0; i < 100; i++) { sem_wait(&empty); // 빈 슬롯 하나 확보 sem_wait(&mutex); // 버퍼 접근 lock buffer[fill] = i; fill = (fill + 1) % BUFFER_SIZE; sem_post(&mutex); // 버퍼 접근 unlock sem_post(&full); // 찬 슬롯 하나 증가 } return NULL; } void consumer(void arg) { for (int i = 0; i < 100; i++) { sem_wait(&full); // 찬 슬롯 하나 확보 sem_wait(&mutex); int val = buffer[use]; use = (use + 1) % BUFFER_SIZE; sem_post(&mutex); sem_post(&empty); // 빈 슬롯 하나 증가 printf("consumed: %d\n", val); } return NULL; }</code></pre> empty</code>와 full</code> 세마포어가 생산자와 소비자 간 흐름 제어를 담당한다. 버퍼가 꽉 차면 생산자가 블록되고, 비면 소비자가 블록된다. 이 패턴은 Dijkstra(1965)가 세마포어를 처음 제안할 때의 핵심 예제이며, OSTEP Chapter 31에서도 동일하게 다룬다. </blockquote> 정리</h4> 스핀락: - 구현: atomic instruction + busy-wait loop - 대기 방식: CPU를 소모하며 반복 확인 (spinning) - 사용처: 커널 내부, 짧은 critical section, sleep 불가능한 컨텍스트 뮤텍스: - 구현: 내부 스핀락 + OS sleep/wakeup (futex 등) - 대기 방식: lock 못 잡으면 sleep → unlock 시 wakeup - 소유권: lock한 스레드만 unlock - 사용처: 유저스페이스 상호 배제의 기본 세마포어: - 구현: 정수 카운터 + 내부 스핀락 + OS sleep/wakeup - 대기 방식: 카운터 ≤ 0이면 sleep - 소유권: 없음 (아무나 post 가능) - 사용처: 상호 배제, 순서 제어, 리소스 카운팅</code></pre> 참고 문헌: Arpaci-Dusseau, R. & Arpaci-Dusseau, A. Operating Systems: Three Easy Pieces (OSTEP). Chapters 28–31.</li> Herlihy, M. (1991). "Wait-free synchronization." ACM TOPLAS, 13(1).</li> Dijkstra, E. W. (1965). "Cooperating Sequential Processes." Technical Report EWD-123.</li> Love, R. (2010). Linux Kernel Development, 3rd ed. Addison-Wesley.</li> </ul> </blockquote> Week 02: 컴퓨팅 사고로의 전환 Sijun Yang — Thu, 12 Mar 2026 00:00:00 +0000 핵심 역량 목표</h2> 문제해결: 주어진 문제를 정의하고 논리적으로 해결하는 능력 알고리즘 문제의 입력/출력/제약 조건을 정확히 파악하고, 실버~골드 수준의 백준 문제를 스스로 분석하여 해결 전략을 수립할 수 있다.</li> </ul> </li> 설계: 효율적이고 확장 가능한 시스템 구조를 기획 시간 복잡도를 이해하고, 사용한 알고리즘과 구현의 시간 복잡도를 올바르게 평가할 수 있다.</li> </ul> </li> 구현: 설계된 내용을 실제로 동작하는 코드로 작성 정렬, 정수론 등의 기초 알고리즘을 직접 구현하고, 재귀 함수와 백트래킹 문제를 올바르게 구현할 수 있다.</li> </ul> </li> 품질: 버그 없는 안정적인 코드 및 테스트 작성 제약 조건의 엣지 케이스에 대한 예외 처리를 고려하여 코드를 작성할 수 있다.</li> </ul> </li> 유지보수: 가독성이 좋고 수정이 용이한 코드 작성 함수 단위로 로직을 분리하고, 직관적으로 이해 가능한 네이밍을 사용한다.</li> </ul> </li> 협업: 팀원과 소통하며 시너지를 내는 과정 데일리 스크럼으로 목표와 진행 상황을 공유하고, 매일 푼 과제를 공유/리뷰하며 지식을 나눈다.</li> </ul> </li> 태도: 자기주도적인 학습과 과제에 대한 몰입(집요함) 문제를 풀고 넘어가는 게 아닌, 여러 번 반복하여 체화한다. 특히, 틀린 문제는 2번 이상 반복 풀이한다.</li> </ul> </li> 비즈니스 이해: 서비스의 가치와 사용자 입장을 고려하는 시각 알고리즘 복잡도가 실제 서비스 성능(응답 시간, 메모리 사용)에 미치는 영향을 이해하고 설명할 수 있다.</li> </ul> </li> AI 활용: AI 도구를 활용하여 생산성을 극대화하는 능력 AI는 이론 공부와 풀이 피드백 용도로만 사용한다.</li> [공부 - AI 활용] → [풀이 - AI 금지] → [1차 피드백 - AI 금지] → [2차 피드백 - AI 활용]</code></li> </ul> </li> 학습 민첩성: 새로운 기술이나 개념을 빠르게 습득하는 능력 정수론과 백트래킹 관련 개념을 4일 내에 습득하고 설명할 수 있을 정도로 공부한다.</li> </ul> </li> </ol> WIL (What I Learned)</h2> 목표 1. 정수론/재귀/백트래킹 문제풀이 역량 확보</h3> 자신 없는 정수론/재귀/백트래킹 문제를 중급 난이도까지 풀 수 있는 이론 지식, 문제 풀이 능력을 가지기. 접근</h4> 이번 주 과제 중 중급 난이도 이하의 모든 문제를 일요일까지 풀기. 제한시간 30분.</li> 못 푼 문제를 리스트업하고 해당 문제의 개념을 공부 후, 2번 이상 복습.</li> 비슷한 요구사항의 문제를 찾아 더 풀이하기.</li> </ol> 과정</h4> 백트래킹 문제의 대표적인 순열/조합 유형 구현 방법을 복습하기 위해 AI를 활용해 정리 자료를 생성</a></li> 2026/03/09 - Recursion 특강 정리</a></li> 하노이의 탑 정리</a></li> 난이도 중 이하 모든 문제 2번 이상 반복 풀이</li> </ul> 결과</h4> 정수론은 출제 빈도와 응용 범위를 고려해 우선순위를 낮게 두었고, 그만큼 아직 부족한 부분이 남아 있다. 확장 유클리드 호제법은 이해조차 못했다.</del> 하노이의 탑, 완전탐색, 순열/조합, N-Queen 등의 백트래킹/재귀 문제를 풀 수 있게 되었다. 반복 풀이를 통해 재귀/백트래킹의 공통 패턴과 구현 방식을 체득한 것이 이번 주차의 가장 큰 성과다. 문제 조건 분석과 접근 방식 선택(base case 설정 등)은 아직 미숙하지만, 충분한 시간이 주어지면 구현 자체에서 실수하는 경우는 거의 없어졌다. 목표 2. 과제 공유/리뷰를 통한 팀 성장</h3> 팀원들과 공유하여 더 빠른 성장을 돕고, 다른 관점의 풀이를 보며 함께 성장하기. 접근</h4> 첫 스크럼에서 매일 푼 문제를 슬랙에 올리고 서로 리뷰하자고 제안했다.</li> 여러 유용한 자료를 찾거나 준비하여 팀에게 전달했다. 코테 준비 노트 (기존에 정리했던 것)</a></li> 학습 계획 (신규 정리)</a></li> 파이썬 + 프로그래밍 강의 추천 (링크)</a></li> </ul> </li> </ol> 과정</h4> 매일 스크럼 시 슬랙을 통해 풀이 내역이 담긴 커밋 링크를 공유했다. 2주차 커밋 내역 링크</a> 코어타임에 문제 풀이를 공유하고, 팀원과 헷갈리는 개념에 대해 대화를 나눴다. 결과</h4> 예상보다 각자의 알고리즘 문제 풀이에 많은 시간이 소요되었다. 그로 인해 팀원 간 공유나 협력이 원활하지 않았다. 다만 공유한 자료들은 팀 내에서 유용하게 활용되고 있는 것으로 보인다. 회고</h2> 역량 달성률</h3> 초기 목표를 얼마나 달성했는지를 기준으로 상/중/하로 구분. 단, 해당 주차와 관련이 없거나 평가가 어려운 경우 N/A로 표기. 어느 정도 주관적인 판단이 포함될 수 있음. #</th> 역량</th> 달성률</th> 설명</th></tr></thead> 1</td> 문제해결</td> 중</td> 골드 수준의 문제 분석 및 전략 수립은 아직 어려움.</td></tr> 2</td> 설계</td> 상</td> 대략적으로나마 시간 복잡도를 유추할 수 있음.</td></tr> 3</td> 구현</td> 상</td> 개념을 이해한 경우, 구현 자체에는 문제 없었음.</td></tr> 4</td> 품질</td> 하</td> 동일 문제를 반복 풀이하는 데 집중한 탓에 엣지케이스 판단 능력을 키우지 못했음.</td></tr> 5</td> 유지보수</td> N/A</td> 2주차 내용과 관련성이 낮음.</td></tr> 6</td> 협업</td> 하</td> 예상보다 잘 되지 않음. (후기에서 후술함)</td></tr> 7</td> 태도</td> 중</td> 문제 공유나 협업 측면에서는 잘 수행했으나 전반적으로 기대에 미치지 못함.</td></tr> 8</td> 비즈니스 이해</td> N/A</td> 2주차 내용과 관련성이 낮음.</td></tr> 9</td> AI 활용</td> 중</td> 잘 활용했지만, 힌트를 받는 방식이 더 좋았음. 처음 의도와 달라짐.</td></tr> 10</td> 학습 민첩성</td> 중</td> 빠르게 학습하긴 했지만, 한 문제에 지나치게 시간을 소비하여 전체 진도가 느렸음.</td></tr> </tbody></table> 후기</h3> 이번 주 활동에 대한 평가</h4> 전반적으로 높은 목표를 설계했다는 느낌을 받았다. 또 시간 관리도 부족하다고 느꼈다. 협업도 예상보다 쉽지 않았다. 리뷰하기에는 본인 과제를 풀이하기에도 시간이 않지 않았다. 의도적으로 시간을 할당하는 등의 의식적인 노력이 필요할거 같음. 나에게는 준비 없는 구두 설명이 어려웠다. 자료 공유 방식이 더 효과적이였던 것 같음. 다음 주에 시도해 볼 것</h4> 문제당 시간 제한을 두고, AI 해설을 적극 활용하여 더 많은 유형에 노출되는 방식으로 전환한다. 난이도를 올리기보다는 중급(실버~골드) 수준을 유지하면서 유형 폭을 넓히는 데 집중한다. 팀 기여 방식은 구두 설명보다 자료 공유가 더 효율적이고 내 강점에도 맞으므로, 자료 공유를 더 적극적으로 한다. WIL의 형식에 대한 후기</h4> 다른 사람들의 제출을 보니, 너무 핵심 역량 목표에 집중된 듯한 느낌을 받음. 별개로 나누어서 해야 할거 같음. 힉심 역량 파트를 줄이고, WIL은 말 그대로 배운 것들의 리스트가 나와야 할 듯. 추가 — 03/12 운영진 티타임</h3> Q&A: 핵심 역량 목표의 의미</h4> Q: 핵심 역량 10가지에 대해 목표를 세우게 되는데, 알고리즘 주차의 경우 유지보수나 비즈니스 이해와 직접적 관련이 없어 보인다. 10개를 모두 작성해야 하는가? 어떤 항목을 중심으로 써야 할까? A: 이동석 코치님 10가지를 모두 작성할 필요는 없다. 특정 주차에는 상대적으로 덜 중요한 역량이 있을 수 있다. 다만 모든 핵심 역량은 중요하므로 각 역량과의 연결점을 고민해보면 좋겠다. 여기서 배우는 것들은 실제 현장에서 필요한 역량이고, 어떤 식으로든 현실과 연결되는 부분이 있다. A: 김현수 코치님 핵심 역량 목표를 도입한 배경은, 이전 기수들이 많은 활동을 했음에도 이력서에 잘 드러나지 않는 점이 아쉬웠기 때문이다. 따라서 몇 가지 역량에 집중해서 계획을 세우고 발전 과정을 기록하여, 성과가 가시적으로 드러나도록 하려는 의도다. 예를 들어, 알고리즘 주차를 완료했다고 해서 문제 해결 능력이 뛰어난 것은 아니다. 하지만 알고리즘 주차에서 문제 해결을 위한 구체적 목표를 세우고 달성한 기록이 있다면, 문제 해결 능력을 어필할 수 있다. 이력서 활용뿐 아니라, 목표가 있으면 스스로의 성장에도 도움이 될 것이다. 항상 전부 채울 필요는 없지만, 이런 의도를 이해해주면 좋겠다. 생각: 핵심 역량 목표를 어떤 식으로 세워야 할까?</h4> 이 답변과 Week2 WIL 작성 시의 생각을 종합했을 때 다음과 같은 결론을 세웠다. 최소 2~3개 이상의 핵심 역량 목표를 정한다.</li> 수치화하거나 이전 상태와 비교 가능한 형태로 목표를 설정한다.</li> 선택하는 역량은 한 영역에 치우치지 않고, 개인 역량과 협업 역량에서 각각 최소 1개 이상 포함한다.</li> </ul> 수치화/비교 가능한 목표의 예: 저번 주차 미해결 골드 문제를 이번 주차에 30분 내 독립 풀이. 전/후 소요시간 기록.</li> 엣지케이스 체크리스트 도입, Week 02 대비 1차 제출 정답률 비교 기록.</li> 팀원 피드백 시간을 별도로 할당하여 N회 이상 실행. 팀 프로젝트 시 머지 컨플릭을 잘 해결하는 Skill.md 도입 등.</li> </ul> 정글 에세이: 퇴사하고 정글에 온 이유 Sijun Yang — Fri, 06 Mar 2026 00:00:00 +0000 첫 번째 회사에서 약 1년 8개월의 일을 마무리하고 정글에 참여하게 되었다. 크래프톤 정글에 가야겠다고 다짐한 이유</h2> 나는 광주소프트웨어마이스터고등학교를 다녔다. 학교에서는 팀 프로젝트 위주의 자습이 대부분이였고 이론이나 CS를 깊게 배우기 어려운 환경이었다. 이런 아쉬움에 개인적으로 OS나 CS 자료를 찾아 공부했는데, 어렵게 찾은 개념을 잘 정리해둔 글이 크래프톤 정글을 다니면서 쓴 글이라는 걸로 정글을 처음 알게 되었다. 정글을 찾아보니, 합숙 방식과 CS 위주의 커리큘럼이 매력적이었다. 특히 고등학교에서 기숙사 생활과 팀 프로젝트를 통해 빠르게 성장한 경험이 있어서 더 공감할 수 있었다. 고등학교 졸업 후 바로 정글에 지원하고 싶었지만, 길어진 취준 생활이 두려워 도피성으로 부트캠프를 찾는 건 아닌지 의심이 들어 취업에 집중했다. 운이 좋게도 2025년 7월에 강남의 작은 스타트업에서 백엔드 개발자로 일을 시작했다. 그럼에도 CS 공부에 대한 욕심은 사라지지 않았다. 단순 구현만 가능한 개발자가 아니라, CS와 기본기를 바탕으로 빠른 기술 적응과 의사 결정이 가능한 개발자가 되어야 한다는 생각은 변하지 않았다. 특히 AI의 발전으로 이 생각은 더 강해졌다. 5개월 동안 얻고 싶은 것</h2> 1. 기본기</h3> CS나 자료구조 같은 기본기는 항상 필요하다고 생각하지만, 당장 티가 나는 지식이 아니다 보니 일하면서 공부하기 어려웠다. 이 기회에 확실하게 집중해서 학습하고자 한다. 커리큘럼 중 자료구조, 알고리즘, 운영체제와 컴퓨터 시스템은 더 집중해서 배울 생각이다. 2. 여러 사람들과 팀 프로젝트 경험</h3> 소마고를 다니면서 팀 프로젝트를 해보았지만, 거의 정해진 팀원과 개발했고 시간 여유도 많았다. 정글에선 더 높은 난이도의 과제를 팀원들과 협력해보고, 만나보지 못했던 다양한 나이대와 배경의 사람들을 만나보고 싶다. 특히 운영체제나 기본기에 관심이 많았지만 이야기할 사람이 없었는데, 여기서는 함께 이야기하면서 학습할 수 있어서 기대된다. 참여하는 태도</h2> AI를 적극적으로 사용하면서 학습 능력의 저하를 많이 체감했다. 최대한 AI 없이, 고통스럽더라도 스스로 고민하며 학습하는 방식을 시도해 볼 생각이다. 원래 이런 방식을 선호하지만, 시간과 효율을 이유로 실천하지 못했다. 첫 주차 미니 프로젝트를 하면서 하루 15시간 이상을 순수 작업에 쏟을 수 있는 환경이라는 걸 체감했고, 이 시간적 여유를 활용해 최대한 삽질을 많이 해볼 생각이다. 이때가 아니면 언제 가능하겠나 싶다. 협업 관점에서는 실무/개발 경험을 가진 사람이 많지 않아(최소한 이번 기수, 나의 반에서는) 이런 경험으로 알게 된 지식을 기반으로 많이 도움을 줄 수 있을 것 같다. 머신러닝이나 딥러닝도 커리큘럼에 있는데, 전혀 해본 적이 없어서 이 파트에선 오히려 도움받는 입장이 되지 않을까 싶다. 정글이 끝난 후의 나</h2> CS 기초가 탄탄하게 쌓여서 새로운 개념들을 쉽게 공부하고 배워나갈 수 있는 사람이 되었으면 좋겠다. 이를 기반으로 오픈소스에 기여하거나 난이도 있는 토이 프로젝트를 진행하며 개발 능력을 높여가고자 한다. (그리고 가능하면 취업에도 성공하고</del>) [월간 기록] 2026년 2월 Sijun Yang — Sat, 28 Feb 2026 00:00:00 +0000 이번 달의 큰 이벤트는 크래프톤 정글 SW 12기 합격과 참여를 위한 첫 번째 회사의 퇴사이다. 인수인계와 시험 준비에 많은 시간을 소요하여 자료 수집과 작업을 많이 하지 못했다. 수집</h2> 흥미롭거나 유용했던 자료들 LLM을 칩 위에 '인쇄'하는 Taalas의 방식</a> | GeekNews</a></h3> Taalas라는 스타트업이 Llama 3.1 8B 모델의 가중치를 하드웨어 칩의 트랜지스터로 직접 구현했다. 원래 X에서</a> 먼저 알았는데 GeekNews에도 올라왔다. TokenPost 기사</a>도 참고. 처음 보고 모델을 칩에 고정한다는 발상이 신선했는데, 생각해 보면 비슷한 사례가 이미 있다. 부동소수점 연산은 원래 소프트웨어로 처리하다가 CPU에 내장되었다. ARM도 JavaScript의 부동소수점→정수 변환을 하드웨어 명령어(FJCVTZS</a>)로 넣었다. 자주 쓰이는 연산을 하드웨어에 옮기는 건 반복되어 온 패턴이지만, LLM이 가능할 거라고는 직관적으로 생각하지 못했던 부분이다. 속도가 비교도 안 되게 빠르다. 데모 사이트</a>에서 직접 대화해 보면 체감할 수 있다. 바이브코딩의 보안 문제: MoltBook 해킹</a> (GeekNews</a>) | OpenClaw 마크다운 악성코드</a> (GeekNews</a>)</h3> MoltBook이 Supabase 설정 오류로 150만 개의 API 키, 35,000개 이상의 이메일, 비공개 메시지가 노출되었다. RLS(Row Level Security)가 비활성화되어 누구나 전체 DB에 접근 가능한 상태였다. OpenClaw 에이전트의 마크다운 악성코드 문제도 있었다. ClawHub의 인기 스킬이 마크다운 문서에 위장된 악성 링크를 포함하고 있었는데, 사람들이 마크다운 파일을 위험하다고 인식하지 않는 점을 노린 것이다. 이제는 텍스트 자체가 취약점이 될 수 있다는 사실을 인지해야 한다. 다만 두 사례는 별개의 이슈다. MoltBook의 사례를 예시로 OpenClaw가 위험하다는 식의 의견을 종종 보았는데, 이는 맞지 않는 말이다. MoltBook은 기업가 Matt Schlicht가 코드를 직접 보지 않고 바이브코딩으로 만든 플랫폼이고, OpenClaw의 Peter Steinberger는 전 소프트웨어 엔지니어로 코드 구조를 설계하고 리뷰한다. OpenClaw의 악성코드 문제는 사칭 배포처에서 발생한 사건으로, 사람이 만든 소프트웨어라도 동일하게 발생할 수 있는 유형이다. 또한 OpenClaw 자체 구조상 플랫폼 내부에서 개인정보가 유출되는 문제와는 직접적인 관련이 없다. 다만 OpenClaw는 AI에게 강력한 권한을 부여하는 도구이기 때문에, 이런 문제는 자연스러운 특성에 가깝다. 어쨌든 바이브코딩의 문제점을 잘 보여주는 사례다. 개인정보를 저장하고 관리하는 곳에 바이브코딩을 적용하는 게 올바른지는 확실히 고민해 봐야 한다. Andrej Karpathy도 보안 취약점/해킹/스팸/조작 등의 이유로 사용을 비추하면서도, 대규모(15만+) 에이전트 네트워크를 만들어낸 건 흥미롭다고 평가했다.</a> Rust 한국 디스코드 채널의 Rust-for-Linux 관련 글 | Discord</a></h3> Linux Kernel v7.0-rc1 릴리즈와 함께 Rust 지원이 확대되었고, 실제 하드웨어 디바이스 지원을 위한 기능들이 추가되었다. Linux Plumbers Conference 2025 분위기도 Rust 중심이었으며, 커널 개발 쪽에서 Rust 채택 흐름이 강해지는 상황이다. 커널 개발에 관심 있는 사람이라면 지금 Rust 기반 커널 개발 흐름에 참여하는 것도 좋다는 의견이 나왔다. 2026년, 그냥 Postgres를 쓰자</a> | GeekNews</a></h3> 대부분의 기업은 PostgreSQL 하나로 충분하다는 주장이다. AI 에이전트 시대에는 단일 DB 환경에서 빠르게 테스트하고 디버깅하는 것이 효율적이고, 백업/모니터링/보안 전략을 단일화하여 운영 비용을 줄일 수 있다. PostgreSQL 확장 기능으로 검색(pg_textsearch), 벡터 검색(pgvector), 시계열(TimescaleDB), 문서(JSONB) 등을 전문 프로그램과 비교하여 거의 비슷한 성능을 낼 수 있다고 주장한다. 실무에서도 그런 통계 결과가 나올지 모르겠지만, 실제 데이터 시연 결과를 보여주고 증명하는 점에서 테스트해 보고 도입해 볼 만한 것 같다. Stop Forwarding Errors, Start Designing Them</a></h3> Rust에서 더 나은 에러 처리를 위해, 기계가 처리할 정보와 사람이 읽을 정보를 분리하자는 글. 예를 들어 기계용 정보로는 ErrorKind</code> 열거형과 ErrorStatus</code>를 통해 처리 방법, 재시도 가능 여부 등을 명시하고, 사람용 정보로는 #[track_caller]</code>로 호출 위치를 자동으로 기록하며, 타입 시스템으로 모듈 경계에서 문맥 추가를 강제한다. 액션베이스(Actionbase) – 좋아요, 최근 본, 팔로우를 위한 데이터베이스</a> | GeekNews</a></h3> 좋아요, 팔로우, 최근 본 항목 등 "누가 무엇을 어떻게 했다"라는 관계형 기능을 위한 카카오의 오픈소스 DB이다. 쓰기 시점에 모든 데이터를 미리 계산하고 읽기는 단순 조회만 수행하여 빠르고 예측 가능한 성능을 제공한다. 카카오톡 선물하기 위시 등 프로덕션 환경에서 분당 100만 건 이상의 요청을 처리 중이라고 한다. 회사에서 비슷한 걸 RDB로 만들어 본 적 있는데, 구현이나 유지보수가 어려웠다. 나중에 비슷한 기능을 구현하게 될 수도 있다고 생각하는데, 이 프로젝트의 코드나 원리를 뜯어보면 적용할 수 있을 것 같다. 그 외 수집한 글</h3> Todd C. Miller – 30년 넘게 Sudo를 유지보수한 개발자</a> (GeekNews</a>): sudo가 30년간 한 명이 유지보수해 온 프로그램이라는 사실. sudo가 별도 프로그램이라는 것도 새삼 인식하게 되었다.</li> Claude Skills 구축을 위한 완벽 가이드</a> (GeekNews</a>): Anthropic이 제공하는 33쪽 가이드. 마크다운 번역본</a>도 정리해 두었다.</li> How I Assess Open Source Libraries</a>: 오픈소스 보안 컨설팅 전문가가 라이브러리를 채택할 때의 평가 기준을 소개하는 글.</li> microgpt - 200줄 순수 파이썬으로 구현한 GPT 학습 및 추론</a> (GeekNews</a>): Andrej Karpathy가 외부 의존성 없이 200줄로 GPT 전체를 구현한 교육용 프로젝트.</li> How I became a Linux Kernel Contributor</a>: 한 커널 컨트리뷰터가 본인의 기여 여정을 소개하는 영상. 실제 커널 기여 시 전체적인 참여 흐름을 이해하는 데 도움이 될 듯하다.</li> 메모리 관련 자료 모음</a>: "What Every Programmer Should Know About Memory" 요약 버전. 메모리 최적화 기법</a>도 함께 참고.</li> LLM이 만든 비밀번호가 위험한 이유, 100비트처럼 보이지만 실제론 27비트</a> (GeekNews</a>): LLM은 근본적으로 토큰 생성기다. 따라서 인간과 마찬가지로 진정한 무작위성과는 거리가 있다.</li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들 짧은 글: AI 시대의 학습과 올바른 사용에 대한 고민</h3> AI 시대에서의 학습 능력과 프로젝트 개발 의욕 저하</h4> Anthropic 연구</a> (GeekNews</a>)에 따르면, AI에 작업을 전적으로 맡긴 개발자들은 퀴즈에서 17% 낮은 점수를 기록했다. AI는 학습 측면에서는 그다지 도움이 되지 않을 수 있다. "AI가 당신을 지루하게 만든다"</a> (GeekNews</a>)라는 글에서도 말하듯, AI 중심의 개발 방식은 금방 흥미를 잃게 만들 수 있다. 나 역시 이 의견에 동의하는데, AI를 많이 사용할수록 결과물에 대한 애착이 줄어들고 장기적으로 이해도가 떨어진다는 느낌을 받았다. 따라서 의도적으로 AI 없이 코드를 작성하고 학습하는 과정을 만들어야 한다고 생각하고 있다. 어떻게 코드를 다루어야 할까?</h4> Node.js 메인테이너인 Matteo Collina</a> (GeekNews</a>)도 AI를 생산성 도구로 활용하되, 판단력과 책임은 포기하면 안 된다고 주장한다. 요즘 해커뉴스나 긱뉴스, 여러 오픈소스 커뮤니티에서 AI Slop의 남발로 인한 문제는 심심치 않게 접할 수 있다. 하지만 AI 활용이 긍정적인 사례도 분명히 있다. hwplibsharp 업스트림 관리</a>에서는 AI가 포팅 코드를 작성하고 리뷰만으로 유지보수하는 방식을 소개한다. 이전에 본 $5짜리 프롬프트로 $2,418짜리 취약점을 찾은 사례</a>도 좋은 영향을 주는 AI 활용 예시라고 생각한다. 이런 식으로 AI를 사용하되, 피해나 부담을 주지 않으면서 긍정적으로 활용하려는 자세가 필요한 듯하다. AI 개발의 3가지 조합</h4> X에서 본 글인데, 인간(의지/의도 주입) + LLM(코드 생성) + 정적분석(타입체커, 린터, 자동테스트)</a>을 조합하는 구성이 좋다는 의견이다. 좋은 패턴이라고 생각해서 시도해 볼 계획이다. AI와 함께 개발한다면, 혼자가 아니라 다른 사람과 협업하는 것처럼 접근해야 한다. 코드를 작성하는 주체가 여럿이므로 이런 구성을 기본으로 사용하는 게 올바르다고 생각한다. 짧은 글: Functor와 Monad가 무엇인가?</h3> 참고한 글: 카테고리 이론으로 설명하는 프로그래머를 위한 글</a></li> TypeScript로 보는 Monad</a></li> 모나드는 포켓몬이다: 수학 없이 배우는 모나드 입문 - RosettaLens 번역본</a></li> </ul> 정리한 핵심 개념: Functor: A => B</code>를 적용하면서 컨텍스트는 불변. 현실의 사이드이펙트나 별도 기능을 의미하는 컨테이너로 실제 값(타입)을 감싸는 것.</li> Monad: A => M[B]</code>를 적용하면서 컨텍스트를 합성. Monad는 Functor를 포함한다.</li> Context: 계산의 성격이나 값의 추가 정보. Option(있거나 없음), List(여러 개), Future(대기 중) 등.</li> Monad의 실용적 관점: 연산 중 컨테이너를 컨테이너로 감싸는 중첩 문제를 해결하기 위한 것.</li> Monad의 함수적 관점: 숫자에 0을 더해도 값이 변하지 않듯, 어떤 컨테이너를 pure</code>로 감싸고 다시 펴는 행위가 원래의 정보나 상태에 영향을 주지 않아야 한다.</li> Monad 종류: Option, Either, List, IO, Future, State, Reader 등. 구현을 바꾸면 패턴을 유지하면서 동작을 변경할 수 있다.</li> </ul> 사실 하스켈 같은 순수 함수형에 가까운 언어를 사용해 본 경험이 거의 없어서, 이런 식으로 정보만 접하는 게 올바른지는 모르겠지만, 모나드에 대해서 실용적으로 적용할 수 있을 정도는 이해한 것 같다. zsh + starship 터미널 환경 세팅</h3> zsh + starship</a>을 사용해 봤다. oh-my-zsh 대신 플러그인 zsh-autosuggestions</code>, zsh-syntax-highlighting</code>를 설치한 기본 zsh에 적용하였다. 스타일은 oh-my-zsh보다 취향에 맞아 만족하고 있다. 참고한 자료: starship 가이드</a>, zsh 설정 참고</a>, dotfiles 예시</a> CS146S: The Modern Software Developer 강의 정리</h3> 1월에 소개했던 Stanford CS146S 강의</a>를 주차별로 정리했다. 다만 3주차부터는 시간이 없어서 실습을 하지 못했고, 자료에 대한 요약을 훑어보기만 했다. (항상 이런 식으로 대충 마무리된다.</del>) Week 1: 정리</a></li> Week 1 추가: Deep Dive into LLMs - Andrej Karpathy</a></li> Week 1 추가: AI Prompt Engineering - Anthropic</a></li> Week 2: 정리</a></li> Week 3: The AI IDE</a></li> Week 4: Coding Agent Patterns</a></li> Week 5: The Modern Terminal</a></li> Week 6: AI Testing and Security</a></li> Week 7: Code Review</a></li> Week 8: Automated UI and App Building</a></li> Week 9: Agents Post-Deployment</a></li> </ul> 노트: LLM 토큰 반복 루프 이해</h3> LLM 공부를 하다 보니 원리가 궁금해져서 예전에 본 뉴로사마 고장 영상</a>의 원인을 찾아보았다. 어떤 이유로 "location"의 선택 확률이 비정상적으로 높아지면, 출력된 "location"이 컨텍스트 윈도우에 누적되고, 컨텍스트에 "location"이 많을수록 다음 토큰으로 "location"을 선택할 확률이 더 높아져서 피드백 루프가 발생한다. 비달(개발자)은 뉴로(LLM 에이전트)에게 중립적인 단어를 계속 말하게 하여 컨텍스트 윈도우에서 "location"을 밀어내서 해결하였다. 짧은 생각</h2> 근황과 요즘 하는 생각 크래프톤 정글 SW 12기에 합격하였고, 참여를 위해 1년 8개월 정도 다닌 회사를 퇴사하게 되었다. 주위에서 주워들은 정보로 보면 충분히 안정적이고 성장 가능성 있는 회사라고 생각하지만, 개인적인 성장에 대한 욕심이 있어 퇴사하게 되었다. 개발용으로 사용할 노트북을 중고로 저렴하게 구했다. 배터리 상태 100%인 MacBook M1 Pro, RAM 32GB / SSD 512GB 모델을 150만 원에 구매했다. BongoCat</a>이라고 데스크톱에서 고양이가 마우스 위치와 타이핑을 따라하는 앱이 재미있고 귀여워 보여 설치했다. 가끔 유튜브에서 비슷한 기능을 버튜버들이 쓰는 걸 볼 수 있고, 나는 작게 우측 하단에 띄워놓으면서 쓰고 있다. [월간 기록] 2026년 1월 Sijun Yang — Sat, 31 Jan 2026 00:00:00 +0000 이번 달에는 정규표현식 내부 구조, 비동기 모델, 스레드 메모리 위치 같은 기술 관련 내용을 파봤다. 기술 관련 글을 읽다가 궁금해진 것들이다. 그리고 여러 개인, 기업, 교육기관에서 AI 활용 능력을 다룬 글들이 많이 눈에 띄었다. 수집</h2> 흥미롭거나 유용했던 자료들The Missing Semester of Your CS Education</a></h3> MIT에서 진행하는 강의다. CS 수업과 달리 명령줄, 에디터, 버전 관리 시스템 등 개발자가 매일 사용하는 도구를 효율적으로 활용하는 방법에 초점을 둔다. 강의 자료와 영상은 인터넷에 공개되어 있어 외부 사용자도 자유롭게 학습할 수 있다. Git, 디버깅, Shell 활용, dotfiles 관리, 기본적인 보안 개념 등 실무에서 알아두면 좋은 주제들을 넓고 얕게 정리해 준다. 관심 있는 주제만 골라서 봐도 이해하는 데 상관없어 부담 없이 볼 수 있다. 2026년 강의는 현재 촬영 중이며, 2020년 이후 새롭게 공개되는 강의이다. LSP와 AI 기반 도구 관련 내용이 추가되고 Shell이나 Vim의 비중은 줄어드는 등, 개발 환경의 변화가 비교적 잘 반영되고 있는 듯하다. 73 Programming Project Ideas to Inspire and Challenge You</a> | HackerNews</a></h3> 직접 구현해볼 수 있는 73개의 프로그래밍 프로젝트 아이디어와 참고 자료를 정리한 글이다. GitHub에서 유명한 build-your-own-x</a> 레포가 있는데, CodeCrafters에서 운영하고 있다. CodeCrafters는 Redis, Git 같은 유명한 프로젝트를 직접 만들어보는 서비스를 제공한다. 관심 가는 프로젝트들이 있어서 시간 나면 시도해볼 생각이다. Regular Expression Matching Can Be Simple And Fast</a> | HackerNews</a></h3> 대부분의 프로그래밍 언어는 backreference, look-around 같은 확장 기능을 지원하기 위해 백트래킹 NFA를 사용하는데, 이 방식은 최악의 경우 지수 시간이 걸릴 수 있다. 반면 Thompson NFA는 이런 확장 기능을 지원하지 못하지만, 최악의 경우에도 O(mn) 시간을 보장한다. awk</code>, grep</code> 같은 전통적인 Unix 텍스트 처리 도구가 이 방식을 사용한다. 정규표현식이 유한 상태 기계(Finite State Machine)로 구현된다는 사실은 들어봤는데, 실제 코드를 보니 더욱 흥미로웠다. 정규표현식과 FSM을 변환해주는 FSM2Regex</a>를 사용해보면 이해에 도움이 된다. Why async Rust?</a> | HackerNews</a></h3> Rust의 async가 왜 현재의 모습을 가지는지 핵심 기여자가 설명한 글. 글 자체로도 좋지만, 다중 스레드의 생성 원리, 비동기 실행 모델과 Rust의 executor에 대한 궁금증이 생겨서 추가로 찾아보게 된 좋은 계기였다. CS146S: The Modern Software Developer</a> | 공식 한국어 번역본</a></h3> Stanford 강의와 공식 한국어 번역본이다. 강의에서 AI 기반 개발을 꽤 자세하게 다루는 것 같다. 번역하는 팀</a>을 봤는데 시니어/리더급 엔지니어 분들이다. AI 기반 번역이고 검수가 되지 않은 듯한 부분에서 누락/오역 등의 문제가 있어 원문과 비교하면서 보는 걸 추천한다. Use The Index, Luke</a></h3> "Introduction to PostgreSQL Indexes" 해커뉴스 글</a>의 댓글에서 추천받아 알게 되었다. 목차까지만 보았는데 SQLP 준비할 때 배웠던 내용과 겹치는 부분이 많아서 잘 구성된거 같고, 여러 DBMS를 다루고 있어서 기억해두려고 한다. AI 시대, 리팩터링은 더 이상 노가다가 아니다</a> | GeekNews</a></h3> 레거시 컴포넌트들이 코드베이스에 혼재하는 문제를 AI와 Codemod로 해결한 사례를 설명한 글이다. AI를 매우 잘 사용한 좋은 예시가 될 수 있겠다. 이런 자동화 관련된 사례가 많이 보이는데, 이제 AI를 사용해서 대규모, 엣지 케이스가 있는 작업도 자동화가 쉽게 가능해진 것 같다. 비슷한 글: Claude Skills로 GitLab 업그레이드 자동화하기</a> 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄여주는 고수들의 행동패턴 따라하기</a></h3> 실력 있는 개발자들의 디버깅 패턴을 정리한 글. 핵심은 원인 파악에 시간을 투자하고, 정상 동작에 대한 심적 표상(머릿속에 구축된 지식 구조)를 쌓아야 한다는 말. 이전에 읽고 실천했을 때 효과가 좋았고, 오랜만에 봐도 좋은 내용이라고 생각한다. MoltBot 제작자: “나는 읽지 않은 코드를 배포한다” | GeekNews</a></h3> 창업자 출신인 Peter Steinberger의 개인 프로젝트지만 많은 관심을 받고 있는 Moltbot</a>은 메신저를 인터페이스로, 로컬 머신을 실행 환경으로 사용하는 LLM 에이전트 게이트웨이다. 로컬에서 지속적으로 실행되며 개인용 AI 에이전트로 활용할 수 있다. 개발 워크플로우를 다룬 인터뮤가 공개되었는데, AI 에이전트를 적극 활용한 개발 방식을 사용한다. 코드 자체보다 프롬프트를 보고 결과물을 평가하는 접근이 인상적이였다. 물론 책임 소재가 사용자에게 있는 오픈소스에 개인 프로젝트라서나 가능한 방식이고, 회사 환경에서는 책임 소재나 검증 문제로 그대로 적용하기 어려울 거 같다. 에이전트 기반 개발의 한 방향성으로 참고할 만하다. 성공하는 언어의 조건, C를 계속 배워야 하는 이유에 대한 의견</a></h3> 간단한 토이프로젝트를 만드려고 했는데 애플이 제공하는 C 라이브러리를 사용해야 했다. Rust는 FFI가 필요해서, C 라이브러리를 바로 쓸 수 있는 Zig로 해볼까 검색하며 찾아보는 흥미로운 의견을 발견헀다. Zig는 성공하는 언어의 기준에 맞지 않아 성공하기 어렵고 C는 여전히 필요하다는 흥미로운 의견을 발견했다. 극단적이긴 하지만, 언어가 기업의 선택을 받고 성공하는 기준에 대해 그럴듯하고 공감가는 의견이라 기록해둔다. 그 외 수집한 글</h3> AI 시대의 소스코드 품질 - akwiki</a>: AI로 작업하면서 품질 하락을 막기 위한 구체적인 도구들을 소개한다.</li> 타입 시스템은 왜 증명처럼 동작하는가</a>: 예전에 OCmal 공부할 때 Hindley-Milner, Curry-Howard 같은 타입 이론을 들어봤는데, TypeScript를 이런 Curry-Howard 이론 관점에서 설명한다. 언어를 Curry-Howard 이론으로 설명하는게 무용하다는 의견</a>도 있다.</li> Sylvain Kerkour의 블로그</a>: Rust, 보안에 대한 내용을 다룬다. Dev Containers</a>, 오류 처리</a>, Rust, Axum, SQLx 스택</a>, 대규모 코드베이스 권장사항</a>, 아키텍처</a> 등을 다룬다. 다만 웹 개발/보안 쪽에 치우쳐져 있고 동의하지 않는 주장도 있어 주의하기.</li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들"시간 데이터를 올바르게 다루는 방법"</a> 블로그 작성</h3> 원래는 핵심 원칙만 간단히 정리할 생각이었지만, 쓰다 보니 시간 처리의 역사나 참고한 Temporal API까지 추가하는 게 이해하기 좋을 것 같아 내용이 대폭 늘었다. 그 과정에서 글의 완성도를 신경 쓰다 보니 시간이 많이 들었다. 다음에 블로그를 쓸 때는 머릿속으로 구조를 완성해두고 명확히 잡는 편이 좋을 것 같다. 이번 글은 아직 하나의 글로 마무리하기에는 준비가 덜 된 주제여서 많은 시간이 걸렸다. Thompson NFA 구현 이해하기</h3> Regular Expression Matching Can Be Simple And Fast</a> (한국어 번역</a>) 글을 보고 Python 코드로 바꿔가며 이해를 높이려고 했다. 정리한 Gist 글</a>. AI를 쓰기도 했고, 실제로 여러 번 따라 쳐본 건 아니라 확실하게 이해했다고 하기엔 무리지만, 일단 이 정도면 충분한 것 같다. 정규표현식이 어떻게 오토마타로 구현되는지, 백트래킹 방식과 Thompson 알고리즘의 차이가 무엇인지 코드를 통해 이해할 수 있었다. The Missing Semester of Your CS Education 강의 학습</h3> 위에서 소개한 MIT 강의를 2020년 버전 위주로 영상과 스크립트를 훑어보았다. 깊이는 얕지만 무엇을 공부해야 할지 폭넓게 다뤄서 좋았다. 모르는 내용도 꽤 있었고, 2026년 강의에서 AI 관련 내용이 추가되는 것 같아 그것도 나중에 볼 예정이다. 강의 노트</a>는 메모하고 AI로 내용 요약한 정도라 기억에 오래 남진 않을 것 같다. 필요할 때 찾아보는 정도로 쓸 듯. AI로 탐색: 비동기 모델과 메모리 구조 정리</h3> "Why async Rust?"</a>를 읽다가 궁금해진 부분을 파고들다 보니 비동기나 스레드의 메모리 위치에 대한 사실들을 알게 되었다. Gist에 정리하였다. Rust 비동기 실행 모델의 내부 원리</a></li> Linux 스레드와 메모리 구조</a></li> Stackful 비동기의 동작 방식 & 비동기 실행 모델의 분류</a></li> </ul> DB Hub</a>를 사용한 MCP Server 사용</h3> 추가 — 2026/02/03 어제(02/02) OpenAI가 Mac용 Codex App을 출시했다.</a> 이를 활용하면 별도 채팅 UI를 구축할 필요가 없고, 인증/설정에 필요한 env 기반 Bearer token과 Headers를 지원하므로 OAuth Provider 서버를 구축할 필요도 없어졌다. key-value 기반의 액세스 키만 발급/관리 기능만 만들면 가볍게 사용하기 충분하다. 가이드 문서를 제공하여 비개발 직군도 손쉽게 DB 분석 환경을 사용할 수 있게 되었다. </blockquote> 추가 — 2026/02/12 최근에 MCP 서버를 공부하다가 알게 되었는데, OAuth Provider를 Auth0 같은 별도 서비스를 통해 직접 만들지 않고, mcp-auth-proxy와 같은 프록시를 사용하면 Github이나 Google 같은 외부 Provider를 사용해도 된다.</a> Google 기반을 사용하면 조직 도메인 등으로 검증할 수 있어 세세한 권한 제어가 필요없는 작은 규모의 조직에서는 좋아보인다. </blockquote> 회사에서 비개발 직군도 회사 DB에 접근할 수 있게 하는 것이 목적이었는데, 관리 비용과 보안 문제로 실패했다. 결국 몇몇 분에게만 VSCode + Codex 환경을 임시로 세팅해 드렸다. 대신 개발 쪽에서 아주 유용하게 쓰고 있다. 팁: 레거시로 인해 스키마/컬럼명이 명확하지 않다면, Comment를 함께 전달하도록 tool을 작성하면 AI가 컨텍스트를 더 정확히 파악한다. 문제 배경: 회사 DB 접근 MCP 서버를 비개발자도 안전하게 사용하게 하려면? MCP 연동 방식별 특성: - 로컬 개발 도구 (Codex, Claude Code 등): 로컬에서 직접 MCP 서버 호출 → IP 화이트리스트 적용 가능 - 로컬 데스크톱 앱 (Claude 앱 등): 외부 MCP 서버 연결 기능 미지원 - 웹 서비스 (GPT, Claude 웹): AI 회사 서버 경유 → 우리 측 IP 제한 불가 선택지: 1. 외부 IP 노출 안 함 ├─ a. 로컬 개발 도구 사용 (Codex, Claude Code 등) │ → 문제: 비개발자 사용 어려움, UX 목적과 불일치 │ └─ b. 자체 중간 서버 구축 (LLM API + MCP 연동) → 문제: 별도 개발/운영 필요 별도 채팅 UI/서버 필요 (슬랙 연동 등으로 UI 대체가 가능하나 자유로운 대화가 제한) API Key 비용 발생 → 장점: IP 화이트리스트 유지 가능 2. 외부 IP 노출함 ├─ a. OAuth Provider 서버 구축 → 자체 인증 │ → 배경: 웹 환경의 Claude/GPT MCP 커넥터는 OAuth 인증 외에 다른 인증은 지원하지 않음 │ → 문제: OAuth Provider 인프라 개발 필요 │ → 장점: GPT/Claude 웹에서 바로 사용, UX 최적, 사용자 관리 가능(IP보다 세밀한 제어 가능) │ └─ b. 퍼블릭 개방 → 제외 (보안 불가)</code></pre>AI로 인한 학습과 성장 방향성에 대한 생각</h3> 요즘 해커뉴스나 긱뉴스를 보면 AI와 개발자 커리어에 대한 글이 자주 올라온다. 극단적인 의견도 있지만, 대부분의 의견은 이렇다. AI로 인한 변화는 피할 수 없고, 시니어급 개발자들이 보기에도 기존 개발 작업 대다수를 대신할 수 있을 정도로 발전했다. 관련한 의견들을 보면서 정리한 생각은, 앞으로 주니어가 성장해야 할 방향에는 크게 3가지 능력이 필요하고 이를 키우기 위해 노력해야 한다는 것이다. 올바른 의사결정을 위한 CS 및 기초 지식 기초 지식은 개발뿐 아니라 도메인도 해당될 수 있다. 다만 주니어에게 도메인까지 기대하긴 어렵다.</li> 프레임워크 기반 개발을 하던 과거에도 기초 지식은 중요했다. AI 시대가 되어도 이건 바뀌지 않는다.</li> </ul> </li> AI 활용과 도구 선택 능력 AI를 적절한 영역에 사용하고, 자동화/프롬프팅/에이전트 활용을 통해 효과적으로 동작하게 하는 능력이 중요하다.</li> 동시에 AI가 잘 못하는 부분은 다른 도구로 보완할 수 있어야 한다.</li> </ul> </li> 넓은 범위의 학습/적용 능력 T자 인재의 필요성은 여전하다. 과거에는 신입에게 하나를 제대로 하거나 기초만 있어도 충분했다.</li> 그러나 AI로 인해 다른 영역으로 확장하기 쉬워졌으므로, 주니어도 그 능력을 키워야 한다.</li> </ul> </li> </ol> 관련되서 이번 달에 보았던 글을 정리해두었다. LLMs and your career</a> | GeekNews</a></li> Andrej Karpathy(OpenAI 공동 창립자)의 Claude 코딩 경험</a> | GeekNews</a> | HackerNews</a></li> Don't fall into the anti-AI hype - antirez(Redis 창시자)</a> | HackerNews</a></li> The Next Two Years of Software Engineering</a> | GeekNews</a></li> XP, TDD, 그리고 바이브 코딩: Kent Beck(TDD/XP 창시자)의 인터뷰 번역</a></li> </ul> 짧은 생각</h2> 근황과 요즘 하는 생각 요즘에 AI 활용을 더 적극적으로 시도해보려고 하고 있다. 세계 상위권 대학들이 AI 관련 내용을 커리큘럼에 빠르게 추가하는 걸 보면, 교육 현장에서도 이런 능력이 중요하다고 판단하는 것 같다. 시간 데이터를 올바르게 다루는 방법 Sijun Yang — Mon, 12 Jan 2026 00:00:00 +0000 프로그래밍을 어느 정도 해봤다면, 시간 관련 버그를 한 번쯤은 겪거나 들어보았을 것이다. 서버 환경을 바꾸니 시간이 9시간 밀린다거나, 로컬에서는 잘 되던 게 배포만 하면 시간이 이상하게 보인다거나. 이런 버그가 종종 보이는 이유는 단순한 문자열1</a>이나 정수형 타입과 다르게 시간 데이터의 다루는 데 생각보다 많은 주의사항이 존재하기 때문이다2</a>. 이 글에서는 시간 데이터의 두 가지 타입과 관련 문제들을 살펴본 뒤, 내가 사용하는 두 가지 원칙을 소개한다. 마지막으로 이 원칙에 영향을 준 JavaScript Temporal API를 간단히 다룬다. 익숙한 Java/JavaScript 생태계를 중심으로 설명하지만, 모든 언어에 적용 가능하다. 시간의 2가지 타입</h2> 시간 데이터는 크게 두 종류로 나눌 수 있다. Exact Time(물리적 순간): 유일한 하나의 시점을 가리킨다. "2024-01-01T00:00:00+00:00"는 전 세계 어디서든 같은 순간이다. Unix timestamp나 UTC 오프셋을 포함한 ISO 8601 형식(예: 2024-01-01T00:00:00Z)이 여기에 해당한다. Wall-clock Time(벽시계 시간): 특정 시점이 아니라 날짜와 시간 값 자체를 의미한다. "12월 25일"은 뉴욕 시간이나 한국 시간처럼 특정 지역의 시간을 의미하지 않는다. JavaScript의 Temporal API가 이 개념을 잘 설명해서, 이 글에서도 Temporal의 용어를 차용하여 설명한다. 시간 데이터를 다룰 때 주의해야 할 점</h2> 타임존 정보 손실</h3> Java의 LocalDateTime</code>은 Local-</code>로 시작하는 이름에서 유추할 수 있듯이 타임존 정보를 저장하지 않는다. 하지만 LocalDateTime.now()</code>를 호출하면 시스템의 기본 타임존을 사용해서 현재 시각을 가져온다3</a>. Python의 datetime.now()</code>나 C#의 DateTime.Now</code>도 비슷하게 절대 시점을 저장하지 않는다. 이러한 함수를 보았을 때 타임존 변환이 일어났는지 알기 어렵다. 또한 내부 구현에서 타임존 정보를 유지하지 않는다. 객체 생성하는 도중 타임존을 사용해서 변환은 했지만, 결과 객체에선 어떤 타임존이었는지는 저장하지 않는 것이다. 그래서 이 값을 직렬화하거나 저장하면 어느 지역의 시간인지 알 수 없게 된다. 직렬화할 때 로컬의 시간대 정보를 함께 보내면 되지 않나 싶지만, now()</code> 호출 시 타임존을 직접 지정하는 것도 가능하기 때문에 선언 시점을 제외하면 어떤 타임존이었는지 알 방법이 없다. 특히 요즘의 서비스에선 아주 많은 "로컬"이 존재할 수 있다. 클라이언트와 서버만 있는 간단한 웹 서비스도 2개의 노드가 존재한다. MSA 서비스라면 LB, DB, Redis, 모니터링 등 서버만 수십 개가 넘어갈 수도 있다. 이때 타임존 없는 시간 문자열을 주고받으면, 원래 어떤 타임존이었는지 복구할 방법이 없다. 여러 기술의 함정</h3> 다양한 기술 스택에서 타임존 처리와 관련된 함정들이 존재한다. 직렬화 라이브러리, ORM, DB 등에서 타임존 관련 기본 설정이나 옵션이 직관적이지 않아 의도하지 않은 동작을 유발할 수 있다. 몇가지 예시를 살펴보자. Jackson</h4> DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE</code>4</a>은 기본적으로 true로 설정되어 있는데, 이 옵션이 활성화되어 있으면 ZonedDateTime</code>이나 OffsetDateTime</code>을 역직렬화할 때 원본 타임존을 컨텍스트 타임존(기본값 UTC)으로 변환한다. 이 과정에서 시점 정보는 유지되지만, 원래 타임존 정보를 잃어버린다 (이 옵션은 Jackson 3버전 부터 DateTimeFeature</code> 객체로 이관되었다5</a>). ANSI SQL의 TIMESTAMP WITH TIME ZONE</h4> ANSI SQL 표준의 TIMESTAMP WITH TIME ZONE</code> 데이터 타입은 이름과 달리 타임존 정보를 유지해야 한다는 요구사항이 없다6</a>. 그래서 Oracle의 경우 타임존 정보를 저장하는 반면, PostgreSQL은 타임존 정보를 저장하지 않는 등 제각각의 구현이 존재한다. PostgreSQL을 자세하게 설명해보자면, 데이터 타입 timestamp</code>(timestamp without time zone</code>)는 문자열로 Wall-clock Time 정보를 저장한다. 그래서 시간 비교 등의 연산에서 취약하다7</a>. Exact Time을 저장하려면 timestamptz</code>(timestamp with time zone</code>)를 사용해야 하는데, UTC로 변환되어 저장되고 타임존 정보는 유지되지 않는다. 또한 조회 시 세션의 타임존에 의존하여 시간 결과를 반환한다. JPA와 Hibernate</h4> Hibernate는 6.0 이후부터 LocalDateTime</code>은 TIMESTAMP</code>, Instant</code>는 TIMESTAMP_UTC</code>로 매핑된다8</a>. TIMESTAMP_UTC</code>는 저장 시 값을 UTC로 정규화하지만, TIMESTAMP</code>는 변환 없이 그대로 저장된다. 즉, 두 타입을 Exact Time 표현용과 Wall-clock Time 표현용으로 구분하고 있다. Hibernate는 LocalDateTime</code>을 DB에 저장할 때 JVM 기본 타임존을 기준으로 java.sql.Timestamp</code>로 변환한 뒤 UTC로 정규화한다. 이 과정에서 원본 타임존 정보가 사라진다. 여러 DB 접근 라이브러리를 함께 사용하는 환경에서는 각 라이브러리의 타임존 설정 차이로 인해 시간 오차가 발생할 수 있다9</a>. Spring Data 개발자 Jens Schauder 역시 LocalDateTime</code>은 타임라인 상의 특정 순간을 표현할 수 없으므로 Instant</code>를 사용하는 것이 바람직하다고 설명한다10</a>. 그럼에도 불구하고 많은 코드에서 여전히 Exact Time 데이터를 LocalDateTime</code>으로 선언해 사용하고 있다 (예: spring-boot-java-template BaseEntity의 createdAt, updatedAt</a>). 시간 데이터를 다루는 2가지 원칙</h2> 나는 시간 데이터를 다룰 때 두 가지 원칙을 기준으로 삼고 있다. 이걸 꼭 따라야 한다는 말은 아니다. 하지만 "모든 노드(클라이언트, 서버, DB, 캐시 등)에서 시간 데이터에 대한 해석이 일관되어야 한다."는 조건을 만족하려면 이 원칙과 비슷한 결론에 도달할 것이다. 원칙 1: Exact Time과 Wall-clock Time을 명확히 구분하라</h3> 시간 데이터가 특정 시점을 나타내는지, 아니면 단순한 날짜/시간 값인지 먼저 판단해야 한다. 로그 타임스탬프, 결제 완료 시각, 이벤트 발생 시각처럼 "언제 일어났는가"가 중요한 데이터는 Exact Time으로 저장한다. Exact Time이 아니면 정확한 시점을 알 수 없기 때문이다. LocalDateTime.now()</code>처럼 타임존 정보가 사라지는 방식으로 저장하면, 나중에 원래 시점을 복구할 방법이 없다. 생일, 기념일, 공휴일처럼 특정 시점이라는 개념 자체가 없는 데이터는 Wall-clock Time으로 저장해서 날짜/시간 값 자체만 저장한다. 이런 데이터를 Exact Time으로 다루면 오히려 문제가 생길 수 있다. 단, 이 기준은 도메인에 따라 달라진다. 산부인과 병원 시스템이라면 출생아의 생일이 출생 시점(Exact Time)으로 관리되어야 할 수 있다. 저장 포맷</h4> 각 타입에 적합한 저장 포맷을 사용해야 한다. Exact Time: Unix timestamp (밀리초 또는 초 단위 정수)</li> PostgreSQL의 TIMESTAMPTZ</code></li> ISO 8601 with offset (예: 2024-01-01T00:00:00Z</code>)</li> </ul> Wall-clock Time: DATE</code> 타입 (예: 2024-12-25</code>)</li> TIME</code> 타입 (예: 14:30:00</code>)</li> 문자열 (예: "2024-12-25"</code>, "14:30"</code>)</li> </ul> 타입 객체 선언 시점 주의사항</h4> 대부분의 시간 관련 버그는 코드에서 시간 타입을 생성할 때 발생하므로 주의 깊게 보아야 한다. Exact Time이 필요한 곳에서 LocalDateTime.now()</code>를 쓰고 있지는 않은지 확인한다. Instant.now()</code> 또는 System.currentTimeMillis()</code>를 사용해야 한다.</li> Wall-clock Time이 필요한 곳에서 UTC 변환을 하고 있지는 않은지 확인한다. LocalDate.of(2024, 12, 25)</code>처럼 날짜 값 자체만 저장해야 한다.</li> </ul> 원칙 2: Exact Time은 UTC로 저장하고, 타임존은 별도 관리하라</h3> Exact Time 데이터는 저장, 직렬화/역직렬화, 송수신 등 모든 과정에서 UTC 또는 Unix timestamp로 처리한다. 타임존이 필요한 경우</h4> 비행기 출발 시각, 회의 시간처럼 특정 지역의 시간 표현이 필요한 경우에는 Exact Time과 타임존을 별도 필드로 관리한다. 내부적으로는 UTC(Unix timestamp)로 저장하고, 사용자에게 보여줄 때만 해당 타임존으로 변환한다. 이렇게 하면 시간 비교나 집계 등의 계산이 편리해진다. 저장된 값 자체가 바뀌지 않기 때문이다. 앞서 말했듯 타임존 타입의 지원이 아직 완전하지 않거나 주의해야 하는 시스템이 존재하기 때문에^{11</a>, 모든 곳에서 타임존을 UTC로 고정하거나 타임존 정보가 없는 Exact Time인 Unix timestamp 형태로 관리하는 것이 안전하다.} 전송/저장 시점 주의사항</h4> DB 저장, API 직렬화 등의 과정에서 정보가 손실되는지 확인해야 한다. 명시적인 포맷이나 타입 계약이 없다면, 동일한 값이라도 시스템마다 다르게 해석될 수 있다. DB 데이터 타입, gRPC 같은 스키마 기반 통신 처럼 포맷(타입) 계약이 존재하면 이를 그대로 따른다. JSON이나 텍스트 기반 통신처럼 계약이 없거나 범용 포맷이 필요한 경우, Unix timestamp 또는 UTC 오프셋을 포함한 ISO 8601을 사용한다. ISO 8601는 가독성이 높고, 대부분의 직렬화 라이브러리에서 기본 지원된다. Unix timestamp는 숫자 자체가 절대 시각이므로 해석 오류 여지가 없고, 저장 공간도 적다. 다만 자동 변환을 지원하지 않는 환경에서는 추가 처리가 필요하다. DST와 정책 변경 대응</h4> 타임존과 시간대 정보가 포함된 데이터를 다루는 경우, 여러 가지 모호한 상황(Ambiguity)이 발생할 수 있다. 이와 관련된 구체적인 예시는 "Temporal Time Zones and Resolving Ambiguity - Temporal Proposal Documentation"</a>에서 찾을 수 있다12</a>. DST 시작/종료 같은 일시적 Offset 이동으로 인해서 동일한 벽시계 시간이 두 번 발생(fall back)하거나 존재하지 않는 시간(spring forward)이 생길 수 있다.</li> 정책 변경으로 TimeZone 정의가 변경되어 기존에 저장된 미래 시점의 값과 새로운 규칙 간 충돌이 발생할 수 있다.</li> </ul> 지금 설명중인 2가지 원칙들을 따르면 이러한 문제 대부분을 피할 수 있다. UTC로 저장하면 DST 영향을 받지 않는다. DST는 특정 타임존의 오프셋이 변경되는 것이지, UTC 자체가 바뀌는 것이 아니기 때문이다.</li> 타임존 ID를 별도 필드로 저장하면 정책 변경 시에도 올바른 현지 시간을 계산할 수 있다. IANA 타임존 데이터베이스가 업데이트되면 새로운 규칙이 자동으로 적용된다.</li> </ul> Temporal API 소개</h2> 역사적 배경</h3> 1996년 Java 1.0에서 java.util.Date</code>가 도입됐다. 이는 많은 문제가 있는 구현이였는데, 월이 0부터 시작하고 연도는 1900을 빼서 저장하고 객체가 mutable해서 언제든 값이 바뀔 수 있었다13</a>. JavaScript가 만들어질 때, Java의 Date 구현을 거의 그대로 가져왔다14</a>. Java는 이후 개선을 시도한 반면, Date는 거의 30년이 지난 지금까지 사용되고 있다. (그래서 프로덕션 환경에선 별도의 시간 라이브러리를 많이 쓴다.) 2002년 Stephen Colebourne이 Java Date의 문제를 보완한 Joda-Time 라이브러리를 만들었다. Joda-Time은 큰 성공을 거뒀고, 2014년 Java 8의 공식 java.time</code> 패키지(JSR-310)로 이어졌다15</a>. JavaScript에서는 Date의 문제를 해결하기 위해 Temporal API 제안이 진행되었고, TC39(ECMAScript 기술위원회)에서 이 제안은 Stage 3(명세가 확정되어 구현을 진행) 상태에 있다. Temporal의 설계</h3> Temporal은 Exact Time과 Wall-clock Time의 구분을 타입 시스템에서 강제한다. 원본 링크</a> 위 다이어그램에서 왼쪽은 Exact Time(물리적 순간)을 아는 타입들이고, 오른쪽은 Wall-clock Time(벽시계 시간)을 아는 타입들이다. Temporal.Instant</code>는 물리적 순간만 표현한다. 타임존이나 캘린더 없이 절대 시점만 저장한다. Temporal.ZonedDateTime</code>은 물리적 순간에 타임존과 캘린더를 더해서 양쪽에 걸쳐 있다. 반면 Plain-</code> 접두사가 붙은 타입들(PlainDateTime</code>, PlainDate</code>, PlainTime</code> 등)은 타임존 정보가 없다. 원본 링크</a> 이 다이어그램은 각 타입이 문자열로 직렬화될 때 어떤 정보가 포함되는지 보여준다. Instant</code>는 UTC 시간만, ZonedDateTime</code>은 오프셋과 타임존 ID까지, Plain</code> 타입들은 날짜/시간 정보만 포함된다. Plain vs Local</h3> 여기서 "Plain"이라는 네이밍이 중요하다. java.time의 "Local"은 이름에서 위치를 암시하지만, "Plain"은 타임존에 대한 어떤 가정도 없다는 것을 명확히 보여준다. 단순하게 날짜와 시간 값 자체만을 표현한다는 의미가 더 직관적으로 드러난다. Temporal의 설계자들 역시 이러한 의도를 가지고 Plain이라는 이름을 선택했다16</a>17</a>. Temporal.Now의 분리</h3> Temporal은 "now"를 다루는 방식이 기존의 일반적인 라이브러리와 다르다. Temporal.Now</code>라는 별도 객체가 존재해서, Temporal.Now.instant()</code>나 Temporal.Now.plainDateTimeISO()</code> 같은 형태로 사용한다. 현재 시각 조회를 별도 API로 분리해서 타임존 정보 손실이 발생할 수 있다는 것을 API 표면에서 명확하게 알려준다. 반면 java.time에서는 LocalDateTime.now()</code>처럼 각 타입에 now 메서드가 붙어 있어 정보 손실이 발생 가능하다는 것이 명확하지 않다. 애매모호한 상황 처리</h3> Temporal은 Plain 타입에서 Exact 타입으로 변환할 때 발생하는 모호함을 다루는 방법을 개발자가 선택할 수 있게 한다12</a>. 앞서 제시한 원칙을 따르면 이런 기능이 필요한 상황 자체가 드물어진다. 다만 레거시 데이터 마이그레이션이나 사용자 입력 처리 같은 예외 상황에서는 유용하므로, 어떤 옵션을 제공하는지 알아두면 좋다. References</h2> 사실 문자열도 그렇게 단순하지는 않다. 유니코드, 인코딩, 정규화 등 고려해야 할 사항이 많다. 이와 관련해서는 The Absolute Minimum Every Software Developer Must Know About Unicode in 2023</a>, UTF-8 Everywhere</a>, 아�니 이 글자 왜 들어간 거예요?</a> 같은 글을 읽어보는 걸 추천한다. ↩</a> </li> 여기서 다루는 내용과 별개지만, 시간 데이터의 정확성 자체도 완벽하지 않다. 분산 시스템에서 "정확한 시간"을 정의하는 것 자체가 매우 어려운 문제다. 이와 관련해서는 "Designing Data-Intensive Applications"</a>, Chapter 8: 'Unreliable Clocks'를 읽어보는 것을 추천한다. ↩</a> </li> OpenJDK, "LocalDateTime.java source code"</a>, GitHub. ↩</a> </li> Jackson, "DeserializationFeature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE"</a>, JavaDoc. ↩</a> </li> Jackson 3.0.3, "DateTimeFeature"</a>, JavaDoc. ↩</a> </li> SQL-92 Standard, Section 4.5 "Datetimes and intervals" - Modern SQL</a>, Full Draft</a>. ↩</a> </li> PostgreSQL Wiki, "Don't Do This"</a>. ↩</a> </li> Hibernate ORM, "Instant mapping changes"</a>, Migration Guide, Version 6.0. ↩</a> </li> jOOQ GitHub, "LocalDateTime param binding handled differently by hibernate"</a>, Issue #11753, 2021. ↩</a> </li> Jens Schauder, "Don't use LocalDateTime"</a>, Schauderhaft Blog, 2018. ↩</a> </li> Hibernate ORM Discussion, "Support timestamp with timezone/offset"</a>, GitHub. ↩</a> </li> TC39, "Temporal Time Zones and Resolving Ambiguity"</a>, Temporal Proposal Documentation. ↩</a> ↩2</a> </li> Oracle, "Legacy Date-Time Code"</a>, The Java Tutorials. ↩</a> </li> Allen Wirfs-Brock, Brendan Eich, "JavaScript: The First 20 Years"</a>, Proceedings of the ACM on Programming Languages, Volume 4, June 2020 (비공식 한국어 번역</a>). ↩</a> </li> Oracle, "Java Date Time APIs"</a>, Java Platform, Standard Edition 8; JSR 310 Expert Group, "JSR 310: Date and Time API"</a>, Java Community Process. ↩</a> </li> TC39 Temporal Proposal, "What should be the long-term name of LocalDateTime?"</a>, GitHub Issue #707. ↩</a> </li> 여러 시간 라이브러리에서 사용되는 Local-</code> 네이밍은 C언어의 localtime()</code></a> 함수에서 유래했을 것으로 추측한다. 표준처럼 굳어진 용어를 바꾸자는 주장에 마냥 동의하지는 않지만, Local-</code>의 의미가 명확하지 않은 것은 사실이라 이 경우에는 이름을 바꾸는 결정이 합리적이라고 본다. ↩</a> </li> </ol> </section> [월간 기록] 2025년 12월 Sijun Yang — Wed, 31 Dec 2025 00:00:00 +0000 RDB 기반 큐로 회사 내부에 문제 많던 코드를 개선했는데, 만족스러운 경험이였다. 나중에 기회가 되면 다뤄볼까 한다. 또한 새로운 블로그 글도 작성했는데, 이 두 작업에 이번 달의 대부분을 투자했다. 수집</h2> 흥미롭거나 유용했던 자료들Lobsters - 해커뉴스와 비슷하지만 초대제로 운영되는 커뮤니티</a> | GeekNews</a></h3> 기본적으로 해커뉴스를 더 많이 보긴 하는데, 여기에도 재미있거나 유익한 내용이 많다. 업로드 가능한 사람이 제한적이라 그런지 올라오는 글이 해커뉴스와 잘 겹치지 않는 것 같다. SQLite는 어떻게 테스트되는가</a> | GeekNews</a></h3> SQLite의 테스트 방법론에 대한 공식 문서이다. SQLite가 최근 서버 쪽에서도 사용하자는 의견이 종종 보여서 찾아보다가 알게 되었다. 로컬에서 돌려도 될 만큼 가볍고, 생각보다 높은 성능과, 수많은 기기에서 쓰일만큼 높은 신뢰도가 마음에 든다. 토이프로젝트에서 서버를 만들어야 한다면 Rust, SQLite를 사용해 만들어보고 싶다는 생각을 하고 있다. SQLite의 알려지지 않은 이야기 | GeekNews</a>나 Quality Management</a>도 함께 보면 좋다. Wide Events: 로깅의 새로운 패러다임</h3> Wide Events 소개 | GeekNews</a></li> Logging Sucks - Wide Events 공식 사이트</a></li> HackerNews 토론</a></li> </ul> 기존 로깅 방식의 근본적인 문제를 해결하려는 새로운 접근법. 요청당 수십 줄의 분산된 로그 대신, 하나의 포괄적인 구조화된 이벤트를 발행하자는 의견이다. 공감하는 사람들도 많을거라 생각하는데, 서비스의 로그를 분석하다 보면 불편한 상황이 많이 생긴다. 필요한 정보를 주는 로깅이 없다거나, 연결된 로그를 찾기 어렵다거나 등등. 실제 운영을 통한 평가를 받아봐야 확실해지겠지만, 이 기법을 사용한다면 문제 해결이 쉬워지지 않을까 싶다. 나날이 발전하고픈 개발자를 위한 AI 활용법</h3> 발표 자료 (PDF)</a></li> 유튜브 영상</a> X</a></li> </ul> </li> </ul> 관심 가는 거만 메모했다. 빠진부분이 많다. 조언 AI는 변화가 빨라서 몇 개월만 지나도 지식이 outdated됨</li> 학습 모드(Study Mode) 등 LLM이 제공하는 새로운 기능들을 시도해봐야 함</li> 여전히 가장 중요한 인사이트(고객, 지식)는 사람으로부터 나온다</li> AI 관련 무료 공식 자료가 풍부함: Anthropic Prompt Engineering</a>, Google Prompt Engineering</a>, OpenAI Prompt Engineering Guide</a>, Anthropic Courses</a>, deeplearning.ai</a> (메모: 요즘엔 Vercel의 React 프롬프트, Supabase의 PostgreSQL 프롬프트 같이 프롬프트 공유도 많이 하는 듯)</li> </ul> </li> </ul> </li> 코딩 관점 What + Why를 효과적으로 주는 프롬프팅: STICC</a></li> 여전히 일부 분야에서 How가 필요: CTA(Cognitive Task Analysis, 인지 작업 분석)필요. AI와 반복적인 학습을 통한 이해. AI가 메타 평가.</li> MCP는 다양한 기능이 있지만 대부분 툴 기능만 사용됨, 켰다 껐다 가능하므로 필요할때만 써서 토큰 아끼기</li> 정적 타입 검사, 린터 등 Validator 활용하기, AI보다 정확함: AI 시대의 소스코드 품질</a></li> 디버깅 마인드셋</a>, 인프콘 2014 발표</a></li> Kent Beck의 TDD와 AI 관련 내용: XP, TDD, 그리고 바이브 코딩: Kent Beck의 Programmatic Engineer 인터뷰 일부 번역</a></li> </ul> </li> 제품 개발 관점 문제 정의(누구를 위해, 왜, 무엇을)에서부터 시작함</li> LLM/에이전트가 항상 정답은 아님: 비용을 지불하는 건 문제 해결이지 AI 자체가 아님</li> 미국 VC가 언급한 지금 AI로 창업하기 어려운 분야들</a></li> MVP, MMP, MLP 개념과 올바른 이해: MVP, MMP, MLP, MDP, MAP 스타트업 단계 가이드 : r/startups</a>, MVP, MMP or MLP. What's best?</a>, MVP에 대한 정확한 해석에 대한 의견</a></li> </ul> </li> </ul> 그 외</h3> 시궁쥐(Rat)에게 DOOM 학습시키기</a>: 그냥 순수하게 재미있는 프로젝트. 지금도 진행중인 듯</a>하다.</li> AWS ECS의 리버스 프록시 사이드카 패턴 | Containers on AWS</a>: AWS 직원들이 운영중인 비공식 블로그의 글. 가끔 보이는 패턴인데 명확한 이유를 찾기 어려워 궁금했던 내용. 주요 이점은 작업 분담(압축), 효율적인 트래픽 처리이다.</li> 오픈 소스 어플리케이션의 아키텍쳐 | GeekNews</a>: 인사이트 출판사에서 1권 번역본을 샀었는데, 원서</a>는 무료로 공개되어 있다. 많은 오픈소스 프로젝트의 핵심 기여자들이 프로젝트의 설계 철학을 말해준다.</li> Tokio와 Compio의 차이 - 비동기 모델 비교 | Reddit</a>: epoll vs io_uring 기반 비동기 런타임의 차이점. IGGY의 주요 개발자가 답글을 달았는데 쉽게 설명해준다.</li> 태그로 돌아본 웹의 30년 | GeekNews</a>: 웹 생태계의 진화 과정을 다룬 글. 프론트엔드뿐 아니라 백엔드 개발자도 알면 유익한 내용. 관련 글: JavaScript의 간략한 역사 | GeekNews</a></li> </ul> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들RDB 기반 큐를 사용해보기</h3> DB의 작업 성공과 함께 사이드이펙트나 추가 처리(알림, 비동기 처리)가 필요한 경우, MQ가 유용하다. 하지만 당장 고트래픽 처리와 확장성이 필요 없다면 DB 기반 스케줄러를 쓰는 게 더 좋다. (90% 이상의 경우 여기에 해당할 것이다.) 회사에서 db-scheduler</a>를 사용하여 별도 인프라 추가 없이 단계별로 복구 가능한 Task를 만들 수 있었고, 기존의 여러 문제를 해결하는 만족스러운 결과를 얻었다. 이에 대한 건 따로 블로그를 써볼 예정이다. 우아한형제들 기술블로그에서도 유사한 패턴을 직접 구현한 사례</a>가 있다. (왜 직접 만들었는지는 모르겠지만) Rust에는 apalis</a>가 제일 유명한 거 같다. 블로그 글 "동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나</a>" 작성</h3> X에서 개발 관련 포스팅을 보면서 시간을 때우곤 하는데, 동기/비동기 관련 사분면이 잘못되었다는 글</a>을 보게 되었다. 명확하게 설명은 못했지만 저런 사분면으로 나눠서 설명하는 것이 뭔가 이상하다는 생각을 가지고 있던 터라, AI를 활용해 여러 자료를 찾아보았다. 이런 사분면 설명은 잘못된 설명이라는 걸 알게 되어 글을 작성했다. 요즘엔 AI를 사용하면 이전에 비해 자료 검색 속도가 말도 안 되게 빨라졌다. 정확한 자료를 빠르게 찾아볼 수 있어서 좋다. 짧은 생각</h2> 근황과 요즘하는 생각 기존에 오픈소스 기여에 관심을 가지고 더 깊이 있는 부분에 참여하고 싶었지만, 아직 많이 부족함을 느끼고 있다. 기초적인 능력 향상에 집중하기 위해 한동안은 쉴 예정이다. AI를 개발과 자료조사에 적극 활용하면서, 공식문서나 개념을 쉽게 풀어쓴 블로그 글을 볼 필요가 없어졌다. 이제는 전문성 있는 글이나 개인적인 시선이 담긴 글 위주로 보고, 나도 그런 글을 쓰려고 하고 있다. (어떻게 보면 AI가 저품질 글을 대체했다고 볼 수 있을까?) [월간 기록] 이전 자료 모음 Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000 월간 기록을 시작했는데, 이전에 정리한 자료 중에서도 좋은게 많다. "월간 기록"이라고 볼 순 없지만 버리기는 아까워, 최근 몇 개월 동안 모아두었던 기록 중에 다시 찾아볼 만한 것들을 정리했다. 수집</h2> 흥미롭거나 유용했던 자료들Computer Networks: A Systems Approach (무료 원서)</a></h3> 나는 한글 번역본을 책으로 가지고 있는데, 영어 원서는 무료로 공개되어 있다. 네트워크를 제대로 공부하고 싶을 때 참고하면 좋을 듯. Interactive SICP JS</a></h3> SICP의 설명을 Scheme 대신 기능이 제한된 JS로 대체한 에디션이다. 인터넷에서 무료로 볼 수 있고 실행 환경을 구축할 필요 없이 웹사이트에서 실습할 수 있다. 원문 또한 검색하면 공식적으로 무료로 풀려있고, 원문과 SICP in JS의 내용을 비교하고 싶다면 여기의 비교판</a>에서 볼 수 있다. SICP(Structure and Interpretation of Computer Programs, 컴퓨터 프로그램의 구조와 해석)는 전 MIT 입문 프로그래밍 교재</a>로, Scheme(Lisp 방언)을 사용해 추상화, 재귀, 데이터 구조, 인터프리터/컴파일러 구현 등 컴퓨팅의 본질적 개념을 다룬다. </blockquote> 나는 특히 3장에서 substitution model에서 environment model로 전환하는 것과 4장에서 겉보기에는 동일한 언어라도 평가 전략이나 실행 모델과 같은 구현 선택에 따라 동작이 달라질 수 있다는 점이 인상 깊었다. Cloudflare 한국에서의 망 연동 문제</h3> Cloudflare는 망 사용료로 인한 비용 문제로 CDN 사용 시 국외의 노드와 연결된다. 한국에 ICN(인천) 리전이 있지만, Enterprise 플랜을 사용해야만 고정이 가능하다. CDN 뿐만 아니라 R2나 다른 기능들에서도 한국 리전이 사용되지 않는 듯 하나 확실하진 않다. 이에 대한 공식적인 내용을 찾아보기는 어렵지만, 사실 상 망 사용료로 인한 문제임이 확실한 것 같다. 클라우드플레어 임원 "한국 망 사용료가 비슷하다고? 20배 이상 비싸"</a></li> 관련 블로그 글</a></li> 나무위키</a>, 가온위키(처음 보는 위키인데 내용이 많아서 링크)</a></li> </ul> SQL과 관계형 모델</a></h3> 관계형 모델의 이론과 RDB를 연관지어 설명한다. 실제 DM 사용 경험이 적다곤 하지만, 이런 관점의 글은 본 적 없고 인상깊었다. 아마 블로그 글 저자가 컴파일러나 언어학에 관심이 있어서 이런 관점의 글이 나온거 같음. 템플릿 콜백 패턴과 스프링 트랜잭션 관리 방법</a></h3> 고등학교 후배의 포트폴리오 프로젝트 코드를 보다가 궁금해져서 찾아본 내용. 라이브러리 사용자가 Context를 알지 않아도 실행 가능하게 하는 편리한 패턴이라고 생각된다. 전역이 아닌 별도의 생명 주기를 가지는 Context는 어떤 식으로 관리되는지 생각해볼 수 있었다. $5짜리 프롬프트로 $2,418짜리 취약점 찾은 썰</a> | GeekNews</a></h3> 내용이 좋다. 실제로 LLM을 사용한 긍정적이고 효과적인 방법이라고 볼 수 있을 듯. 오픈소스 기여나 학습 측면에서 이런 시도가 나오고 있다는건 좋은 것 같다. 하지만 이와 반대로 LLM이 오픈소스 생태계 유지에 악영향을 줄 수 있을 것 같아 걱정이다. FFmpeg, cURL, Spring</a> 같은 여러 오픈소스에서도 AI Slop이 많아져 불만을 표하는 글을 보기도 했고. SQLite 창시자가 제안한 "CRLF 그만 보내기" 선언 (그리고 철회)</a> | HackerNews</a></h3> 이런 역사적 잔재는 생각보다 많다. tty, base64 등. 지금 당연하게 쓰는 관행이 사실은 수십 년 전 하드웨어 제약의 흔적인 경우가 많다. SQLite 창시자 Richard Hipp이 "이제 CR은 그만 보내자"는 선언문을 작성했다가 철회했다. 주장이 과격했고, 호환성 문제가 있었기 떄문이다. 실제로 SQLite 관련 코드를 수정했다가 다른 서비스나 언어 구현에서 처리가 안 되어 깨지는 사례가 발생했다. 그럼에도 HN 토론에서 많이 언급됐듯이, 이런 레거시는 언젠가 정리해야 한다는 의견에 동의한다. Railway Oriented Programming (ROP)</h3> Railway Oriented Programming (ROP)</a> Railway Oriented Programming이란? (Medium)</a> Rust의 Result</code>, Kotlin의 Result</code> 도 이 패턴을 사용한다. try-catch와 달리 예외 흐름을 선형적으로 처리할 수 있다. Spring 트랜잭션 같은 기존 패턴과는 잘 맞지 않아서 실무에서 자주 쓰진 않았다. 실패 경로를 명시적으로 다뤄야 할 때 써본 적은 있지만, 돌이켜보면 크고 복잡한 코드의 레거시를 갈아엎지 못하던 상황에서 나온 코드였다. ROP 자체는 좋다고 생각하지만, JVM 생태계는 프레임워크/라이브러리가 예외 기반이라, 제한된 영역이 아니라면 ROP 스타일이 잘 맞지 않아 보인다. 좋은 디자인이란? - 게슈탈트와 밀도로 알아보기</h3> 색이나 예쁜 걸 말하는 게 아니라 레이아웃이나 어떻게 정보를 전달할 것인가를 다루는 내용들. UI Density (Matthew Ström)</a></li> HackerNews 토론</a></li> 게슈탈트 심리학과 UI</a></li> </ul> 레이아웃을 잘 꾸미고, 서비스 특성에 따라 밀도를 조절하기 Frameworkless Frontend Development 스터디</a></h3> 프레임워크 없이 프론트엔드 개발하기. 내용은 괜찮은데 책으로 보면 불편할 듯. 블로그로 원서를 찾아보거나 직접 구현 분석하는 게 더 나을 것 같다. 원본 코드 (GitHub)</a> (아래 작업 파트에 누가 스터디한 레포 포크해서 개인적으로 정리한 레포를 적어둠.) 최적화를 위한 알고리즘</a></h3> GeekNews</a></li> Jupyter Notebook 버전</a></li> </ul> 최적화 문제를 다루는 알고리즘 책. 무료로 공개되어 있고, Julia 언어로 구현되어 있다. (Julia</a> 나무위키) 다만 이런 의견도 있음을 주의하고 보기. 책에 Firefly, Cuckoo Search 같은 메타휴리스틱이 포함된 걸 보고 놀람. 이 알고리즘들은 학계에서 신뢰받지 못하고, ITOR 논문에서도 비판받았음 </blockquote> Top GitHub Users in South Korea</a></h3> 깃헙 유저들 나라 별 기여/팔로워 순 순위를 모아놓은 레포에서 한국인끼리 모아둔 페이지. 내리다 보면 아는 사람이나 유명한 블로그 쓰는 사람들이 종종 보인다. 내 계정도 있는데, 팔로워, 기여 수 조건이 있어 아슬아슬하게 들어가있다. 기여는 학교에서 안 공개 프로젝트 덕에 높게 나오는거 같다. OOP의 35년 실수 - Casey Muratori 발표영상 In BSC 2025</a></h3> Claude AI 요약</a> Casey Muratori가 OOP의 구조적 문제점을 지적한 강연. 논쟁적이지만 생각해볼 거리를 많이 던져준다. ECS, Fat Struct 같은 패턴이 이전부터 있었고, 특정 상황에서는 이게 더 적절하다는 것. 현재의 OOP가 범용 대규모 프로그래밍에 유리하다는 인식과 달리 초기에는 제한된 도메인(분산 시스템)의 소규모 팀에서 탄생한 개념이라는게 인상깊었음. 선언적 프로그래밍에 대한 착각과 오해</a></h3> 선언형 프로그래밍이 무엇인지, 왜 오해받는지에 대한 깊이 있는 분석. What Every Programmer Should Know About Memory</a></h3> 공식 PDF (114페이지)</a></li> 구글 검색하기</a></li> </ul> 메모리 계층 구조, 캐시, NUMA 등 하드웨어 수준의 메모리 동작 원리를 다룬 유명한 글. 114페이지의 방대한 분량이라 모든 내용을 알아야 하는 건 아니라는 주장이 HN에서 꾸준히 나온다. (오래된 글이라 그런지 인용이 너무 많이 되서 해커뉴스 링크들를 주기보다는 그냥 구글에 검색하는게 나을 정도) 그럼에도 일부 핵심 개념은 성능 최적화를 할 때 중요하므로, 필요할 때 참고하면 좋을 듯. Thread dump — the simple tool for debugging Java-applications in production | by Gustav Karlsson</a></h3> 프로덕션 환경에서 Java 애플리케이션의 성능 문제나 데드락을 진단하는 실용적인 방법. Thread dump를 어떻게 수집하고 분석하는지 단계별로 설명한다. 내가 만든 방어 유틸 함수 5종 세트 | 포프머신</a></h3> 서버에서 유용한 커스텀 Assert 함수 패턴. 로깅, 슬랙 알림, 에러 로그, 심지어 사이렌 등으로 알리고, 중요도에 따라 다르게 구성한다. 코드로써 의미가 명확하고 가독성이 좋다. 테스트까진 아니지만 효율적이고 그에 준하는 효과 (가정이 깨지는 순간 파악, 의도적인 범위/제한 명시)를 가진다. 좋아보인다. 도입해볼만한 가치가 있을 듯. Reflections on Trusting Trust - Ken Thompson</a></h3> 한국어 AI 번역 (Gist)</a> Ken Thompson의 유명한 튜링상 수상 강연. 컴파일러에 백도어를 심어도 소스 코드 검사만으로는 발견할 수 없다는 걸 보여준 논문."신뢰를 어디까지 확장할 수 있는가?"라는 근본적인 보안 질문을 던진다. The Surprising Truth About Pixels and Accessibility</a></h3> px, em, rem 단위를 언제 어떻게 사용해야 하는지에 대한 실용적인 가이드. 특히 사용자의 접근성 관점에서 설명함. 대부분 상황: rem. 사용자 기본 폰트 크기 설정(=사용자가 의도한 크기)에 따라 크기가 바뀌기 떄문</li> 부모/자신의 font-size에 비례해야 할 때: em</li> 고정된 크기: px</li> </ul> You no longer need JavaScript</a> | HackerNews</a></h3> 현대 CSS와 HTML만으로 대부분의 웹 기능을 구현할 수 있다는 점을 보여주는 글. 지금 이 글을 보여주는 개인 블로그를 만들 때 사용한 css 작성 스타일에도 영향을 주었다. Hypermedia Systems</a></h3> htmx 제작자 Carson Gross가 쓴 책이다. REST 아키텍처의 원래 의도를 설명하고, SPA 프레임워크 없이 hypermedia(HTML) 기반으로 웹 애플리케이션을 구축하는 방법을 다룬다. 무료로 온라인에서 읽을 수 있다. 추가: Single HTML로 만드는 코드 - Gist</a> 관련해서 잘 정리된 글: 웹은 왜 복잡해졌나? -모던 웹의 복잡성과 하이퍼미디어 시스템</a> 작업</h2> 학습, 개발, 실험 등 직접 손댄 것들네트워크에서 MAC과 IP가 분리된 이유</h3> "Rust in Action" p.345를 보고 궁금해져서 찾아본 내용. IP와 MAC은 다른 용도를 가지고 서로 다른 단체에 의해 다른 연도에 만들어졌다: MAC: LAN 내부 하드웨어의 통신용</li> IP: 네트워크 간 통신용, 먼저 만들어졌다.</li> </ul> 두 가지를 연결하기 위해 ARP가 등장했다. 참고로 MAC과 IP가 항상 같이 쓰이는 건 아니다. (MAC 주소 개념을 사용하지 않거나, IP 주소 ↔ 링크 주소 매핑이 다른 방식으로 처리되는 경우도 있음) Perplexity 검색 결과</a></li> 정리 Gist</a></li> </ul> Frameworkless Frontend Development 구현 연습</a></h3> 원본 스터디 레포</a>를 fork해서 직접 구현해본 프로젝트. 프레임워크 없이 순수 JavaScript로 프론트엔드 애플리케이션을 만들면서 라우팅, 상태 관리, 컴포넌트 시스템 등의 기본 원리를 학습했다. 프레임워크가 내부적으로 어떻게 동작하는지 이해하고, 실제로 직접 구현해보면서 웹 플랫폼의 기초를 다질 수 있었다. CHIP-8 에뮬레이터 (C 언어)</a></h3> C 언어로 CHIP-8 에뮬레이터를 구현한 프로젝트. CPU 명령어 해석, 메모리 관리를 직접 만들면서 이해할 수 있었음. awesome-for-me</a></h3> 개인적으로 유용하다고 생각하는 자료들을 정리한 저장소. 지금은 개인 디스코드나 월간 기록으로 자료 관리 방식을 바꿔서 더 이상 업데이트하지는 않고 있음. [월간 기록] 시리즈 소개 Sijun Yang — Sun, 28 Dec 2025 00:00:00 +0000 평소 관심 가는 여러 자료를 수집하고 학습하는데, 관심사가 자주 바뀌다 보니 시간이 지나면 흩어지거나 까먹곤 한다. 자잘한 활동을 기록하고 공유도 할 겸 유용한 자료, 회고, 일상, 학습 기록 등을 한곳에 남겨두는 "월간 기록" 시리즈를 만들었다. 포맷</h2> 매달 마지막 날을 기준으로 업로드하며, 다음과 같은 구성으로 이루어진다. 수집: 그 달에 발견한 흥미롭거나 유용했던 자료들</li> 작업: 학습, 개발, 실험 등 직접 손댄 것들</li> 짧은 생각: 근황과 요즘 하는 생각</li> </ul> 내부 형식은 자유롭게 작성한다. 목적</h2> 월간 기록을 시작한 이유는 활동 기록도 있지만, 자료 선별 목적도 있다. 개인 디스코드 채널에 자료를 모아왔는데, 정리되어있지 않은데다가 3년이 넘으니 찾기 어려워졌다. 그래서 수집 방식은 유지하되, 월말에 참고할 만한 것만 선별해 따로 기록하기로 했다. 동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나 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>에 있는 강의를 함께 들어가면서 진행했다. (강의는 유튜브로도 공개되어 있다.</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 강의를 통해 컴퓨터 시스템, 특히 컴퓨터와 프로그래밍 언어의 동작 원리를 이해할 수 있는 귀중한 경험이였다. 실습을 통해 이론적 지식을 실제로 구현해 보면서 얻은 인사이트는 다른 학습 방법으로 대체할 수 없다고 생각한다. 특히, 새로운 기술에 대한 열린 자세와 프로그래밍에 대한 더 넓은 시각을 얻은게 된 것이 나에게 중요한 성취 중 하나였다. 앞으로는 다양한 분야와 기술에 도전하며, 배운 내용을 바탕으로 더욱 성장해 나갈 것이다.

Sijun Yang

[월간 기록] 2026년 4월

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

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

Jungle SW-AI Lab 활동</h3>

6주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 7주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 8주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 짧은 생각</h2> 근황과 요즘 하는 생각</p>

7주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 8주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 짧은 생각</h2> 근황과 요즘 하는 생각</p>

8주차</h4> 글</strong>:</li> 프로젝트</strong>:</li> </ul> 짧은 생각</h2> 근황과 요즘 하는 생각</p>

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

Week 07: 탐험 준비

핵심 역량 목표</h2>

목표 1. 작성 예정</h3> 관련 역량: 작성 예정</small></p>

과정</h4> 작성 예정</p>

결과 및 피드백</h4> 작성 예정</p>

목표 2. 작성 예정</h3> 관련 역량: 작성 예정</small></p>

과정</h4> 작성 예정</p>

결과 및 피드백</h4> 작성 예정</p>

그 외 작업</h2> 핵심 목표나 관련있는 내용은 아닌데, 따로 했던 활동이나 소개하고 싶은 것들 정리</p> 예: Jungle Bell 개발, Skill 만든거 공유, 오픈소스 기여 등 핵심 주제는 아닌데 공유하고 싶은것들 자유롭게</p>

회고</h2>

수요코딩회 후기</h3>

아쉬운 점 / 개선할 점</h4> 작성 예정</li> </ol> 코어타임 / 협업 회고</h3> 작성 예정</p> 핵심 역량 목표 회고</h3> 잘 된 점</h4> 작성 예정</p> 고민</h4> 작성 예정</p> 다음 주차에 시도할 것</h4> 작성 예정</p>

코어타임 / 협업 회고</h3> 작성 예정</p>

핵심 역량 목표 회고</h3>

잘 된 점</h4> 작성 예정</p>

고민</h4> 작성 예정</p>

다음 주차에 시도할 것</h4> 작성 예정</p>

Week 06: 탐험 준비

핵심 역량 목표</h2>

목표 1. 자료구조를 직접 구현하고, 실제 라이브러리의 구현 방식과 동작 원리를 분석하기</h3> 관련 역량: 구현, 문제해결, 학습 민첩성</small></p>

목표 2. 학습한 내용과 자료를 팀에 공유하기</h3> 관련 역량: 협업, 태도</small></p>

과정</h4> CLion용 devcontainer 설정, AddressSanitizer와 Valgrind 같은 도구를 공유하였다. 또한 수요코딩회에서 참고하기 좋은 간단한 참고 자료들도 공유하였다.</p>

WIL (What I Learned)</h2> 04/09 김현수 코치님 커피챗</h3> 회고가 끝난 뒤 1층 라운지에서 약 1시간 20분 정도 이야기를 나눴다. 자세한 내용은 개인적으로 정리했지만, 공유하고자 하는 내용만 작성해 보았다.</p>

04/09 김현수 코치님 커피챗</h3> 회고가 끝난 뒤 1층 라운지에서 약 1시간 20분 정도 이야기를 나눴다. 자세한 내용은 개인적으로 정리했지만, 공유하고자 하는 내용만 작성해 보았다.</p>

회고</h2>

수요코딩회 후기</h3> Week 6 수요코딩회 저장소</a> 와 운영안 배경 정리</a> 에 이번 시도의 배경을 정리해 두었다.</p>

핵심 역량 목표 회고</h3>

C에서의 자료구조 라이브러리 구현 알아보기

element와 data structure의 메모리 관리</h2>

element의 메모리 관리</h3>

조사</h4> AI와 실제 공식문서, 코드 약간 참고(전부는 아님)</p> C 범용 자료구조 라이브러리의 container 특징</strong></p>

대표적인 C 자료구조 라이브러리 코드 분석하기</h2> 편의를 위해 GLib는 Gitlab에서 관리되지만, Github에 있는 미러 레포지토리로 봄.</p>

Tsoding 유튜브의 C관련 내용 정리

Week 05: 컴퓨팅 사고로의 전환

핵심 역량 목표</h2>

목표 1. DP/Greedy 기본 유형을 답 없이 풀 수 있을 정도로 많이 풀기</h3> 관련 역량: 문제해결, 구현, 학습 민첩성</small></p> DP/Greedy 기본 유형을 문제 기준으로 반복해서 풀고, 해설 없이 해결 가능한 범위를 넓힌다.</p>

목표 2. AI 활용 방식을 더 적극적으로 실험하고 정리하기</h3> 관련 역량: AI 활용, 협업, 학습 민첩성</small></p>

결과 및 피드백</h4> 결과적으로 목표를 이루지 못했다. Claude의 사용량 제한으로 여러 기능을 충분히 테스트하지 못했고, 따라서 팀원들에게 공유하는 작업도 하지 못했다.</p> 다만 몇 가지 개선 방법을 알게 되었다.</p>

WIL (What I Learned)</h2>

회고</h2> 수요코딩회 후기</h3> 잘된 점 / 유지할 점</h4> 싱크 맞추기</strong>: 초반에 함께 모여 목표와 구현 방향을 충분히 맞춰둔 덕분에, 중간에 한 차례 어긋난 시점을 제외하면 작업이 비교적 원활하게 진행되었다.</li>

수요코딩회 후기</h3>

잘된 점 / 유지할 점</h4> 싱크 맞추기</strong>: 초반에 함께 모여 목표와 구현 방향을 충분히 맞춰둔 덕분에, 중간에 한 차례 어긋난 시점을 제외하면 작업이 비교적 원활하게 진행되었다.</li>

핵심 역량 목표 회고</h3>

잘 된 점</h4> 두 목표 모두 완전히 달성하지는 못했고, 아쉬운 부분이 많다. 그럼에도 활동 기록을 통해 알고리즘 풀이 방식의 단점과 해결 방향을 잡았다는 것에서 의미가 있지 않을까 싶다.</p>

[월간 기록] 2026년 3월

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

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

짧은 글: 제한 없는 AI 개발은 위험하다.</h3> 아직, 그리고 앞으로도 제한 없는 AI 개발은 위험할 것이다.</p>

개인 토이프로젝트 - Jungle Bell</a></h3> 크래프톤 정글 출석체크 알림용 시스템 트레이 앱.</li> AI를 적극적으로 써서 배포하고 실사용자까지 나온 첫 프로젝트.</li>

Jungle SW-AI Lab 활동</h3>

Week 04: 컴퓨팅 사고로의 전환

핵심 역량 목표</h2>

목표 1. 외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬 구현하기</h3> 관련 역량: 구현, 품질, 설계</small></p> 이진 검색 트리, DFS/BFS, 위상정렬 알고리즘을 외부 자료 없이 스스로 설명하고 구현해낼 수 있어야 한다.</p>

과정</h4> 계획했던 재구현 과정은 따로 진행하지 못했지만, 기본 문제를 풀면서 일부 문제를 AI나 힌트 없이 직접 구현하는 과정에서 자연스럽게 목표를 달성했다고 판단했다.</p>

결과 및 피드백</h4> 계획과 과정은 달랐지만 목표 자체는 달성.</p> 외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬을 활용한 문제 풀이가 가능했다.</p>

목표 2. 기본 제공 강의 외의 알고리즘 문제를 풀기</h3> 관련 역량: 문제해결, 학습 민첩성, AI 활용</small></p> Week 4 문제 풀이 외의 문제도 중(실버 상급 ~ 골드) 난이도 정도로 4문제 이상 풀이 시도하기.</p>

과정</h4> 난이도는 실버 1~골드 5로, 목표 범위(실버 상급 ~ 골드) 내의 추가 문제 6개를 선정했고 그중 3문제를 풀었다.</p> 3/21(금)</p>

결과 및 피드백</h4> 난이도 중 이하 문제를 다 푼 후, 목표의 4문제 대비 3문제 완료.</p>

목표 3. 자료 공유</h3> 관련 역량: AI 활용, 협업</small></p> 내 경험/지식을 활용해서 팀 학습에 기여하기.</p>

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

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

6주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
7주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
8주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
짧은 생각</h2>
근황과 요즘 하는 생각</p>

7주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
8주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
짧은 생각</h2>
근황과 요즘 하는 생각</p>

8주차</h4>

글</strong>:</li>
프로젝트</strong>:</li> </ul>
짧은 생각</h2>
근황과 요즘 하는 생각</p>

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

목표 1. 작성 예정</h3>
관련 역량: 작성 예정</small></p>

과정</h4>
작성 예정</p>

결과 및 피드백</h4>
작성 예정</p>

목표 2. 작성 예정</h3>
관련 역량: 작성 예정</small></p>

과정</h4>
작성 예정</p>

결과 및 피드백</h4>
작성 예정</p>

그 외 작업</h2>
핵심 목표나 관련있는 내용은 아닌데, 따로 했던 활동이나 소개하고 싶은 것들 정리</p>
예: Jungle Bell 개발, Skill 만든거 공유, 오픈소스 기여 등 핵심 주제는 아닌데 공유하고 싶은것들 자유롭게</p>

아쉬운 점 / 개선할 점</h4>

작성 예정</li> </ol>
코어타임 / 협업 회고</h3>
작성 예정</p>
핵심 역량 목표 회고</h3>
잘 된 점</h4>
작성 예정</p>
고민</h4>
작성 예정</p>
다음 주차에 시도할 것</h4>
작성 예정</p>

코어타임 / 협업 회고</h3>
작성 예정</p>

잘 된 점</h4>
작성 예정</p>

고민</h4>
작성 예정</p>

다음 주차에 시도할 것</h4>
작성 예정</p>

목표 1. 자료구조를 직접 구현하고, 실제 라이브러리의 구현 방식과 동작 원리를 분석하기</h3>
관련 역량: 구현, 문제해결, 학습 민첩성</small></p>

목표 2. 학습한 내용과 자료를 팀에 공유하기</h3>
관련 역량: 협업, 태도</small></p>

과정</h4>
CLion용 devcontainer 설정, AddressSanitizer와 Valgrind 같은 도구를 공유하였다. 또한 수요코딩회에서 참고하기 좋은 간단한 참고 자료들도 공유하였다.</p>

수요코딩회 후기</h3>
Week 6 수요코딩회 저장소</a> 와 운영안 배경 정리</a> 에 이번 시도의 배경을 정리해 두었다.</p>

대표적인 C 자료구조 라이브러리 코드 분석하기</h2>
편의를 위해 GLib는 Gitlab에서 관리되지만, Github에 있는 미러 레포지토리로 봄.</p>

목표 1. DP/Greedy 기본 유형을 답 없이 풀 수 있을 정도로 많이 풀기</h3>
관련 역량: 문제해결, 구현, 학습 민첩성</small></p>
DP/Greedy 기본 유형을 문제 기준으로 반복해서 풀고, 해설 없이 해결 가능한 범위를 넓힌다.</p>

목표 2. AI 활용 방식을 더 적극적으로 실험하고 정리하기</h3>
관련 역량: AI 활용, 협업, 학습 민첩성</small></p>

잘 된 점</h4>
두 목표 모두 완전히 달성하지는 못했고, 아쉬운 부분이 많다. 그럼에도 활동 기록을 통해 알고리즘 풀이 방식의 단점과 해결 방향을 잡았다는 것에서 의미가 있지 않을까 싶다.</p>

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

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

목표 1. 외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬 구현하기</h3>
관련 역량: 구현, 품질, 설계</small></p>
이진 검색 트리, DFS/BFS, 위상정렬 알고리즘을 외부 자료 없이 스스로 설명하고 구현해낼 수 있어야 한다.</p>

과정</h4>
계획했던 재구현 과정은 따로 진행하지 못했지만, 기본 문제를 풀면서 일부 문제를 AI나 힌트 없이 직접 구현하는 과정에서 자연스럽게 목표를 달성했다고 판단했다.</p>

결과 및 피드백</h4>
계획과 과정은 달랐지만 목표 자체는 달성.</p>
외부 자료 없이 이진 검색 트리, DFS/BFS, 위상정렬을 활용한 문제 풀이가 가능했다.</p>

목표 2. 기본 제공 강의 외의 알고리즘 문제를 풀기</h3>
관련 역량: 문제해결, 학습 민첩성, AI 활용</small></p>
Week 4 문제 풀이 외의 문제도 중(실버 상급 ~ 골드) 난이도 정도로 4문제 이상 풀이 시도하기.</p>

결과 및 피드백</h4>
난이도 중 이하 문제를 다 푼 후, 목표의 4문제 대비 3문제 완료.</p>

목표 3. 자료 공유</h3>
관련 역량: AI 활용, 협업</small></p>
내 경험/지식을 활용해서 팀 학습에 기여하기.</p>