오늘 한 내용 AGENTS.md, AGENTS.override.md의 적용 순서 정리 전역 규칙과 프로젝트 규칙이 어떻게 병합되는지 확인 배운 내용 규칙 파일은 전역에서 프로젝트 하위 디렉토리로 내려오면서 적용된다. 같은 디렉토리에서는 AGENTS.override.md가 AGENTS.md보다 우선하고, 하위 디렉토리의 규칙이 더 구체적인 지침으로 해석된다. 결국 규칙은 전역에서 프로젝트 루트, 현재 작업 디렉토리 순서로 합쳐진다. 공통 원칙은 위쪽에 두고, 특정 모듈의 세부 규칙은 아래쪽에 두는 이유가 여기에 있다. 해결 내용 전역 원칙은 전역 규칙에, 프로젝트 공통 원칙은 루트에, 모듈별 세부 지침은 하위 디렉토리에 두는 계층을 정리했다. 더 가까운 디렉토리의 규칙이 구체적인 지침으로 적용된다는 점도 확인했다. ...

오늘 한 내용 Antigravity의 Rules, Skills, Workflows 구조 정리 dev-data-server-light의 AGENTS 규칙을 새 구조에 맞춰 마이그레이션 배운 내용 Antigravity의 핵심 구조는 다음처럼 정리할 수 있다. Rules = 행동 규칙 Skills = 특정 분야의 지식과 노하우 Workflows = 작업 절차 Rules는 항상 지켜야 할 원칙을 정의하고, Skills는 Storage 설계나 코드 리뷰처럼 특정 작업에 필요한 전문 지식을 담는다. Workflows는 계획, 구현, 테스트처럼 작업을 어떤 순서로 진행할지 정의한다. 기존 AGENTS.md를 그대로 옮기는 것이 아니라, 공통 원칙과 모듈별 규칙을 분리해야 했다. 규칙을 작게 나누면 모든 작업에 불필요한 문맥을 주입하지 않으면서도 필요한 순간에 더 구체적인 지침을 적용할 수 있다. ...

오늘 한 내용 Antigravity IDE의 에이전트, 에디터, 터미널, 브라우저 구조 살펴보기 File Storage 구현 순서와 StorageService 설계 배운 내용 Antigravity는 에디터 안에서 에이전트가 작업을 수행하고, 브라우저와 터미널을 사용해 결과를 검증하는 개발 환경이다. Agent는 기능 개발이나 버그 수정처럼 실제 작업을 담당하고, Tab은 자동완성에 가깝다. File Storage는 먼저 계약을 만들고, 그 다음 fs/promises 기반 구현체와 테스트를 추가한 뒤, Express와 분리된 Service를 얹는 순서로 진행하기로 했다. 처음부터 multipart 업로드까지 확장하지 않고, JSON과 단순한 파일 콘텐츠로 흐름을 검증하는 것도 중요한 범위 조절이었다. ...

오늘 한 내용 LeetCode 3558 풀이 DB 모듈에서 capability와 use case 분리 File Storage 모듈의 계약과 서비스 설계 배운 내용 기존에는 Route가 Database 인터페이스를 직접 사용했다. 리팩터링 후에는 Route -> DatabaseService -> RecordStore -> InMemoryRecordStore 흐름으로 바꾸었다. RecordStore는 레코드를 저장하고 꺼내는 교체 가능한 capability이고, DatabaseService는 여러 저장소 동작을 조합하는 use case다. 예를 들어 replace 이후 갱신된 레코드를 반환하거나, 삭제 결과에 따라 오류를 판단하는 흐름은 Service가 맡는다. File Storage도 같은 기준을 적용했다. 계약은 key와 Uint8Array만 사용해 작고 명시적으로 만들고, 로컬 파일 시스템이나 경로 검증은 구현체 안에 가둔다. ...

오늘 한 내용 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를 구성하는 핵심 요소는 크게 다음과 같다. ...

음식 사진에서 색상을 뽑아서 카드의 배경색에 적용하는 기능을 구현해야 했다. 처음 생각한 방향 원본 이미지를 그대로 다루면 비용이 크다. 색이 너무 많으면 후보가 지저분해진다. 원하는 색이 반드시 많이 나오는 색은 아니다. 결과를 화면에 어떻게 보여줄지도 같이 고민해야 한다. 직접 구현해보자. 외부 라이브러리를 쓰기보다는, 가능한 경우에는 항상 먼저 구현해보고 그 이후에 외부 라이브러리를 쓰는 방향을 선호하기 때문에, 직접 구현해보기로 했다. 학부 시절에 이미지 프로세싱을 하기도 했고 나름대로 흥미롭게 접근했다. CoreGraphics에서 픽셀 읽기 색상을 추출하려면 결국 이미지의 픽셀 값에 접근해야 했다. ...