신기술사업금융회사 투자실적 취합 시스템을 대상으로 한 진단 범위·방법론·일정·의견서 목차 견본입니다. 계약 전에 “무엇을 받고 무엇을 하지 않는지”를 확인하기 위한 문서입니다.
포함과 제외를 계약 전에 고정합니다. 아래는 본 과업(기술 진단·자문, 7일)에서 통상 적용하는 경계입니다.
| 구분 | 포함 (이 과업에서 수행) | 제외 (이 과업에서 수행하지 않음) |
|---|---|---|
| 코드·구조 | 소스코드 리뷰, DB 구조·아키텍처 적합성 검토, 구현 기능 동작·로직 파악 | 리팩터링 실행, 코드 수정·커밋, 기능 구현 |
| 리스크·자문 | 보안·성능·확장성·유지보수성 리스크 분석, 유지 vs 재구축 판단, 고도화 로드맵 조언 | 재구축 상세 설계서 작성, 개발 착수, 인프라 구축·배포 운영 |
| 산출·소통 | 시스템 진단 결과 및 기술 자문 의견서 (Word 또는 PPT) | 상주·오프라인 방문, 운영 장애 대응, 제3자 감사 인증 대행 |
공고가 명시한 산출물은 의견서입니다. 아래는 같은 견적·7일 일정 안에서 저희가 함께 드리는 항목이며, 공고 요구사항과 별도로 표기합니다.
각 축마다 무엇을 보는지, 어떤 수단으로 보는지, 어떤 기준으로 판정하는지를 고정합니다. 스택은 FastAPI · React · SQLite 기준으로 점검합니다.
모듈 경계, 명명·계층 일관성, 중복·순환 의존, 예외 처리 패턴, 타입·스키마 사용 깊이, 프론트 컴포넌트 책임 분리.
정적 분석(린트·import 그래프 샘플), FastAPI 라우터·의존성 주입·Pydantic 모델 수동 리뷰, React 컴포넌트 트리·상태 위치 수동 리뷰, 핵심 경로 실행 검증(가능 시).
변경 시 영향 범위 예측 가능 여부, 도메인 규칙이 한곳에 모이는지, 테스트 없이 회귀를 막을 수 있는 구조인지.
SQLite 스키마 정규화, 인덱스·외래키, 트랜잭션 경계, 동시 쓰기 경로, 마이그레이션 이력, 보고·집계용 쿼리 형태.
스키마·마이그레이션 파일 리뷰, 대표 쓰기/읽기 경로 추적, EXPLAIN 샘플(가능 시), 백업·복구 절차 문서·스크립트 확인.
무결성 제약의 명시성, 배치 적재·보고서 생성 시 잠금 위험, 향후 RDBMS 이관 시 스키마 이질성 크기.
인증·인가 미들웨어, 시크릿 관리, 입력 검증(Pydantic·프론트 이중 검증), SQL·명령 주입 여지, CORS·쿠키·세션, 파일 업로드 경계, 감사 로그.
인증 체인 코드 추적, 의존성 취약 버전 스캔(공개 CVE 목록 대조), 권한 분기 수동 리뷰, 업로드·다운로드 경로 실행 검증(가능 시).
최소 권한 원칙, 시크릿 하드코딩 부재, 역할 경계가 서버에서 강제되는지, 금융 실적 데이터 유출 경로 통제 여부.
동기/비동기 I/O 사용, N+1 쿼리, 대용량 응답, React 번들·렌더 비용, SQLite writer 직렬화 구간, 배치·리포트 생성 시간 특성.
핫 경로 코드 리뷰, 쿼리 패턴 샘플링, 프론트 번들·리렌더 지점 점검, 가능 시 대표 시나리오 응답 시간 측정(부하 테스트 전면 수행은 범위 밖).
동시 사용자·배치 작업이 겹칠 때 체감 지연 원인 식별 가능성, 병목이 코드·스키마·인프라 중 어디에 있는지 설명 가능 여부.
모듈 추가 비용, API 버전·스키마 진화, 멀티 유저·멀티 프로세스 전제, SQLite→서버 RDBMS 이관 준비도, 엑셀 업로드·보고서 자동화 확장점.
디렉터리·패키지 구조 리뷰, 설정·환경 분리, 큐·백그라운드 작업 유무, 데이터 접근 계층 추상화 수준 점검.
고도화 기능을 “덧붙이기” vs “기반을 갈아엎기” 중 어느 쪽이 짧은 경로인지, 이관 시 애플리케이션 변경량 예측.
문서·README·환경 구성, 테스트 유무·실행 방법, 로깅·에러 메시지, 인수인계 난이도, 배포·시드 데이터 재현성.
저장소 첫 클론부터 기동까지의 경로 재현 시도, 테스트 스위트 존재·커버 범위 샘플, 운영 런북·주석 품질 리뷰.
제3 개발자가 1~2일 내 핵심 흐름을 수정할 수 있는지, 장애 원인을 로그로 좁힐 수 있는지, 지식 편중이 과도한지.
착수 후 소스코드 열람 시 실제 확인에 쓰는 항목 견본입니다. 체크 상태는 비어 있으며, 샘플 단계에서는 판정하지 않습니다.
총 36항목 · 6축 배분 · FastAPI / React / SQLite 스택 기준
발견 항목은 심각도(업무·데이터·규제 영향)와 발생 가능성(조건이 갖춰질 확률·빈도)으로 등급을 나눕니다. 아래 매트릭스는 분류 규칙만 보여 주며, 실제 시스템에서 확인한 이슈를 채워 넣지 않습니다.
샘플 고지 · 셀 안의 문구는 등급 정의와 예시 유형(카테고리)입니다. “귀사에서 ○○가 발견되었다”는 의미가 아닙니다.
| 영향 ↓ · 가능성 → | 발생 가능성 · 낮음 | 발생 가능성 · 중간 | 발생 가능성 · 높음 |
|---|---|---|---|
| 영향 · 높음 | P1 예시 유형 · 드물지만 데이터 손실 가능 경로 |
P0 예시 유형 · 권한 우회·대량 무결성 깨짐 |
P0 예시 유형 · 상시 노출 인증 공백 |
| 영향 · 중간 | P2 예시 유형 · 국소 성능 병목 |
P1 예시 유형 · 배치 중 잠금·타임아웃 |
P1 예시 유형 · 반복 운영 실수 유발 UI·API |
| 영향 · 낮음 | P2 예시 유형 · 스타일·네이밍 불일치 |
P2 예시 유형 · 문서 부재·온보딩 마찰 |
P1 예시 유형 · 잦은 소모성 수작업 |
결론은 단일 점수가 아니라 아래 축의 신호 조합으로 서술합니다. 한 축만으로 전면 재구축을 단정하지 않습니다.
| 판단 축 | 유지 쪽으로 기우는 신호 | 재구축(또는 핵심 재작성) 쪽으로 기우는 신호 |
|---|---|---|
| 도메인 로직 응집도 | 투자실적·취합·보고 규칙이 모듈 단위로 모이고, 화면·API가 이를 호출하는 구조 | 동일 규칙이 프론트·SQL·핸들러에 복제되어 한 곳을 고치면 다른 곳이 어긋나는 구조 |
| 테스트 가능성 | 핵심 계산·권한·적재를 단위·통합 테스트로 고정할 수 있는 경계가 있음 | DB·UI에 뭉친 절차만 있고, 회귀를 사람 클릭에만 의존 |
| 데이터 마이그레이션 비용 | 스키마가 비교적 정규화되어 있고, 이력·마스터 분리가 가능 | 비정규·암묵 컬럼·파일 병행 저장이 많아 이관 설계 자체가 프로젝트 규모 |
| 스키마·저장소 확장 여력 | SQLite여도 트랜잭션·인덱스·접근 계층이 정리되어 서버 RDBMS 이관 경로가 보임 | 동시 쓰기·배치 적재·리포트가 저장소 한계와 강하게 결합되어 앱 전면 가정이 흔들림 |
| 인력 인수인계 난이도 | 기동·배포·용어·주요 흐름 문서가 있고, 모듈 이름이 업무 언어와 대응 | 특정인 암묵지에만 의존, 저장소만으로 업무 흐름 복원이 어려움 |
| 고도화 정합 (엑셀·규제 보고) | 업로드·검증·집계 파이프라인을 기존 API 위에 붙일 확장점이 있음 | 새 요구가 들어올 때마다 스키마·화면·권한을 통째로 다시 짜야 하는 구조 |
의견서에는 축별 관찰 근거(코드·스키마 위치)와 함께 “유지 + 부분 재작성”, “핵심 도메인만 재구축”, “전면 재구축” 중 권고 옵션을 비용·기간·리스크 관점으로 비교해 적습니다. 본 샘플 단계에서는 권고를 내리지 않습니다.
다음은 공고에 적힌 스택·고도화 방향만으로 세운 가설입니다. 착수 즉시 최우선으로 검증하며, 소스 열람 전에는 사실로 단정하지 않습니다.
공고에 명시된 고도화 방향(엑셀 업로드 · 금감원 보고서 자동 생성)을 SQLite 위에 얹을 때 동시 쓰기 잠금, 대량 배치 적재 중 무결성, 이후 RDBMS 이관 비용이 실제 병목이 될 수 있다. 이 지점이 「유지 vs 재구축」 판단의 분기점이 될 가능성이 높다.
왜 이렇게 보는지 (일반 기술 사실 기반)
SQLite는 journal 모드와 무관하게 쓰기는 직렬화됩니다(동시에 하나의 writer).
기본 DELETE(rollback journal) 모드에서는 쓰기 중 읽기가 막히고,
WAL 모드에서는 reader와 writer가 동시에 진행할 수 있어 읽기 차단이 크게 줄어듭니다. 다만 writer 직렬화는 그대로입니다.
따라서 잠금 위험의 실제 크기는 현재 journal_mode가 무엇인지, busy_timeout이 설정되어 있는지를 먼저 확인해야 판정할 수 있습니다.
업로드 적재와 대화형 저장·리포트 생성이 겹치면 모드·설정에 따라 잠금 대기나 실패 체감이 달라질 수 있습니다.
엑셀 배치 적재는 행 단위 검증·부분 실패 처리·재시도가 필요해 트랜잭션 설계 부담이 커지고,
규제 보고 자동 생성은 집계·스냅샷·재현 가능성이 중요해 스키마와 저장 엔진 선택이 장기 비용에 직결됩니다.
따라서 진단 초반에 journal_mode·busy_timeout을 확인한 뒤 “쓰기 경로·배치·리포트” 세 축을 묶어 보면,
현 저장 모델을 유지한 채 확장할지 이관을 전제한 재설계가 짧은 경로인지를 빠르게 가를 수 있습니다.
검증 방법(예정) · 진단 초반 PRAGMA journal_mode·busy_timeout 확인, 쓰기 API·업로드 진입점 코드 추적, 트랜잭션·busy 처리 확인, 리포트 쿼리·잠금 구간 식별, 스키마가 집계 키를 표현하는지 대조. 결과는 의견서 가설 검증 절에 기록합니다.
착수일 = Day 1. 클라이언트 협조(NDA·Git·접속·인터뷰)가 늦어지면 동일 순서를 유지한 채 달력만 밀립니다.
킥오프 · 접근 확보 · 범위 고정
중간물킥오프 메모, 진단 범위 확인서(포함/제외), 저장소·환경 접근 체크리스트
협조NDA 체결, Git 권한, 로컬/원격 기동 방법, 담당자 1인 연락 창구
아키텍처·DB 스키마 1차 매핑
중간물모듈 맵, 테이블·관계 초안, 핵심 업무 흐름(취합→저장→조회) 스케치
협조업무 용어 사전(투자실적 항목·보고 주기), 샘플(비식별) 데이터 유무 안내
백엔드·보안·쓰기 경로 심화
중간물FastAPI 인증·인가·트랜잭션 경로 노트, 가설(SQLite 쓰기) 검증 로그
협조테스트 계정·역할 구분 설명, 운영과 개발 환경 차이 요약
프론트·기능 로직·성능 관점 리뷰
중간물React 화면·상태·API 결합 노트, 성능 위험 후보 목록(등급 미확정 초안)
협조주요 화면 사용 시나리오 15~30분 인터뷰(화상)
리스크 등급 · 유지/재구축 프레임 적용
중간물P0/P1/P2 초안, 판단 축별 근거 표, 고도화(엑셀·보고서) 기술 옵션 비교 초안
협조우선 확인하고 싶은 의사결정 질문 목록(선택)
의견서 초안 작성
중간물진단 결과·자문 의견서 초안(Word 또는 PPT), 내부 교차 점검
협조사실 관계 확인이 필요한 항목에 대한 서면/단문 답변
의견서 확정 · 화상 브리핑 1회(추가 제공)
최종물(공고)의견서 제출 (Word 또는 PPT)
추가 제공화상 브리핑 1회, 브리핑 자료, 후속 우선순위 1페이지 요약
협조브리핑 참석(의사결정권자 포함 권장), 질의 응답
납품 형식은 Word 또는 PPT 중 협의합니다. 아래는 의견서에 담을 장·절 구조 견본입니다.