어라, 맞는데 왜 틀리지?

안녕하세요, 블로그를 이전하려합니다. 
감사합니다.
https://codestudy.org/ 

들어가며

안녕하세요, 오랜만입니다. 3개월 만에 글을 작성하네요.
글 작성이 늦어진 이유는 회사에서의 바쁜 일정도 있지만, 글을 작성하는 관점이 달라져서도 있는 것 같습니다.

이전에는 글을 쓰는 행위 자체를 중요하게 생각하였는데, 이제는 하고 싶은 말이 무엇인지가 가장 중요한 것 같습니다.
하고 싶은 말이 없다면 구태여 무언가를 적어내릴 필요가 있나라는 생각입니다.

주 7일제를 원하는 개발자

주 5일은 개발자로서 서비스를 만들고, 주말에는 코딩 강사나 개발 콘텐츠를 만드는 일을 하고 싶습니다.
서비스를 만드는 일은 여전히 재밌고, 배울 것이 많으며 그 자체로 동기를 부여해 줍니다.
하지만 동시에 요구사항을 읽고, 문서화하고, Agent를 사용하고, 검증을 하며, 코드를 병합하는 같은 프로세스의 반복이기도 합니다.
그래서 다른 방향으로 자극을 받고, 경험의 한계를 넓히고 싶다는 생각을 하게 되네요.

당장 사이드 잡을 찾는 것은 어려우니, 인프런에 무료 강의라도 열어볼까 혹은 AI 쇼츠 자동화 서비스를 만들어서 직접 운영해 볼까 등 여러 가지 생각은 많은데 언제나 그렇듯 구체화하는 것은 쉽지 않은 것 같습니다.

제 블로그 구독자분이나, 깃허브 친구를 맺어주시는 분들과 프로젝트나 스터디를 해도 재밌겠다는 생각도 합니다.

생각보다 기술 블로그

이건 놀라운 사실인데요, 블로그 조회수 TOP 5안에는 항상 기술 글이 포함돼 있습니다.
시기마다 순서나 기술 글의 비중은 달라지지만, 최소 1개 이상은 포함돼 있단 건 변함없습니다.

개인적으로 글이란 작성 당시의 생각과 철학을 반영하고 있어야 생각해, 수정을 하지 않는 편입니다.
그래서 틀린 내용이나, 엄밀하지 않은 부분도 그냥 내버려두는 편인데 조회 수가 많이 나오는 글들은 리뉴얼을 한번 해야 할까 싶기도 합니다.

제 블로그가 회고 모음집이 아닌 기술 블로그 역할을 한다는 것이 매우 기쁘네요.

마무리하며

분명하고 싶은 말이 있어 글을 작성하였는데, 막상 다 쓰고 나니 뭘 말하고 싶었던 건지 모르겠습니다.

일을 잘한다는 것, 개발의 총량과 값싸진 코드, 채용과 주니어 개발자 등 무언가 작성한 것은 많은데 결국에는 다 쓰지 못하고 회고 글 비슷하게 작성이 되었네요.

그냥 손 때가 묻어있는 글을 쓰고 싶었던 것 같습니다.
근데 막상 쓰고나서 보니까 LLM Generated 된 느낌이 나네요 LLM이 작성하는 문서를 많이 읽어서 그런건가?

오늘은 퇴근하는데 여름이 성큼 다가와 바로 곁에 있음이 느껴졌습니다, 습식 사우나에 있는 기분이었거든요.
더운 여름, 각자의 자리에서 뜨겁게 보내시길 바랍니다.

2025년 회고

설 연휴가 끝나고 2026년이 정식으로 시작되었습니다.
작년에도 그랬듯이 이번에도 같은 방식으로 회고를 작성해보려 합니다.

첫 직장

2025년의 시작은 더없이 기분 좋았습니다.
졸업하자마자 가비아라는 회사에 전환형 인턴으로 합류하게 되었고, 취업이 힘든 시기에 좋은 기회를 잡아 하루하루 행복했던 기억이 선명합니다.

