오늘 한 내용 LeetCode 3689, 2574 풀이 dev-data-server-light의 AGENTS.md 구조 정리 루트와 모듈별 개발 규칙의 중복 검토 배운 내용 새 디렉토리 구조에서는 공통 원칙을 루트 AGENTS.md에 모으고, 모듈에만 해당하는 규칙은 해당 모듈의 문서에 두는 방향이 적절하다. 루트에는 TypeScript, Express, Vitest 같은 기술과 전체 아키텍처, 테스트 원칙을 둔다. 반면 DB 모듈의 레코드 모델이나 저장소 구현 규칙처럼 다른 모듈이 알 필요 없는 내용은 DB 문서에 남긴다. 중복된 규칙은 단순히 길이의 문제가 아니다. 같은 내용이 여러 파일에 있으면 나중에 한쪽만 수정될 수 있고, AI가 서로 다른 지침으로 해석할 가능성도 생긴다. ...
오늘 한 내용 dev-data-server-light의 계층형 구조를 모듈형 구조로 바꾸는 작업 검토 AGENTS.md가 새 디렉토리 구조와 충돌하지 않도록 정리 Database, Route, Service의 책임 재검토 배운 내용 기존 구조는 routes, services, db처럼 계층별로 나뉘어 있었다. 새 구조에서는 모듈이 자신의 계약, 구현체, 서비스, 라우트를 함께 소유하도록 바꾸려 했다. 계층형 구조에서는 AGENTS.md에 각 계층의 역할을 적기 쉬웠지만, 모듈형 구조에서는 모듈의 책임과 공개 API를 기준으로 규칙을 작성해야 한다. 구조가 바뀌면 문서도 함께 바뀌어야 하며, 기존 규칙을 억지로 유지하면 오히려 AI가 잘못된 경계를 학습하게 된다. ...
오늘 한 내용 dev-data-server-light의 DB 모듈 설계 정리 System 모듈과 DB 인터페이스 구현 방향 검토 저장소와 애플리케이션 로직의 경계 정리 배운 내용 이름도 설계의 일부 처음에는 DocumentStore, StoredDocument, DocumentBody라는 이름을 사용했다. 하지만 DB CRUD 인터페이스를 설계하는 과정에서 이 이름들이 프로젝트가 특정 Document Database를 전제로 한다는 인상을 준다는 것을 발견했다. In-Memory, SQL, JSON File 등 여러 구현을 염두에 둔다면 인터페이스도 구현 방식에서 자유로워야 한다. 그래서 RecordStore, StoredRecord, RecordData처럼 더 중립적인 이름으로 바꿨다. ...
요약 LeetCode 문제를 풀면서 자료의 표현 방식이 성능에 큰 영향을 준다는 점을 다시 확인했다. 또한 Express의 req, res, next()가 어떻게 협력하여 요청을 처리하는지 파이프라인 관점에서 정리했다. 배운 것 LeetCode 3043 최적화 LeetCode 3043번 문제를 풀었다. 두 정수형 배열에 있는 원소들 중 임의의 두 수를 선택했을 때, 공통의 일치하는 prefix의 최대 길이를 구하는 문제였다. 우선, 각 배열의 길이가 최대 50000이기 때문에, 가능한 모든 쌍을 만들어서 크기를 구하는 방식으로 하면 시간복잡도가 O(n²)이 되어서 문제를 제 시간 안에 해결하기 힘들다. (n은 둘 중 긴 배열의 원소의 개수) ...
요약 Express의 핵심 구성 요소와 요청 처리 흐름을 정리했다. 특히 Middleware가 특정 객체가 아니라 요청 처리 과정에서 동작하는 함수들의 역할이라는 점과, Express가 함수형 체인이 아닌 공유 객체(req, res)를 사용하는 파이프라인 구조라는 점을 이해하게 되었다. 배운 것 오늘 공부한 내용 Express의 App, Router, Middleware Express의 동작 Express의 간단한 내부 구조 Express의 핵심 구성 요소 처음에는 Express를 iOS의 MVC에서 View를 제거한 형태 정도로 생각했다. Route Handler가 Controller 역할을 하는 것이라고 생각했다. Express를 구성하는 핵심 요소는 크게 다음과 같다. ...