도입 범위 판단
이 문서의 결과: HandStack을 적용하기 좋은 상황과 다른 접근이 더 나은 상황을 구분한다.
HandStack이 잘 맞는 경우
| 특징 | 이유 |
|---|---|
| 화면·SQL·간단한 서버 로직 위주의 사내 업무 시스템 | 계약 중심 구조로 화면/서버 역할이 명확히 분리됨 |
| 여러 데이터베이스(MSSQL, Oracle, MySQL/MariaDB, PostgreSQL, SQLite)를 함께 다뤄야 함 | dbclient가 데이터베이스 종류를 계약 수준에서 추상화 |
| 배포 환경을 가볍게 유지하고 싶음 | 정적 웹 서버, CDN 등 다양한 방식으로 배포 가능, 컴파일 불필요 |
| 화면 수가 많고 반복되는 CRUD 패턴이 많음 | 항목 ID 규칙(BOD010, BOD011...)으로 일관된 구조 유지 |
신중히 검토해야 하는 경우
| 특징 | 검토할 점 |
|---|---|
| 복잡한 실시간 그래픽·게임처럼 프레임 단위 렌더링이 필요함 | HandStack은 업무 화면(CRUD, 조회, 입력) 중심 |
| 이미 확정된 마이크로서비스 아키텍처에 강하게 종속돼야 함 | 모듈러 모놀리식 아키텍처 문서로 구조 적합성 먼저 확인 |
| 팀 전체가 계약 기반 개발 방식에 대한 학습 시간을 전혀 낼 수 없음 | 최소 [01~04주제]까지는 학습 시간이 필요 |
작은 업무로 시작하는 방법
- 화면 1
3개, 테이블 12개 수준의 업무(예: 게시판, 신청서 목록)를 선정합니다. - 03. 프로젝트와 개발 서버에서 별도 프로젝트로 격리해 실습합니다.
- 운영 시스템과 무관한 SQLite 등 가벼운 데이터베이스로 먼저 검증합니다.
- 성공 기준(조회·저장·삭제가 정상 동작, 오류 시 원인 추적 가능)을 미리 정합니다.