학생 때 확률과 통계 수업에서 처음 접했던 몬티 홀 문제.당시에도 "바꾸는 게 유리하다"는 결론은 머리로 받아들였지만,직관적으로는 끝까지 와닿지 않았다.오랜만에 생각나서 Python으로 시뮬레이션을 짜봤는데,단순한 검증을 넘어서 흥미로운 사실 하나를 더 발견했다.몬티 홀 문제란미국의 게임쇼 Let's Make a Deal에서 나온 유명한 확률 퍼즐이다.참가자 앞에 세 개의 문이 있다. 한 문 뒤에는 자동차가, 나머지 두 문 뒤에는 염소가 있다.참가자가 문 하나를 고른다.진행자(몬티 홀)는 남은 두 문 중 염소가 있는 문 하나를 열어 보여준다.참가자에게 묻는다. "고른 문을 유지할래요, 아니면 다른 문으로 바꿀래요?"직관적으로는 "이제 문이 두 개 남았으니 50:50 아닌가?"라고 생각하기 쉽다. 하지만 ..

들어가며면접에서 이 질문을 받았다. 알고 있다고 생각했는데, 막상 말로 풀어내려니 생각보다 정리가 안 됐다.면접이 끝난 뒤 다시 정리한 기록.질문의 진짜 의도"AI Agentic Coding 시대에 개발자가 프로그래밍 언어를 배워야 할까요?"이 질문은 단순히 "배워야 한다 / 안 배워도 된다"를 묻는 게 아니다. 면접관이 보고 싶은 건 AI 시대에 개발자로서 본인의 가치를 어떻게 재정의하고 있는가에 대한 사고 프레임이다."그래도 기본은 알아야죠"라고 답하면 무난하지만 인상에 남지 않는다. "AI가 다 해주니까 안 배워도 됩니다"는 위험한 사람으로 보인다. 이 질문에는 확실한 입장 + 그 입장을 뒷받침하는 구조화된 논거가 필요하다.내 결론: 반드시 배워야 한다다만 배우는 이유가 달라진다.기존에는 "코드를 ..

오래전에 알고 있었던 개념이지만, 막상 면접에서 질문을 받으니 입이 안 떨어졌다."알고 있다"와 "설명할 수 있다"는 완전히 다른 레벨이라는 걸 체감한 뒤, 다시 정리한 기록.SOLID란SOLID는 객체지향 설계에서 지켜야 할 5가지 원칙의 앞글자를 따서 만든 이름이다.S — Single Responsibility Principle (단일 책임 원칙)O — Open-Closed Principle (개방-폐쇄 원칙)L — Liskov Substitution Principle (리스코프 치환 원칙)I — Interface Segregation Principle (인터페이스 분리 원칙)D — Dependency Inversion Principle (의존 역전 원칙)이 원칙들의 공통 목표는 하나다. 변경에 유연..

위 이미지는 Gemini Nano Banana를 통해 제작했습니다.들어가며Mac mini를 홈서버로 쓰면서, SSH 비대화형 세션에서 docker compose up -d --build를 실행하려 했다.Docker Desktop의 macOS Keychain 의존성에 막혔고, Colima 전환으로 해결했다.배경: SSH로 Mac mini를 원격 관리하는 환경Mac mini를 홈서버로 쓰고 있다. 초기 세팅 때만 키보드와 모니터를 연결했고, 이후 모든 작업은 맥북에서 SSH로 접속해서 처리하는 headless 운용 환경이다.이 환경에서 자동화하고 싶었던 흐름은 단순했다.SSH 접속 → git pull → docker compose up -d --build → 배포 완료CI/CD 파이프라인이든, 자동화 스크립..

위 이미지는 Gemini Nano Banana를 통해 제작했습니다.들어가며사이드바가 잠깐 사라졌다가 다시 나타나는 현상은 작은 디테일처럼 보이지만,앱 셸의 완성도를 크게 떨어뜨린다.이 글은 "사이드바 접힘 상태를 어디에 저장하는 것이 맞는가"를 정리한 기록이다.문제 상황ChatGPT나 Claude처럼 사이드바가 앱의 기본 크롬(chrome) 역할을 하는 서비스에서는, 첫 페인트부터 접힘/펼침 상태가 안정적으로 유지되어야 한다.사이드바를 구현하면서 핵심적으로 다룬 문제는 두 가지였다.강제 새로고침 시 사이드바 상태가 유지되어야 한다.첫 페인트에서 사이드바가 안 보였다가 나타나는 hydration flicker가 없어야 한다.기존 구현에서 생긴 문제처음 구현은 클라이언트 상태 저장 관점에서는 자연스러웠다. ..

