강의 자료 요청

안녕하세요 김다현님, 좋은 말씀과 함께 정말 값진 피드백 남겨주셔서 감사합니다.마침 내부적으로 하네스 엔지니어링 전체를 체계화한 테크니컬 리포트를 정리 중이었습니다. 여기에 김다현님이 제안해주신 “상황 → 하네스 선택” 실무 의사결정 포함해서 강의 자료로 제공하겠습니다. 예를 들어, 작업 유형(신규 기능 / 리팩터링 / 버그 수정 / 마이그레이션)별 적합한 하네스 구성, 그리고 프로젝트 규모, 팀 상황별 도입 순서 (혼자 vs 팀, 레거시 vs 신규) 검토하겠습니다.이번 7월내로 업데이트 될 예정이며, 공개되면 새소식으로 알려드리겠습니다. 이런 제안이 강의를 실제로 좋게 만듭니다.감사합니다 :)

현재 미니케이스 자동완성 검색창 설계1 강의를 보고있습니다.

안녕하세요, 작성자 정보가 삭제되어 있으셔서 수강생 데이터를 보고 판단할 수가 없네요.물론 섹션 1 자체가 기대에 미치지 못했다고 느끼실 수 있고, 그 부분에 대한 의견은 존중합니다. 다만 아직 다루지 않은 전체 강의 내용까지 “이론이 얕다”고 평가하는 것은 실제 커리큘럼과는 다소 차이가 있어, 다른 수강생분들이 오해하지 않도록 이 점은 설명드립니다.다만 현재 확인되는 수강 진도 기준으로는 섹션 1의 기초 파트만 수강하신 상태에서 강의 전체의 이론적 깊이를 판단하신 것으로 보여 조금 아쉬움이 있습니다.우선 솔직한 중간 피드백 남겨주셔서 진심으로 감사합니다. 아직 판단을 유보하고 끝까지 들어보겠다고 해주신 것만으로도 감사한 일입니다.구체적으로 어떤 부분에서 깊이가 부족했다고 느끼셨는지 남겨주시면, 내용 개선에 참고하겠습니다.지금 보고 계신 섹션 1은 시스템 디자인이 처음인 분들도 따라올 수 있도록 사고 프레임워크를 잡는 구간이라, 현업 경험이 있으신 분께는 입문적으로 느껴질 수 있습니다. 실무에서 마주치는 문제들, 대규모 상태 관리, 통신 프로토콜 선택, MFE, 관측성과 장애 대응 등은 11강부터 시작되는 섹션 2에서 본격적으로 다룹니다. 특히 17~19강(통신 프로토콜)과 25~27강(관측 아키텍처)은 현업 시나리오 기반이라 기대하시는 내용에 가까울 겁니다.그리고 추가적으로 제가 상세히 피드백을 작성해서 드리고 있기 때문에 미션도 한번 해보시는 것을 권장 드리고 싶습니다.하나 여쭤봐도 될까요? 현업에서 겪고 계신 문제 중 이 강의에서 다뤄줬으면 하는 주제가 있다면 알려주세요. 지금 빅테크 실전 케이스 스터디 섹션(섹션 3)을 제작 중인데, 7월 중순 이후 순차적으로 업데이트 될 예정입니다. 실제 수강생분들이 겪는 문제를 케이스로 반영하고 싶습니다. 남겨주시는 내용은 우선적으로 검토하겠습니다.감사합니다.

Monolith 아키텍쳐 질문

