이 프로젝트를 만든 이유
코드를 만드는 속도와
이해하는 속도 사이
AI 덕분에 더 많은 기능을 만들고 더 많은 문제를 해결합니다. 그런데 결정을 빠르게 위임할수록, 몇 달 뒤 그 시스템을 설명하는 일은 오히려 어려워질 수 있습니다.
손으로 몇 줄 썼는지는 핵심이 아닙니다
중요한 건 code ownership입니다. 왜 이 architecture를 골랐는지, 어디서 무너지는지, AI가 제안한 변경을 어떤 evidence로 승인했는지 설명할 수 있어야 합니다. 과제 면접에서 모든 코드를 암기해 다시 쓰는 능력과, production system을 안전하게 이끄는 능력은 겹치지만 같지는 않습니다.
개발자 한 명이 작은 Tech Lead가 되는 시대
구현의 일부를 AI agent가 맡으면 개발자의 일은 specification, decomposition, review, evaluation, incident ownership 쪽으로 이동합니다. 그래서 framework 사용법만큼 database, network, cloud, delivery pipeline과 비용의 연결을 이해해야 합니다.
한국어로 배우고, 글로벌 환경에서 통하는 언어로 설명합니다
Breaking Point가 지향하는 기준은 특정 국가나 회사의 관행이 아닙니다. 국제 표준, 원전, 공식 문서와 여러 지역의 production practice를 근거로 삼습니다. 본문은 한국어 존칭으로 쉽게 설명하되, 기술 이름과 metric, architecture pattern은 전 세계 동료가 같은 의미로 검색하고 토론할 수 있는 원어를 함께 사용합니다.
글로벌 스탠다드는 하나의 유행이나 정답 목록이 아닙니다. RFC나 specification처럼 합의된 표준인지, vendor의 공식 동작인지, 널리 쓰이는 practice인지, 한 조직의 경험인지 먼저 구분합니다. 지역마다 법률, 비용, 조직과 traffic 조건이 다르므로 적용 범위와 trade-off까지 설명할 수 있는 판단력을 목표로 합니다.
왜 TypeScript인가요?
거창한 이유는 없습니다. 작성자에게 가장 익숙해서 simulation과 설명을 빠르게 만들 수 있었기 때문입니다. TypeScript가 더 우월하거나 system design의 정답이라고 생각하지 않습니다.
개발자는 주어진 환경에 적응해 문제를 풀 수 있어야 합니다. 같은 queue와 concurrency 문제도 Node.js, Go, JVM에서 드러나는 방식과 사용할 수 있는 도구가 다릅니다. 중요한 건 문법이 아니라 runtime의 특성과 constraint를 파악하고, 그 환경에 맞는 trade-off를 선택하는 능력입니다. 이 사이트는 language-agnostic한 model을 먼저 다루고, 구현 예제는 TypeScript를 시작점으로 Go, Kotlin, Java까지 비교할 수 있게 확장합니다.
누구를 위한 프로젝트인가요?
구현 경험은 쌓였지만 설명할 언어가 흐릿해진 개발자, 연차보다 성장 속도를 높이고 싶은 junior와 mid-level engineer, 팀의 판단 기준을 시각적으로 공유하려는 senior와 Tech Lead를 위해 만듭니다.
만든 사람
이 프로젝트는 software engineer인 Rayleigh Ko가 자신의 실무 경험을 다시 설명 가능한 지식으로 바꾸기 위해 시작했습니다. 현재 다음 팀을 찾고 있으며, 이 사이트 자체를 architecture, product thinking, verification 방식에 대한 공개 work sample로 만들고 있습니다.
어떻게 만드나요?
AI 도구 목록보다 중요한 건 이터레이션입니다. Orient → Spec → Change → Verify → Review → Integrate 순환으로 lab과 인프라를 만들고, rebase로 선형 이력을 유지합니다. 특정 Agent OS나 리뷰 CLI는 권장 참고일 뿐 merge 조건이 아닙니다.