프로그래밍

사내 프로젝트 툴 제작기 : AI 다써보기

noeyodeeeeeel — Thu, 27 Nov 2025 09:32:44 +0900

프로젝트 소개

프로젝트 툴을 직접 만들게 된 이유

회사에서 여러 팀이 프로젝트, 업무(Task), 주간보고를 각각 다른 방식으로 관리하고 있었어요.
현재 시장에 나와있는 프로젝트 툴은 많지만 딱 필요한 것만 있는 가벼운 프로젝트 툴이 필요했다

그래서 우리만의 프로젝트 툴을 만들기로 했습니다.
업무(Task) → 주간 계획 → 주간 보고서가 자연스럽게 이어지는! + AI 다 써보자 ( Figma make, GPT, Cursor, copilot)

⏱️ 프로젝트 개요

개발 기간: 약 6주 (2025.10 ~ 2025.11)

순수 개발 기간은 약 10일 이후 2-3주 주니어 개발자 1인이 수정 배포를 수행함.

3주는 주니어 개발자 1인이 수정·배포를 수행.
AI 도입 효과: 개발 소요시간 약 40% 단축
개발 단계: 분석 → 설계 → 디자인 → 개발 → 테스트 → 배포
현재 버전: v1.0 배포 완료

⚙️ 기술 스택

Frontend: React (Vite, TypeScript, Tailwind)
Backend: Spring Boot + eGovFrame + MyBatis
DB: MariaDB 10.11
AI Toolchain: GPT, Copilot, Cursor
Design: FigmaMake

개발 단계

1️⃣ 분석·설계 – GPT와 함께 구조부터 잡기

처음에는 제가 하고 싶은 시스템을 자연어로 GPT에게 설명했어요.
그러면 GPT가 도메인 모델이나 데이터 흐름을 초안으로 만들어 줍니다.
저는 그 초안을 실제 회사 업무 흐름에 맞게 다듬었고요.

핵심적인 도메인

프로젝트
업무(Task)
주간 계획
주간 보고서
첨부파일
댓글
팀 멤버와 권한

전체 개발 프로세스는
Figma → GPT 명세 자동화 → Cursor 코드 생성 → React → Spring Boot → Tomcat
기존 방식보다 훨씬 빠르게 구조를 잡을 수 있었습니다.

2️⃣ 디자인 – Figma Make로 화면 자동 생성

UI는 Figma Make + Clobe Plugin 조합으로 만들었어요.
GPT에게 “이런 시스템을 만들 거야”라고만 설명하면, 정말 필요한 화면을 거의 다 뽑아줍니다.

- 사용한 프롬프트 (figma Make는 영어를 더 잘 인식한다고 들었음..)

