AI의 도움을 받은 번역
기술 아키텍처 · CTO
기술 지도
현재 웹사이트의 기술 지도와 데이터 읽기 흐름: 웹페이지, 작업 API, 데이터 접근 계층.
기술 내용을 읽고 수정하며 소스 코드와 대조할 수 있도록 Mermaid로 다이어그램을 작성했습니다. 아래 그림은 현재 시제품을 설명하며 Võ 게임의 백엔드를 나타내지 않습니다.
이 부분은 기술 구성 요소의 연결 방식을 설명합니다. CEO의 요청을 누가 접수하고 업무를 배정하며 결과를 인계하는지 보려면 다음을 읽으세요 팀 협업 절차.
현재 시스템 지도
브라우저는 Astro에서 페이지를 받는다. 최신 데이터가 필요한 페이지는 서버 데이터 접근 계층을 호출하고 업무 API는 별도 읽기 경로다.
프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.
다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.
- 정적 페이지는 빌드 때 생성하고 SSR[TOP03] 페이지는 요청 때 HTML을 생성하며 둘 다 브라우저에서 읽는다.
- SSR[TOP03] 페이지는 repository를 직접 호출한다. 업무 API도 같은 repository로 JSON을 반환하며 SSR[TOP03] 페이지의 필수 중간 단계는 아니다.
- 업무는 로컬 데이터를 사용한다. 구성원 프로필은 구성원 목록과 로컬 활동 기록을 결합하고 공개 허용 부분만 보여준다.
- 프로토타입에는 운영 DB, 공개 쓰기 API[TOP02], 로그인, 결제 시스템이 아직 없다.
Mermaid 소스 보기 · v1.0.0
flowchart TB
accTitle: 현재 웹사이트 시스템 지도
accDescr: 브라우저는 정적 페이지, SSR 페이지 또는 업무 API를 읽는다. SSR 페이지와 API는 repository로 로컬 데이터를 읽는다.
browser["브라우저"]
staticPages["Astro 정적 페이지"]
ssrPages["Astro SSR 페이지"]
ticketApi["업무 API · GET 전용"]
ticketRepo["업무 Repository"]
teamRepo["구성원 Repository"]
ticketData[("로컬 업무 데이터")]
teamData[("구성원 목록 및 활동")]
browser -->|"페이지 조회"| staticPages
browser -->|"페이지 조회"| ssrPages
browser -->|"GET 호출"| ticketApi
ssrPages --> ticketRepo
ssrPages --> teamRepo
ticketApi --> ticketRepo
ticketRepo --> ticketData
teamRepo --> teamDataID로 업무 항목 조회
GET /api/tickets/{id}는 잘못된 형식의 ID, 존재하지 않는 작업 항목, 유효한 결과를 구분합니다. 상세 페이지는 같은 데이터 계층으로 HTML을 생성합니다.
프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.
다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.
- 애플리케이션은 작업 항목의 고정 ID로 GET /api/tickets/{id}를 전송합니다.
- 형식이 잘못된 ID는 HTTP 400을 받고 유효한 ID는 repository에서 조회한다.
- 기록이 없으면 HTTP 404, 있으면 공개 필드를 담은 ticket 객체와 HTTP 200을 반환한다.
- /tickets/{id}/ 경로는 별도의 SSR[TOP03] HTML 페이지입니다. 리포지토리를 직접 호출하며 ID가 잘못되었거나 존재하지 않으면 404 페이지를 반환합니다.
Mermaid 소스 보기 · v1.0.0
sequenceDiagram
accTitle: API가 ID로 작업 항목 읽기
accDescr: API는 ID 형식을 확인하고 리포지토리를 조회해 오류 400, 오류 404 또는 공개 데이터 200을 반환합니다.
participant client as 호출자
participant api as 작업 API
participant repo as Repository
client->>api: GET /api/tickets/{id}
alt 잘못된 ID 형식
api-->>client: 400 · invalid_id
else 유효한 ID
api->>repo: get(id)
repo-->>api: 레코드 또는 null
alt 찾을 수 없음
api-->>client: 404 · not_found
else 레코드 있음
api->>api: 공개 필드 선택
api-->>client: 200 · ticket
end
end목록 페이지별 조회
GET /api/tickets는 프로젝트 ID, 항목 제한, 연속 커서를 받으며 응답당 최대 50개 업무를 담는다.
프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.
다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.
- 첫 요청의 gameId와 limit 기본값은 vo와 20이며 limit는 1–50 정수여야 한다.
- Repository가 쿼리를 검증한다. after가 있으면 해당 ID가 같은 프로젝트에 존재해야 하며 잘못된 쿼리나 커서는 HTTP 400을 반환한다.
- 결과는 공개 items와 nextCursor를 담으며 ID 형식이 유효하지만 업무가 없는 프로젝트는 빈 목록을 반환한다.
- nextCursor가 null이 아니면 같은 gameId와 함께 after로 보내 이어서 읽는다. null은 현재 목록의 끝이며 응답 제한이 대규모 운영 역량을 입증하지 않는다.
Mermaid 소스 보기 · v1.0.0
sequenceDiagram
accTitle: 업무 목록 페이지 API
accDescr: Repository가 프로젝트, 제한, 커서를 확인하고 공개 목록과 다음 커서를 반환한다.
participant client as 호출자
participant api as 업무 API
participant repo as Repository
Note over client,api: gameId=vo, limit=20
client->>api: GET /api/tickets
api->>repo: list(gameId, limit, after)
alt 잘못된 쿼리 또는 커서
repo-->>api: InvalidTicketQuery
api-->>client: 400 · invalid_query
else 유효
repo-->>api: items 및 nextCursor
api->>api: 각 항목의 공개 필드 선택
api-->>client: 200 · items 및 nextCursor
opt nextCursor가 null이 아님
client->>api: 동일 gameId로 GET, after=nextCursor
api->>repo: 다음 페이지 조회
repo-->>api: items 및 새 nextCursor
api-->>client: 200 · 공개 필드
end
end제안됨 · 미구현
데이터와 필요가 늘어날 때
리포지토리는 인터페이스와 데이터 저장소 사이의 계약 역할을 합니다. 이후 로컬 데이터셋을 데이터베이스로 바꾸고 인덱스 기반 ID 조회와 데이터 원본의 페이지 처리를 사용할 수 있습니다. 이는 확장 방향이며, 현재 시제품은 대규모 서비스 능력을 입증하지 않았습니다.
로그인, 권한, 지원서 접수, 데이터 쓰기에는 별도의 요구 사항, 설계, 구현 권한이 필요합니다. 현재 다이어그램은 공개 읽기 경로만 설명합니다.
팀 협업에 관하여