웹 프로젝트

table of contents

• 프로젝트 개요
• 기술 스택 및 아키텍처 개요
• 데이터 소스
• 역할 분담
• 문서 구성
  • 요구사항 정의
  • 데이터 스키마
  • API 상세 정의
  • UI/UX 스펙 정의
  • ADR 및 룰
• 협업 컨벤션
• 어려움 극복 및 주요 배운 점
• 향후 개선점
• 최종 발표 기록
  • 5조
  • 6조
  • 2조
    • 메모
  • 4조
  • 1조
  • 3조
  • 전체 회고
  • 질의응답

프로젝트 개요

• 목표
  1. 웹 기반으로 간단한 수준의 데모 MES(Manufacturing Execution System) 구현
  2. 구현 과정에서 기획과 명세 관련 각종 문서를 작성하고, 협업 컨벤션을 정의하고 따름으로써 실무적인 협업 프로세스를 경험할 것
  3. 이에 따라 목표 1의 프로젝트는 목표 2에서 작성된 문서를 프로젝트의 절대적 기준으로 간주하는 문서 중심 개발을 지향할 것.
• 구현 목표
  • 물리적 설비 연동을 대신하여 사전에 준비된 시계열 데이터를 순차적으로 재생함으로써 공정의 실시간성을 모사한다.
  • 메인 대시보드: KPI 및 현장 현황 요약
  • 공정 모니터링: 실시간 트렌드 차트 제공
  • 품질 리포트: 산점도 시각화 및 PDF 내보내기

  

기술 스택 및 아키텍처 개요

• 모노레포 구조: 단일 저장소 내 프론트엔드/백엔드 통합 관리 및 docs/를 통한 문서 일원화

구분	사용 기술	비고
Backend	Java Spring Boot 3.x (Gradle)	시뮬레이션 제어 API
Frontend	Vue.js 3.x (Vite)	대시보드 및 관리 UI
Database	MySQL 8.x	수주, 계획, 생산 이력 저장
Communication	STOMP WebSocket	실시간 데이터 전송 및 제어

데이터 소스

• 의류 공정최적화 AI 데이터셋
  • https://www.kamp-ai.kr/aidataDetail?AI_SEARCH=&page=1&DATASET_SEQ=90&DISPLAY_MODE_SEL=LIST&GUBUN_SEL=C004021
  • 작업자의 노하우에 따라 품질이 크게 달라지는 염색가공 공정에서 품질문제와 공정 데이터들을 분석하여 데이터 간의 상관관계를 찾고 제품 컬러에 영향을 주는 인자를 분석하여 품질을 예측하고, 이를 기반으로 공정 최적화 모델을 만드는 것을 목적으로 만들어진 데이터셋임
  • 데이터 개수 : 총 31,813,751개
  • 데이터 총량 : 157MB
  • 분석에 사용된 변수 : 염색 가동 길이, TRD_TEMP_PV, TRD_SPEED1, 염색 색차 DE 등 총 11개 변수
• 고객사 모델별 주문량 제조AI데이터셋
  • https://www.kamp-ai.kr/proveDataDetail?AI_SEARCH=&page=2&DATASET_SEQ=64&DISPLAY_MODE_SEL=LIST&TARGET_SEL=C004021
  • MES 시스템으로부터 수집한 고객사 주문시트

역할 분담

내가 맡은 역할만 자세히 쓰겠음 백엔드는 팀원이 했음

• 기획 및 문서 정리: 데이터 스키마, 데이터 생성/전처리 정의, 아키텍처 설계, API 상세 정의, UI/UX 스펙 정의, ADR 작성, AGENTS 문서 작성 등
• 프로젝트 전체 관리: 문서, 커뮤니케이션 관리, 협업 관리
• 데이터 전처리 및 생성: 원천 데이터 수집, 전처리, 병합, 프로젝트 데이터 생성
• 프론트엔드: 대시보드 및 관리 UI 구현

문서 구성

요구사항 정의

• 기능 요구 명세서
  • 프로젝트 소개, 기술 스택, 데이터 소스 및 정합성 지침이 포함됨
  • 모듈별 기능 요구사항
    • 수주 및 생산 계획: 데이터 로드, 작업 지시 발행, 수주 잔량 관리, 생산 트리거, 작업 지시 발행
    • 실시간 공정 감시: 설비 상태 매핑 및 현황 표시(설비번호-Lot 번호), 진척률 산출, 환경(설비 온도, 속도 등) 변수 시각화(그래프)
    • 생산 실적 및 품질 리포트 모듈: 품질 자동 판정(기준치 룰 베이스 양불 판정), 최종 실적 집계(진척률과 품질 결과 요약 기록), 보고서 자동 생성(표준 양식의 생산 검사 성적서 생성)
  • 사용자 플로우
    • 메인 화면 진입, 생산 현황 요약 대시보드 확인
    • 수주 확인 및 지시
    • 생산 시작 및 감시
    • 품질 검사
    • 보고서 출력
  • 핵심 기술 로직: 시뮬레이터
    • 시뮬레이션의 트리거는 프론트가, 재생은 백엔드가
    • 복잡한 데이터 변환 로직 없이 사전에 정제된 로그를 순차적으로 DB에 적재하고 프론트에 전달함으로써 실시간 데이터 전송 및 제어를 모사함
  • 그 외 커뮤니케이션 규약 정의