“Create a modern responsive web dashboard UI for an internal Project Management and Weekly Report System. The system includes: Login and member management (admin can create, edit, delete members; fields: name, email, phone, password, role, join date, status). Layout: sidebar navigation (Members / Projects / Weekly Reports / Settings)... Style: clean, modern, blue (#2563eb) and white color palette, rounded corners....

이 프롬프트 하나로 전체 UI의 90%가 자동으로 만들어졌습니다.
디자인 단계에서는 완성도를 높이기보다 빠르게 초안을 확보하는 것이 목표였는데, AI 덕분에 이 단계가 정말 빨랐어요.
이후 색깔, 여백, 컴포넌트 조정은 Cursor에서 미세 조정을 해서 마무리했습니다.

3️⃣ DB·API 설계

데이터베이스와 API 설계는 반복 작업에 가까웠어요.

FigmaMake → 구조 자동 추출
GPT가 이를 표 형태·스키마 형태로 정리
개발자가 실제 업무 규칙에 맞게 컬럼과 제약 조건을 보완

AI가 초안을 만들어주는 속도가 빨라서 저는 디테일한 부분만 수정했습니다.
이 단계에서 시간 절약 효과가 매우 컸습니다.

4️⃣ 개발 – GPT → Copilot → Cursor로 이어지는 개발 체인

기능 하나를 개발할 때마다 이렇게 진행했어요.

GPT에게 기능 요구사항 설명
GPT가 Copilot에 넘길 프롬프트 생성
Copilot이 Controller–Service–Mapper 코드 생성
생성된 코드를 기반으로 GPT가 Cursor용 프롬프트 작성
Cursor가 React UI와 API 연결까지 자동 구현

제가 직접 타이핑을 하는 코드는 거의 없었고 코드를 검토하고 판단하는 시간이 더 많았어요.

5️⃣ 테스트·보완 – AI는 빠른 분석 보조 역할

테스트 단계에서도 GPT는 유용했어요.

에러 로그 원인 분석
매핑 오류 위치 찾기
의심되는 부분 추려주기
Cursor는 리팩토링과 정리 작업을 빠르게 해줬습니다.

마무리

AI를 쓰면서 느꼈던 어려움

AI는 빠르지만 의사결정은 사람이 해야 한다.

질문을 조금만 바꿔도 다른 답이 나오고
장단점만 나열하고 결론을 안 내리고
조직의 상황이나 맥락을 이해하지 못하죠
결국 “어떤 방식이 맞는가?”는 개발자가 판단해야 했습니다.

=> 그래서 개발자에게는 최종 판단을 내릴 수 있는 지식과 기준이 반드시 필요합니다.
AI가 제안은 해줄 수 있지만 의사결정을 하는 책임은 결국 사람에게 있기 때문입니다.

새로운 기능을 만들 때보다, 기존 코드를 수정할 때 AI는 훨씬 약하다.

관련 파일을 제대로 찾지 못함 ( 파일 이름이 비슷할때 )
엉뚱한 부분을 수정하려고 함 (아주 디테일하게 설명해야함, cursor 의 'add to chat"기능 활용하면 좋음)
기존 구조와 맞지 않는 코드 제안
존재하는 함수를 활용하지 못하고 중복되는 기능을 다시 만듬 (코드가 너무 길어져서 수정속도가 느려짐.

그래서 기존 코드를 손볼 때는 두 가지 선택지가 생겼습니다.
아예 처음부터 아주 디테일하게 범위를 잡고 AI에게 다시 요청하거나
잘못된 방향으로 가기 시작하면 과감히 undo하고 처음부터 다시 시작하는 게 더 빠를 때도 있습니다.

기존 코드 수정은 AI보다 사람이 직접 구조를 파악하고 판단하는 쪽이 더 효율적인 순간이 많았습니다.

사용해본 AI 특징과 실제 활용 모습

GPT → 설계·명세 정리 및 정확한 프롬프트 작성
요구사항을 빠르게 구조화하고 명세로 정리해 주었으며,
Cursor와 Copilot에서 바로 활용할 수 있는 정확한 프롬프트를 만드는 데 큰 역할을 했습니다.

Figma Make → 디자인 자동 생성 + 초기 프론트 코드 초안 생성
디자인을 정말 순식간에 만들어줄 뿐 아니라,
프론트엔드에서 바로 활용 가능한 UI 코드 초안까지 자동 생성해 주었습니다.
초기 화면을 ‘바로 써도 될 정도’로 만들어 주는 점이 특히 놀라웠고,
백엔드 개발자 입장에서는 더 흥미로운 경험이었습니다.

Cursor(프론트엔드) → UI·상태 관리·API 연동 구현 가속화
Figma Make로 만들어진 화면을 기반으로 빠르게 UI와 로직을 붙일 수 있었고,
특히 Plan 모드와 Add to Chat 기능을 활용하면
필요한 변경 지점을 지정해 해당 부분 위주로 정확하게 수정해 주어
프론트 개발 속도가 크게 향상되었습니다.

Copilot(백엔드) → 백엔드 기본 구조 및 구현 자동 생성

2025.10.27 - [work] - 프론트 페이지 리팩토링

Controller–Service–Mapper 구조와 기본 로직을 빠르게 생성해 주었고,
Eclipse 환경에서도 매끄럽게 작동하여 백엔드 개발 시간을 크게 줄였습니다.
다만 코드 생성 속도 자체는 Cursor가 훨씬 더 빠르게 느껴졌습니다.

=> 이 조합 덕분에 6주 예상 일정이 2주로 60%이상 단축될 만큼 효과가 컸습니다.

바이브 코딩 개발 회고

AI를 잘 쓰려면 오히려 더 탄탄한 설계가 필요하다
요구가 조금만 모호해도 결과가 흐려지고 세부 조건을 정확하게 잡아주지 않으면 AI가 엉뚱한 방향으로 가더라고요.
그래서 자세한 프롬프트의 중요성을 느꼈습니다.

방향을 결정하는 건 개발자의 역할
AI가 여러 옵션을 던져줘도, 그중에서 어떤 방식이 맞는지 고르고
전체 구조를 보완하는 일과 책임을 지는 건 개발자라는 걸 다시 느꼈습니다.

AI는 개발자를 대체제보다는 개발자의 판단력과 기준을 기반으로 개발 속도를 빠르게 만들어주는 도구
잘 쓰면 엄청난 가속 장치가 되고 잘못 쓰면 오히려 돌아가는 시간이 더 늘어나는 그런 도구라고 생각합니다.

이후에도 앞으로 AI가 얼마나 발전되었는지 앞으로 얼마나 빠르고 똑똑하게 발전할지 기대되는 경험이었습니다.

* 참고 *
프로젝트 진행중 과정을 남기 포스팅

2025.10.13 - [work] - 업무관리 프로젝트 (Figma make)

2025.10.14 - [work] - 주간보고 페이지 수정

2025.10.16 - [work] - 전자정부 프레임워크 4.3.0과 copilot 같이 쓰기

2025.10.20 - [work] - 백엔드(copilot) 을 사용한 후 프론트엔드 (cusor) 로 연결

2025.10.20 - [work] - Copilot으로 만드는 댓글 관리 API

2025.10.27 - [work] - 프론트 페이지 리팩토링

2025.10.27 - [work] - 팀 멤버 추가 api 구현 (gpt, copilot)

2025.10.29 - [work] - 기능 추가 - 날짜 필터링

기능 추가 - 날짜 필터링

noeyodeeeeeel — Wed, 29 Oct 2025 13:46:43 +0900

주간 보고페이지에 있는

업무 요약, 내 주간 보고서에게 날짜 필터를 적용시킬 예정
수정사항은 어떤 새로운 기능을 만들때보다 더 세세하게 들어가야한다
1. 프론트엔드 (cursor)에게 현재 상황을 먼저 받아옴

"업무 요약 카드와 내 주간보고서 카드에서 호출하는 조회 api가 뭔지 알려줘 "

[cursor 에게 받은 응답]

  업무 요약 카드와 내 주간 보고서에서 호출하는 조회 API 정리
이미지에서 보이는 두 섹션에서 호출하는 API들을 정리해드리겠습니다:
  1. "업무 요약" 카드 (MyTasksSummary 컴포넌트)
호출하는 API:
백엔드 엔드포인트: GET /api/tasks
프론트엔드 서비스: taskService.getTasksByProject('')
위치: src/services/taskService.ts (36-63번째 줄)
API 호출 방식:
실제 요청 URL:
데이터 처리:
모든 업무를 가져온 후 프론트엔드에서 현재 사용자의 업무만 필터링
task.assignedTo === currentUserId 조건으로 필터링
  2. "내 주간 보고서" 카드 (MyPlanTable 컴포넌트)
호출하는 API:
백엔드 엔드포인트: GET /api/weekly-plans
프론트엔드 서비스: getWeeklyPlans()
위치: src/api/weeklyPlansApi.ts (41-47번째 줄)
API 호출 방식:
실제 요청 URL:
데이터 처리:
프로젝트 정보와 매핑하여 projectName 추가
availableProjects.find(p => p.id === plan.projectId)?.name 로 프로젝트명 설정
  관련 API들
프로젝트 목록 조회:
백엔드 엔드포인트: GET /api/projects
프론트엔드 서비스: getProjects()
위치: src/services/projectService.ts (13-61번째 줄)
사용자 목록 조회:
백엔드 엔드포인트: GET /api/users
위치: src/hooks/useWeeklyReports.ts (90번째 줄)
주간 보고서 목록 조회:
백엔드 엔드포인트: GET /api/weekly-reports
쿼리 파라미터: startDate, endDate, project_id, assignee_id
위치: src/api/weeklyReportsApi.ts (39-76번째 줄)
  요약
업무 요약: /api/tasks → 모든 업무 조회 후 사용자별 필터링
내 주간 보고서: /api/weekly-plans → 주간 계획 데이터 조회
프로젝트 정보: /api/projects → 프로젝트명 매핑용
사용자 정보: /api/users → 사용자 목록 조회
이 API들이 이미지에서 보이는 테이블 데이터를 구성하는 핵심 데이터 소스입니다!

2. 프롬프트를 넘겨서 gpt에게 전달하고 내가 구현하고 싶은 기능과 함께 요청하며 백엔드 (copilot) 에게 넘길 프롬프트 요청

[GPT에게 받은 응답]

[목표]
"업무 요약"과 "내 주간업무 보고서"에서 사용할 기간별 필터 기능을 백엔드 레벨에서 지원하도록 개선해줘.

현재 프론트 구조
----------------------------------------------------
1️⃣ 업무 요약 (MyTasksSummary)
- API: GET /api/tasks
- 호출 위치: src/services/taskService.ts (36~63)
- 필터 방식: 프론트에서 전체 업무를 가져온 후
  task.assignedTo === currentUserId 로 필터링함.

2️⃣ 내 주간업무 보고서 (MyPlanTable)
- API: GET /api/weekly-plans
- 호출 위치: src/api/weeklyPlansApi.ts (41~47)
- 필터 방식: 주간 계획 전체를 가져온 후
  availableProjects.find(p => p.id === plan.projectId)?.name 으로 프로젝트명 매핑함.
----------------------------------------------------

[요구사항]
1. 두 API 모두 기간 필터(startDate, endDate)를 쿼리 파라미터로 받을 수 있도록 수정.
   예:  
   - GET /api/tasks?startDate=2025-10-20&endDate=2025-10-26  
   - GET /api/weekly-plans?startDate=2025-10-20&endDate=2025-10-26

2. startDate와 endDate가 제공된 경우,
   - `/api/tasks` → task.start_date, task.due_date 기준으로 필터링  
     (`WHERE start_date >= :startDate AND due_date <= :endDate`)
   - `/api/weekly-plans` → week_start_date, week_end_date 기준으로 필터링  
     (`WHERE week_start_date >= :startDate AND week_end_date <= :endDate`)
   - 파라미터가 없을 경우 기존 전체 조회 로직 유지.

3. Controller, Service, Mapper 각각 수정해줘.
   - Controller: @RequestParam("startDate") @RequestParam("endDate") optional 로 추가
   - Service: 기간이 존재하면 Mapper 쿼리 호출 시 map에 조건 추가
   - Mapper: SQL WHERE 절에 조건 추가 (동적 <if test> 문 사용)

4. 반환 데이터 포맷은 기존 ApiResponse 유지.

[추가 참고]
- WeeklyPlanController.java: list() 메서드 참고
- TaskController.java: getTasks() 또는 listTasks() 참고
- 테이블 구조:
  - tb_task(start_date, due_date)
  - tb_weekly_plan(week_start_date, week_end_date)

[출력 형태]
- 수정된 Controller / Service / Mapper 코드 전체
- 수정된 SQL 예시
- startDate, endDate 없이 호출 시 전체 조회 유지되는 부분 명시

3. copilot에게 위 프롬프트를 전달

팀 멤버 추가 api 구현 (gpt, copilot)

noeyodeeeeeel — Mon, 27 Oct 2025 13:36:01 +0900

- GPT 에게 프롬프트 생성 요청

-- weekly_report.tb_project_team_member definition

CREATE TABLE `tb_project_team_member` (
  `id` char(36) NOT NULL DEFAULT uuid(),
  `project_id` char(36) NOT NULL,
  `user_id` char(36) NOT NULL,
  `role` varchar(100) NOT NULL,
  `assigned_date` date DEFAULT curdate(),
  `is_active` tinyint(1) DEFAULT 1,
  `created_at` timestamp NULL DEFAULT current_timestamp(),
  `updated_at` timestamp NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
  PRIMARY KEY (`id`),
  UNIQUE KEY `project_id` (`project_id`,`user_id`),
  KEY `user_id` (`user_id`),
  CONSTRAINT `tb_project_team_member_ibfk_1` FOREIGN KEY (`project_id`) REFERENCES `tb_project` (`id`) ON DELETE CASCADE,
  CONSTRAINT `tb_project_team_member_ibfk_2` FOREIGN KEY (`user_id`) REFERENCES `tb_user` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci;

이게 프로젝트 멤버 테이블이고 crud api만들려고해 어떻게 copilot에게 요청할 프롬프트 만들어줘 
첨부한 사진처럼 되어있는곳에 api를 추가할거야

프롬프트 생성, copilot에게 입력

Spring Boot + MyBatis 기반으로 프로젝트 팀 구성원(tb_project_team_member) CRUD API를 구현해줘.

---

  테이블 구조
CREATE TABLE tb_project_team_member (
  id char(36) PRIMARY KEY DEFAULT uuid(),
  project_id char(36) NOT NULL,
  user_id char(36) NOT NULL,
  role varchar(100) NOT NULL,
  assigned_date date DEFAULT curdate(),
  is_active tinyint(1) DEFAULT 1,
  created_at timestamp DEFAULT current_timestamp,
  updated_at timestamp DEFAULT current_timestamp ON UPDATE current_timestamp,
  UNIQUE KEY (project_id, user_id),
  FOREIGN KEY (project_id) REFERENCES tb_project(id) ON DELETE CASCADE,
  FOREIGN KEY (user_id) REFERENCES tb_user(id) ON DELETE CASCADE
);

---

  구현 목표

1. **팀 구성원 목록 조회**
   - `GET /api/projects/{projectId}/members`
   - tb_project_team_member + tb_user 조인
   - 응답 데이터 예시:
     ```json
     [
       {
         "userId": "uuid",
         "name": "이도연",
         "email": "lee@krediv.com",
         "department": "백엔드",
         "role": "홈 화면 API구현",
         "avatarUrl": "...",
         "assignedDate": "2025-10-27"
       }
     ]
     ```
   - is_active = 1 인 사용자만 조회

2. **팀 구성원 추가**
   - `POST /api/projects/{projectId}/members`
   - 요청 바디: `{ "userId": "...", "role": "..." }`
   - 같은 user_id 가 이미 존재하면 409 반환
   - 성공 시 201 반환

3. **팀 구성원 수정**
   - `PATCH /api/projects/{projectId}/members/{userId}`
   - 요청 바디: `{ "role": "..." }`
   - 역할(role) 또는 활성 상태(is_active) 변경 가능

4. **팀 구성원 제거**
   - `DELETE /api/projects/{projectId}/members/{userId}`
   - 실제 삭제 대신 is_active = 0 업데이트

---

  구현 방식
- Controller: `ProjectTeamMemberController`
- Service: `ProjectTeamMemberService`
- Mapper 인터페이스: `ProjectTeamMemberMapper`
- Mapper XML: `ProjectTeamMemberMapper.xml`
- DTO: `ProjectTeamMemberRequest`, `ProjectTeamMemberResponse`
- 응답 래핑: `ApiResponse<T>` 형태 사용
- 예외 처리: 중복 추가, 존재하지 않는 사용자, FK 제약 위반 시 적절한 메시지 반환

---

  추가 설명
이 API는 프로젝트 상세 페이지의 “참여 인원 카드”에서 사용됨.  
- ‘추가’ 버튼 → POST  
- ‘수정’ 버튼 → PATCH  
- ‘삭제’ 버튼 → DELETE  
- 페이지 진입 시 → GET 호출

UI 예시는 첨부된 이미지 참고.

- copilot 결과

I implemented the requested Project Team Member CRUD API (no DTOs — controller uses Map<String,Object> / path params) and wired MyBatis mapper + XML. Files I added/updated and what they do:

Files created
- src/main/java/egovframework/ai/managing/controller/project/ProjectTeamMemberController.java  
  - REST endpoints:
    - GET /api/projects/{projectId}/members
    - POST /api/projects/{projectId}/members
    - PATCH /api/projects/{projectId}/members/{userId}
    - DELETE /api/projects/{projectId}/members/{userId}
  - Uses ApiResponse<T> wrapper.

- src/main/java/egovframework/ai/managing/service/project/ProjectTeamMemberService.java  
  - Service interface.

- src/main/java/egovframework/ai/managing/service/project/ProjectTeamMemberServiceImpl.java  
  - Business logic: validation, duplicate detection, add / update / deactivate operations using mapper, transactional behavior.
  - addMember checks for existing active membership and throws DuplicateKeyException if already present.

- src/main/java/egovframework/ai/managing/mapper/project/ProjectTeamMemberMapper.java  
  - MyBatis mapper interface (annotated @Mapper) with:
    - selectMembersByProjectId, selectMember, countMember, insertMember, updateMember, deactivateMember.

- src/main/resources/mapper/ProjectTeamMemberMapper.xml  
  - SQL mappings for the mapper methods. Joins tb_user for listing members and supports insert/update/deactivate.

Files modified
- src/main/java/egovframework/ai/managing/common/GlobalExceptionHandler.java  
  - Added handlers for DuplicateKeyException (409) and DataIntegrityViolationException (400) to return meaningful ApiResponse.fail messages.

Behavior / validation / error responses
- List members (GET)
  - Returns ApiResponse.success("ok", List<Map<String,Object>>) with only active members (is_active = 1).
  - Each item contains: userId, name, email, department, role, avatarUrl, assignedDate.

- Add member (POST)
  - Request body (JSON): { "userId": "...", "role": "..." , optional "assignedDate":"yyyy-MM-dd" }
  - Validates projectId and userId presence.
  - If the same user is already an active member -> 409 CONFLICT (DuplicateKeyException) with message.
  - If FK or DB integrity issues (e.g. userId or projectId not exist) -> 400 BAD REQUEST with details (DataIntegrityViolationException).
  - On success -> 201 CREATED with ApiResponse.success("Member added", null).

- Update member (PATCH)
  - Request body can include any of: role, isActive, assignedDate (no DTO — Map used).
  - If member not found -> 404 NOT FOUND (NoSuchElementException).
  - On success -> 200 OK with ApiResponse.success("Member updated", null).

- Remove member (DELETE)
  - Soft delete: sets is_active = 0.
  - If member not found -> 404 NOT FOUND.
  - On success -> 200 OK with ApiResponse.success("Member removed", null).

Notes / implementation choices
- No DTOs used: controller methods accept Map<String, Object> or path parameters as requested.
- MyBatis xml namespace = egovframework.ai.managing.mapper.project.ProjectTeamMemberMapper and placed under src/main/resources/mapper (same location as existing mappers).
- Mapper interface annotated with @Mapper so MyBatis/Spring should pick it up (consistent with other mappers).
- I added selectMember in the mapper/XML for potential reuse (e.g. re-activate earlier inactive rows) though current addMember only checks active existence — if you want to automatically reactivate an inactive record instead of inserting, I can adjust the service logic to update is_active=1 when selectMember shows an inactive row.
- Exceptions are handled by the global exception handler added/updated earlier; errors are returned as ApiResponse.fail with appropriate HTTP status codes.

Example request/response outlines
- GET /api/projects/abcd-1234/members
  - 200 OK
  - body: ApiResponse.success("ok", [ { "userId":"...", "name":"...", "email":"...", "department":"...", "role":"...", "avatarUrl":"...", "assignedDate":"2025-10-27" } ])

- POST /api/projects/abcd-1234/members  (body: { "userId":"u-1", "role":"Developer" })
  - 201 Created -> ApiResponse.success("Member added", null)
  - 409 Conflict -> ApiResponse.fail("User is already a member of the project")

- PATCH /api/projects/abcd-1234/members/u-1  (body: { "role":"Lead" })
  - 200 OK -> ApiResponse.success("Member updated", null)
  - 404 Not Found -> ApiResponse.fail("Member not found")

- DELETE /api/projects/abcd-1234/members/u-1
  - 200 OK -> ApiResponse.success("Member removed", null)
  - 404 Not Found -> ApiResponse.fail("Member not found")

If you want:
- I can change addMember to reactivate an existing inactive row instead of inserting a duplicate.
- Add unit/integration tests for controller/service.
- Provide sample curl/postman examples or add OpenAPI annotations.

Next step? (pick one)
- I’ll implement automatic reactivation on add if you prefer.
- Or I’ll add tests and example requests.

프로젝트 팀 구성원 API 명세서

구성원 목록 조회	GET	/api/projects/{projectId}/members	Path: projectId	200 OK	활성(is_active=1) 구성원 목록 조회. tb_user 조인하여 이름, 이메일, 부서, 역할, 프로필 등 반환
구성원 추가	POST	/api/projects/{projectId}/members	Body:{ "userId": "...", "role": "...", "assignedDate": "YYYY-MM-DD" }	201 Created409 Conflict400 Bad Request	구성원 추가. 이미 존재 시 409 반환, FK 오류 시 400 반환
구성원 수정	PATCH	/api/projects/{projectId}/members/{userId}	Body:{ "role": "...", "isActive": 0 or 1, "assignedDate": "YYYY-MM-DD" }	200 OK404 Not Found	역할, 참여일자, 활성 여부 수정. 존재하지 않으면 404
구성원 삭제 (비활성화)	DELETE	/api/projects/{projectId}/members/{userId}	Path: projectId, userId	200 OK404 Not Found	실제 삭제 대신 is_active = 0 으로 처리 (소프트 삭제)

이제 이 api를 가지고 프론트에 연결할거야 cursor에게 요청할 프롬프트 만들어줘 프로젝트 목록 > 프로젝트 상세보기 > 참여인원 (수정 버튼 ) > 프로젝트 팀 구성원 다이얼로그 추가 버튼 - 생성 api 연결 추가된 멤버 수정 버튼 - 수정 api 연결 제거 버튼 - 제거 api 연결 카드 멤버 - 조회 api 연결

프로젝트 상세 페이지의 "참여 인원(Team Members)" 섹션에 다음 API를 연동해줘.

백엔드 API 엔드포인트 (이미 구현 완료):
- GET    /api/projects/{projectId}/members
- POST   /api/projects/{projectId}/members
- PATCH  /api/projects/{projectId}/members/{userId}
- DELETE /api/projects/{projectId}/members/{userId}

요구사항:

1️⃣ **멤버 목록 조회 (카드 렌더링용)**
- 프로젝트 상세 페이지 진입 시 자동 호출.
- Axios GET 요청 → 응답 data를 상태로 관리 (예: `members`, `setMembers`).
- 각 카드에는 이름, 역할, 부서, 이메일, 아바타, 참여일자 표시.
- API 응답: ApiResponse.success("ok", [ {userId, name, role, ...} ])

2️⃣ **추가 버튼 (다이얼로그 내에서 호출)**
- 다이얼로그에서 userId, role, assignedDate 입력 후 "추가" 버튼 클릭 시 POST 요청.
- 요청 바디: `{ userId, role, assignedDate }`
- 성공 시 다이얼로그 닫고, 목록 새로고침 (GET 다시 호출).
- 실패 시 alert로 에러 메시지 출력 (409 또는 400 처리).

3️⃣ **수정 버튼 (다이얼로그 내 기존 멤버 수정)**
- 수정 대상 멤버 선택 후 PATCH 요청.
- 요청 URL: `/api/projects/{projectId}/members/{userId}`
- 요청 바디: `{ role, isActive, assignedDate }`
- 성공 시 목록 갱신.

4️⃣ **제거 버튼 (비활성 처리)**
- 목록의 각 멤버 카드에서 “제거” 클릭 시 DELETE 요청.
- 성공 시 목록 갱신 (GET 다시 호출).
- 삭제 전 confirm 창 표시 (“이 멤버를 제거하시겠습니까?”).

5️⃣ **UI 연동**
- 상위 페이지: `ProjectDetailPage.tsx`
- 참여인원 카드 컴포넌트: `ProjectMembersCard.tsx`
- 추가/수정 다이얼로그: `ProjectMemberDialog.tsx`
- API 호출 로직: `projectMemberService.ts` 파일로 분리해서 axios 함수 정리
  ```ts
  export const projectMemberService = {
    list: (projectId) => apiClient.get(`/api/projects/${projectId}/members`),
    add: (projectId, data) => apiClient.post(`/api/projects/${projectId}/members`, data),
    update: (projectId, userId, data) => apiClient.patch(`/api/projects/${projectId}/members/${userId}`, data),
    remove: (projectId, userId) => apiClient.delete(`/api/projects/${projectId}/members/${userId}`)
  }

프론트 페이지 리팩토링

noeyodeeeeeel — Mon, 27 Oct 2025 10:58:52 +0900

GPT 5 에게 프롬프트 생성 요청

" CURSOR에게 요청할 프롬프트를 만들거야 REACT 로 만들어져있는 프로그램인데 한 페이지의 .TSX 코드길이가 너무 길어져서 이걸 나누려고 해 코드를 삭제하기 전에 이유를 설명하고 내 동의 후에 진행시켜줘 "


이 파일은 React + TypeScript (.tsx)로 작성된 페이지입니다.
현재 한 파일의 코드 길이가 너무 길어져서 유지보수가 어렵습니다.

1. 코드를 역할별로 적절히 분리해 주세요.
   - UI 컴포넌트, 훅, 유틸, 상수, 스타일 등을 별도 파일로 나누세요.
   - 파일 분리 시 import/export 구조를 자동으로 맞춰주세요.

2. 불필요한 코드(사용되지 않는 변수, import, console.log 등)는
   제거하기 전에 "이 코드를 삭제해도 되는 이유"를 반드시 설명하고
   내 허락을 받은 뒤 삭제 제안을 해주세요.

3. 리팩터링 후 구조를 명확히 설명해 주세요.
   - 어떤 컴포넌트로 분리했는지
   - 각 컴포넌트가 어떤 역할을 하는지
   - 삭제하거나 변경한 이유를 함께 적어주세요.

4. 코드 스타일은 현재 프로젝트 규칙(ESLint/Prettier)에 맞게 유지해주세요.

CURSOR

src/
├── types/
│   └── weeklyReports.ts          # 타입 정의들
├── constants/
│   └── weeklyReports.ts          # 상수 및 Mock 데이터
├── utils/
│   └── weeklyReports.ts          # 유틸리티 함수들
├── hooks/
│   ├── useWeeklyReports.ts       # 주간보고서 관련 훅들
│   └── useMeetingMinutes.ts     # 회의록 관련 훅
├── components/
│   ├── weeklyReports/
│   │   ├── MyTasksSummary.tsx           # 내 업무 요약 테이블
│   │   ├── MyPlanTable.tsx              # 내 업무 계획 테이블
│   │   ├── WeeklyReportsTable.tsx       # 주간 보고서 테이블
│   │   ├── MeetingMinutesSection.tsx    # 회의록 섹션
│   │   ├── AddMeetingDialog.tsx         # 회의록 추가 다이얼로그
│   │   ├── AddTaskDialog.tsx            # 업무 추가 다이얼로그
│   │   └── TaskDetailDialog.tsx        # 업무 상세보기 다이얼로그
│   └── WeeklyReportsPage.tsx            # 메인 컴포넌트 (300줄로 축소!)

*** 리팩토링 후 서버 돌려봤더니
import 경로 문제 발생

해결

Copilot으로 만드는 댓글 관리 API

noeyodeeeeeel — Mon, 20 Oct 2025 17:34:41 +0900

Copilot을 이용하여 댓글 CRUD 구현함.

GPT에게 Copilot에 넣을 프롬프트를 요청함.
요청 내용은 “댓글(Comment)에 대한 CRUD API를 만들기 위한 프롬프트 생성”이었음.
아래는 GPT가 만들어준 프롬프트 원문임.

게시판 또는 프로젝트 관리 시스템에서 댓글(Comment)을 생성, 조회, 수정, 삭제할 수 있는 CRUD REST API를 만들어줘.

요구사항은 다음과 같음:

1️⃣ 각 댓글(Comment)은 다음 필드를 가짐.
- id (UUID)
- task_id (UUID, tb_task의 FK)
- author_id (UUID, tb_user의 FK)
- content (text)
- created_at (timestamp)
- updated_at (timestamp)

2️⃣ Spring Boot(Java)로 Controller, Service, Repository 계층 구조를 사용해 작성할 것.

3️⃣ 아래의 API 엔드포인트를 포함할 것:
- POST /api/comments (댓글 생성)
- GET /api/comments?task_id=... (특정 업무의 댓글 목록 조회)
- PATCH /api/comments/{id} (댓글 수정)
- DELETE /api/comments/{id} (댓글 삭제)

4️⃣ 입력 검증(Validation)을 적용할 것.
- content는 비어 있을 수 없음.
- task_id, author_id는 필수임.

5️⃣ 응답은 ApiResponse(success, message, data) 형태로 반환할 것.

6️⃣ RESTful 네이밍 규칙과 HTTP 상태코드를 준수할 것.

이 프롬프트를 Copilot에 그대로 입력함.
Copilot이 자동으로 CommentController, CommentService, CommentRepository, DTO 구조를 생성함.
전체적인 구조는 아래와 같음.

src/
 ├─ controller/
 │   └─ CommentController.java
 ├─ service/
 │   └─ CommentService.java
 ├─ repository/
 │   └─ CommentRepository.java
 ├─ dto/
 │   ├─ CommentCreateRequest.java
 │   ├─ CommentUpdateRequest.java
 │   └─ CommentResponse.java
 ├─ common/
 │   └─ ApiResponse.java
 └─ config/
     └─ SwaggerConfig.java

API 명세서

기능	메서드	엔드포인트	설명
댓글 생성	POST	/api/comments	새로운 댓글 등록
댓글 목록 조회	GET	/api/comments?task_id=...	특정 업무의 댓글 리스트 조회
댓글 수정	PATCH	/api/comments/{id}	댓글 내용 수정
댓글 삭제	DELETE	/api/comments/{id}	댓글 삭제

결과물 기록

이후에 Copilot이 생성한 실제 코드와 Swagger 문서 캡처를 아래에 추가할 예정임.
오늘의 포인트는 GPT를 통해 프롬프트를 설계하고 Copilot으로 CRUD 구조를 자동 생성한 것임.

백엔드(copilot) 을 사용한 후 프론트엔드 (cusor) 로 연결

noeyodeeeeeel — Mon, 20 Oct 2025 17:04:38 +0900

- ask모드로 파일구조 파악후, 어떻게 연결할지 코드와 설명을 듣기

백엔드-프론트엔드 연결 방안
백엔드 API 엔드포인트들
GET /api/projects - 프로젝트 목록 조회 (필터링, 페이징 지원)
GET /api/projects/{id} - 프로젝트 상세 조회
POST /api/projects - 프로젝트 생성
PATCH /api/projects/{id} - 프로젝트 수정
DELETE /api/projects/{id} - 프로젝트 삭제
️ 연결을 위한 작업
프로젝트 서비스 파일 생성 (src/services/projectService.ts)
프로젝트 타입 정의 (src/types/project.ts)
기존 ProjectsPage 수정 (API 연동)
다음과 같이 파일들을 생성/수정하면 됩니다:
1. 프로젝트 타입 정의 (src/types/project.ts)
2. 프로젝트 서비스 (src/services/projectService.ts)

2. ask모드로 설명듣고, Agent모드로 파일 생성 및 수정 진행

✅ 완료된 작업 요약
생성된 파일들
src/types/project.ts - 프로젝트 관련 TypeScript 타입 정의
src/services/projectService.ts - 백엔드 API와 통신하는 서비스 함수들
src/data/projectInsertStatements.sql - 초기 프로젝트 데이터 SQL
수정된 파일들
src/types/api.ts - 프로젝트 API 응답 타입 추가
src/components/ProjectsPage.tsx - API 연동으로 완전히 재작성
src/components/ProjectsList.tsx - 새로운 API 타입에 맞게 수정
구현된 기능들
프론트엔드 기능
✅ 프로젝트 목록 조회 (실시간 API 연동)
✅ 프로젝트 생성 (백엔드 API 호출)
✅ 프로젝트 수정 (백엔드 API 호출)
✅ 프로젝트 삭제 (백엔드 API 호출)
✅ 로딩 상태 표시
✅ 에러 처리 및 사용자 피드백
✅ 상태별 필터링 (계획, 진행, 완료, 지연, 보류, 취소)
✅ 클라이언트별 필터링
백엔드 연동
✅ /api/projects GET - 프로젝트 목록 조회
✅ /api/projects/{id} GET - 프로젝트 상세 조회
✅ /api/projects POST - 프로젝트 생성
✅ /api/projects/{id} PATCH - 프로젝트 수정
✅ /api/projects/{id} DELETE - 프로젝트 삭제
다음 단계
이제 실제로 테스트해볼 수 있습니다:
백엔드 서버 실행: cd ../ai.managing && mvn spring-boot:run
프론트엔드 서버 실행: npm run dev
브라우저에서 확인: http://localhost:3000
프로젝트 관리 페이지에서 실제 데이터베이스의 프로젝트들을 확인하고 관리할 수 있게 되었습니다!

전자정부 프레임워크 4.3.0과 copilot 같이 쓰기

noeyodeeeeeel — Thu, 16 Oct 2025 17:13:29 +0900

1. 프론트는 figma make로 만든 상태 react bite 형태로 빌드하고 cusor에 프론트 실행

2. 백엔드랑 프론트 합친 프로젝트 만들어서 깃에도 올리고 프로젝트 시작

3. 백엔드 개발 시작

지금 까지는 이상태

내가 담당한 projects 부분 시작

GPT로 프론트, 기술스택, 개발환경, 데이터베이스 설명하고 api명세서 뽑음

INFINITUM 프로젝트 관리 시스템 — Projects API 명세서

(실제 MariaDB 테이블 projects 기준)

✅ 공통 정보

Base URL: /api/projects
데이터베이스 테이블: projects
Primary Key: id (char(36))
기본 정렬 기준: created_at DESC

1️⃣ 프로젝트 목록 조회

GET /api/projects

설명

전체 프로젝트 목록을 조회합니다.

상태, 우선순위, 기간 등의 필터링 및 정렬을 지원합니다.

Query Parameters

이름 타입 설명 예시

status	string	상태 필터 (planned, in-progress, completed, delayed, on-hold, cancelled)	in-progress
priority	string	우선순위 (low, medium, high, urgent)	high
search	string	프로젝트명 또는 고객명 검색	디지털
page	int	페이지 번호	1
limit	int	페이지 크기	10
sort_by	string	정렬 기준 (created_at, start_date, progress)	start_date
order	string	정렬 순서 (asc, desc)	desc

✅ Response (200)

{
  "success": true,
  "data": [
    {
      "id": "a91b5a02-8fa6-4c7a-8b24-f3174adf2ab3",
      "name": "디지털 지갑",
      "description": "정부24 디지털 지갑 서비스 구축",
      "start_date": "2024-01-15",
      "end_date": "2024-03-30",
      "status": "in-progress",
      "progress": 65,
      "priority": "high",
      "budget": 100000000,
      "actual_cost": 65000000,
      "project_manager_id": "user-001",
      "client_name": "정부24",
      "created_by": "user-admin",
      "created_at": "2024-01-01T09:00:00Z",
      "updated_at": "2024-03-15T10:00:00Z"
    }
  ],
  "pagination": {
    "page": 1,
    "limit": 10,
    "total": 20
  }
}

조회만 보자면 이렇게 나옴

주간보고 페이지 수정

noeyodeeeeeel — Tue, 14 Oct 2025 10:09:02 +0900

주간보고 탭 수정

처음에 공통 프롬프트를 입력했을 때 결과물이 이렇게 나왓다

일단 내가 넣고 싶은 내용으로 수정하기

여기에서 나온 프롬프트

'주간보고 페이지'를 만들어줘.
디자인과 폰트는 현재 지정된 스타일을 그대로 유지해줘.

페이지는 상단부터 아래 순서로 구성되게 해줘:

---

### 1️⃣ 주간 회의 요약 섹션
- 제목: "주간회의록 (날짜)"
- 회의일자, 작성자, 참석자 정보를 한 줄에 배치할 수 있는 영역
- 예시: [회의일자: 2025.08.18] [작성자: 김효민] [참석자: 이도연, 남가현, 임의빈, 황두환]

---

### 2️⃣ 개별 회의록 본문
- 제목: “YYYYMMDD 주간업무보고”
- 문서 박스 형태로 구성 (회색 테두리, 내부 여백 있음)
- 각 항목은 번호로 구분된 리스트 형태로 정리
  예시 구조:
  1. 진료내역확인시스템
     - 전반사항 인수인계 완료
     - 일정 체크 및 코드 분석 정리 중
  2. CBT
     - 내부 완료 예정: 8월 31일
     - 개발물 전달일: 8월 20일 & 테스트 예정
  3. 사내 서버 진단도구 완료
  4. 진행 사업별로 차주부터 별도 진행
  5. 상용 소프트웨어 현안 및 정책 체크

---

### 3️⃣ 관련 업무 요약 섹션
- 제목: "관련 업무 요약"
- 표 형태로 구성하고 다음 컬럼을 넣어줘:
  | 담당자 | 관련 프로젝트 | 진행상태 | 비고 |

---

### 4️⃣ 팀 전체 회의 목록
- 제목: "팀 전체 회의 목록"
- 표 또는 카드 리스트 형태로 구성
- 각 행(또는 카드)에는 아래 정보가 포함되게 해줘:
  - 회의일자
  - 제목 (예: 8.18 주간업무보고)
  - 주요 안건 요약 (예: CBT 완료, 진료내역시스템 인수인계 등)
  - 작성자
  - ‘자세히 보기’ 버튼 또는 아이콘 (클릭 시 해당 회의록 상세로 이동하는 구조)

---

### 5️⃣ 하단 요약 정보
- 전체 회의 수, 이번 주 작성된 회의록 수, 미작성 인원 수 등을 보여주는 간단한 요약 영역을 추가해줘.
- 요약은 작은 박스 형태로 나란히 배치 (예: 이번주 회의 3건 / 작성자 5명 / 미작성 2명)

---

전체 레이아웃은 현재 페이지 디자인 흐름과 동일하게,
한 페이지 안에서 스크롤로 회의록과 목록을 모두 확인할 수 있도록 만들어줘.
불필요한 색상 변경이나 폰트 변경은 하지 말고,
지금 지정된 스타일 안에서 정보 구조만 설계해줘.

- 전체 주간업무 요약 추가하기

before

현재 디자인 스타일과 폰트는 그대로 유지하고,
‘주간보고 페이지’에 아래의 새로운 섹션을 추가해줘.

---

### [전체 구성]
주간보고 페이지는 기존처럼
1) 이번주 업무 요약
2) 팀 전체 회의 목록
3) 하단 통계
를 그대로 유지하고,
그 아래에 새로 “팀 전체 업무 계획 테이블” 섹션을 추가해줘.

---

### ️ [팀 전체 업무 계획 테이블]
제목: “팀 전체 업무 계획 요약 (전주 계획 / 전주 달성 / 금주 계획)”

테이블 형태로 구성하고, 다음 컬럼을 포함해줘:

| 담당자 | 전주 계획 | 전주 달성 (YYYY.MM.DD ~ YYYY.MM.DD) | 금주 계획 (YYYY.MM.DD ~ YYYY.MM.DD) |

각 컬럼별 내용 예시는 다음과 같아:
- **전주 계획:** 전주 주간보고에 작성된 예정 업무 내용 (예: DB 이관 로그 정리, 차세대 관련 데이터 정비)
- **전주 달성:** 실제 완료된 내용 요약 (예: DB 이관 완료, 장애 매뉴얼 작성)
- **금주 계획:** 이번 주 예정 업무 (예: 월간 단위 정기점검, 이미지 리사이징 수정)

각 셀 안의 내용은 텍스트가 여러 줄로 표시될 수 있게 하고,
텍스트가 많을 경우 자동 줄바꿈되게 구성해줘.

---

### [디자인 구조]
- 각 담당자별 행(Row)을 하나의 구분선으로 나누고,
  전주계획 → 전주달성 → 금주계획을 좌→우로 배치.
- 표 상단에는 날짜 범위 표기 (예: 2025.09.29 ~ 2025.10.10)
- 표는 회색 테두리와 가는 구분선으로 정돈.
- 텍스트 정렬은 왼쪽 정렬, 행 간 간격은 넉넉히 띄워서 가독성 좋게.

---

### [통합 구조]
주간보고 페이지 전체 구조는 다음 순서로 구성해줘:

1. 이번주 업무 요약
2. 팀 전체 회의 목록
3. 하단 통계 (이번주 회의 / 작성자 / 미작성자)
4. **팀 전체 업무 계획 요약 테이블 (전주 계획, 전주 달성, 금주 계획)**

페이지는 세로 스크롤로 이어지게 구성하고,
섹션 간 여백은 충분히 확보해서 구분이 명확하도록 해줘.

---

### [추가 조건]
- 폰트, 컬러, 버튼 스타일 등 기존 주간보고 페이지의 디자인 규칙을 변경하지 말 것.
- 테이블은 반응형으로 구성되어, 인원 수가 많아도 스크롤로 확인할 수 있도록 만들어줘.
- 상단 날짜 범위는 자동으로 이번 주 기준으로 업데이트될 수 있는 구조로 설계해줘.

이런것도 수정하는게 똑똑하다

업무관리 프로젝트 (Figma make)

noeyodeeeeeel — Mon, 13 Oct 2025 17:16:23 +0900

1. 템플릿으로 시작

2. 작성한 기능정의서와 CRUD를 바탕으로 ChatGPT가 프로프트를 정리함

공통 프롬프

Create a modern responsive web dashboard UI for an internal Project Management and Weekly Report System.
The system includes:
Login and Member Management
Admin can create, edit, and delete members
Fields: name, email, phone, password, role, join date, status
Project Management
Create, edit, and end projects
Manage project basic info: name, goal, period, status
Assign team members by role (backend, frontend, QA, designer, PM)
Comment and reply system
View projects in both Kanban and list modes
Manage TODO folders, progress tracking, and work hours
Weekly Dashboard
Weekly project summary
Previous week’s plan/result and this week’s plan
Work progress and effort tracking
Meeting notes section
Layout
Sidebar navigation: Members / Projects / Weekly Reports / Settings
Top bar: Search, User info
Main area: Tables, modals for CRUD actions

  Page Structure (페이지 구성)

1️⃣ 회원 관리 (Member Management)
회원 목록 / 등록 / 수정 / 삭제
2️⃣ 프로젝트 관리 (Project Management)
프로젝트 목록 / 생성 / 수정 / 종료
프로젝트 상세 보기
구성원 매핑 페이지 (역할 설정)
TODO / 폴더 관리 페이지
칸반보드 / 일반보드 보기 페이지
업무 진척도 / 공수 관리 페이지
3️⃣ 주간보고 대시보드 (Weekly Dashboard)
주간 업무 현황 대시보드
날짜별 업무 (전주 계획·달성 / 이번 주 계획)
업무 진척도 / 공수 시각화 페이지
회의록 관리 페이지
4️⃣ 기타 페이지 (Etc.)
로그인 / 회원가입 페이지
관리자 설정 페이지

3. 프로젝트 관리 상세페이지 추가

Create a responsive Project Management Detail Page for a web dashboard system.

When a user clicks on a project in the project list page, open a Project Detail Page like a board view.

The Project Detail Page should display:

Project name (프로젝트명)
Project goal (목표)
Project description (상세설명)
Project period (기간)
Project status (상태: 진행중, 계획중, 완료 등)
Progress bar (진행률)
Team members (참여 인원 수)

Below the project information, include a “Add Task (할 일 추가)” section.

Each task includes: task title (할 일), due period (기간), progress status (진행상태: 예정, 진행중, 완료).
Tasks should be displayed in a list or board format.

Add a comment feature (댓글 기능):

Users can write comments on the project itself.
Each task inside the project can also have its own comment thread.

Layout:

Top area: project title, goal, and progress bar
Middle area: task list with “Add Task” button
Bottom area: comment section for both project and each task

- Point to edit 기능으로 Figma make에서 직접 수정하기

- 수정할 부분 : 참여인원 클릭하면 참여인원 보기 , 할일 목록 보드형식 말고 게시판 형식으로 바꾸기, 진행률 수정,

- 알람 기능 삭제

- 참여인원 클릭하면 인원 확인할 수 있게

참여인원 클릭 기능 추가

CBT 튜토리얼 구현기 — 페이지 설계와 개선 과정

noeyodeeeeeel — Thu, 25 Sep 2025 16:57:24 +0900

1. 프로젝트 배경

CBT 시험을 보기 전 수험자가 실제 시험 환경을 경험해볼 수 있도록 튜토리얼 기능을 구현.
튜토리얼은 수험자가 기본 환경을 점검하고 시험 방식을 익힐 수 있도록 다음 단계로 구성.

튜토리얼

접수정보 확인 → 로그인 → 화면 조정 → 키보드 확인 → 마우스 확인 → 문항 형태 → 사용법 → 예제 풀이

→ 모의시험 풀어보기 페이지로 연결

2. 초기 설계 — JSP 페이지 분리

각 단계를 별도의 JSP 페이지로 나누어 구현함.

virtualTestStandby.jsp → 접수정보 확인
virtualTestLogin.jsp → 로그인 화면
tutoScreen.jsp → 화면 조정
tutoKeyboard.jsp → 키보드 확인
tutoMouse.jsp → 마우스 확인
tutoItemTp.jsp → 문항 형태 확인
tutoManual.jsp → 사용법 안내
tutoMockTest.jsp → 예제 풀이

컨트롤러에서 view 파라미터를 받아 각 JSP로 분기하는 구조를 사용함.

// Controller 일부
@RequestMapping("/page.do")
public Object tutorial(HttpServletRequest request,
                       HttpServletResponse response,
                       @RequestParam(value="view", required=false) String view,
                       CHashMap param,
                       BindingAwareModelMapEx model) {
    // 기본 페이지 설정
    String resolved = (view == null || view.trim().isEmpty()) ? "tutoScreen" : view.trim();

    // JSP 경로 매핑
    String jspPath = VIEW_TO_JSP.getOrDefault(resolved, "/tutorial/" + resolved);
    jspPath = this.pathInfo.getJspPath(jspPath);

    model.addJspJsonValue("contentPage", "tutorial/" + resolved);
    model.addJspJsonValue("currentView", resolved);

    return setData(request, param, model, jspPath);
}

단계별 역할을 명확히 구분할 수 있었음.
파일 이름만 봐도 화면 용도를 쉽게 파악할 수 있어, 다른 개발자가 보더라도 이해하기 편리했음.

3. 피드백 — JSP 통합 필요성, 확인값 저장 기능 추가

피드백 1 : 컨트롤러에서 분기하는 구조보다 JSP 자체를 합쳐서 step 전환으로 처리하는 것이 좋다
하나의 tutorial.jsp 안에서 화면 전환만 스크립트로 처리하는 것이 더 단순하고 효율적이다.

JSP 파일 수가 많아질수록 프로젝트 구조가 무거워짐
단순 안내 화면까지 모두 분리할 필요는 없음
유지보수 시 여러 파일을 동시에 열어야 해서 불편할 수 있음

피드백 2 : 사용자가 확인한 항목은 다시 반복해서 나오지 않도록 하는 것이 UX적으로 더 좋다

체크박스 값, 튜토리얼 확인값을 LocalStorage에 저장.
체크박스를 선택하지 않으면 다음단계로 넘어가지 않게 저장.
사용자가 이미 확인한 단계는 다시 보지 않아도 되므로 불필요한 반복을 줄임.

	$(document).ready(function() {

		j$(document).ready(function () {
		  const KEY = "checkboxChecked:tutoMouse";
		  const ctx = (j$.st.context || "");

		  // 체크박스 상태 복원
		  if (localStorage.getItem(KEY) === "true") {
		    j$("#mouse_Check").prop("checked", true);
		  }

		  // 체크박스 상태 저장
		  j$("#mouse_Check").on("change", function () {
		    if (j$(this).is(":checked")) localStorage.setItem(KEY, "true");
		    else localStorage.removeItem(KEY);
		  });

		  // 다음 버튼
		  j$("#btn_next").off("click").on("click", function (e) {
		    e.preventDefault();
		    if (!j$("#mouse_Check").is(":checked")) {
		      (j$.alert)('"PC 설정을 확인하였습니다(필수)" 체크해 주세요.');
		      return;
		    }
		    window.location.href = ctx + "page.do?view=tutoItemTp";
		  });
		});

	 // (마우스 체크 박스)메뉴 이동 제한
	  const MUST_CHECKED = new Set(["사용법", "예제 풀이", "문항 형태"]);
	  j$(".lnb_menu a").on("click", function (e) {
	    const text = j$(this).text().trim();
	    if (MUST_CHECKED.has(text)) {
	      const checked = localStorage.getItem("checkboxChecked:tutoMouse") === "true";
	      if (!checked) {
	        e.preventDefault();
	        (j$.alert)(`마우스 확인의 체크박스를 선택해야 '${text}' 메뉴로 이동할 수 있습니다.`);
	      }
	    }
	  });

4. 회고 — 설계 의도와 배운 점

처음에는 다른 개발자가 보았을 때 용도가 명확하고, 유지보수가 쉬운 구조를 만들고자 JSP를 단계별로 모두 분리했음.
이 접근은 직관적이었고, 화면 역할을 이해하기 쉽게 만드는 데 효과적이었음.

하지만 실제로 규모 있는 프로젝트에 적용하다 보니
프로젝트 무게나 성능, 유지보수 효율성을 고려하지 못했다는 것을 깨닫게 됨.
당시에는 기능을 충분히 수행하는 것에만 집중했으나
피드백을 통해 시스템 전체의 크기와 구조적 단순화까지 고려해야 한다 는 점을 배우는 계기가 되었음.

5. 마무리

프로젝트 구조를 어떻게 잡아야 하는가에 대해 생각해볼 수 있는 기회였음.

작은 단위로 쪼개는 것만이 항상 좋은 것은 아님
프로젝트의 규모, 무게, 유지보수성을 종합적으로 고려해야 함
협업 환경에서는 가독성과 단순화의 균형이 필요함

앞으로는 기능 구현뿐 아니라 전체 시스템 구조를 고려한 설계를 지향할 계획임.

 VIEW_WHITELIST = new HashSet<>();
        VIEW_WHITELIST.add("tutoScreen");
        VIEW_WHITELIST.add("tutoKeyboard");
        VIEW_WHITELIST.add("tutoMouse");
        VIEW_WHITELIST.add("tutoItemTp");
        VIEW_WHITELIST.add("tutoManual");
        VIEW_WHITELIST.add("tutoMockTest");
        VIEW_WHITELIST.add("mockTestPrac");

        VIEW_TO_JSP = new HashMap<>();
        VIEW_TO_JSP.put("tutoScreen"  , "/tutorial/tutoScreen");
        VIEW_TO_JSP.put("tutoKeyboard", "/tutorial/tutoKeyboard");
        VIEW_TO_JSP.put("tutoMouse"   , "/tutorial/tutoMouse");
        VIEW_TO_JSP.put("tutoItemTp"  , "/tutorial/tutoItemTp");
        VIEW_TO_JSP.put("tutoManual"  , "/tutorial/tutoManual");
        VIEW_TO_JSP.put("tutoMockTest", "/tutorial/tutoMockTest");
        VIEW_TO_JSP.put("mockTestPrac", "/tutorial/mockTestPrac");

 @RequestMapping("/page.do")
    public Object tutorial(HttpServletRequest request,
                           HttpServletResponse response,
                           @RequestParam(value="view", required=false) String view,
                           CHashMap param,
                           BindingAwareModelMapEx model) {

        // 좌석/로그인/상태 값 주입 제거
        request.setAttribute("layoutPage", this.pathInfo.getJspPath("/cbt/examne/index"));

        // 검증
        String resolved = (view == null || view.trim().isEmpty()) ? "tutoScreen" : view.trim();
        if (!VIEW_WHITELIST.contains(resolved)) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            String notFound = this.pathInfo.getJspPath("/error/404");
            return setData(request, param, model, notFound);
        }

        // JSP 경로 매핑
        String jspPath = VIEW_TO_JSP.getOrDefault(resolved, "/tutorial/" + resolved);
        jspPath = this.pathInfo.getJspPath(jspPath);

        model.addJspJsonValue("contentPage", "tutorial/" + resolved);
        model.addJspJsonValue("currentView", resolved);

        return setData(request, param, model, jspPath);
    }

4. 회고 — 설계 의도와 배운 점

처음에는 **“다른 개발자가 보았을 때 용도가 명확하고, 유지보수가 쉬운 구조”**를 만들고자 JSP를 단계별로 모두 분리했음.
이 접근은 직관적이었고, 화면 역할을 이해하기 쉽게 만드는 데 효과적이었음.

하지만 실제로 규모 있는 프로젝트에 적용하다 보니,
프로젝트 무게나 성능, 유지보수 효율성을 고려하지 못했다는 한계를 깨닫게 됨.
당시에는 “기능을 충분히 수행하는 것”에만 집중했으나,
피드백을 통해 **“시스템 전체의 크기와 구조적 단순화까지 고려해야 한다”**는 점을 배우는 계기가 되었음.

⚡ 트러블슈팅과 배운 점

1. 로그인 오류 문제

튜토리얼 개발 과정에서 로그인 오류 현상이 발생함.
처음에는 원인을 특정하기 어려웠으나, 사무실과 집을 오가며 개발 환경을 바꾸는 과정에서 IP 주소 설정이 달라졌던 점이 원인으로 판단됨.
결국 네트워크 환경에 따라 세션이나 접근 경로가 달라지면서 로그인 리다이렉트 오류가 발생한 것이었음.

2. Swiper 적용 과정

마지막 예제 풀이와 모의시험 페이지를 구현하면서 Swiper를 도입함.
처음에는 기본 설정만으로 슬라이드 이동을 구현했으나, 실제 사용 시 민감도가 높아 의도치 않은 슬라이드 전환이 자주 발생하는 문제가 있었음.

이를 해결하기 위해 Swiper 옵션을 조정하여 민감도를 낮추는 설정을 적용함.

const swiper = new Swiper('.swiper-container', {
  nextButton: '.question_next_btn',
  prevButton: '.question_prev_btn',
  threshold: 30,       // 터치 이동 최소 거리 (민감도 낮춤)
  touchRatio: 0.5,     // 슬라이드 전환 민감도 조정
  onSlideChangeEnd() {
    updatePager(swiper);
    syncTabs(swiper);
    restoreSelectedVisualForSlide(swiper.activeIndex);
  }
});

threshold: 30 → 손가락/마우스를 일정 거리 이상 움직여야만 슬라이드가 넘어감
touchRatio: 0.5 → 터치/드래그 민감도를 낮춰서 불필요한 전환 방지

이 설정을 통해 실제 시험 환경과 유사한 UX를 제공하면서도, 사용자의 실수로 인한 불편을 줄이는 방법을 배움.

3. 회고

로그인 오류를 통해 개발 환경(IP, 네트워크) 차이가 예상치 못한 문제를 유발할 수 있음을 경험함.
Swiper 적용 과정에서 단순 기능 사용을 넘어서, 옵션 조정을 통해 UX 품질을 개선하는 방법을 배움.