포트폴리오에서 판단을 읽고,
사이트에서 근거를 확인하도록

1. 역할을 나눠 연결하기

사이트가 주장을 대신하지 않는다. 포트폴리오만 읽어도 판단을 이해하고, 추가 확인이 필요할 때 사이트로 들어갈 수 있어야 한다.

2. 현재 완성도와 보완할 근거

체험본·영상은 아직 제작되지 않았다. 통합 프로토타입과 과거 실제 Streamlit을 서로 대체하지 않는다. 수치의 기간·분모·비교 대상은 이미 확보한 원자료부터 점검하고, 미확인 부분을 채워 넣지 않는다.

3. 먼저 보여줄 대표 체험

1. 공통 품번 조회 → 입출고 요청 → 승인 → 일정 → 완료 → 상품 이력.
2. 복잡한 주문 입력 → 부분 자동화 → 비교 검수에서 사은품 연결 문제 발견 → 수정된 결과.
3. 관행적 업체 선택 → 조건별 비교 → 일정·품질 고려 선택 → 청구무게 보정 근거.

정상 동작만 빠르게 누르는 영상보다, 대표 판단 하나와 결과 확인을 포함하는 짧은 시연을 먼저 만든다. 실제 고객 주문 대신 합성·익명화 데이터를 사용한다.

4. 서비스 개발 일정 산정 예시

실제 개발 확약이나 당시 소요 기간이 아니다. 프론트 1명·백엔드 1명, 기획/QA 1명 겸임, 기존 UI 활용, 주5일 기준의 제안이다. 우선 수동 입력·현재 월 데이터로 시작하고 외부3PL 실시간 연동·자동 재학습·레거시 전체 이관은 제외한다. 팀·기술·원본 데이터 확인 후 다시 산정한다.

MVP: 계정·상품/재고·요청/승인·일정/이력

합계 약 8–10주. 두 개발자가 각 단계 안에서 병행하는 전제이며, 작업량을 단순히 인원수로 나눈 값이 아니다.

후속: 운영 기준·자동화·비용 비교

추가 약 4–6주, 전체 약 12–16주. 자동화 원본 양식, 계약 요금, 예외 규칙의 확정 상태에 따라 변동한다.

일정이 달라지는 조건

• 이전 상태·현재고가 불명확하면 데이터 확인과 UAT가 늘어난다.
• Slack/3PL 접근권한 지연은 연결 범위의 일정에 영향을 준다.
• 주문서 형식·혼합 포장·할증 규칙이 늘어나면 자동화 검수 범위가 커진다.
• 실운영 보안·장애 대응·백업·접근 정책은 개발 제안 단계에서 추가 검토가 필요하다.

개발 리소스가 더 적으면 상품·재고부터 구축해 수동 기록을 시작하고, 입출고·일정 연결을 추가한다. 현재 Streamlit 자동화의 웹 고도화는 이후 범위로 미룰 수 있다.

5. 포트폴리오·사이트 제작 일정

사용자 검토와 자료 확보 시간을 제외한 집중 작업일 예시다. 실제 시작일·주당 가용 시간은 확정하지 않았다.

약 8–11 집중 작업일. 기존 프로토타입과 디자인을 활용하는 전제다. 원본의 실행 환경·데이터 의존성 때문에 체험본이 지연되면 먼저 영상 또는 검증된 샘플 결과로 연결한다.

6. 다음 작업 우선순위

1. 주장과 근거: 수치·기여·원본/재구성/제안 상태와 대표 전후 결과를 확정.
2. 개발 전달력: C의 대표 시나리오 한 건을 화면·권한·데이터·예외·검수·일정까지 연결.
3. 재현 가능한 체험: 시트와 Streamlit의 최소 샘플/영상 제작.
4. 탐색 가능한 사이트: 같은 콘텐츠 데이터로 프로젝트 상세·DB·기획서·다운로드를 연결.

별도 작성한 portfolio-content.json은 향후 사이트와 발표 자료가 같은 내용·상태를 참조할 수 있는 초기 콘텐츠 구조다. 현재 사이트나 PDF가 이 파일에서 자동 생성된다는 뜻은 아니다.