데이터 스키마

• 데이터 전처리 지침
  • 이 프로젝트의 데이터는 서로 다른 두 소스로부터 유래했기 때문에, 논리적/수치적 모순이 없도록 병합해야 함
  • 의류 염색 데이터는 Lot 단위로, 하루에도 여러 개의 Lot 데이터가 존재하고, Lot마다도 시간대별로 측정한 여러 개의 데이터가 존재함
  • 전자제품 주문 데이터는 하루 주문/발송 데이터로 구성됨.
  • 전자제품 주문 데이터의 시간 단위가 더 크지만, 이 데이터를 분해한다고 의류 데이터와 숫자를 똑같이 맞출 수 없기 때문에 의류 데이터를 일일 단위로 묶어서 전자제품 주문 데이터에 덮어쓰기하기로 함.
  • 정합성을 유지하기 위해 일일 생산량이 모두 그날 판매되는 것으로 간주함. 임의로 재고나 납기 지연 등의 케이스를 만들기엔 시간도 부족했고, 데이터 자체에 대해서도 잘 모르는 상태에서 시도하기엔 데이터가 망가질 리스크가 너무 크다고 봤음.
• 데이터 스키마 정의

  • 제품 마스터 (Products)

    컬럼명	타입	설명	출처 데이터 항목
    product_id (PK)	VARCHAR	제품 고유 코드	에스윈텍 code, 의류 공정코드(에스윈텍 측 값이 없을 때 의류 데이터의 공정코드로 대치)
    name	VARCHAR	제품명 (예: 고신축 폴리 원단)	에스윈텍 name, 의류 작업명(에스윈텍 측 값이 없을 때 의류 데이터의 작업명으로 대치)
    category	VARCHAR	제품 계층/분류	에스윈텍 hierarchy
    safety_stock	INT	적정 안전 재고량	에스윈텍 safety_stock

  • 수주 관리 (SalesOrders)

    컬럼명	타입	설명	출처 데이터 항목
    order_id (PK)	VARCHAR	수주 고유 번호	에스윈텍 uid
    product_id (FK)	VARCHAR	제품 외래키	에스윈텍 code
    order_date	DATE	주문 발생 일자	에스윈텍 date
    order_qty	FLOAT	일일 확정 주문량 (집계값)	의류 염색 가동 길이 합계

  • 작업 지시 (WorkOrders)

    컬럼명	타입	설명	출처 데이터 항목
    wo_id (PK)	VARCHAR	작업 지시/LOT 번호	의류 PRODT_ORDER_NO
    order_id (FK)	VARCHAR	연관 수주 번호	(데이터 생성 시 매핑)
    planned_qty	FLOAT	LOT별 계획 생산량	의류 염색 가동 길이
    machine_id	VARCHAR	할당 설비 번호	의류 RESOURCE_CD

  • 공정 실행 로그 (ProductionLogs)

    컬럼명	타입	설명	출처 데이터 항목
    log_id (PK)	BIGINT	로그 고유 ID	CSV log_id 컬럼
    wo_id (FK)	VARCHAR	작업 지시 외래키	의류 LOT_NO
    timestamp	DATETIME	수집 일시 (1분 단위), 포맷 yyyy-MM-dd HH:mm:ss	의류 INSRT_DT
    cr_temp	INT	설비 가동 목표온도(℃)	의류 CR_TEMP
    temp_sp	FLOAT	설비 가동 지시온도(℃)	의류 TRD_TEMP_SP
    temp_pv	FLOAT	설비 현재 온도(실측, ℃)	의류 TRD_TEMP_PV
    speed	INT	설비 가동 속도	의류 TRD_SPEED1

  • 품질 검사 결과 (Inspections)

    공정 완료 후 기록되는 최종 품질 데이터. 품질 판정 기준은 color_de < 1.0 = Pass, color_de >= 1.0 = Fail 이다.

    컬럼명	타입	설명	출처 데이터 항목
    insp_id (PK)	VARCHAR	검사 고유 번호	CSV insp_id 컬럼
    wo_id (FK)	VARCHAR	작업 지시 외래키	의류 lot_no
    color_de	FLOAT	종합 색상 차이 지수	의류 염색 색차 DE
    pass_fail	BOOLEAN	합격 여부 (DE < 1.0 기준)	의류 염색 색차 DE 판정

  • ER 다이어그램

    
    %%{init: { 'theme': 'redux-color', 'themeVariables': { 'lineColor': '#00aaaa', 'fontSize': '15px', 'background': '#000000' } } }%%
    
    erDiagram
      direction LR
      Products {
        string product_id PK ""
        string name  ""
        string category  ""
        int safety_stock  ""
      }
    
      SalesOrders {
        string order_id PK ""
        string product_id FK ""
        date order_date  ""
        float order_qty  ""
      }
    
      WorkOrders {
        string wo_id PK ""
        string order_id FK ""
        float planned_qty  ""
        string machine_id  ""
      }
    
      ProductionLogs {
        bigint log_id PK ""
        string wo_id FK ""
        datetime timestamp  ""
        int cr_temp  ""
        float temp_sp  ""
        float temp_pv  ""
        int speed  ""
      }
    
      Inspections {
        string insp_id PK ""
        string wo_id FK ""
        float color_de  ""
        boolean pass_fail  ""
      }
    
      Products||--o{SalesOrders:"has"
      SalesOrders||--o{WorkOrders:"splits_to"
      WorkOrders||--o{ProductionLogs:"has"
      WorkOrders||--o|Inspections:"has"
    
    

API 상세 정의

• 프론트엔드와 백엔드가 주고받을 API의 이름과 기능을 정의함
• STOMP 기반 웹소켓 프로토콜만을 사용하며, json을 주고받는다.
• 응답 규격:
  • success: 성공 여부 (boolean).
  • data: 실제 데이터 객체 혹은 배열.
  • message: 오류 발생 시 원인 메시지(성공 시에는 빈 문자열 또는 생략 가능, 팀에서 통일).
• 실시간 스트리밍은 프론트엔드의 별도 요청 없이 백엔드가 푸시함.
• 설비 이상 알림은 백엔드가 감시하다가 이상 감지 시 별도 토픽으로 프론트에 보냄

UI/UX 스펙 정의

• Sidebar: 모듈 별 메뉴 이동
• Header: 현재 연결 상태 및 시뮬레이션 상태 표시.
• Content: 각 모듈의 핵심 컴포넌트 배치.
• 메인 대시보드 (Executive Summary)
  • KPI 카드 컴포넌트: 목표 대비 실적(일일 총 주문량 대비 생산 완료량) 시각화, 품질 합격률 표시
  • 현장 현황판: 현재 가동 중인 설비별 LOT번호 및 실시간 진척도 게이지 차트
• 수주 및 생산 계획 (Order & Planning)
  • 수주 현황 테이블: SalesOrders 데이터를 로드하여 제품명, 주문량, 납기일자를 리스트업함.
  • 생산 트리거 위젯: current_inven이 safety_stock 이하인 품목을 강조하여 강조 표시함.
  • 작업 지시 발행 버튼: 수주 항목 선택 시 해당 사양(planned_qty, machine_id)에 맞는 WorkOrder를 생성하는 모달(Modal) 실행.
• 실시간 공정 모니터링 (Execution Monitoring)
  • 실시간 트렌드 차트: WebSocket(STOMP)으로 수신되는 temp_pv(실측 온도), temp_sp(지시 온도), cr_temp(목표 온도) 및 speed(포속)를 실시간 꺾은선 그래프로 출력함. 지시·목표는 참고선 또는 별도 시리즈로 표현할 수 있다.
    • Y축: 온도(℃), 속도(m/min) / X축: 시간(Timestamp).
  • 로그 스트리밍 패널: 서버에서 삽입되는 ProductionLogs 레코드를 텍스트 로그 형태로 실시간 롤링 업데이트.
• 품질 검사 및 리포트 (Quality & Reporting)
  • 품질 분포 산점도(Scatter Plot): 로트별 color_de 값을 좌표로 표시하여 품질 편차 시각화.
  • 검사 성적서 뷰어: 특정 로트의 작업 사양, 생산 로그, 품질 판정 결과가 결합된 표준 양식 프리뷰.
  • PDF 내보내기 버튼: 뷰어에 표시된 내용을 문서 파일로 저장하는 기능 제공.

ADR 및 룰

• ADR: 의사 결정 사항을 기록함. 프로젝트 처음부터 쓰던 건 아니고, 중간에 멘토님 피드백 받고 쓰기 시작한 거라 (1) 초기의 모든 결정 정리한 ADR, (2) 통신 방식 전환 ADR 이렇게 2개 썼음
• ADR 기본 템플릿
  • 배경 및 문제: 이 의사결정이 왜 필요하게 되었는지, 어떤 의사결정을 위한 것인지 작성
  • 최종 결정: 결정된 결론 먼저 작성. 어느 영역(프론트, 백엔드, 데이터 등)인지, 무엇을 선택했는지, 버전/규칙은 무엇인지, 선택 사유는 무엇인지 작성.
  • 대안과 트레이드오프
    • 최종 결정된 사안을 포함해 의사결정 과정에서 고려했던 방안들에 대해 서술(즉, 최소 2개)
    • 각 방안의 장단점과 해당 안의 선택 여부를 작성할 것
  • 기대 효과와 리스크
    • 최종 결정된 사안을 반영했을 때 기대되는 효과와 예상되는 리스크
    • 예상 리스크에 대한 대응 방안
  • 미해결 이슈
  • 변경 이력: 최초 작성 이력을 포함함
• ADR 사례: 통신 방식 전환
  • 배경 및 문제: 기존에 기술 스택으로 정의된 통신 프로토콜은 HTTP와 STOMP 기반 WebSocket으로 구성되어 있었음. 본 프로젝트의 규모가 작고, 제공하는 기능이 그다지 많지 않기 때문에 두 가지 통신 방식을 혼용하는 것보다는 하나의 방식으로 통일하여 제공하는 것이 더 효율적일 것으로 논의됨.
  • 최종 결정
    • 영역: Frontend, Backend
    • 최종 선택: WebSocket(STOMP), SockJS
    • 버전/규칙:
      • WebSocket(STOMP) 서버 구성은 백엔드 빌드에 이미 포함된 스프링부트 웹소켓 의존성을 기준으로 한다.
      • SockJS는 백엔드에서 별도 Gradle 의존성을 추가하는 대상이라기보다 WebSocket 엔드포인트 설정에서 withSockJS()로 활성화한다.
      • 프론트엔드는 기존 sockjs-client 의존성을 사용함.
      • 관련 버전은 Spring Boot 3.x/Java 17과 호환 범위를 따름
    • 선택 이유
      • 본 프로젝트의 주요 UX 고려사항 중 하나는 사용자가 새로고침을 하지 않고서도 화면에 보이는 데이터가 업데이트되어야 한다는 점이었음. 이를 구현하기 위해 WebSocket을 고려하였으며, 메시지 규격 정의를 간소화하기 위해 STOMP를 채택함
      • 기본적으로 자바 스프링부트는 SockJS가 없어도 웹소켓 통신이 가능하나, 본 프로젝트는 웹소켓만을 통신 프로토콜로 사용하기 때문에 통신에 문제가 생겼을 경우 시스템 전체가 멈추게 되는 리스크가 존재한다. 이에 SockJS가 제공하는 fallback 기능을 활용하여 통신 문제가 생겼을 경우 대체 방안을 제공하기 위해 채택함.

  • 대안과 트레이드오프

    옵션	장점	단점	선택 여부
    STOMP (WebSocket)	메시지 규격 정의가 간소화되어 개발 생산성 향상	웹소켓 특성 상 테스트가 번거로움	O
    SockJS	웹소켓 통신 문제 시 대체 방안을 제공함	테스트가 번거로움	O
    HTTP REST	일반적으로 권장되는 통신 방식으로 쉽게 테스트 가능하며, 인프라 호환성 높음	서버가 먼저 화면 갱신을 밀어주는 모델을 표준화하기 어렵고, 실시간에는 폴링/중복 요청 비용이 생김	X

  • 기대 효과
    • 프론트와 백엔드가 서로에게 메시지를 보낼 수 있고, 오버헤드 감소
      • 짧은 갱신이 잦을 때 HTTP 반복 요청 대비 연결/헤더 비용이 줄어듦
  • 리스크 및 대응
    • 리스크: 웹소켓 연결 상태가 좋지 않을 때 명시적인 대안이 없음
    • 대응: SockJS의 fallback 통신 수단이 HTTP stream과 long polling으로 구성되어 있어 리스크가 완화되나, 통신 장애/재연결/타임아웃은 별도 점검
  • 미해결 이슈
    • 좀 더 간단하고 간편하게 테스트할 방법은 아직 찾지 못했음
    • 프론트엔드가 이전 설계대로 이미 구현을 해버려서 고쳐야 함
  • 추가
    • 저 ADR을 쓸 때는 내용에 포함되지 않았지만, 이후에 단지 프론트엔드만의 필요 때문에 웹소켓을 사용하기로 하는 것은 설득력이 약간 부족해서 백엔드의 필요성을 추가했었다.
    • 원래는 정상 납기만 존재하는 데이터를 사용했기 때문에 생산이나 납품 측면에서 문제가 발생하는 경우에 대한 고려가 없었지만 설비 데이터에 이상치가 존재하긴 했기 때문에, 이걸 기준으로 백엔드가 데이터를 감시하다가 이상치가 발견되면 프론트에 alert를 보내는 시나리오를 추가해서 백엔드 관점에서도 웹소켓의 필요성을 부여했다.
    • 물론 이건 프로젝트의 타당성을 좀 더 다잡기 위한 것이지 엄밀히 말하면 앞뒤가 바뀌긴 했음.

협업 컨벤션

원본 보기: docs/collaboration-conventions.md

• 작업 흐름
  • 이슈 → 브랜치 → 커밋 → PR → 리뷰 → approve → merge로 이어지는 개발 흐름을 정의함
  • 브랜치 이름 규칙, PR 규칙 등을 정의함
• 커밋 메시지: 커밋 메시지 양식 정의
• 코드 품질: 린터, 작명 컨벤션 정의, PR 전 정상 실행 확인하기 규칙 포함됨.
• API 및 데이터: 문서 참고
  • docs/api-details.md
  • docs/data-schema-definition.md
• 역할과 소통
  • 코드 리뷰는 팀원이 있는 한 항상 포함됨. 팀원 부재 시(인원 부족할 경우) 코파일럿 코드 리뷰로 대체함.
  • 진행 중의 문의사항은 이슈로 기록
• ADR: 파일명 양식 정의, ADR 작성 사유 기록됨.
• PR 템플릿 및 작성 규칙: 대부분 내용은 PR 템플릿 문서에 다 있고, 아직 merge할 만큼은 아니지만 리뷰가 필요한 경우 draft PR 작성. approve는 코파일럿 리뷰 검토가 끝난 후 요청할 것.
• 이슈/PR 템플릿: 작성 가이드는 주석으로 포함되어 있어서 Code 모드로 확인하면 보인다.
  • 이슈 템플릿
  • PR 템플릿

어려움 극복 및 주요 배운 점

• 로컬 main 오염 복구
  • 개발 초기 팀원의 로컬 main이 잠깐 오염된 적이 있었음. 브랜치가 바뀌지 않은 것을 미처 확인하지 못하고 커밋한 다음, 그 사실을 인지하지 못하고 main을 pull하다가 전후상황을 이해하지 못하고 merge까지 한 상황이었다.
  • source tree를 설치해서 브랜치 트리구조를 GUI로 확인하고, main 브랜치가 처음으로 오염된 지점을 식별했다.
  • 최초 오염 지점 바로 이전 커밋까지 브랜치를 초기화한 후 다시 main을 pull해서 오염은 복구했고, 리셋한 분량은 테스트 커밋으로 들어갔던 거라 삭제해도 무방한 내용이었음.
  • 만약 삭제하면 안되는 분량이 끼어있었다면 rebase나 cherry-pick으로 뽑아서 원래 있었어야 했을 브랜치에 붙이고 main을 리셋했겠지만 그럴 필요까지는 없었다.
  • 이렇게 오염되어본 적이 처음이라 약간 당황했지만 브랜치 트리 시각화 UI가 살렸다.
• ADR의 가치
  • 내가 참 못하는 일 중의 하나가 특정 결정을 했을 때 그 이유를 오래도록 기억하는 일인데, 딱 그걸 ADR이 해결해줬음. 시간이 지나도 나의 결정 의도를 보존할 수 있었다.
  • 나의 결정뿐만 아니라, 내가 기억하기 더 어려운 팀원의 결정 의도도 똑같이 보존되니까 적어도 ADR에 기록된 사항에 대해서는 모든 팀원이 똑같이 설명할 수 있게 하는 환경이 갖춰진 거임.
  • 난 이게 제일 크다고 본다. 프로젝트를 구구절절 문서로 남기면 그 문서의 양이 버거울 수도 있긴 한데(적어도 이번 팀원은 그래 보였다), 그럴수록 팀원들이 이 프로젝트에 대해 동일하게 이해할 수 있는 기반을 마련하는 거임. 기록하지 않고 동일한 이해를 기대하는 것과 기록하고 동일한 이해를 기대하는 것 중 어느 쪽이 더 실현 가능성이 높겠어요? 후자잖아.
• 컨벤션의 중요성
  • ADR과 비슷한 사유로 이것도 정하면 정할수록 도움이 되는구나 싶었음.
  • 이번엔 상당히 소규모 팀과 프로젝트였기 때문에 간결하게 정했지만, 그럼에도 정하지 않은 다른 부분에서 발생하는 자잘한 불일치 문제들이 있었음. 구체적으로 기억하지는 못하지만 서로 API를 맞추는 부분도 아주 매끄럽지는 않았던 것 같고, 이슈/PR 템플릿을 쓰게 된 것도 내가 원하는 수준의 ‘기록’과 팀원이 생각하는 수준의 ‘기록’이 달라서였음.
  • 이런 식으로 팀원마다 다른 프로젝트 정합성에 대한 기준을 하나로 합의하고 통일하는 거임. 경우에 따라서는 강제하는 면도 있고. 이게 정말 편했음.

향후 개선점

• 미완성 기능 구현
  • 역주행 그래프 문제
    • 데이터 전처리 과정에서 타임스탬프가 잘못돼서 날짜 단위만 들어가고 시간 단위가 전부 0시 0분으로 되어버렸다.
    • 그로 인해 실시간 생산 모니터링 그래프에 스트리밍되는 데이터의 순서가 올바르다고 보장할 수 없게 되었으며, 그래프는 역주행을 하게 되었음. 타임스탬프가 제대로 들어간 임시 데이터로 테스트했을 때는 정방향으로 제대로 지나갔으니 타임스탬프 문제가 맞음.
  • 시뮬레이션 시작 트리거 미구현
    • 원래 의도대로라면 사용자가 직접 시작 버튼을 눌러야 실시간 데이터 스트리밍이 재생되어야 하는데, 사용자가 사이트에 접속하는 순간부터 자동으로 스트리밍이 시작되게 되었다.
  • 데이터 순차 적재 미구현
    • 원래는 시뮬레이션이 시작될 때, 백엔드는 csv 데이터를 한 줄씩 읽어서 DB에 적재하고, 그렇게 DB에 데이터가 쌓여가는 과정이 프론트엔드에서는 ‘시뮬레이션 재생’으로써 나타났어야 했다.
    • 백엔드가 csv 데이터를 한번에 다 읽고 DB에 올리는 방식으로 구현되어서 프론트엔드에서도 모든 데이터가 한번에 다 보이게 되었고, 그로써 시뮬레이션에 어울리지 않게 미래의 모든 데이터가 처음부터 보이는 상황이 발생함.
  • UX 개선 미비
    • UI의 기본적인 요소들은 갖추었지만 특정 영역의 길이 제한이 설정되지 않고, 50만 개 이상의 데이터가 모두 화면에 나타나게 되면서 화면 스크롤이 지나치게 길어지게 되었다. 요소 별 길이 제한이 필요했다.
• 배포
  • 위의 다양한 수정사항들로 인해 배포는 손도 못댔다.

최종 발표 기록

이 프로젝트는 “1조” 보면 된다 조별 순서는 발표 순서 그대로 썼다

5조

• 깃허브 보니까 dev 브랜치가 디폴트로 설정돼있고, main 브랜치는 51커밋이 밀려 있던데, 브랜치 전략을 어떤 방식으로 정하고 활용하셨는지 궁금쓰
  • 배포도 했는데 main이 아니라 develop이라는 이름으로 배포된 게 약간 이해하기 어렵다
  • 답변: 바빠서 메인까지 못올라갔다
• 닫힌 PR들을 보니 설명이 하나도 없고, 리뷰도 없던데 혹시 팀 내에서 코드 리뷰 같은 것을 따로 하셨는지? → 발표자료를 보니 지라에서 코드 리뷰를 진행한 것 같다. 내가 지라를 안써봐서 그러는데 혹시 깃허브 PR과 지라가 연동되는가?
  • 답변: 시간 없어서 리뷰 안했다. 브랜치명이 곧 커밋메시지라고 생각하면 된다.
• 데이터는 어디서 얻었는지?
  • 답변: 랜덤 생성이다

6조

• 특이하게 모든 팀원이 기능 단위로 풀스택 개발을 했는데, 이렇게 배정한 이유가 있었는지?
  • 답변: API 정의를 따로 하느니 각자 기능 단위로 풀스택을 맡는 게 더 낫겠다고 생각하기도 했고, 팀원들도 풀스택 경험을 해보고자 각자 맡게 되었다
• ERD를 보니 bom 테이블의 기본키와 price 테이블의 기본키가 동일하다. 이에 대해 price 테이블의 기본키는 bom 테이블의 기본키로부터 유래한 외래키를 사용하고 있음이 발표자료에 나와 있었다. 이런 구조로 데이터를 구성했을 때의 특징에 대해 알고싶다. 장단점 같은 것들.
  • 답변: 기억 안남 근데 적당히 타당했음
• 데이터 수집 출처 알려달라
  • 부품 같은 건 실제 차량 판매 페이지에서 참고했고, 주문 데이터는 생성했다
• 전체 회원 목록에서도 회원의 액티브 상태를 바꿀 수 있는가? 그것이 액티브에서 보류 상태로 변경하는 것도 가능한가? 그렇다면 만약 어떤 관리자가 전체 관리 탭에서 delete를 눌러야 하는데 pending으로 잘못 눌렀고, 추후 그 사실을 잊어버리고 해당 회원을 다시 승인하는 경우에 대한 대비가 가능한지? 이에 대해 전체 회원 목록 탭에서는 회원의 활성화 상태 수정을 금지하고 권한만 변경 가능하도록 하는 게 나을 것 같고, 권한 부여도 회원이 먼저 신청한 후 승인하는 방식으로 따로 탭을 내어 실행하도록 하면 사용자의 실수를 방지하는 데 도움이 될 것 같다
  • 답변: 피드백 감사요
• 발표자료에 쓴 것 이외의 컨벤션이 있는지?
  • 답변: PR 쓸 때 내용을 자세히 썼고, 커밋 메시지도 자세히 썼다
• 권한 분리가 구현되어 있는데, 권한마다 사용 가능한 기능이나 조회 가능한 페이지의 차이가 있는지?
  • 답변: 사용자는 권한 관리 페이지만 접근 불가하며, url로 직접 접근하려고 해도 불가하다.
• 강사님 피드백
  • 컬러파레트 정의하고 디자인한 거 다른 팀도 참고하세요
  • 배포할 때는 콘솔 로그 지우세요
  • 회원가입 시 비밀번호 확인란 없고, ‘사번’ 항목에 자릿수 제한이나 범위 제한 같은 것이 없는 것 같다.

2조

• AWS로 배포했다는 내용이 있는데, 이 결정을 하는 과정에서 어떤 고려들을 했는지 알고 싶다. 고려했던 후보들은 뭐가 있고, 무엇을 사유로 AWS가 확정되었는지? 이 질문에서 궁금한 점은 AWS가 사용량 기반으로 요금이 청구되다 보니 인스턴스를 열어놓고 관리를 잘못하면 요금 폭탄을 맞는 경우도 가끔 있는데 이러한 관리까지도 염두에 둔 선택이었는지 궁금하다.
  • 답변: (AWS를 쓴 이유?) 프론트는 오라클 클라우드, 백엔드만 AWS를 썼다. 프론트는 경험이 있어서 그렇게 했고, 백엔드는 경험을 하고 싶어서 선택했다고 한다.
• 스쿼시 머지를 사용했다고 하는데, 이건 일반적인 merge와 뭐가 다른지, 왜 스쿼시 머지를 하기로 했는지 설명해달라
  • 답변: 기록을 안남기고 싶었다
• 깃허브에 머지하지 않고 그냥 close된 PR이 있던데, 어째서 머지하지 않았나?
  • 답변: 기능 테스트하면서 올라간 연습용 PR이었다
• AI 허브에서 데이터를 가져왔다고 하는데, 그렇다면 이 데이터는 머신러닝과 예측을 목적으로 생성된 데이터라고 예상이 된다. 이 프로젝트에서는 이 데이터를 사용하면서 머신러닝을 시도한 부분이 있는지, 혹은 이미 라벨링된 데이터를 기반으로 화면에 보여주는 것이 더 중심적이었는지?
  • 답변: 라벨링된 데이터를 보여줬다
• 노션에 요구사항 정의서 4.0버전이 있던데, 변경 이력에 대한 추적이 따로 존재하는지?
  • 답변: 로컬에서만 변경 이력이 관리되었다

메모

• 트리쉐이킹: 필요한 라이브러리만 선택적으로 import해서 모듈 로드 용량을 줄이는 방법에 대한 이름
• 스웨거 UI: 링크 넣고 의존성만 주입해주면 API 명세를 보여준다

4조

• 코드 리뷰 사례 있음?
• text to SQL 모델은 어느 정도로 자연어를 이해할 수 있는지? SOH라고 말하는 것과 배터리 건강도라고 말하는 것 모두 같은 쿼리를 실행해줄 수 있는지? 혹은 사용자가 문제 상황을 설명하면 어떤 부분을 확인해야 하는지 제안까지도 가능한지?
  • 그냥 내가 시연하는거 봤는데 아마 그정도로 고능하지 않을 것 같음
• 번역은 기계번역인지 수동번역인지? 만약 기계번역이라면 잘못 번역된 부분이 있었는지?
  • 답변: 기계 번역인데 내용 상 문제 없어서 그대로 썼다
• feature 브랜치가 16개라고 집어서 작성해뒀는데, 아마 처음부터 브랜치를 16개 쓰자고 정하고 시작하지는 않았을 것 같다. 브랜치 관리는 구체적으로 어떻게 이루어졌는지?
• 재검사를 실행하는 화면에서, 재검사 버튼을 누르니까 셀 히트맵에서는 이상치가 사라졌는데, 이건 디폴트 값이 정해져 있어서 기본적으로 정상으로 뜨는 것인지?
  • 답변: 맞다 정상값이 디폴트임

1조

• 칭찬받았다^^
• 배포를 못한건지 안한건지? → 안했다에 가깝다. 이런저런 리스크를 고려해서 일단 배포는 배제하고 개발했다.
• 업무 배분은 각 파트에 대한 사전 숙련도를 반영하여 배정된 부분과, 각자의 진로 선호를 반영하여 배정된 부분이 있음.
• 딱히 타겟팅한 산업이나 기업, 공정 등은 없고, 굳이 말하자면 원천 데이터로 사용된 의류 염색 공장 정도를 이 프로젝트의 모티브로 볼 수 있다.

3조

• UI 디자인은 어떻게 했는지? 다른 팀의 발표를 참고하자면 피그마를 사용한 경우가 많았는데 이 팀은 어떤 방법으로 이 UI를 구성했는지 궁금하다.
• 가동 중, 유휴, 충전 중 설비를 나타내는 색깔을 선택한 기준이 있는지? 보통 정상 혹은 잘 작동하고 있는 설비를 초록색으로 표현하고, 주의가 필요한 것에 노란색 혹은 주황색, 명백히 문제가 있는 것에 빨간색을 쓰는 걸 많이 봤는데, 이 UI는 정상 작동으로 간주할 수 있을만한 대상인 ‘가동 중’ 마커가 주황색으로 되어 있다. 이 부분에 대한 설명 가능함?
  • 답변: 색깔에는 의미 ㄴㄴ. 왜냐면 가동 중인 설비도 정도껏 가동해야 정상이지 과하게 가동하면 그것도 문제가 된다. 그런 면을 고려하여 가동 중이라고 무조건 정상이라고 간주하지 않아 색깔에는 의미를 두지 않았다.
• 회원가입 화면에 있는 ‘첫 가입자는 자동으로 전체 권한이 부여됩니다’ 문구에 대한 설명 요구, 전체 권한을 가진 관리자가 자신의 그 ‘전체 권한’을 타인에게 양도할 수 있는지 궁금
  • 답변: 이 DB에 처음으로 등록한 사람에게 자동으로 글로벌 어드민 권한이 부여되고, 웹상에서 이걸 양도할 방안은 없으며, DB를 직접 수정해야 한다.
• 전체 분포 요약은 공장과 시나리오, 시간을 기준으로 필터링해서 데이터를 보여주는데, 그렇다면 이렇게 필터링된 데이터는 케이스당 몇 개 정도 있나? 왜 로딩이 오래걸리나?
  • 전체 분포 요약 화면은 전체 공장 요약과 선택된 공장 요약 2가지 뷰를 제공한다. 전체 공장 요약 뷰를 로드하는 데에 걸리는 시간이다. 완전히 모든 데이터를 불러오는 것은 아니지만 많은 데이터를 불러오기 때문에 시간이 걸리는 것 같다.
• 브랜치 재활용했어요?
  • 답변: 예

전체 회고

• 이번 발표회의 목표
  • 면접관은 면접에서 하고 싶은 질문이 없어도 안 할 수가 없다. 없으면 만들어야지. 그런 상황을 경험시키고 싶었고.
  • 다른 팀의 결과물로부터 참고할만한 사항이 있다면 잘 배워가기.
  • 사람이 풀타임 집중을 하는 건 당연히 어렵긴 하지만, 그럼에도 해야 할 순간이 있어요. 그거 연습하시기.
• 이 세상엔 토론 면접이라는 게 있어요. 알아두시기.
• 기록과 증거를 남겼다는 것은, 그것이 채점에 있어 검증의 수단이 될 수 있다는 것을 알아두기
• 말로 이미지 관리 잘 하세요
  • 이것저것 목표한 것은 많았으나, 그에 미치지 못했다 → 향후 발전 가능성이 높은 프로젝트입니다
  • 아 이게 로컬에서는 됐거든요 → 보고받는 상급자 입장에서는 불필요한 말이다. 그냥 “빠르게 고쳐보겠습니다” 한마디 하면 됨.
  • 팀 내 불화는 그냥 티를 내지 마세요 보여주지 마세요 ← 아 쟤는 저런 거 어디 가서 티 내는 사람이구나 생각합니다

질의응답

• 보통 웹 개발을 하면 요구사항이나 API 명세는 누가 정하는지 궁금하다
  • 개발자가 하기도 하고, 기획자가 하기도 한다. 기획자가 제안하고 개발자에게 검수하는 경우가 보통이다.
  • 설계 중요해요
• 개발을 함에 있어서 일정 관리는 어떻게 하나요
  • 깃허브 관리는 1조가 합격점임. 문서 정리가 아직 덜 된 부분은 있지만 그래도 다른 팀에 비하면 베스트였다.
  • 현업자들은 일단 이미 프로젝트를 시작할 때 거쳐야 하는 단계를 알고 있고, 경험적으로 어떤 작업에 얼마나 시간이 걸릴지 알고있다. 또한 예정된 프로젝트 기간이라는 게 있잖아요. 최소 언제까지는 끝내고, 그 다음으로 무엇을 하자 라는 팀 내 데드라인을 정하는 거예요. 그 다음엔 프로젝트 진행 과정의 역순으로 일정을 소거하는 겁니다. 전체 기간 중 얼마만큼을 어느 작업에 할당할지 큼직하게 분배한 다음, 그 안에서 세부 분배를 하는 거임.
• 도커 사용 시 “제 로컬에서는 됐는데요” 문제가 많이 해소되는지?
  • 강사님 체감으로는 20~25% 정도 해소되었던 것 같다. 로컬과 배포 환경에서의 설치 프로그램 차이나 버전 차이를 미리 방지할 수 있기 때문에 그정도는 해결이 되는 것 같다.