대규모 프로젝트에서 스펙파일 구조 설계

안녕하세요. 굉장히 중요한 질문을 해주셔서 정말 감사합니다.강의를 제대로 보신 분들만 할 수 있는 질문이라 생각합니다.대규모 프로젝트로 간다면 그때부터 스펙 관리는 꽤 복잡한 부분이 있습니다.예를 들어보면, 대형 프로젝트가 모노레포로 관리된다고 했을 때는 각 모노레포에 소속된 패키지 별로 스펙 분리를 1차원적으로 할 수 있을 겁니다.이 경우에는 specs/client, specs/server 이런식으로 분할할 수도 있고, 또는 도메인에 대한 관리를 둘 수도 있을 겁니다. 이를테면, specs/payments, specs/registration.그렇다면 해당 스펙 디렉터리에 어떤 요소가 들어갈지는 각 달라지게 됩니다. 만약 payment 기능을 개발하는데 client, server로 두 개의 스펙 문서를 만들어 2개로 각각을 관리하게 된다면, 이 두 개의 문서는 서로 다른 분야를 개발하지만 공통된 root 스펙이 필요하게 됩니다. 이를테면 payment에 사용되는 스키마가 되겠죠. 그렇다면 이 경우에는 payment를 담당하는 root 스펙과 더불어 그것을 client, server에 각각 참조할 수 있도록 하는 형태로 스펙 문서를 배치하는 것이 유리합니다.반면 도메인별로, feature 별로 관리를 하게 된다면 payments/ 디렉터리 안에 root에 대한 스펙(payments/root.spec.md), 각 요소 또는 기능에 대한 스펙(payments/client.spec.md) 등으로 넣을 수도 있지만 실제로는 client에 모든 스펙 요소를 다 넣는 것이 안되서 상세 규칙을 따로 빼야할 경우가 생길 겁니다. 그렇다면 스펙의 구조는 root.spec.md가 가장 뿌리client.spec.md는 payments의 client측 개발을 위해 참조하는 인덱싱 목록 형태의 스펙 문서paymemts/rules/ 안에는 세부 규칙 요소 배치payments/details/ 안에는 세부 스펙 배치와 같은 형태로 구현할 수 있습니다. 또한 이 과정에서 점진적 참조(skills에서 다룬 것처럼)를 하여 client.spec.md 파일 안에 링크를 넣는 형태로 구현하시면 상황에 따른 참조를 하실 수 있습니다.스펙 관리는 이처럼 소속된 패키지 단위, 기능 단위 정도로 관리될 수 있으니 현재 대규모 프로젝트의 구조나 기존 개발이 진행될 때의 방향성과 어느정도 맞추는게 좋습니다. 가령 조직이 패키지 단위 개발을 한다면 패키지 단위 스펙 정책이 유효하다고 보이며, 반면 기능 묶음 단위라면 기능 단위로 스펙을 구조화하시는 것을 추천드리겠습니다.

완강 후 느낀점

강의가 짧다면 짧고 길다면 긴 강의인데 100% 완강하신 것에 대해 먼저 축하 말씀드립니다. 이 강의를 구매하고 며칠 안에 다 보실 수 있는 집중력이시라면 앞으로 AI Agent 분야에서 일어나는 일들을 마주하실 때 바로바로 익히고 이해하실 수 있으리라 생각합니다. 새로운 개념, 단어, 전략 등이 계속 등장하는 게 인공지능 분야라고 하지만 기반이 탄탄하다면 문제가 될 일은 없을 것이라 생각합니다. 큰 골격을 잡으셨으니 앞으로는 자신만의 답을 향해 나아가실 것이라 예상해봅니다.축하드립니다.

1과업 = 1세션 에대한 질문

