728x90

전체 글 120

[Python] 로또 분석 서비스를 만들어봤다 #7 — 번호마다 성격이 있다고?

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다.시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다#6 27번의 전설, "빼면 나오는 저주"#7 번호마다 성격이 있다고? ← 지금 읽고 있는 글번호에 "성격"이 있을까?#6에서 27번의 전설을 다뤘다. 9회 중 7회 출현, 빼면 나오는 저주. 27번은 확실히 뭔가 "성격"이 있는 것처럼 느껴졌다.그래서 이번에는 다른 번호들도 파봤다. 1,200회 넘는 데이터에서 번호마다 정말 다른 패턴이 있는지.결론부터 말하면 — 있는 것처럼 보이지만, ..

프로그래밍/AI 2026.04.15

SI 산업의 공동화(空洞化) — 가운데가 사라진다

— 위에서 빠지고, 아래에서 빠지고, 남는 것1편에서 한국 SI의 구조적 정체를 진단했습니다. 2편에서 AI가 그 구조의 결함을 가속시키는 과정을 분석했습니다.3편에서는 예측을 이야기합니다. 이 구조가 AI와 만나면 어디로 가는가. 한 가지 먼저 환기하겠습니다. 1975년, 프레더릭 브룩스는 『맨먼스 미신(The Mythical Man-Month)』에서 이렇게 썼습니다. "9명의 임산부를 모아도 1개월에 아기를 낳을 수 없다." 사람을 늘리면 커뮤니케이션 채널이 기하급수적으로 늘어나고, 조율 비용이 산출물 증가를 잡아먹는다는 것이 그의 논증이었습니다. 50년 전의 통찰입니다. 그런데 한국 SI는 50년이 지난 지금도 Man-Month를 씁니다. "12명을 투입하면 1명이 12개월 걸릴 일을 1개월에 끝낼..

프로그래밍/AI 2026.04.15

AI는 한국 SI를 구할까, 무너뜨릴까

— 네 주체가 각자의 논리로 AI를 도입할 때 벌어지는 일1편에서 한국 SI 산업의 구조적 정체를 분석했습니다. 검증 체계, 발주처, SI사, 개발자 — 네 주체가 각자의 위치에서 합리적으로 행동한 결과, 전체로는 비합리적인 균형이 20년 넘게 유지되어 왔다는 이야기였습니다. 이 균형은 외부 충격 없이는 깨지지 않는 구조였습니다. 지금, 그 외부 충격이 도착했습니다. AI 코딩 도구의 확산입니다. Cursor, GitHub Copilot, Claude Code — 이름은 다양하지만, 공통된 약속은 같습니다. "개발 생산성을 획기적으로 높여준다." 문제는 이 도구가 도입되는 환경입니다. 1편에서 살펴본 바로 그 구조 — MM 기반 과금, 문서 중심 검증, 떠넘기기의 먹이사슬 — 위에 AI가 얹어집니다. 그..

프로그래밍/AI 2026.04.13

한국 SI는 왜 발전하지 않는가

— 네 주체의 합리적 선택이 만든 비합리적 구조한국 SI 산업에는 오래된 수수께끼가 있습니다. 기술은 매년 바뀝니다. 자바에서 파이썬으로, 온프레미스에서 클라우드로, 그리고 이제 AI로. 하지만 일하는 방식은 20년째 크게 달라지지 않았습니다. 10년 전 프로젝트의 진행 구조와 오늘의 프로젝트 진행 구조를 놓고 보면, 도구만 바뀌었을 뿐 사람을 투입하고, 기간을 산정하고, 결과물을 납품하는 방식은 거의 같습니다. 삼성은 반도체를 만들 때 이전 세대 기술 위에 다음 세대를 쌓습니다. SI에는 이 축적이 없습니다. 프로젝트가 끝나면 팀이 해산되고, 다음 프로젝트는 다시 처음부터 시작합니다. 왜 그럴까요. 누군가 무능해서가 아닙니다. 이 산업을 구성하는 네 주체 — 검증 체계(감리), 발주처, SI사, 개발자..

프로그래밍/AI 2026.04.09

EP.07 — 락-프리 스마트 포인터: mutex 없이 포인터를 바꿀 수 있다고?

이 글은 『서버 개발 수기』 시리즈의 일곱 번째 글이다.지난 회에서는 Write 버퍼 병합을 다뤘다.오늘은 조금 다른 세계다. 락 없이 포인터를 바꾸는 이야기.※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다.게시판 이야기게임서버에 "현재 이벤트 설정"이라는 공유 데이터가 있다. 경험치 2배, 드롭률 1.5배, PK 페널티 감소 같은 설정.스레드 8개가 패킷 처리할 때마다 이 설정을 읽는다. 초당 수십만 번. 읽기만 하니까 문제없다.락도 필요 없다. 읽기끼리는 충돌이 안 나니까.회사 게시판이라고 생각하면 된다. 교실 앞에 붙어있는 게시판을 지나가면서 읽는 거다.줄 서서 읽을 필요가 없다. 누가 읽는 동안 옆에서 같이 읽어도 아무 문제없다. 그런데 문..

