[Control Tower] 개발 효율은 AI로, 팀 성장은 믿음으로 (Cursor, DDD, Git 회고)

 

오늘은 멘토링, 팀 프로젝트, 기술 면접 준비까지 꽉 찬 하루였다. 단순히 코드를 짜는 행위를 넘어, 개발 효율을 극대화하는 방법과 팀원과 함께 성장하는 태도에 대해 깊이 고민했던 하루를 기록해본다.

1. 개발 효율과 아키텍처 (Cursor & DDD)

🤖 AI 활용: Cursor 공통 프롬프트 제작

팀원들 중 AI에게 질문하는 것(프롬프트 작성)을 어려워하는 분들이 있어, 제미나이(Gemini)와 대화하며 우리 프로젝트에 딱 맞는 'Cursor 공통 프롬프트'를 완성했다.

이 프롬프트를 팀에 공유하고 적용해보니, 요구사항 분석(Gap Analysis) → 백엔드 구현 → 프론트엔드 리팩토링으로 이어지는 흐름이 통일되면서 개발 능률이 눈에 띄게 높아졌다. 도구 하나만 잘 세팅해도 개발 경험(DX)이 달라진다.

[공유한 Cursor 프롬프트]

Markdown

# Role
너는 Java Spring Boot (DDD 아키텍처) 및 React 프론트엔드 풀스택 전문가야.

# Context
현재 나는 **[기능명]** 기능을 개발 중이야.
- Frontend: `@[프론트 파일명].jsx` (UI 구현 완료, 현재 Mock Data 사용 중)
- Backend: Entity 구현 완료 (`@[엔티티 파일명].java` 참조), 비즈니스 로직(Service/Controller) 부재.

# Task
1. Gap Analysis (선행 분석):
   - 프론트엔드 파일의 UI 데이터와 기존 Entity를 비교하여 부족한 필드/로직 리스트업.
2. Backend Implementation (Spring Boot):
   - DTO Strategy: `[도메인명]Dto` 클래스 내부에 static inner class로 요청/응답 객체 관리.
   - Service: Interface와 Impl 분리 구현.
3. Frontend Refactoring (React):
   - Mock Data 제거 및 axios/useEffect로 실제 API 연동.

# Output Process
1. [분석 결과] 2. [Backend Code] 3. [Frontend Code]

🏗️ DDD 구조의 난관: 직원 vs 관리자

도메인 주도 설계(DDD)를 적용하면서 가장 힘들었던 건 **'도메인 경계'**를 정하는 것이었다. 특히 직원과 관리자를 하나의 도메인으로 볼지, 분리할지가 큰 고민이었다.

깊은 공부 끝에 "Controller는 분리하되, 비즈니스 로직(Service)과 도메인(Entity)은 공유하거나 재사용"하는 형태로 구조를 잡았다. 역할에 따른 진입점(Controller)이 명확해지니 이후 로직 구현이 훨씬 수월해졌다.

[확정한 패키지 구조]

Plaintext

Attendance/
├── controller/
│   ├── AdminAttendanceController.java    (관리자용 API: 권한 체크 및 관리자 기능)
│   └── EmployeeAttendanceController.java (직원용 API: 본인 근태 처리)
├── service/
│   ├── AttendanceService.java            (핵심 비즈니스 로직 인터페이스)
│   └── AttendanceServiceImpl.java        (구현체: Repository 호출 및 데이터 가공)
├── domain/ (Entity)
│   └── Attendance.java                   (DB 테이블과 매핑되는 공통 엔티티)
├── repository/
│   └── AttendanceRepository.java         (JPA를 이용한 공통 DB 접근)
└── dto/
    └── AttendanceDto.java                (Inner Class 전략 사용)
        ├── AdminReq / AdminRes           (관리자용 DTO)
        └── EmployeeReq / EmployeeRes     (직원용 DTO)

---

2. 멘토링 회고: Git은 '선택'이 아니라 '기본'이다

오늘 멘토님과의 회의에서 뼈가 되고 살이 되는 피드백을 들었다.

"Git은 Java 문법을 알듯이, 개발자라면 숨 쉬듯이 기본으로 알고 있어야 합니다."

• 충돌(Conflict)은 친구다: 충돌이 났다고 무서워하지 말자. 혼자 해결해보는 경험이 쌓여야 내 것이 된다.
• 필수 키워드: gitflow, branch, workflow, stash
• 긴급 수정 대응: 개발 중 급한 요청이 오면? 당황하지 말고 git stash로 현재 작업을 저장하거나, workflow에 따라 새 브랜치를 따서 처리 후 복구하는 과정이 물 흐르듯 자연스러워야 한다.
• Graph: Git Graph가 지저분해지는 걸 두려워 말자. 깔끔하면 좋지만, 그것 때문에 주눅 들 필요는 없다.

---

3. 협업의 태도: '내가 다 해주기'를 멈추다

그동안 팀원들이 Git을 어려워하면 프로젝트가 꼬일까 봐 내가 도맡아서 해결해주곤 했다. 덕분에 나는 온갖 에러 상황을 겪으며 Git 마스터가 되었지만, 문득 "팀원들은 배울 기회를 뺏기고 있는 게 아닐까?"라는 생각이 들었다.

과거 '새미 프로젝트' 시절, 나 또한 실수투성이였지만 팀원들이 믿고 기다려준 덕분에 성장했던 기억이 났다. "이제 나도 팀원들을 믿어줘야겠다." 내가 다 해결해주는 게 효율적일진 몰라도, 팀원들이 직접 충돌을 겪고 해결하며 익숙해지도록 돕는 것이 진정한 리더십임을 깨달았다.

---

4. 면접 준비: 'Public'한 언어로 말하기

기술 면접 스터디로 **GC(Garbage Collection)**를 준비했다. 내용은 잘 알고 있다고 생각했는데 피드백을 통해 중요한 점을 배웠다.

• Public한 대답: 나만 아는 느낌적인 느낌이 아니라, 면접관(타인)이 들었을 때 오해 없는 '표준적이고 명확한 정의'를 사용해야 한다.
• 같이의 가치: 다른 팀원들의 답변을 들으니 내가 놓친 부분이 보였다. 혼자 하는 것보다 공부법을 공유하고 같이 준비하는 것이 훨씬 빠르고 정확하게 성장하는 길이다.