안녕하세요굉장히 좋은 아이디어로 과업 관리를 진행하고 계시는군요.1세션과 1과업이라는 측면에서 좋은 시도라고 생각하는데 실제 환경에서 서브 에이전트 수준으로 상호작용하고 일을 처리 하는게 좋을지(단일 세션에서 하위 에이전트 호출 방식으로), 또는 단일 또는 병렬로 제안된 과업에 대해 각각 별개의 세션에서 처리하는게 좋을지는 상황에 따라 달라질 것 같습니다.그래서 만약 제가 질문자님의 상황을 모사해서 진행한다고 한다면,Q: 오늘 과업은 ~~~가 있어, 병렬 처리할 수 있는 것과 아닌 것을 분류해봐.A: A,B,C 과업은 병렬로 처리하는게 좋고 D,E는 단일로 처리하는게 좋겠습니다.이때 다른 세션에서 처리를 하는게 현명하다면 Q: A,B,C 과업을 하나의 세션에서 별도의 워크트리를 가지며 진행될 수 있도록 칩을 생성해.라고 하면 별도 세션에서 해당 문제를 해결하게 될 것이고, D,E는 Q: D,E를 과업을 위해 각각의 핸드오프를 준비하고 마찬가지로 워크트리로 생성할 수 있도록 칩을 생성해. 라고 하여 총 3개의 별도 세션을 호출하는 방식으로 가능하게 됩니다.이렇게 되면 병렬 A,B,C 과업을 처리하는 에이전트는 하나의 에이전트 내에서 병렬 처리를 하는 형태로 볼 수 있고, D,E도 각각 하나의 과업을 달성하겠죠.그렇다면 병렬 처리될 수 있는 과업은 무엇이냐는 점입니다. 제가 생각할 때, 이미 개인 환경에서 등록한 별도의 에이전트를 따로따로 호출하여 동시성이 존재하며 개발될 수 있는 상황의 과업을 분별하는게 좋을 것 같습니다. 이를 위해서는 2가지 사전 작업이 필요하겠죠.내가 하는 작업들을 위한 전용 에이전트 설계프롬프트에 에이전트 호출이 자연스럽게 이뤄질 수 있도록 하는 가이드이렇게 한다면 결과적으로 각각의 작업을 별도 세션에서 처리할 수 있을 것이고, 동시성이 필요한 세션은 동시에 여러 에이전트를 호출하는 방식으로 가능하실 겁니다.질문하신 내용이 1세션 = 1과업에 대한 것이지만 과업이라고 하는 것을 어떤 규모와 서브 에이전트 수준에서 처리 가능한 것을 의미하고 말하신것인지 아닌지가 명확하지 않아 어느정도 큰 사이즈라 가정하고 답변 드립니다.

캬 그동안 클로드 코드 100달러 주고 1달러치 사용하고있었네요

안녕하세요, 수업이 도움이 되셨다니 기쁩니다.좋은 하루 되세요!

강의자료

안녕하세요.(사진)수업 노트 보기를 눌러보시면 강의 설명란에 있습니다.감사합니다.

불변성을 지키며 수정 삭제를 할때도 Map이 유리한가요?

안녕하세요 깊은 생각을 하고 공부에 임하고 계시군요. 결론부터 말씀드리자면 1초에 1번 수준에서는 Map와 Object의 성능 차이는 무의미합니다. 그래서 질문의 전제를 살짝 교정해 설명드리도록 하겠습니다. 불변성 패턴 자체의 비용Map의 경우setState(prev => new Map(prev).set(key, value)) Object의 경우setState(prev => ({ ...prev, [key]: value })) 둘 다 매번 새로운 객체와 맵을 생성하는 것은 동일하며, 맵이 메모리를 더 사용하지만 1초에 1번 수준이면 GC가 여유롭게 처리하기 때문에 실질적 차이는 없습니다. 그렇다면 더 맵이 더 많은 메모리를 차지한다는 말의 맥락이 무엇인지 생각해볼 필요가 있는데, 이건 수백만개 이상의 엔트리를 다루는 수준에서 입니다. React를 통한 일반적 데이터에서는 신경 쓸 필요는 없습니다. 이 부분에 있어서 "어떤 게 더 빠른가" 라는 부분은 과도한 사전 최적화에 해당합니다. 오히려 "이 데이터가 Map의 특성(동적 키, 순서 보장, non-string 키)이 필요할까?" 라는 기준으로 선택하면 됩니다. 만약 빈번한 업데이트가 병목이 된다면 그것은 데이터 타입의 문제가 아닌 상태 관리 도구를 어떤 식으로 활용할지 고민해보는게 더 좋습니다.

3장 디자인패턴에 프롭스 컬렉션과 슬롯 부분 강의 누락

안녕하세요 확인해보니 2개의 강의가 어떤 이유에선지 비공개 처리가 되어 있었네요. 수정해뒀습니다. 감사합니다.

추천패턴

