2025년 9월 17일·7분
프레임워크 관례가 문서 필요성을 줄이는 방법
프레임워크 관례는 긴 문서 없이도 애플리케이션을 이해하기 쉽게 만듭니다. 관례가 무엇을 다루는지, 어디서 실패하는지, 예외만 문서화하는 방법을 알아보세요.
프레임워크 관례는 긴 문서 없이도 애플리케이션을 이해하기 쉽게 만듭니다. 관례가 무엇을 다루는지, 어디서 실패하는지, 예외만 문서화하는 방법을 알아보세요.
프레임워크 관례는 프레임워크가 조용히 권장하거나(또는 기대하는) “기본적인 방식”입니다. 모든 팀이 각자 폴더 레이아웃, 이름 규칙, 요청/응답 흐름을 발명하는 대신, 프레임워크가 공통 패턴을 제공합니다. 그 패턴을 따르면 다른 개발자는 긴 설명 없이도 파일이 어디에 있고 어떻게 동작하는지 예측할 수 있습니다.
대부분 문서는 사람들이 문서 쓰는 것을 좋아해서가 아니라 반복되는 몇 가지 문제를 해결하기 위해 존재합니다:
관례는 특히 앞의 두 가지 문제를 잘 다룹니다. “X를 어디에 둘까?”와 “Y를 무엇으로 부를까?”가 이미 프레임워크에 의해 정해져 있으면 설명할 것과 논쟁할 것이 줄어듭니다.
“관례가 문서를 대체한다”는 말은 프로젝트가 문서가 전혀 없는 상태가 된다는 의미가 아닙니다. 대신 기본 안내의 큰 부분이 산문에서 예측 가능한 구조로 이동한다는 뜻입니다. 컨트롤러가 어디에 있는지를 배우기 위해 위키 페이지를 읽는 대신, 프레임워크가 컨트롤러를 특정 위치에 기대하기 때문에 그것을 추론하게 됩니다(도구, 제너레이터, 예제가 이를 강화합니다).
결과는 명백한 것에 대한 문서가 줄어들고, 프로젝트 특유의 것—비즈니스 규칙, 특이한 아키텍처 선택, 의도적인 예외—을 문서화하는 데 더 집중하게 됩니다.
이 글은 문서가 산처럼 많은 곳 없이도 코드베이스를 더 명확하게 하고 온보딩을 빠르게 하려는 개발자, 기술 리드, 제품 지향 팀을 위한 것입니다.
프레임워크 관례가 어떻게 “암묵적 문서”를 만드는지, 관례가 보통 표준화하는 항목, 관례가 도움이 멈추는 지점, 그리고 여전히 명시적 문서가 필요한 것들을 배우게 됩니다—그래서 문서는 줄어들면서도 명확성은 올라갑니다.
“설정보다 관례(Convention over configuration)”는 프레임워크가 당신을 위해 합리적인 선택을 해준다는 뜻입니다—단, 그 합의된 규칙을 따르면. 설정 방법을 한 줄씩 쓰고 읽는 대신 팀은 모두가 인식하는 공유된 기본값에 의존합니다.
모두가 오른쪽 차선에서 운전하고, 빨간불에서 멈추고, 표준 표지판을 따르는 나라에서 운전하는 것과 비슷합니다.
교차로마다 세세한 매뉴얼을 쓸 수는 있지만(“빨간 팔각형을 보면 멈춰라; 녹색이면 가라…”), 그럴 필요가 없습니다—관례가 이미 알려져 있고 일관되게 적용되기 때문입니다.
프레임워크 관례도 마찬가지입니다: “여기서는 이렇게 한다”를 예측 가능한 동작으로 바꿉니다.
프레임워크가 기본값을 가지면 모든 사소한 결정을 문서화할 필요가 없습니다. 프레임워크(그리고 팀)는 다음과 같은 패턴을 가정할 수 있습니다:
User 모델이 users 데이터에 매핑되는 식)그 공유된 기준선은 문서를 “여기에 대해 설정하는 모든 단계”에서 “우리는 프레임워크 기본을 따릅니다—예외가 있으면 표기합니다.”로 축소합니다. 또한 온보딩 중 정신적 부담을 줄여줍니다: 새 개발자는 다른 프로젝트에서 본 것과 일치하는 코드를 보고 더 자주 올바르게 추측할 수 있습니다.
관례는 공짜가 아닙니다. 단점은 때때로 특이한 폴더 구조, 커스텀 네이밍, 맞춤형 워크플로를 포기해야 한다는 것입니다.
장점은 일관성입니다: 토론이 줄고, 놀라움이 줄고, 오래된 직원만 아는 부락 지식(tribal knowledge) 규칙이 줄어듭니다. 팀은 설명에 시간을 덜 쓰고 구축에 더 많은 시간을 쓸 수 있습니다.
관례가 문서를 절약하려면 사람들이 이미 그것을 알고 있거나 한 번 배우고 어디서든 재사용할 수 있어야 합니다.
그래서 인기 있는 프레임워크의 힘이 큽니다: 관례가 널리 교육되고, 널리 사용되며, 많은 코드베이스에서 반복됩니다. 프로젝트가 그 공유된 기본값에 가깝게 머무를수록, 코드가 별도의 설명 없이도 기본적으로 이해 가능한 상태가 됩니다.
프레임워크 관례는 공유된 지름길입니다. 새로운 팀원이 첫날 묻는 질문들을 표준화합니다: “이걸 어디에 두지?”와 “이건 뭐라고 불러야 하지?” 그 답이 예측 가능하면 몇 페이지 분량의 문서를 몇 가지 일관된 기본값으로 대체할 수 있습니다.
대부분의 프레임워크는 UI용 장소, 라우트용 장소, 데이터 접근용 장소, 테스트용 장소 같은 알아보기 쉬운 프로젝트 구조를 권장합니다. 이 일관성은 “페이지를 렌더링하는 부분”과 “데이터베이스와 통신하는 부분”을 찾기 위해 가이드를 읽을 필요가 없게 만듭니다.
최고의 관례는 일반 작업이 근육 기억처럼 느껴지게 합니다: 새 화면을 추가하면 이미 어느 폴더에 넣어야 하는지 압니다.
이름 규칙은 “우리 컨트롤러는 X에 있고 Y에 연결되어야 한다” 같은 설명의 필요성을 줄입니다. 대신 이름이 역할을 암시합니다.
일반 예시:
많은 웹 프레임워크는 파일을 라우트에 매핑하거나 라우트를 추론하기 쉽게 만듭니다. 파일명에서 URL을 추측할 수 있거나 그 반대라면, 모든 기능에 대해 별도의 라우팅 문서를 작성할 필요가 없습니다.
관례는 동적 라우트, 중첩 라우트, 404 처리에 대한 기대도 설정하므로 “새 엔드포인트를 어떻게 추가하나?”라는 질문에 표준 답이 존재합니다.
관례는 종종 “데이터 코드”가 어디에 있는지 정의합니다: 모델, 리포지토리, 서비스, 마이그레이션, 스키마 파일. 앱이 작더라도 데이터 접근의 합의된 위치가 있으면 UI 코드 전반에 흩어지는 임시 데이터 호출을 막을 수 있습니다.
실행, 테스트, 빌드, 린트, 포맷 같은 표준 명령은 모호함을 제거합니다. 새 개발자가 프로젝트를 시작하려고 위키 페이지를 찾을 필요 없이 npm test(또는 동등한 명령)가 분명한 첫 동작이어야 합니다.
이 다섯 영역이 일관되면 코드베이스 자체가 대부분의 “여기서는 어떻게 하죠?” 질문에 답합니다.
모든 것을 설명하려는 위키는 전체 시스템을 산문으로 설명하려고 하며, 초기에는 유용하지만 폴더가 이동하고 이름이 바뀌고 새로운 기능이 추가되면서 점점 최신성이 떨어집니다. 관례는 그 아이디어를 뒤집습니다: 긴 설명을 읽는 대신 구조를 읽습니다.
프레임워크(및 팀)가 어디에 무엇이 있는지 합의하면 저장소는 도시 그리드처럼 탐색 가능해집니다.
UI 컴포넌트가 components/에, 페이지 수준 뷰가 pages/에, API 핸들러가 api/에 있다는 것을 알면 “X는 어디에 있지?”라는 질문을 멈출 수 있습니다. 맞지 않을 때조차 검색 범위가 좁아집니다: 아무 데나가 아니라 몇 개의 예상되는 장소 중 하나입니다.
관례는 파일명과 심볼에 의미를 부여합니다. 새로 온 사람은 위치와 이름만 보고도 동작을 추론할 수 있습니다:
user.controller라는 파일은 요청 로직을 담당할 가능성이 높고UserService 클래스는 비즈니스 규칙을 담고 있을 가능성이 높고migrations/ 폴더는 순서대로 실행되는, 한 번 실행되는 데이터베이스 변경을 담고 있을 가능성이 높습니다그러한 추론은 “아키텍처를 설명해 달라”는 질문을 더 작고 답하기 쉬운 질문들(“이 서비스가 직접 DB를 호출해도 될까?”)로 분해합니다.
지도를 강화하는 가장 빠른 방법은 스캐폴딩입니다. 스타터 템플릿과 제너레이터는 기본적으로 ‘올바른’ 형태로 새 기능을 만들어 줍니다—폴더, 파일명, 보일러플레이트 연결, 종종 테스트까지.
관례는 일관되게 적용될 때만 도움이 되므로 템플릿은 가드레일 역할을 합니다: 새 라우트, 컴포넌트, 모듈을 예상되는 구조로 유도해 코드베이스가 추가 위키 페이지 없이도 읽기 쉬운 상태를 유지하게 합니다.
내부 스캐폴드를 유지한다면 간단한 온보딩 페이지(예: /docs/getting-started)에서 링크하고 폴더 트리가 나머지를 하게 두세요.
프레임워크 관례는 종종 조용한 내장 지침처럼 작동합니다. “여기를 두면 작동한다”는 식으로 결정을 이미 내리고 있으므로 따로 문서를 쓰지 않아도 됩니다.
Rails는 설정보다 관례로 유명합니다. 간단한 예: OrdersController라는 컨트롤러를 만들면 Rails는 app/views/orders/에 대응하는 뷰 폴더가 있다고 가정합니다.
이 단일 관례는 그렇지 않았다면 다음을 설명하는 문서를 상당 부분 대체할 수 있었습니다:
결과: 새 팀원은 폴더 패턴을 따라 페이지를 추가할 수 있고 “이 파일은 어디에 가야 하나?”라고 묻지 않습니다.
Django는 일관된 “앱” 구조를 권장합니다. Django 앱을 보면 models.py에는 데이터 구조, views.py에는 요청 처리, templates/에는 HTML이 있다고 기대합니다.
프로젝트 해부를 설명하는 긴 가이드를 쓸 수 있지만 Django의 기본값이 이미 그것을 가르칩니다. 페이지를 바꾸려면 templates/를 보고, 저장된 데이터를 조정하려면 models.py를 확인하면 됩니다.
결과: 수정이 빨라지고, 찾는 시간이 줄며, “이 파일이 이걸 제어하나요?” 같은 메시지가 줄어듭니다.
Next.js는 폴더 구조가 라우팅을 직접 반영하도록 만들어 라우팅 문서를 줄여줍니다. app/about/page.tsx(또는 이전 방식의 pages/about.tsx)에 파일을 만들면 자동으로 /about 페이지가 생깁니다.
이것은 다음 문서의 필요를 제거합니다:
결과: 온보딩이 단순해지고 사람들은 디렉터리를 스캔하면서 사이트의 구조를 발견할 수 있습니다.
Rails, Django, Next.js는 다르게 보이지만 원리는 동일합니다: 공유된 기본값이 프로젝트 구조 자체를 지침으로 만든다. 모두가 같은 관례를 신뢰하면 코드베이스가 많은 “여기서는 어떻게 하지?” 질문에 별도 문서 없이 답합니다.
관례가 잘 작동할 때는 파일이 어디에 있는지, 무엇이라 불리는지, 요청이 앱을 통해 어떻게 흐르는지 추측할 수 있습니다. 혼란은 코드베이스가 그 공유된 기본값에서 벗어날 때 돌아옵니다.
초기에는 다음과 같은 패턴이 나타납니다:
UserService, 다른 부분은 UsersManager, 또 다른 부분은 user_service 사용이것들이 자동으로 틀린 것은 아니지만, 새 팀원이 더 이상 프레임워크의 “지도”에 의존할 수 없다는 뜻입니다.
대부분의 관례 붕괴는 합리적인 국소 최적화에서 시작합니다: “이 기능은 특수하니 여기다 둡시다” 또는 “이 네이밍이 더 읽기 좋다”. 문제는 예외가 전염성이 있다는 것입니다. 첫 번째 예외가 배포되면 다음 개발자는 그것을 선례로 삼습니다:
그 시점에서 관례는 더 이상 관례가 아니라 부락 지식이 됩니다.
관례가 흐려지면 온보딩이 느려집니다. 사람들은 어디를 찾아야 할지 예측할 수 없기 때문입니다. 일상 작업이 길어지고(“이 폴더가 진짜인가?”), 실수가 늘며(잘못된 모듈을 연결하거나 잘못된 네이밍을 사용하는 등), 팀은 보상으로 더 많은 동기화 회의, 더 긴 PR 설명, 오래된 퀵 문서를 추가합니다.
명확한 이유가 있을 때만 커스터마이즈하고, 짧은 메모를 남기세요.
그 메모는 가볍게 유지할 수 있습니다: 특이한 구조 근처의 한 줄 주석이나 폴더 내부의 짧은 README.md, 또는 /docs/decisions에 간단한 항목을 남기는 식입니다.
프레임워크 관례는 많은 설명을 제거해 주지만 책임까지 없애주지는 않습니다. 문서화가 여전히 필요한 부분은 대체로 “대부분의 개발자가 가정할 것과 의도적으로 다른” 프로젝트의 부분입니다.
표준적인 프레임워크 동작을 다시 설명하지 마세요. 대신 사람들이 일하면서 영향을 받는 결정들을 캡처하세요:
예: “우리는 소유권이 팀에 매핑되고 교차 팀 결합을 줄이기 때문에 레이어 폴더(/src/components, /src/services) 대신 /src/features 아래 기능 폴더를 사용한다.” 이 한 문장은 느린 드리프트를 몇 주 동안 방지할 수 있습니다.
예외가 지역적으로 중요한 경우 그 지점에 메모를 두세요. 폴더 내부의 작은 README.md나 파일 상단의 짧은 헤더 주석이 중앙 위키보다 낫습니다.
좋은 후보:
메모는 짧고 실행 가능하게: 무엇이 다른지, 왜 다른지, 다음에 무엇을 해야 하는지.
한 장짜리 가벼운 페이지(보통 /docs/project-rules.md 또는 루트 README)에 사람들이 걸리기 쉬운 5–10가지 핵심 선택을 적으세요:
완전한 매뉴얼이 아니라 공동의 가드레일입니다.
관례가 있어도 사람들이 앱을 실행하지 못하면 온보딩이 막힙니다. 표준 명령과 실제 설정을 일치시키는 짧은 “How to run/test” 섹션을 추가하세요.
관례 명령이 npm test인데 프로젝트가 npm run test:unit을 요구한다면 그 차이를 명확히 문서화하세요.
문서는 변경의 일부로 취급될 때 정확성을 유지합니다. 리뷰에서 “이 변경이 새로운 예외를 도입했는가?”를 묻고, 그렇다면 같은 PR에 지역 README, Project Rules, 또는 루트 퀵스타트의 갱신을 요구하세요.
관례가 코드베이스의 “공유 기본값”이라면 자동화는 그것들을 실질화합니다. 모든 개발자에게 위키를 기억하라고 요청하지 말고 규칙을 실행 가능하게 만들어 프로젝트가 스스로를 강제하도록 하세요.
좋은 설정은 드리프트를 조용히 그리고 초기에 잡아냅니다:
*.spec.ts, describe/it 문구 또는 필요한 어서션을 강제이 검사들은 “제발 기억해라”라는 문장 몇 줄을 대체합니다: 코드가 규칙을 따르거나 따르지 않거나.
자동화가 뛰어난 이유는 빨리 실패하게 하기 때문입니다:
최고의 규칙 세트는 작고 지루합니다. 프레임워크의 기본값에서 시작하고, 명확성을 지키는 항목(네이밍, 구조, 경계)만 추가하세요. 새로운 검사 하나가 늘어날수록 사람들이 이해해야 할 것이 늘어나므로, 새 규칙은 반복되는 문제를 해결할 때 추가하고 도움이 안 되면 제거하세요.
관례를 따르는 코드베이스에서 테스트는 단순한 동작 증명 이상이 됩니다. 테스트는 구현 옆에 시스템이 무엇을 약속하는지 설명할 수 있습니다.
유용한 규칙: 하나의 테스트는 하나의 행동을 끝까지 설명해야 한다. 누군가 테스트 이름을 훑어보고 시스템의 약속을 이해할 수 있다면 별도의 문서를 덜어낸 것입니다.
좋은 테스트는 보통 다음 리듬을 따릅니다:
이름은 사용자 의도를 닮게 하면 더 좋습니다:
signing_in_with_valid_credentials_redirects_to_dashboardcheckout_fails_when_shipping_address_is_missing이런 이름은 실패하는 테스트가 대화를 불러일으키기 때문에 업데이트를 잊기 어렵습니다.
수용(또는 피처) 테스트는 사용자 관점에서 제품이 어떻게 동작하는지를 문서화하는 데 탁월합니다.
예시 행동:
이 테스트들은 “X를 하면 무슨 일이 일어나나?”라는 질문에 답합니다.
유닛 테스트는 다음을 문서화하는 데 강력합니다:
프레임워크 관례로는 명백하지 않은 규칙일수록 유닛 테스트가 중요합니다.
샘플 데이터도 살아있는 문서가 될 수 있습니다. 작고 잘 이름 붙은 픽스처(예: user_with_expired_subscription)는 위키의 한 문장보다 도메인을 더 빨리 가르쳐 줍니다.
핵심은 절제입니다: 픽스처는 최소화하고 읽기 쉬우며 한 가지 아이디어에 묶어 두어야 신뢰할 수 있는 예제가 됩니다.
스타터 템플릿(및 그 뒤의 제너레이터)은 “여기서 우리는 이렇게 한다”를 실제로 사람들이 따르게 만드는 가장 빠른 방법입니다. 모든 팀원이 올바른 폴더, 스크립트, 툴링을 기억하도록 요구하는 대신, 올바른 결정을 리포지토리에 구워 넣으세요.
이 셋은 관례를 문서화 대신 기본값으로 인코딩하여 문서 부채를 줄입니다.
실무에서는 Koder.ai 같은 도구가 도움이 됩니다: 채팅 기반 워크플로로 새 React 앱, Go 백엔드, PostgreSQL 스키마, Flutter 클라이언트를 생성하면 기본 출력이 관례와 일치하게 만들고 그 소스 코드를 리포로 내보내서 팀의 골든 패스를 유지할 수 있습니다.
온보딩 중 가장 큰 혼란은 비즈니스 로직보다는 ‘어디에 무엇이 있는가’와 ‘어떻게 실행하는가’입니다. 좋은 템플릿은 공통 작업을 모든 리포지토에서 동일하게 만듭니다: 동일한 스크립트, 동일한 폴더명, 동일한 체크 명령, 동일한 PR 기대치.
적어도 다음을 맞추세요:
/src, /test, /docs(예외용))test, lint, format 스크립트팀이 건너뛰지 않을 만큼 작게 유지하세요:
install + dev)test, lint, format 스크립트가장 큰 위험은 “작년에 잘 작동했으니”라며 오래된 템플릿을 복사하는 것입니다. 오래된 종속성, 레거시 스크립트, 방치된 패턴이 템플릿에 들어가면 빠르게 퍼집니다.
템플릿을 제품처럼 취급하세요: 버전 관리하고, 일정에 따라 검토하고, 관례가 바뀌면 업데이트하세요. (플랫폼이 스냅샷과 롤백을 지원하면—Koder.ai처럼—그걸 사용해 스타터를 안전하게 반복하세요.)
문서를 줄인다고 사람들이 추측하도록 내버려 두는 것이 아닙니다. 일반 경로(happy path)를 일관되게 만들어 대부분의 질문이 스스로 답하도록 하고, 진짜 이례적인 부분만 문서화하면 됩니다.
사람들이 슬랙, PR 코멘트, 스탠드업, 온보딩 세션에서 반복해서 묻는 곳을 찾아보세요. 몇 가지 프롬프트:
같은 질문이 두 번 이상 들리면, 아마도 더 많은 설명이 필요한 것이 아니라 관례가 필요합니다.
반복되는 질문마다 다음 중 하나로 결정하세요:
유용한 규칙: 편차가 실제로 시간을 절약하거나 실질적 위험을 줄이지 않는다면 그 편차는 장기적으로 혼란만 초래하므로 유지할 가치가 없다.
하나의 짧은 페이지(예: /docs/conventions)에 다음을 적으세요:
이것은 누군가 첫 주에 필요한 것만 담아야 합니다. 페이지가 커지기 시작하면 코드베이스를 단순화해야 할 신호일 가능성이 큽니다.
앱은 진화합니다. 가벼운 분기별 리뷰 일정을 잡으세요:
가능한 경우 프레임워크 기본값을 우선하고, 다른 점만 명확하고 간결하게 문서화하세요.
프레임워크 관례는 프레임워크가 조용히 권장하거나(또는 기대하는) 기본적인 방식입니다. 폴더 구조, 이름 규칙, 라우팅, 데이터 접근 방식, 자주 쓰이는 명령 등입니다. 관례를 따르면 다른 개발자는 프로젝트별 문서를 읽지 않아도 파일이 어디에 있고 어떻게 동작하는지 추론할 수 있습니다.
문서가 많은 이유는 코드가 바뀔 때 산문으로 된 설명을 정확하게 유지하기가 어렵기 때문입니다. 문서는 주로 다음 문제를 해결하려고 존재합니다:
관례는 구조를 예측 가능하게 만들어 첫 두 가지 문제를 상당 부분 덮습니다.
아닙니다. 관례는 파일이 어디에 있는지, 라우트가 어떻게 연결되는지 등 명백한 부분에 대한 문서를 줄여주지만, 여전히 프로젝트 특유의 부분(비즈니스 규칙, 의도적인 예외, 주요 결정)은 문서화해야 합니다. 요점은 “문서를 덜 쓰되 가치 있는 문서를 쓰자”입니다.
관례는 신입 개발자가 처음으로 묻는 반복적인 질문들을 표준화합니다:
이 항목들이 예측 가능하면 저장소 자체가 설명 역할을 합니다.
코드가 알려진 패턴을 따를 때 디렉터리 구조와 파일명이 길잡이 역할을 합니다. 예를 들어 누군가 templates/에서 템플릿을 찾고, migrations/에서 마이그레이션을 찾는 식으로 기대에 따라 이동합니다. 즉, 긴 아키텍처 문서를 읽는 대신 폴더 구조를 ‘읽는’ 방식입니다.
스캐폴딩 도구와 제너레이터는 관례를 기본값으로 내장해서 사람들이 기억에 의존하지 않도록 만듭니다. 좋은 스캐폴드가 생성하는 것:
이렇게 하면 규칙이 드리프트하는 것을 막고 프로젝트 전체에서 일관된 ‘지도’를 유지할 수 있습니다.
관례가 무너질 때 개발자가 어디에 무엇을 두어야 할지 예측하지 못하는 것이 눈에 보입니다. 일반적인 신호들:
UserService vs UsersManager vs user_service)이 상태가 되면 팀은 슬랙 설명, 긴 PR 설명, 오래된 퀵 문서로 보상하려고 하며 혼란이 커집니다.
명확한 이유가 있을 때만 커스터마이즈하고, 그 이유를 가볍게 문서화하세요:
README.md를 두기/docs/decisions 같은 곳에 항목 추가하기무엇이 바뀌었고, 왜 바뀌었는지, 앞으로 표준 접근법은 무엇인지 세 문장 정도로 남기면 충분합니다.
강한 관례가 있어도 다음과 같은 최소한의 문서는 남겨두는 것이 좋습니다:
가볍게 유지하고, 예외가 생길 때마다 코드 리뷰에서 문서 업데이트를 요구하세요.
관례를 실행 가능한 규칙으로 만드는 자동화가 답입니다. 문서로 ‘기억하라’고 하지 말고, 도구가 ‘강제’하게 하세요:
로컬 개발이나 PR 단계에서 실패하도록 하면 개발자는 즉시 규칙을 배우고 리뷰어는 스타일 단속에 시간을 쓰지 않아도 됩니다.
테스트는 동작을 증명하는 것을 넘어 설명 역할을 할 수 있습니다. 사람이 읽기 쉬운 테스트 규칙:
signing_in_with_valid_credentials_redirects_to_dashboard 등)수용 테스트는 사용자 관점의 흐름을 문서화하고, 유닛 테스트는 경계·검증·모서리 케이스를 설명합니다. 작은 의미 있는 픽스처(예: user_with_expired_subscription)도 도메인 학습에 유용합니다.
스타터 템플릿과 제너레이터는 새 프로젝트나 새 기능 생성 시 관례를 기본으로 주입합니다:
템플릿을 버전 관리하고 정기적으로 검토하세요. 오래된 템플릿은 폐단을 전파합니다.
간단한 체크리스트로 문서를 줄이면서도 명확함을 유지할 수 있습니다:
/docs/conventions 같은 한 페이지에 핵심 관례와 예외만 정리하라요약: 가능한 한 프레임워크 기본을 따르고, 다른 점만 명확하고 간단하게 문서화하세요.