하지만 최종적으로는 정규직으로 전환되지 못하였고, 새롭게 취업 준비를 시작하게 됩니다.
전환 발표 당일 압박감에 헛구역질이 날 정도로 긴장했던 것이 아직도 생생하네요.

스스로에게 가장 아쉬운 부분은, 꽤나 긴 시간 동안 이 경험을 실패로만 받아들였다는 것입니다.
전환되지 못한 것에 대해 스스로가 부끄러웠고, 실패한 경험일 뿐 얻은 것이 너무나 부족하다는 생각을 했었습니다.
지금은 스스로의 부족함을 절실히 깨닫는 계기가 되었고, 성장할 수 있게 만들어준 값진 경험이라 생각합니다.

남을 가르치는 일

가비아에서의 근무가 끝나고, 5월 말부터 새롭게 취업 준비를 해야 하는 상황이었습니다.
이즈음부터 쉬었음 청년이라는 단어가 뉴스에 나오고, IMF 때보다 취업이 어렵다는 말이 나올 정도로 채용 한파가 심해진 기억이 납니다.

이때에는 가비아에서의 실패를 딛고 스스로가 잘할 수 있는 사람임을 증명하고 싶었습니다.
그렇게 여러 가지 일을 찾던 중 코딩을 가르쳐보는 것은 어떨까라는 생각을 하게 되었고, 이것이 또 다른 시작이 되었습니다.

떨리는 마음으로 강사 지원서를 쓰고 최종 합격을 받기까지 일주일정도 걸렸으며, 수업 시연에서는 Spring의 이름이 왜 Spring인지에 대해 설명했던 것이 떠오릅니다. (여러분은 그 이유를 아시나요? 알아보면 나름의 재미가 있습니다.)
그렇게 6월 5일부터 코딩을 가르치는 강사로 일하게 되었고, 이 글을 쓰는 시점(2026/02/21)에 마지막 강의를 마치게 되었습니다.

매주 토요일마다 강의를 하였는데, 공채의 경우 코딩테스트가 토요일에 몰려있어 눈물을 머금으며 아까운 기회를 날리기도 하고, 어떻게든 양해를 구해 코딩테스트에 참석했던 기억도 납니다.

약 9개월간 더없이 좋은 분들과 함께할 수 있었고, 꾸준히 채용을 진행해 조직이 커가는 모습을 보면서 감회가 새롭기도 했습니다.
제가 가르친 학생이 원하는 고등학교에 진학하고, 자격증을 취득하며 개발자로서의 진로를 꿈꾸게 되는 경험은 앞으로도 잊지 못할 것 같습니다.

탈락의 연속

7월부터 12월까지는 꾸준히 취업 준비를 하였습니다.
운 좋게도 카카오게임즈, 네이버웹툰, Daum 모두 임원 면접까지 가게 되었는데

카카오게임즈는 첫 임원 면접에 충분히 준비하지 못하였고
네이버웹툰에서는 가비아 때의 경험을 단순한 실패로 생각했던 것에 대가를 치르게 됐으며
Daum은 가진 역량을 최대한 쏟아부었지만 결국 합격하지 못했습니다.

Daum의 경우 임원 면접 내용도 좋았고, 기술 면접을 지원자 중 가장 잘 봤다는 코멘트도 있어 합격을 예상했었는데 불합격을 받게 되었습니다.
저 셋 모두 신입 공고가 아닌 2년차 내지는 경력 무관 공고여서 더 어려웠던 것 같아요

가비아에 이어 계속해서 최종 탈락을 하게 되니 이때가 가장 힘든 시기였습니다.
친구와 나눈 카카오톡 대화인데요, 표현이 다소 직설적이지만 제 마음이 정말 그랬습니다.

이 친구와는 지금도 이런저런 대화를 나누는데, 서로 잘됐으면 좋겠습니다.

하고 싶은 일