안녕하세요. RJ 님 좋은 질문입니다. 정확히 말씀드리면, Monolith 아키텍처도 Vertical Scaling과 Horizontal Scaling 모두 가능합니다.예를 들어 하나의 Monolith 애플리케이션이 있다고 해보겠습니다.[Client] | v[Load Balancer] | +--> [Monolith Instance 1] +--> [Monolith Instance 2] +--> [Monolith Instance 3] | v [Shared DB]이렇게 동일한 Monolith 애플리케이션 인스턴스를 여러 대 실행하고 Load Balancer 뒤에 배치하면 Horizontal Scaling이 가능합니다. 실제 운영 환경에서도 충분히 사용할 수 있는 방식입니다.다만 Monolith의 제약은 Horizontal Scaling 자체가 불가능하다는 것이 아니라, 기능별로 독립적인 Scaling이 어렵다는 점에 있습니다.이번에는 하나의 Monolith 안에 아래 기능이 같이 있다고 가정해보겠습니다.Monolith Application - User - Payment - Search - Notification트래픽이 Search 기능에만 몰려도 Search 부분만 따로 늘리기 어렵기 때문에 전체 Monolith 인스턴스를 복제하게 됩니다.[Monolith 1] User Payment Search Notification[Monolith 2] User Payment Search Notification[Monolith 3] User Payment Search Notification실제로는 Search만 더 많은 CPU가 필요한데 User, Payment, Notification까지 함께 복제되는 구조가 될 수 있습니다. 그래서 자원 사용이 비효율적일 수 있습니다.반대로 Microservice라면 다음처럼 필요한 서비스만 독립적으로 확장할 수 있습니다.User Service x 2Payment Service x 2Search Service x 10Notification Service x 2따라서 두 아키텍처의 차이는 이렇게 이해하시면 가장 정확합니다.MonolithVertical Scaling 가능Horizontal Scaling 가능다만 전체 애플리케이션 단위로 확장되는 경우가 많음기능별 독립 Scaling이 어려움MicroserviceVertical Scaling 가능Horizontal Scaling 가능서비스별 독립 Scaling 가능대신 네트워크 통신, 분산 트랜잭션, 배포 및 운영 복잡도가 증가함그리고 말씀해주신 “하나의 코드베이스에서 모든 기능이 동작하니 Vertical Scaling이 더 자연스럽지 않나?”라는 생각도 충분히 이해할 수 있습니다. 초기 단계에서는 실제로 더 큰 CPU와 메모리를 가진 서버로 올리는 Vertical Scaling이 가장 단순한 선택이 될 수 있습니다. 하지만 트래픽이 더 증가하면 동일한 Monolith 인스턴스를 여러 대 배치하는 Horizontal Scaling도 사용할 수 있습니다.Monolith의 단점은 Horizontal Scaling이 불가능한 것이 아니라, 특정 기능만 독립적으로 Scaling하기 어렵고 전체 애플리케이션을 함께 확장해야 할 수 있다는 점입니다.질문해주신 부분이 맞고, 영상과 슬라이드의 표현이 혼동을 줄 수 있게 되어 있었습니다. 해당 부분은 수정하겠습니다. 꼼꼼하게 확인해주셔서 감사합니다.수강해주셔서 감사드리며 좋은 하루 되시길 바랍니다

깃허브 이슈 자동화 yaml파일

안녕하세요 HyunSu Lee 님,못찾는 경우가 종종 생기고 있어서, 기존의 텍스트 방식에서 다시 파일로 해당 섹션에 실습 yaml 파일을 수업자료로 업로드 해두었습니다. 감사합니다좋은 하루 되세요

강의에서 사용하시는 그림판? 이거 이름이뭘까요?

안녕하세요 반가우면반갑다고해님,좋은 질문입니다.수강에 감사드리며, Excalidraw 입니다감사합니다좋은 하루 되세요 :)

깃허브 이슈 자동화 yaml파일

안녕하세요 서퍼님좋은 피드백 감사합니다해당 섹션에 실습 yaml 스크립트를 강의 노트에 작성해두었습니다감사합니다좋은 하루 되세요

auto memory

