AI의 도움을 받은 번역

기술 아키텍처 · CTO

기술 지도

현재 웹사이트의 기술 지도와 데이터 읽기 흐름: 웹페이지, 작업 API, 데이터 접근 계층.

기술 내용을 읽고 수정하며 소스 코드와 대조할 수 있도록 Mermaid로 다이어그램을 작성했습니다. 아래 그림은 현재 시제품을 설명하며 Võ 게임의 백엔드를 나타내지 않습니다.

이 부분은 기술 구성 요소의 연결 방식을 설명합니다. CEO의 요청을 누가 접수하고 업무를 배정하며 결과를 인계하는지 보려면 다음을 읽으세요 팀 협업 절차.

현재 시스템다이어그램 버전1.0.0

현재 시스템 지도

브라우저는 Astro에서 페이지를 받는다. 최신 데이터가 필요한 페이지는 서버 데이터 접근 계층을 호출하고 업무 API는 별도 읽기 경로다.

프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.

다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.

  1. 정적 페이지는 빌드 때 생성하고 SSR 페이지는 요청 때 HTML을 생성하며 둘 다 브라우저에서 읽는다.
  2. SSR 페이지는 repository를 직접 호출한다. 업무 API도 같은 repository로 JSON을 반환하며 SSR 페이지의 필수 중간 단계는 아니다.
  3. 업무는 로컬 데이터를 사용한다. 구성원 프로필은 구성원 목록과 로컬 활동 기록을 결합하고 공개 허용 부분만 보여준다.
  4. 프로토타입에는 운영 DB, 공개 쓰기 API, 로그인, 결제 시스템이 아직 없다.
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 --> teamData
QT0006절차 버전1.1.0
현재 시스템다이어그램 버전1.0.0

ID로 업무 항목 조회

GET /api/tickets/{id}는 잘못된 형식의 ID, 존재하지 않는 작업 항목, 유효한 결과를 구분합니다. 상세 페이지는 같은 데이터 계층으로 HTML을 생성합니다.

프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.

다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.

  1. 애플리케이션은 작업 항목의 고정 ID로 GET /api/tickets/{id}를 전송합니다.
  2. 형식이 잘못된 ID는 HTTP 400을 받고 유효한 ID는 repository에서 조회한다.
  3. 기록이 없으면 HTTP 404, 있으면 공개 필드를 담은 ticket 객체와 HTTP 200을 반환한다.
  4. /tickets/{id}/ 경로는 별도의 SSR 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
QT0007절차 버전1.1.0
현재 시스템다이어그램 버전1.0.0

목록 페이지별 조회

GET /api/tickets는 프로젝트 ID, 항목 제한, 연속 커서를 받으며 응답당 최대 50개 업무를 담는다.

프레임 안을 스크롤하면 전체 크기의 다이어그램을 볼 수 있습니다. 프레임을 선택하면 방향키를 사용할 수 있습니다.

다이어그램은 화면에 들어오면 렌더링됩니다. 아래에서 모든 단계를 읽을 수 있습니다.

  1. 첫 요청의 gameId와 limit 기본값은 vo와 20이며 limit는 1–50 정수여야 한다.
  2. Repository가 쿼리를 검증한다. after가 있으면 해당 ID가 같은 프로젝트에 존재해야 하며 잘못된 쿼리나 커서는 HTTP 400을 반환한다.
  3. 결과는 공개 items와 nextCursor를 담으며 ID 형식이 유효하지만 업무가 없는 프로젝트는 빈 목록을 반환한다.
  4. 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 조회와 데이터 원본의 페이지 처리를 사용할 수 있습니다. 이는 확장 방향이며, 현재 시제품은 대규모 서비스 능력을 입증하지 않았습니다.

로그인, 권한, 지원서 접수, 데이터 쓰기에는 별도의 요구 사항, 설계, 구현 권한이 필요합니다. 현재 다이어그램은 공개 읽기 경로만 설명합니다.

팀 협업에 관하여