2025년 12월 말부터 2026년 1월까지, 무조건 취업을 하고 싶다는 마음에 지원서를 닥치는 대로 넣기 시작했습니다.
처음에는 가고 싶은 회사를 선별하고 나름의 기준을 갖고 지원했었는데, 계속해서 조급해지다 보니 말 그대로 무차별 지원을 하게 됐습니다.
감사하게도 여러 곳에서 면접 제의가 왔고, 정말 많은 면접을 보았습니다.

하지만 면접을 볼수록 제가 생각하고 원하는 환경과는 많이 다르다는 것을 느꼈습니다.
오히려 그럴수록 진짜 하고 싶은 일, 멋있다고 느끼는 일을 해야겠다는 생각이 더욱 강해졌습니다.

그러던 중 NHN AD 인턴과 SI 정규직 중 하나를 선택해야 하는 상황이 찾아왔습니다.
처우만 놓고 보면 SI 정규직이 분명 나은 조건이었지만, 훗날 후회가 남을 것 같다는 생각에 NHN AD를 선택했습니다.
인턴인 만큼 계약 기간이 끝난 후 다시 취업 준비를 해야 할 수도 있지만, 그럼에도 후회 없는 선택을 하고 싶었습니다.

인생은 바키처럼

여러분, 바키라는 만화를 아시나요? 대충 이런 내용의 격투 만화입니다.

최근에 드는 생각인데, 인생도 조금은 바보처럼 살아야 하는 것 같습니다.
현재의 우리는 너무나 많은 정보와 선택지 앞에 놓여 있으며, 그중에서 최고의 선택을 하지 못했음을 자책하고 후회하곤 합니다.
그렇기에 자신의 선택이 최고는 아닐지언정, 최선이었음을 믿고 뚝심 있게 밀고 나가는 자세가 필요한 것 같습니다.

마무리하며

2024년 회고에서는 한 해의 총평을 개발자스러운 것들이라고 하였는데, 2025년 회고에서는 다사다난한 성장이라고 하고 싶습니다. 

2026년에는 또 다른 새로운 경험을 하게 될 텐데, 벌써부터 기대가 됩니다.
읽어주셔서 감사합니다. 

세계 최고의 출판사 길벗

길벗에서 책을 협찬받았습니다.
밥 마틴으로 유명한, 로버트 마틴의 우리, 프로그래머들이라는 책입니다.

사실 길벗 하면 개발자분들은 다들 아실 거라 믿습니다.
그런 출판사에서 협찬 제의가 오다니.. 블로그를 3년째 운영 중인데 참뜻깊네요

다 여러분들 덕분입니다.
현재 조회 수가 가장 잘 나오는 글은 '네이버 웹툰 탈락 후기'인데 책을 더 받으려면 또 탈락해야 하나 싶기도 합니다.

우리, 프로그래머들

"우리는 왜 존재하는가? 우리는 디테일을 사랑하는 사람"
"우리가 사랑하는 것은 디테일을 하나씩 조합해서 문제를 해결해 나가는 것"

가장 감명 깊게 읽은 구절입니다.
흔히들 개발자라는 직업을 '문제를 해결하는 사람'으로 정의하는 경우가 많은데 '디테일을 사랑하는 사람'과 일맥상통합니다.

개인적으로는 문제를 해결한다는 조금은 딱딱한 말보다, 디테일을 사랑한다는 감성 있는 문구가 더 마음에 듭니다.
앞으로 나도 써먹어야지.

AI 시대, 하지만 과거를 말한다

이 책의 표지에는 다음과 같은 글이 적혀있습니다.
"AI 시대에 잊혀가는 '프로그래머 정신'을 다시 깨우다" 문구만 본다면 AI가 책의 주제일 것 같지만, 실제로 펄쳐 읽어보면 이 책의 초점은 다른 곳에 있습니다.