안녕하세요 서피님,좋은 질문입니다.CLAUDE.md에서 auto memory를 주의해야 하는 이유는, Claude Code 에서 memory가 단순한 메모가 아니라 다음 작업의 context에 계속 영향을 주는 하네스 요소이기 때문인데, Claude Code는 긴 작업을 할 때 모든 내용을 매번 그대로 들고 가기 어렵기 때문에, CLAUDE.md, session summary, compact, memory 같은 방식으로 중요한 정보를 남기고 다시 사용합니다.이 방식은 장점이 있습니다. 반복해서 설명하지 않아도 되고, 프로젝트 규칙이나 코딩 스타일을 계속 유지할 수 있습니다. 하지만 auto memory는 주의가 필요하게 됩니다. 이유는 아래와 같이 크게 세 가지입니다.첫 번째로, 임시 판단이 영구 규칙처럼 남을 수 있습니다.예를 들면, 한 번만 필요했던 예외 처리나 특정 파일 구조가 auto memory에 저장되면, Claude가 이후 작업에서도 그것을 계속 적용하려고 할 수 있습니다.두 번째로, 오래된 정보가 현재 작업과 충돌할 수 있습니다. 프로젝트 구조, 테스트 명령어, API 방식, 배포 환경은 바뀔 수 있습니다. 그런데 예전 정보가 memory에 남아 있으면 Claude가 최신 코드보다 오래된 규칙을 더 강하게 참고할 수 있습니다.세 번째로, context가 길어질수록 현재 작업의 기준이 흐려질 수 있습니다. Claude Code 중요한 포인트 중 하나는 context window가 핵심 제약이라는 점입니다. 그래서 중요한 정보는 남기되, 무엇을 장기 기억으로 남길지 신중해야 합니다.그래서 저는 CLAUDE.md에는 auto memory를 무조건 많이 쓰기보다, 정말 오래 유지되어도 되는 규칙만 남기는 것을 추천드립니다. 예를 들면, 이런 정보는 남겨도 좋습니다.- 프로젝트의 기본 아키텍처- 코딩 스타일- 테스트 실행 명령어- 금지된 작업- 자주 사용하는 디렉토리 구조- PR 전 검증 절차반대로 이런 정보는 auto memory에 넣지 않는 것이 좋습니다.- 이번 한 번만 필요한 디버깅 가정- 아직 검증되지 않은 원인 추정- 임시 우회 방법- 특정 이슈에서만 쓰는 예외 규칙- 오래되기 쉬운 API 응답 예시- 환경별로 바뀔 수 있는 접속 정보정리하면, auto memory는 Claude를 더 똑똑하게 만드는 기능이라기보다 반복되는 context를 줄여주는 도구에 가깝습니다.그래서 잘 쓰면 좋지만, 아무 정보나 자동으로 쌓이게 두면 Claude가 현재 코드보다 오래된 memory를 기준으로 판단할 수 있습니다.실무에서는 이렇게 관리하는 것을 권장드립니다1. 장기 규칙은 CLAUDE.md에 명시적으로 작성2. 임시 디버깅 정보는 PROGRESS.md나 이슈별 노트에 작성3. 검증되지 않은 추정은 memory에 저장하지 않기4. 프로젝트 구조가 바뀌면 CLAUDE.md도 함께 갱신5. 오래된 memory가 의심되면 /clear 또는 compact 후 현재 기준을 다시 제공즉, Claude가 기억하게 만드는 것이 아니라, 무엇을 오래 기억해도 되는지 구분하는 것입니다.Claude Code 하네스 엔지니어링에서는 memory도 하나의 context harness이기 때문에, 자동으로 많이 쌓기보다 검증된 규칙만 남기는 방식이 더 안정적입니다.감사합니다 훌륭한 질문 해주셨습니다 좋은 하루 되세요 :)

섹션3에 대한 문의사항

안녕하세요 sungjoonlee 님,질문 감사드립니다섹션 3은 현재 비공개 상태로 순차 제작 중이며, 지금까지 배운 내용을 실제 미국 빅테크 서비스 사례를 통해 케이스 스터디 중심으로 구성될 예정입니다.현재 준비 중인 방향은 다음과 같습니다.메타 스레드 스타일 실시간 소셜 피드 프론트엔드 시스템 디자인인스타그램 이미지 피드와 스토리 설계아마존 온라인 커머스 상품 목록과 장바구니 설계넷플릭스/유튜브 비디오 스트리밍 UI 설계슬랙/메신저 실시간 채팅 설계구글 문서/스프레드시트 협업 편집 설계X.com 서비스 피드 시스템 설계우버/리프트 스타일 실시간 위치 기반 설계SpaceX 스타일 로켓 부품 비용 분석 플랫폼 설계Starlink / SpaceX Observability Control Plane 설계Figure AI 스타일 휴머노이드 로봇 운영 대시보드 설계Space Data Center / Orbital Data Center Management Console 설계Rocket Internal Systems Monitoring 프론트 설계섹션 3의 목표는 단순히 “이런 서비스를 만들 수 있다”가 아니라, 실제 복잡한 서비스를 볼 때 요구사항, 아키텍처, 데이터 모델, 인터페이스, 성능, 관측성, 장애 처리까지 어떻게 나눠서 생각하는지 훈련하는 것입니다.그래서 각 케이스는 단순 구현보다는 프론트엔드 시스템 디자인 관점에서 좀 더 깊게 다룰 예정입니다.현재 순차적으로 제작하고 있으며, 완성되는 강의부터 공개할 예정입니다. 기다려주셔서 감사합니다.좋은 하루 되세요!

