- 약 3시간 분량의 시스템 설계 풀코스: 5단계 프레임워크로 Spotify, Booking.com, WhatsApp를 설계한다
- Brain Sandwich: AI에게 맡기기 전과 후, 사람이 직접 생각하는 두 겹의 빵
- Linear 디자이너 Karri Saarinen: 기능이 모두 작동해도 제품은 나빠질 수 있다
70포인트. 이번 주 GeekNews 최상단을 차지한 글은 최신 AI 모델 소식이 아니라, 약 3시간짜리 시스템 설계 강의 영상이었습니다. 코드를 AI가 대신 써주는 시대에도 개발자가 끝까지 붙들고 있어야 하는 것이 무엇인지, 오늘의 TOP3는 같은 질문을 서로 다른 각도에서 던집니다. 설계를 어떻게 설명할 것인가, AI 앞뒤에서 어떻게 생각할 것인가, 그리고 제품에 누구의 관점을 담을 것인가를 차례로 살펴봅니다.
시니어 엔지니어처럼 시스템 설계하기 (풀코스)
면접은 정답이 아니라 사고 과정을 본다
GeekNews에서 70점대 점수를 받은 이 영상은 시스템 설계 면접 준비용 풀코스입니다. 글쓴이는 면접이 최종 아키텍처만 평가하지 않는다고 강조합니다. 평가 축은 소통과 협업, 구조적 사고, 기술 판단력, 실무 깊이, 시간 관리의 다섯 가지입니다. 요구사항이 모호하고 정답이 없기 때문에, 범위를 정하고 추론 과정을 눈에 보이게 만드는 능력이 곧 실력으로 읽힙니다.
60분을 쪼개는 5단계 프레임워크
핵심은 60분 면접을 다섯 단계로 나누는 틀입니다. 요구사항 정리에 5~10분, 데이터와 API 설계에 약 15~20분, 상위 수준 아키텍처에 약 15~20분, 병목과 확장성과 신뢰성 점검에 5~10분을 쓰고, 마지막에 트레이드오프와 확장 방향을 정리합니다. 목표는 60분 안에 완벽한 설계를 내놓는 것이 아니라 계속 발전시킬 수 있는 설계를 보여주는 것이라고 합니다. 또한 일방적인 발표가 아니라 핵심 지점마다 면접관과 합의를 확인하는 협업이어야 한다고 말합니다.
세 가지 사례가 보여주는 숫자 감각
음악 스트리밍 사례에서는 사용자 50만 명과 곡 3,000만 곡에서 출발해 원본 오디오 저장량을 약 90TB로 추산하고, 5,000만 명 규모에서는 약 600TB까지 늘려 잡습니다. 호텔 예약 사례의 난제는 마지막 방 하나를 두 사람이 동시에 예약하는 상황입니다. 연간 약 5억 5천만 건, 초당 약 17건의 예약과 초당 약 1,000건의 읽기를 가정하고, Read Committed에 SELECT … FOR UPDATE를 더하거나 Serializable 격리를 쓰는 방식으로 이중 예약을 막습니다. 메신저 사례는 일일 활성 사용자 5억 명, 피크 동시 접속 5천만 연결을 가정하고 WebSocket, Kafka, Redis, Cassandra 조합으로 풀어갑니다.
Tech Insight — 이 강의가 반복하는 조언은 단순하게 시작해서 병목이 나타날 때만 구성요소를 더하라는 것입니다. AI가 아키텍처 초안을 순식간에 만들어 주는 지금은, 그 초안이 왜 이 구조인지 설명하고 책임질 수 있는 사람이 더 귀해집니다. 복잡한 구성도를 그리는 속도보다 요구사항과 트레이드오프를 말로 풀어내는 힘이 차이를 만듭니다.
Brain Sandwich: AI 앞뒤로 직접 생각하라
생각, 위임, 다시 생각
Terrible Software에 실린 이 글은 AI를 쓰면서도 엔지니어링 실력이 퇴화하지 않도록 하는 3단계 작업 방식을 제안합니다. 첫째, 에이전트에게 맡기기 전에 문제와 맥락을 이해합니다. 구현 계획 전체가 필요한 것은 아니지만 대략의 방향은 알아야 합니다. 둘째, 맥락이 충분해지면 구현은 AI에게 온전히 위임합니다. 셋째, 리뷰를 요청하기 전에 diff를 직접 살피고, 복잡도가 정당한지 판단하고, PR 설명을 다듬습니다.
AI 코드를 리뷰어에게 떠넘기지 마라
글은 문제를 이해하지 못한 채 시작하면 AI가 엉뚱한 방향으로 이끌거나 풀 필요가 없는 문제를 만들어낼 수 있다고 경고합니다. 사전 이해가 있어야 AI 결과물이 맞는지, 과한지, 엉뚱한 문제를 푸는지 판단할 수 있다는 논리입니다. 특히 리뷰 요청 전에 무엇이 왜 바뀌었는지 설명할 수 있어야 하며, AI가 만든 코드를 이해하는 책임을 리뷰어에게 넘기는 행동을 피해야 한다고 말합니다. 모든 사고를 AI에 넘기는 태도는 글에서 ‘Meat Proxy’라는 실패 모드로 불립니다.
댓글에서 나온 반론
Lobste.rs 토론에서는 반론도 이어졌습니다. 기술은 직접 해 봐야 쌓이기 때문에 바깥 층의 능력도 연습을 멈추면 줄어든다는 의견, 15년 경력자도 산출량 압박 때문에 생각과 검토 단계를 지키기 어렵다는 의견이 나왔습니다. 한 댓글은 AI 단계에도 사람의 감독이 많이 필요하니 실제 모습은 샌드위치보다 라자냐에 가깝다고 꼬집었습니다. 테스트를 먼저 만들고 변경을 작게 쪼개 LLM끼리 서로 검토하게 한다는 실무 팁도 공유되었습니다.
Tech Insight — 첫 번째 영상이 말한 요구사항 정리가 Brain Sandwich의 첫 번째 빵과 정확히 같은 일입니다. 팀에 도입한다면 PR 템플릿에 ‘무엇이 왜 바뀌었는가’를 직접 쓰는 칸을 두는 것부터 시작해 볼 만합니다. AI 사용량이 늘수록 리뷰 부담이 한쪽으로 쏠리는 문제를 완화하는 가장 값싼 장치입니다.
소프트웨어 뒤에 있는 사람
제품에는 만든 사람의 관점이 묻어난다
Linear의 Karri Saarinen은 좋은 제품이 만든 사람의 경험과 가치관, 일하는 방식에 대한 생각을 반영한다고 말합니다. 사용자는 누가 만들었는지 몰라도 그 관점을 느낍니다. 요구사항을 모으고 기능을 만들고 지표를 재는 공장식 프로세스만으로는 제품의 성격이 만들어지지 않으며, 비슷한 고객과 도구를 가진 두 팀도 해석과 창업자의 배경에 따라 전혀 다른 제품을 만든다는 주장입니다.
에이전트 병렬 작업이 만드는 프랑켄슈타인
글에서 가장 날카로운 대목은 에이전트로 여러 사람이 각자 변경을 만들 때 공통 비전이 없으면 제품이 기능의 집합으로 쪼개진다는 지적입니다. 개별로는 합리적인 변경이 모여 정성껏 짠 퀼트가 아니라 프랑켄슈타인의 괴물에 가까워진다고 표현합니다. 각 부분이 작동해도 전체가 일관성을 잃으면 제품은 오히려 나빠질 수 있고, 무엇을 추가하지 않을지 정하는 일도 제품을 빚는 일의 일부라고 말합니다.
취향은 AI에게 가르칠 수 있을까
GeekNews 댓글에서는 AI에게 의도와 취향이 있는가를 두고 의견이 갈렸습니다. 취향이 AGENTS.md 같은 지침에 담길 수 있다는 의견이 있었고, AI는 장기적 사용자 가치보다 기술적 완료를 최적화하기 쉽다는 의견도 있었습니다. 의도를 상세히 문서로 남기는 방식이 LLM을 포함한 유지보수에 도움이 된다는 제안도 나왔습니다.
Tech Insight — 구현 속도가 빨라질수록 병목은 무엇을 만들고 무엇을 만들지 않을지 결정하는 사람에게 옮겨 갑니다. 에이전트를 여러 개 돌리는 팀이라면 기능 목록보다 먼저 제품 원칙 문서를 한 장 만들어 두는 편이 낫습니다. 그 문서가 사람과 에이전트 모두의 기준선이 됩니다.
관련 글
출처
- GeekNews – 시니어 엔지니어처럼 소프트웨어 시스템 설계하기 (원문 영상: https://www.youtube.com/watch?v=soTfFFIQQ8U)
- GeekNews – Brain Sandwich
- Terrible Software – The Brain Sandwich (2026-10-02)
- GeekNews – 소프트웨어 뒤에 있는 사람
- Karri Saarinen – Someone Behind the Software
AI Biz Insider · Tech Digest · aibizinsider.com
답글 남기기