튜링, 폰 노이만, 다익스트라, 앨런 등 다양한 거장들의 일대기와 또 다른 거장인 로버트 마틴 자신의 이야기를 서술하는, 일종의 역사서이자 자전적인 내용을 담은 책입니다.

책은 총 4부로 구성돼있으며 가장 많은 분량을 맡은 부분은 2부(거장)로 책의 절반 이상을 차지합니다.
다음으로 많은 분량을 맡은 부분은 3부(급격한 전환점)로 이 둘의 분량은 전체 내용의 80%가량을 차지합니다.

이렇듯 상당 부분을 컴퓨터라는 도구와 프로그래밍의 발전에 대해서 서술하며, 4부(미래) 부분에 AI가 언급되긴 하지만 책의 중심 주제가 되기에는 턱없이 부족합니다.

이렇게 과거에 집중하는 이유는 무엇일까요?

로버트 마틴은 할아버지

앞서 말했듯 이 책은 무식하게 크고 원시적인 컴퓨터에서 현대로 오기까지의 수많은 이야기와 마틴 자신의 경험이 주를 이룹니다.
처음엔 그 방대한 역사적 배경에 압도되기도 했지만, 본문 전체와 집필 후기를 읽으면서 책의 정의를 내릴 수 있었습니다. 

이 책은 할아버지가 말해주는 옛날이야기였던 것입니다.

실제로 로버트 마틴은 1952년 생으로 Elder라는 단어가 어울리는 프로그래밍의 원로이자 할아버지입니다.
그렇기에 지나간 시절에 대한 향수를 가지면서도, 변하지 않는 본질을 전하려고 했던 것 같습니다.

컴퓨터 기술이 원시적이었던 시절부터 현대에 이르기까지, 수많은 거장들이 어떻게든 문제를 해결해나가고 기술을 발전시켜 나간 모습을 보여줌으로써, "아무리 도구가 바뀌어도, 본질적인 것은 남는다"는 메시지를 전하려는 듯이요.

저는 젊은데도 개그콘서트가 그립고 자주 듣는 노래는 다 15년 전 노래거든요.
시간은 지나고 새로운 것은 계속해서 생기지만 그때가 그리운 것은 변하지 않는 본질적인 무언가가 있다는 의미 아닐까요?

디테일을 사랑하는 사람들

컴퓨터라는 개념이 없던 시절부터 개발자라는 말이 보편화된 지금까지.
'디테일을 사랑하는 사람들'은 저마다의 지성과 열정을 보여주며 발전해 왔으며, 이제는 AI라는 괴물과의 동행을 생각해야 하는 때가 왔습니다.

AI의 가파른 발전, 줄어드는 일자리.. 어쩌면 개발자라는 단어 자체가 사라질 수도 있겠다는 생각도 듭니다.
하지만 로버트 마틴이 강조한 것처럼, '디테일을 사랑하는 사람'으로서의 정체성은 남을 것 같습니다.

뭐든 하면서 먹고살지 않을까요?, 저는 그랬으면 좋겠는데..

책장에 꽂아두고, 방향을 잃을 때마다 펴 읽어야겠습니다.
할아버지의 옛날이야기 속에는, 변하지 않을 무언가가 담겨있는 것 같으니까요

들어가는 글

프로그래밍 강사로 아이들을 가르친 지도 어느덧 7개월이 됐습니다. 주로 파이썬과 C 언어를 가르치고 있는데, 언어를 다시 설명하는 과정이 의외로 신선하게 느껴집니다. 알고 있다고 생각했던 개념도 아이들에게 풀어서 설명하다 보면, 제대로 이해하고 있었는지 스스로를 점검하게 되는 것 같기도 합니다.

가르치는 직업이란

강사를 하다 보면, 아이들에게 영향력을 전한다는 것이 가치 있는 일이라는 생각을 자주 하게 됩니다. 누군가의 인생에서 갈림길을 함께 선택해 준다는 게 얼마나 큰 책임감을 동반하는지.