추가 강의 있으면 좋겠어요.

안녕하세요. Ref 님,좋은 의견 감사합니다.맞습니다. MFE는 개념적으로는 shell, remote, host, module federation을 설명해도 실제 프로젝트 구조를 한 번 보지 않으면 감이 잘 안 잡힐 수 있습니다.좋은 피드백 감사합니다. 간단한 프로젝트 세팅과 코드 흐름을 추가해서 보강하는 방향으로 업데이트 진행하되,그래서 간단한 코드 기반 보강 강의를 추가하는 방향으로 준비하겠습니다.(현재 섹션3 가 제작 진행중이기 때문에 후순위로 업데이트 될 예정입니다) 감사합니다 좋은 하루 되세요!

8강 디버깅 하네스는 verification 하네스와 비슷하게 느껴지는데 결정적인 차이가있을까요?

안녕하세요 goodluck 님,훌륭한 질문 해주셨습니다말씀해주신 것처럼 Debugging Harness는 Verification Harness와 겹치는 부분이 있습니다.다만, Claude Code 논문에서 말하는 하네스 관점으로 보면, 두 하네스는 목적과 시작점이 조금 다릅니다.간단히 말하면 이렇게 볼 수 있습니다.Verification Harness→ 결과가 맞는지 확인하는 하네스Debugging Harness→ 결과가 틀렸을 때 왜 틀렸는지 추적하는 하네스예를 들어서, Claude가 코드를 수정한 뒤 테스트를 실행한다고 해보겠습니다.pytest 실행빌드 확인타입 체크린트 실행결과 비교이런 것들은 Verification Harness에 가깝습니다.즉 수정 결과가 요구사항을 만족하는지를 확인하는 단계입니다.반면 테스트가 실패했을 때부터는 Debugging Harness가 중요해집니다.어떤 테스트가 실패했는지또는, 어떤 입력에서 재현되는지 그리고 로그에는 어떤 에러가 나오는지, 환경변수는 맞는지, 로컬과 배포 환경의 차이는 없었는지, DB, API, 파일 경로, 권한 문제 등의 원인을 추적하는 구조가 Debugging Harness입니다.Claude Code 논문 관점에서 중요한 점은, 모델에게 그냥 “고쳐줘”라고 하는 것이 아니라 Claude가 문제를 추적할 수 있도록 관찰 가능한 정보를 제공하는 것입니다.그래서 Debugging Harness에서는 로그, 재현 방법, 환경변수, 실행 명령어, 실패 입력, 에러 메시지 같은 정보가 중요합니다.정리하면, Verification Harness와 Debugging Harness는 연결되어 있습니다.하지만 역할은 다릅니다.Verification Harness→ 실패 여부를 확인한다.Debugging Harness→ 실패 원인을 추적한다.Recovery Harness→ 원인에 맞는 범위만 수정한다.예를 들어, 테스트 실패 상황을 흐름으로 보면 이렇게 됩니다.1. Verification Harness - 테스트 실행 - 실패 여부 확인2. Debugging Harness - 실패 로그 확인 - 재현 조건 정리 - 환경 차이 확인 - 원인 후보 좁히기3. Recovery Harness - 관련 파일만 수정 - 다시 테스트 실행그래서 Debugging Harness는 Verification Harness의 일부처럼 보일 수 있지만, 더 정확히는 Verification 이후에 실패 원인을 찾기 위해 필요한 별도의 하네스라고 볼 수 있습니다.즉 Verification Harness가 “맞는지 확인하는 장치”라면, Debugging Harness는 “왜 안 맞는지 Claude가 추적할 수 있게 만드는 것”입니다.감사합니다 좋은 하루 되세요!