좋은 질문입니다. 채팅은 구조상 최초에 테이블 구조를 잡아두더라도 시간이 지나면서 기능이 추가됨에 따라 데이터가 optional하게 추가되는 경향이 생깁니다. 가령 예를 들면 채팅 메시지로 처음 제품은 만들겠지만 채팅에 대해 이모지 응답, 읽은 사람 숫자 등의 메타 데이터, 첨부 파일, 링크 형태, 링크가 있을 때 미리보기를 제공해줄 수 있는 경우 등 온갖 경우의 수가 계속 생기게 됩니다. 그렇다면 생각해볼 점은 서버에 해당 데이터가 어떤 식으로 저장될까라는 점입니다. 그게 중요한 이유는 프론트에서는 결국 서버에 저장된 데이터의 형태를 따라서 후처리하는 방식으로 구현되기 때문입니다. 만약 새로운 기능이 스키마의 컬럼으로 추가되는 형태라면 프론트에서는 매번 해당 컬럼을 추가해주는 방식으로 타입은 맞춰줄 수 있지만 UI에 적합한 표시를 만들기에는 어색할 수 있을 겁니다. 저장된 데이터에 따라 조건부 렌더링이 매우 다양하게 발생하는 경우가 되는 셈이겠네요. 이와 같은 이유로 채팅과 같은 데이터를 프론트에서 표시할 때는 많은 조건부 렌더링을 대응할 수 있도록 구현하고, 이를 어댑터 패턴으로 구현해 맞춤형 디자인을 매칭해줄 수 있습니다. 다만 채팅은 단순히 어댑터를 이용해서 여러 상태에 맞춰 처리되도록 끼워넣기로만 구현하기에는 깔끔하지 않은 측면이 있습니다. 제 생각에는 조건부 렌더링에 대해 "어댑터 패턴 + compound 패턴"을 복합적으로 활용해 처리하는게 복잡한 경우의 수를 대응해줄 수 있을 것 같습니다.

원시 데이터 할당 방식

안녕하세요. 말씀주신 내용이 맞습니다. 질문하신 내용과 제가 설명한 내용 사이에 차이점이 있어서 질문해주신걸까요? 아니면 질문인걸까요? 제가 강의 내용이 워낙 많아 어떤 부분에 대한 것인지 헷갈리네요. 만약 강의 내용 중에 제가 이와 다르게 설명했다면 몇 강인지, 몇 분에서 설명이 잘못됐는지 알려주시면 감사하겠습니다.

좋아요 배치 처리 로직과 실제 API 동작 차이에 대해 질문드립니다

안녕하세요 클라이언트단 구현과 서버단 구현은 사실 정답이 있는 주제는 아닙니다. 클라이언트에서 막는 것은 서버까지 가는 요청의 총 숫자를 줄여 원천 차단에 의의가 있지만 반대로 정상적인 활동까지 막을 수도 있습니다. 또는 복잡한 예외 처리가 생길 수도 있겠죠. 제가 강의에서 이야기했는지 제 유튜브에서 얘기 했는지 정확히 기억은 나지 않지만, 대표적으로 farming 게임이 클라이언트단에서 모아서 처리하는 예에 해당합니다. 클래시오브클랜과 같은 게임을 해보셨을지 모르겠으나, 해당 게임은 접속하면 광산에 쌓인 골드를 클릭해 수집하고, 엘릭서를 수집합니다. 사용자의 대부분이 그 활동을 하죠. 아주 극소수의 사용자만 몇몇 광산의 골드와 엘릭서를 누락해서 수집할 수 있지만 대부분은 접속하자마자 그동안 쌓인 자원을 수집합니다. 그게 가장 효율적인 패턴이라 그렇죠. 그럴 때 여러번의 클라이언트 요청이 아닌 모아서 처리하는게 오래전부터 사용됐던 패턴이고, 이를 웹 클라이언트에서도 전략적으로 활용할 수 있습니다. 생각하신대로 서버측에서도 처리해도 괜찮은 전략입니다. DB에 너무 많은 짧은 I/O를 발생시키는 것은 서비스가 커질 수록 치명적일 수 있기 때문에 캐시 서버를 둬서 캐시된 데이터를 일정 사이클마다 처리한다던지 하는 방향으로 해결할 수도 있습니다. 인스타그램에서 테스트해보신 건 매우 좋은 습관입니다. 여러 서비스를 탐방하시면서 어떤 시점에 어떤 요청이 발생하는지, 묶어서 발생하는 경우가 있는지, 지속적으로 보시다보면 더 높은 수준의 자신만의 통찰을 얻으시리라 생각합니다. 감사합니다.