제가 처음으로 가르친 학생 중 한 명은 벌써 COSPro 자격증을 취득했고, 소프트웨어 고등학교 진학을 목표로 준비하고 있습니다. 또 어떤 제자는 제 수업을 들은 후 실제로 원하던 소프트웨어 고등학교에 진학하기도 했습니다.

코딩 학원의 특수성

대치동 학원가라고하면, 까다롭고 날 선 학부모님들, 문제푸는 기계 같은 학생들이 떠오릅니다. 그런데 막상 강의를 해보니 아이들은 생각보다 너무나 착하고, 어렵다고 숙제 내주지 말라는 모습들을 보면 한편으론 귀엽게 느껴지기도 합니다. 

아무래도 코딩 학원의 특성상 필수적인 학원이 아니라 정말 코딩을 하고싶은 친구들이 등록을 하기 때문에 더욱 이런 경향이 나타나는 것 같습니다. 국영수 학원은 또 모르겠네요

마무리하며

남을 가르치는 직업은 참 특별한 것 같습니다. 너무나 보람찬 일이고, 제 지식과 기술로 가치를 창출한다는 느낌을 받습니다. 취업을 준비하고 있는 취준생인 저에게 사회적 효용성을 느끼게 하는 이 일은 참으로 사랑스러운 일입니다.

이제는 현업에 들어가서 제가 배워온 지식을 활용하고 싶은 욕구도 있는데요, 부디 그렇게 됐으면 좋겠습니다.
읽어주셔서 감사합니다.

오랜만에 재밌는 글을 가져왔습니다.
Redis는 굉장히 자주 사용되며, 특유의 원자성과 빠른 처리량으로 사랑받는 In-Memory DB 입니다.

원자성을 보장받는 이유는 Singlne Thread이기 때문인데요 "아무리 RAM 에 올라간다 하더라도 어떻게 수백만건의 요청을 처리하지?" 라는 의문을 한번쯤은 가져봤을 것 입니다.

개인적으로 "I/O는 멀티스레드를 써서 빠르다더라" 정도만 알고있었는데요, 이 글이 딥하게 알아볼 수 있는 계기가 되었습니다.

글의 내용

위 글에서 말하는 내용은 다음과 같습니다.

1. Redis는 모든 것을 RAM에 저장하므로 느린 디스크 I/O 를 방지
2. HashMaps, SortedSets, HyperLogLogs 등 최적화된 데이터 구조 사용
3. 고성능 I/O Multiplexing 사용
4. Redis 6.0 이상부터 I/O 처리가 멀티스레드 방식으로 변경

이 글을 읽으면서 햇갈렸던 개념은 I/O Multiplexing 인데요, "성능이 좋아진단건 알겠는데 그래서 그게 뭐지?" 라는 생각이 들어 자세히 찾아봤습니다.

Multiplexing (다중화)란 무엇인가?

Multiplexing은 간단히 말해 하나를 여러 개처럼 보이게 하는 기법이며, Redis는 버전과 상관없이 항상 I/O Multiplexing 기반으로 동작합니다.
운영체제 관점에서는, 하나의 프로세스가 여러 파일(혹은 소켓)을 동시에 관리할 수 있도록 하는 방법을 의미합니다.

리눅스에서 파일(File)은 프로세스가 커널에 접근할 수 있게 해주는 인터페이스이며, 네트워크 환경에서는 파일 = 소켓으로 대응됩니다. 즉, 하나의 서버가 여러 개의 소켓을 관리하여 동시에 많은 클라이언트를 처리할 수 있는 구조가 됩니다.

또 프로세스가 특정 파일에 접근할 때는 파일 디스크립터(File Descriptor, FD) 라는 정수 값을 사용하는데요
이 FD는 커널 내부의 파일 객체(소켓)를 가리키며, I/O Multiplexing은 FD의 상태 변화(readable/writable)를 효율적으로 감시하는 데 초점이 맞춰져 있습니다.

리눅스에서의 I/O Multiplexing: epoll