[Python] 로또 분석 서비스를 만들어봤다 #6 — 27번의 전설, "빼면 나오는 저주"

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다. 시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다#6 27번의 전설, "빼면 나오는 저주" ← 지금 읽고 있는 글27번이라는 번호가 있다이 시리즈를 시작하고 나서, 매주 로또 번호를 분석하고 30개 조합을 만들고, 추첨 후 검증하는 걸 반복하고 있다. 그 과정에서 하나의 전설이 탄생했다. 27번. 1206회부터 1214회까지 9회 동안, 27번은 7번 출현했다. 출현율 78%. 정상 출현율이 13.3%(6/45)인 걸 감안하면 5.9배..

프로그래밍/AI 2026.04.05

프리렌은 여비가 부족하다.

프리렌은 항상 돈이 없다.천년을 살았고, 마왕을 잡은 용사 파티의 일원이었으며, 대륙에서 손꼽히는 마법사인데도 여비가 늘 모자란다. 경유하는 모든 마을의 마법 상점에서 마법 도구나 마도서를 사 모으기 때문이다.옷을 깨끗하게 해주는 마법, 꽃밭을 만드는 마법, 동상을 녹이는 마법. 누가 봐도 쓸모없는 것들이다. 마왕을 잡으려면 화력이 필요하지, 꽃밭이 무슨 소용이겠나.그런데도 프리렌은 마법 상점 앞을 그냥 지나치는 법이 없다. 여비가 모자라질 걸 알면서도.2000년, 밀레니엄이라는 단어가 희망처럼 느껴지던 해였다.97년에 첫 입사를 하고 3년쯤 지났을 때다. 월급이 너무 적었다. 그러다 누군가의 도움으로 돈을 좀 벌게 되었는데, 그 돈으로 내가 산 건 모토로라 스타텍이 아니었다. 69만원짜리 Compaq ..

EP.06 — Write 버퍼 병합: send()를 덜 부를수록 빠른 이유

이 글은 『서버 개발 수기』 시리즈의 여섯 번째 글이다.지난 회에서는 7종 참조 카운팅을 다뤘다.오늘은 데이터를 보내는 이야기다.※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다.택배 이야기MMORPG에서 유저가 필드에 서 있다. 서버가 이 유저한테 보내야 할 정보가 한꺼번에 쏟아져 나온다.1. 옆에 있는 유저가 움직였다 (12바이트)2. 몬스터가 스킬 썼다 (20바이트)3. 파티원 HP가 변했다 (8바이트)4. 채팅 메시지 왔다 (50바이트)5. 버프 시간이 줄었다 (6바이트) 이걸 어떻게 보낼까?내가 생각한 방법은 간단했다. 생길 때마다 바로 보내면 되지 않나? send() 5번.Claude한테 물어봤더니 "그게 왜 느린지 아세요?" 하고 되물어..

[Python] 로또 분석 서비스를 만들어봤다 #5 — 로또 공은 과거를 기억하지 않는다

⚠️ 이 글은 통계 분석 교육 목적이며, 로또 당첨을 보장하지 않습니다. 모든 조합의 당첨 확률은 동일하게 1/8,145,060입니다. 시리즈 링크#1 로또 번호를 만들어 볼까?#2 로또 번호를 맞춰 볼까?#3 1,213회 데이터 기본 통계#4 "나올 때 됐다" — 도박사의 오류 증명#5 로또 공은 과거를 기억하지 않는다 ← 지금 읽고 있는 글"적게 나온 번호가 따라잡아야 하지 않나?"#4에서 "나올 때 됐다"가 도박사의 오류라는 걸 증명했다.그러면 이런 질문이 나온다."아니, 큰 수의 법칙에 의하면 횟수가 많아지면 각 번호의 출현 비율이 같아져야 하잖아. 그러면 적게 나온 번호가 결국 따라잡아야 하는 거 아냐?" 이 질문은 진짜 좋은 질문이다. 그리고 대부분의 사람이 큰 수의 법칙을 잘못 이해하고 있다..

프로그래밍/AI 2026.03.22

EP.05 — 다목적 참조 카운팅: shared_ptr 하나면 되는 걸 왜 7개로 나누는가

이 글은 『서버 개발 수기』 시리즈의 다섯 번째 글이다.지난 회에서는 16슬롯 버퍼 풀을 다뤘다.오늘은 버퍼를 빌린 다음 이야기다. 돌려주는 것.※ 이 시리즈에서 다루는 서버 코드는 Project-AO(Ancient Origin)라는 가명으로 부른다. 책을 돌려주지 않는 사람지난 회에서 버퍼 풀을 도서관에 비유했다. 빌리고 반납하는 시스템.근데 빌렸으면 돌려줘야 한다. 안 돌려주면? 반환되지 않은 메모리가 쌓인다. 도서관에 책이 점점 줄어들고, 결국 빌려줄 책이 없어진다. 이걸 메모리 누수(Memory Leak)라고 한다.게임서버는 24시간 돌아간다. 메모리 누수가 생기면 며칠에 걸쳐 천천히 죽는다. 메모리를 조금씩 먹다가 결국 터진다. 그런데 문제가 하나 더 있다. 버퍼만이 아니라 유저 객체도 관리해야..

반응형