Ecoread
경제 뉴스를 읽다 막힌 사용자가 그 뉴스에 필요한 개념만 1문제로 확인하고, 모를 때만 짧게 배우고, 같은 뉴스를 다시 읽는 3~5분 학습 서비스. 기획 → 화면 → 데이터 모델 → API 명세까지 3일 단독 설계 과제.
주요 기여
경제 뉴스 학습 서비스를 기획부터 API 명세, ERD까지 3일 동안 혼자 설계했습니다. AI가 만든 초안은 관리자가 검수하기 전엔 공개될 수 없게 테이블 구조로 막았고, 와이어프레임 대신 목 프로토타입을 만들어 화면과 API와 ERD가 서로 맞는지 직접 확인했습니다.
3일 안에 기획서·OpenAPI·DBML 3종을 제출해야 했고, 평가 관점은 '서비스 개요 ↔ 요구사항 ↔ UI ↔ ERD ↔ API 간 일관성'이었습니다. AI를 쓰는 서비스를 골랐기 때문에 'AI를 어디까지 믿을 것인가'가 설계의 중심 질문이 됐습니다.
구현이 아니라 설계를 평가받는 과제에서, AI의 역할 범위·개인화 기준·기록 시점 같은 정책을 문서가 아니라 스키마와 API 계약으로 보장하는 것.
AI 사용 지점을 3곳으로 한정했습니다 — 뉴스 분석 초안(관리자 검수 후 확정), 개념 설명 변형(관리자 미리보기), 학습자 '다르게 듣기'(요청 시에만). 반대로 정답 판정·사용자 수준 추론·검수 없는 공개·뉴스 자동 공개는 AI가 하지 않는다고 명시했습니다. 개인화 기준은 관심사 설문이나 AI 추정이 아니라 사용자가 뉴스 안에서 직접 남긴 개념 상태(알아요·배웠어요·헷갈려요)로 두고, 기록 시점을 결과 시트의 CTA를 눌렀을 때로 고정해 이탈로 상태를 추측하지 않게 했습니다. 데이터 모델은 AI 초안(news_ai_analyses)과 관리자 확정본(news)을 물리적으로 분리하고 확정 전에는 news.question이 NULL이 되게 했으며, 완료·보상 중복은 (user_id, news_id) PK로, 잠긴 빵을 아바타로 쓰는 것은 복합 FK로 DB 수준에서 막았습니다. API는 홈을 단일 GET /home으로 두고(배너 선정이 서버 규칙), 뉴스 상세는 /news/{id}와 /news/{id}/learning으로 나눠 기사만 보는 화면에 정답이 실리지 않게 했습니다. 11개 화면은 Next.js 목 프로토타입으로 만들어 URL 쿼리로 모든 상태를 재현하고 캡처 27장을 뽑았습니다.
학습 플로우가 6단계로 시작해 '뉴스 앱인데 시험부터 본다'는 인상을 줬고, 완료 API를 재시도했을 때 409를 돌려주면 완료 화면이 그려지지 않는 문제, 그리고 기능명세·코드·데이터 모델 셋이 미묘하게 어긋나는 문제가 있었습니다.
플로우를 4단계로 줄여 기사를 먼저 읽은 자리에 개인화 안내가 붙게 했고, 핵심 개념은 뉴스당 최대 2개로 제한했습니다. POST /complete는 완전 멱등이고 재완료 시에도 200과 함께 보유 수량을 돌려줘 화면이 그려지게 했습니다 — 네트워크 재시도가 정상 경로이기 때문입니다. 데이터 모델 설계 전에 기능명세(F-xx)와 코드를 대조해 문서 누락 1건은 문서를, 코드 문구 stale 1건은 코드를 고쳤고, 발표자료에 화면별 호출 API 표를 넣어 UI ↔ API ↔ ERD가 한 장에서 이어지게 했습니다. 감사 로그·소프트 삭제·다국어·콘텐츠 버전 테이블은 의도적으로 빼고 이유를 적었습니다.
정책은 문서가 아니라 스키마와 API 계약으로 보장해야 합니다. '검수 없는 AI 결과는 공개하지 않는다'를 테이블 분리와 NULL 제약으로 만들고 나니 설명이 한 줄로 끝났습니다. 멱등성은 '409를 돌려준다'가 아니라 '재시도가 정상 경로여도 화면이 그려진다'까지 설계해야 완성입니다. 빼는 것에도 이유를 적어야 '왜 없냐'는 질문에 방어가 됩니다. 3일 개인 설계 과제로, 백엔드·DB·실제 AI 호출은 미구현이며 프로토타입은 목 데이터로 동작합니다.