리눅스는 I/O Multiplexing을 위해 여러 메커니즘을 제공해왔습니다.
초기에는 select, poll을 사용했지만, 이들은 FD 개수에 비례하는 오버헤드가 있어 수천~수만 연결을 처리하기엔 비효율적이었습니다.

이를 해결한 것이 epoll입니다. epoll은 다음과 같이 동작합니다.

1. 애플리케이션이 epoll_ctl()을 통해 소켓을 등록하고, “이 소켓이 읽기/쓰기 가능해지면 알려달라”고 요청
2. 이벤트 루프 스레드는 epoll_wait()을 호출해 대기
3. 커널은 수천 개 소켓 중 실제로 준비된 것만 골라 이벤트 루프에 전달

즉, 준비된 소켓 목록만 반환하기 때문에, Redis는 수만 개 연결 중 필요한 소켓만 빠르게 처리할 수 있습니다.

Redis의 이벤트 루프 처리 흐름

Redis는 다음과 같은 순서로 이벤트(사용자 요청)를 처리합니다.

1. 소켓을 논블로킹 모드로 오픈
   • 일반적으로 소켓은 Blocking 모드
   • 소켓 수신 버퍼에 데이터가 없으면 -> 스레드가 멈춘 채 데이터 도착할 때까지 기다림
   • 송신 버퍼 가득 차면 -> 버퍼 여유 생길 때까지 기다림
   • Non Blocking 모드
   • 소켓에 데이터가 있으면 즉시 읽고 반환, 데이터가 없으면 에러코드 EAGAIN 반환
   • 송신 버퍼에 들어가는 만큼만 쓰고, 가득 차면 에러코드 EAGAIN 반환
   • 즉 준비된 만큼만 처리하고, 나머지는 다음 이벤트에서 처리
2. I/O Multiplexing 등록
   • Redis 이벤트 루프는 서버 시작 시 OS별로 다중화 방식 선택, Linux(epoll)
   • 논블로킹 소켓의 준비됨(readable/writable) 상태를 커널이 모아 이벤트 루프 스레드에 알려줌
   • 이벤트 루프 = 스레드가 발생한 이벤트를 지속적으로 감지하고, 콜백을 실행하는구조 
   • 소켓에 읽을 게 있으면 REDABLE, 소켓에 쓸 게 있으면 WRITABLE
3. 이벤트 루프 실행
   • 메인 스레드는 준비된 소켓 목록을 받음
   • 준비된 소켓마다 등록된 콜백을 실행 
     • READABLE - 요청 읽기 + 명령 실행
     • WRITABLE - 응답 전송

이 과정을 통해 단일 스레드 이벤트 루프만으로도 수천~수만 개 동시 연결을 처리할 수 있으며, 락(lock)도 필요하지 않습니다.

6.0 이전에는위 과정 전체(읽기, 명령 실행, 응답 전송)를 메인 이벤트 루프 단일 스레드가 처리했으며
6.0 이후에는 I/O 전용 스레드를 도입하여 read/write 작업을 여러 스레드로 분산 처리를 하도록 변경됐습니다. 
(명령 실행 자체는 여전히 단일 스레드에서 순차적으로 처리됩니다.)

Blocking vs Non-blocking 소켓

여기까지 정리한 후 한가지 의문이 생겼는데요 
“어차피 epoll이 준비된 소켓만 알려주면, 소켓을 블로킹 모드로 열어도 괜찮지 않을까?” 라는 생각이었습니다.

하지만 준비된 소켓이라고 해서 read/write가 항상 성공하는 것은 아닙니다.
예를 들어, 수신 버퍼 크기보다 더 많은 데이터를 read() 하거나, 송신 버퍼에 여유가 있음에도 write() 하려는 데이터가 너무 많다면, 버퍼가 다시 준비될 때까지 스레드가 블로킹될 수 있습니다.

따라서 소켓은 논블로킹 모드로 열어주는게 적절하겠네요.