오늘 한 내용

  • LeetCode 3345
  • Codeforces 489C
  • 블로그 스크립트 구조화, npm run 스크립트 정리
  • StackDay 프로젝트 도메인, 데이터 모델, 유즈케이스, MVP 범위 정리
  • Codex SKILL 공부

배운 내용

그리디 의심하기

Codeforces 489C를 DP로 한참 구현하다가, 뒤늦게 그리디로 해결되는 문제라는 걸 알게 되었다.

PS에서는 완전탐색 → 그리디 → DP 순서로 가능성을 검토하는 습관이 중요한 것 같다. 그리디가 최적인 것을 증명하는 연습이 더 필요하다는 것을 느꼈다. 경험을 통한 직관으로…

정책 -> 도메인 -> 데이터 모델 -> 유즈케이스 순서로 사고하기

Day Stack을 한번 뒤엎어야 했던 어제의 실패를 반면교사 삼아서, 이번엔 실제 구현에 들어가기 전에 도메인과 정책부터 제대로 잡으려 했다.

상세 내용은 개발 일지에 적겠지만, 간략하게 말하면. 이 과정이 왜 중요한지 알게 되었다.

  1. 프로젝트 컨셉: 프로젝트가 해결하려는 문제를 정의하고, 한두 문장으로 설명할 수 있을 정도로 정리한다.
  2. 정책 결정: 데이터 모델과 유즈케이스가 흔들리지 않도록 구현 전에 결정해야 할 규칙을 정의한다.
  3. 도메인 모델링: 프로젝트에서 사용하는 개념과 용어를 정의하고, 관계도 정리한다.
  4. 데이터 모델링: 도메인 개념과 용어를 실제 데이터 구조로 표현한다. 어떤 데이터가 원본이고, 어떤 데이터가 파생되는 데이터인지 구분한다.
  5. 유즈케이스 작성: 정책과 데이터 모델을 바탕으로 실제 동작을 정의한다. 이 때, 앞서서 한 과정들이 자연스러운지 검증할 수 있고, 정책의 빈틈도 찾을 수 있다.
  6. MVP 결정: 프로젝트 컨셉에서 잡은 핵심 기능을 보여줄 수 있는 최소 기능만 추려낸다. 프로젝트의 방향을 확인할 수 있다.

이후에 구현 순서는 도메인 -> 레포지토리 -> 유즈케이스 -> 뷰모델 -> 뷰가 될 것 같다.

이 프로세스를 거치면서 앞 단계들이 계속 검증되는 것이 정말 신기했다. 특히 유즈케이스를 작성할 때, 데이터 모델을 뭘 잘못 짰고, 어떻게 바꿔야 할지가 눈에 보였다. (구체적으로 말하자면, 당일에 해야하는 습관 행동을 저장하려 했는데, 그 데이터가 습관과 날짜의 파생 데이터인걸 알게 되었다.)

이런 식으로 유즈케이스를 작성하는 과정에서 모델을 몇번 수정했고, 그 결과 도메인 모델과 데이터 모델을 꽤 일관성 있게 짤 수 있었다.

반대로 어제처럼 구현부터 시작하면 어느 순간 앱을 스스로도 이해하지 못하게 된다. 내가 작성한 코드와 에이전트가 작성한 코드가 서로 다른 기준으로 계속 붙으면서 과도하게 복잡해지고, 내 손을 떠나게 된다.

직접 구현에 박치기 하는 것보다는 조금 프로젝트를 다시 정의하기 위해 시간을 투자했다. 구현 과정에서 훨씬 더 속도를 붙일 수 있겠다는 느낌이 든다.

AI가 원래 잘하는 걸 믿고, 고유의 규칙만 SKILL/AGENTS.md에 담자

프로젝트에서 뷰, 뷰모델, 레포지토리, 유즈케이스, 테스트 생성 SKILL을 사용했는데, ‘실제로 이런 방식으로 하나?’ 의문이 들어서 공개되어 있는 iOS Skill을 찾아봤다.

생각했던 것처럼 View 생성, ViewModel 생성 같은 Skill은 거의 찾아보기 어려웠다. 대신 대부분은 SwiftUI, Swift Concurrency, Testing, Debugging처럼 하나의 전문 분야나 워크플로를 담당하는 Skill이었다.

왜 그런지 살펴보니, View나 ViewModel을 생성하는 일 자체는 이미 AI가 충분히 잘하는 영역이었다. (예전 멘토도 AI보다 코드 잘 짜는 사람은 거의 없을거라고 한게 떠올랐다.) 반면 프로젝트마다 달라지는 폴더 구조, DI 방식, Navigation 규칙, Testing 스타일 같은 것들은 AI가 알 수 없는 정보다.

그래서 Skill이나 AGENTS.md에는 AI에게 코드를 작성하는 방법을 알려주기보다, 프로젝트 고유의 규칙과 컨벤션을 알려주는 것이 더 중요하다.

결국 Skill은 AI에게 코드를 작성하는 방법을 가르치는 도구가 아니라, 프로젝트만의 규칙과 판단 기준을 전달하는 도구에 가깝다는 걸 배웠다. 저번에 본 ‘너의 AGENTS.md가 냄새나는 이유’ 페이퍼에서 배운 내용과 잘 조합해서 작성해보려 한다.

해결한 것

블로그 스크립트 구조화

블로그 스크립트들이 정리가 안되어있어서 한번 구조를 다시 잡았다.

첫 번째로, ‘검증’ 스크립트와 ‘수정’ 스크립트를 분리했다. eof 스크립트 같은 경우에는 eof를 체크도 하고, 추가도 해주는 역할이 있었는데 이를 분리했다.

다음으로 블로그의 미디어 정책을 통일해서, 하나의 파일에 담았다. 검증이든 수정이든 이 정책을 보고 스크립트를 진행하도록 했다.

마지막으로 깃 훅도 정리했다. 훅에서 포스트를 수정하지 않고 그냥 검증이 실패하면 commit도 실패하는 방향으로 만들었다.

pre-commit에서 수정이 발생되어서 커밋과 다른 부분들도 수정되던 문제, 미디어 검사 기준이 따로 놀던 문제, 그리고 작성한 공통 스크립트를 사용 안하던 문제들을 해결했다.

내일 할 것

  • StackDay MVP 기능 구현 시작
  • Codex build-ios-apps Skill 분석 후 프로젝트에 적용
  • Local LLM, Dev-data-server-light, 미방문록 POC 개발일지 등, 블로그에 아직 못올린 포스트 정리하기