위 이미지는 Gemini Nano Banana를 통해 제작했습니다.들어가며면접에서 "OSI 7계층 설명해주세요"라고 물으면, 많은 사람이 1계층부터 순서대로 외운 내용을 말합니다.그런데 "그래서 개발할 때 왜 알아야 하나요?"라고 묻는 순간 답이 흐려지는 경우가 많습니다.중요한 건 계층 이름을 암기하는 것이 아니라, 내가 겪는 문제가 어느 층위의 문제인지 구분할 수 있는 감각입니다.OSI 7계층이란?OSI(Open Systems Interconnection) 7계층은 국제표준화기구(ISO)에서 제시한 네트워크 통신 참조 모델입니다.네트워크 통신 과정을 7개의 역할로 나누어 바라보는 틀이라고 보면 됩니다.이 모델의 핵심은 “현실의 인터넷이 정확히 이렇게 구현되어 있다”가 아니라,통신 과정에서 어떤 책임과 ..

※ 본 썸네일은 나노바나나 AI를 통해 생성된 합성 데이터입니다."손상된 옷 이미지가 100장밖에 없는데, 어떻게 학습시키지?"들어가며의류 품질 검사 AI 프로젝트를 진행하면서 만난 현실적인 문제다.데이터 현황:- 정상 의류: 10,000장- 손상 의류: 100장- 오염 의류: 50장문제: 극심한 클래스 불균형팀 회의에서 나온 해결책들:A: "회전시키고 노이즈 주면 되지 않나요?"B: "나노바나나로 생성하면 되잖아요."C: "그냥 복사해서 늘리면 안 돼요?"다들 맞는 말인데, 정확한 용어를 몰라서 소통이 어려웠다.오늘은 AI 데이터 처리에서 가장 헷갈리는 3가지 개념을 정리한다.핵심 용어 3가지1. Data Augmentation (데이터 증강)정의:기존 데이터를 "변형"해서 다양성을 늘리는 기법핵심:❌..

시리즈 마지막 편입니다. 이번에는 코드 이야기가 아니라 프로젝트를 만들면서 느낀 점, 그리고 실제 프로덕션 트레이딩 플랫폼을 만든다면 어떤 점들을 더 고려해야 하는지 정리해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 이 프로젝트를 만들었는가평소에 궁금했던 게 있었습니다. 주식이든 코인이든, 트레이딩 화면을 보면 숫자가 쉴 새 없이 바뀝니다. 호가창, 체결 내역, 캔들 차트가 동시에 움직입니다. 이걸 프론트엔드에서 어떻게 처리하는 걸까?React로 일반적인 CRUD 앱을 만..

업비트 실시간 대시보드 시리즈 마지막 편입니다. 호가창(Order Book)을 3가지 방식으로 구현하고 실제 성능을 비교해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다. /benchmark 페이지에서 3가지 방식의 성능 차이를 직접 확인할 수 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev# http://localhost:3000/benchmark 접속1. 왜 호가창이 어려운가?호가창은 프론트엔드에서 구현 난이도가 가장 높은 컴포넌트 중 하나입니다. 이유는 단순합니다.업비트 WebSocket으로 초당 10~20회 호가 ..

업비트 실시간 대시보드 시리즈 2편입니다. 이전 글에서 WebSocket 파이프라인을 구축했고, 이번에는 그 위에 캔들 차트를 올립니다. REST API로 과거 200개 캔들을 불러오고, WebSocket 체결 데이터로 마지막 캔들을 실시간 업데이트하는 구조입니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 TradingView Lightweight Charts인가?금융 차트 라이브러리를 고를 때 D3.js, Recharts, ECharts 등을 검토했습니다. 결론은 Lightwe..