부트캠프 최종 피드백 - 이력서와 프로젝트를 다시 돌아보다
부트캠프가 마무리 단계에 접어들면서 이력서와 최종 프로젝트에 대한 피드백을 받을 기회가 있었다.
그동안은 "구현을 많이 하면 좋은 프로젝트"라고 생각했지만, 이번 피드백을 통해 기능의 개수보다 그것을 어떻게 구현했고, 어떤 고민과 과정을 거쳤는지가 더 중요하다는 사실을 다시 한번 느낄 수 있었다.
이번 글에서는 이력서와 프로젝트 측면에서 받은 피드백을 정리하고, 앞으로 어떤 방향으로 개선할 것인지 기록해보려 한다.
📄 이력서 피드백
1. 기술 스택은 '사용했다'가 아니라 '활용했다'를 보여주기
기존 이력서에는 Java, Spring Boot, React처럼 기술 스택 위주로 작성되어 있었다.
하지만 실제로 중요한 것은 어떤 기술을 어디에 활용했고, 어떤 결과를 만들었는지였다.
예를 들어
- Kafka를 이용한 실시간 이벤트 처리
- Redis Queue 기반 AGV Dispatch 구현
- WebSocket(STOMP, SockJS)을 활용한 실시간 관제 화면 구현
처럼 프로젝트 경험과 함께 기술을 설명해야 한다는 피드백을 받았다.
기술은 나열하는 것이 아니라 경험과 연결될 때 비로소 강점이 된다는 점을 배웠다.
2. 결과물을 직접 확인할 수 있도록 구성하기
면접관은 짧은 시간 안에 지원자를 파악해야 한다.
따라서 프로젝트 설명만 작성하는 것이 아니라
- GitHub Repository
- Velog 기술 블로그
- 프로젝트 시연 영상
등 직접 확인할 수 있는 결과물을 함께 제공해야 한다는 피드백을 받았다.
앞으로는 프로젝트 하나를 완료하면 구현에서 끝나는 것이 아니라, 코드와 문서를 함께 정리하여 누구나 쉽게 프로젝트를 이해할 수 있도록 구성할 계획이다.
3. 자기소개서는 경험을 중심으로 작성하기
"책임감이 있다", "협업을 잘한다"와 같은 표현은 누구나 사용할 수 있다.
대신 실제 프로젝트에서
- 어떤 문제를 만났는지
- 어떻게 해결했는지
- 무엇을 배웠는지
를 중심으로 작성해야 설득력이 높아진다는 점을 배웠다.
특히 최근 수행한 프로젝트 경험을 적극 활용하여 개발자로서의 성장 과정을 보여주는 것이 중요하다는 피드백을 받았다.
4. 최근 프로젝트 경험 적극 반영하기
최근까지 진행했던 AIMS 프로젝트에서는 단순히 화면을 구현하는 수준을 넘어 실제 제조 공정을 가정한 실시간 관제 기능을 개발하였다.
특히 내가 담당했던 AGV 실시간 연동 기능은 이력서에서도 충분히 강점으로 활용할 수 있는 경험이라는 피드백을 받았다.
🚗 최근 수행한 AGV 실시간 연동 기능
프로젝트 후반에는 제조 공정 간 AGV 이동을 실시간으로 표현하는 기능을 집중적으로 개발하였다.
초기에는 새로고침을 해야만 상태가 변경되는 방식이었지만, 이를 실시간 구조로 개선하기 위해 WebSocket 기반 통신 구조를 설계하였다.
* Spring Boot WebSocket(STOMP + SockJS)
* React
* Redis
* Kafka
를 함께 활용하였다.
Kafka에서 제조 이벤트를 수신하면 Redis Queue를 통해 AGV 이동 요청을 관리하고, 백엔드에서는 AGV의 이동·도착·복귀 상태를 순차적으로 처리하도록 구현하였다.
상태가 변경될 때마다 WebSocket을 통해 프론트엔드로 즉시 데이터를 전송하여 관제 화면에서 AGV의 이동 상태가 실시간으로 반영되도록 구성하였다.
개발 과정에서는 단순히 기능을 구현하는 것보다 운영 환경에서 발생하는 문제를 해결하는 데 많은 시간을 투자했다.
특히 EKS 환경에서 Backend Pod가 여러 개 실행되면서 Scheduler가 중복 실행되는 문제, Kafka Consumer Group의 Partition 할당 문제, Redis Queue 중복 처리 문제 등을 직접 분석하고 개선하였다.
이 과정을 통해 단순한 기능 구현을 넘어 멀티 인스턴스 환경에서 실시간 시스템을 안정적으로 운영하기 위한 동시성 제어와 메시지 처리 방식에 대해 많은 경험을 쌓을 수 있었다.
프로젝트 최종 단계에서는 제조 이벤트 발생부터 AGV 이동, 다음 공정 전달까지 하나의 흐름으로 연결되는 실시간 관제 기능을 완성할 수 있었다.
🚀 프로젝트 발표 피드백
1. 기능보다 개발 과정을 보여주기
발표 자료는 기능 소개보다
- 왜 만들었는지
- 어떻게 개발했는지
- 어떤 과정을 거쳤는지
를 중심으로 구성하는 것이 좋다는 피드백을 받았다.
특히 Sprint 단위의 개발 과정과 협업 흐름을 함께 보여주면 프로젝트의 완성도를 더욱 효과적으로 전달할 수 있다고 느꼈다.
2. 협업 과정도 프로젝트의 결과물이다
프로젝트는 단순히 기능만 구현한 것이 아니라 팀원들과 함께 계획하고 개선하는 과정이었다.
그래서 발표 자료에는
- Sprint 일정
- Redmine Gantt Chart
- 기능 개발 순서
- 역할 분담
등 협업 과정을 추가하여 프로젝트가 어떤 방식으로 진행되었는지 보여줄 예정이다.
3. Troubleshooting도 중요한 발표 내용
이번 프로젝트에서는 다양한 문제를 경험했다.
예를 들어
- WebSocket 실시간 반영 문제
- Kafka Consumer Group Partition 이슈
- Redis Queue 중복 처리
- Scheduler 동시 실행 문제
- Multi Pod 환경에서 발생한 동시성 문제
등을 직접 해결하면서 프로젝트를 완성했다.
기능 구현보다 이러한 문제를 어떤 방식으로 분석하고 해결했는지를 발표에 포함하는 것이 프로젝트의 깊이를 보여줄 수 있는 요소라는 점을 배웠다.
4. 발표 구성 개선
발표의 전체 흐름도 다음과 같이 수정하기로 했다.
- 프로젝트 목적
- 핵심 기능
- 시스템 아키텍처
- Sprint 기반 개발 과정
- 시연
- 기대 효과
- 향후 계획
또한 시연 영상도 발표 내용을 반복하는 것이 아니라, AI 분석 결과와 AGV 실시간 관제처럼 프로젝트의 핵심 기능을 중심으로 보여주는 방향으로 수정할 예정이다.
✨ 마무리
이번 피드백을 통해 가장 크게 느낀 점은 프로젝트는 기능을 많이 만드는 것이 아니라, 문제를 해결하며 완성해 나가는 과정 자체가 가장 큰 결과물이라는 것이다.
또한 이력서 역시 기술을 나열하는 문서가 아니라, 내가 어떤 기술을 선택했고 어떤 문제를 해결했으며 그 과정에서 어떻게 성장했는지를 보여주는 기록이라는 점을 다시 한번 깨달았다.
앞으로는 프로젝트를 구현하는 것에서 끝나지 않고, 개발 과정과 트러블슈팅, 그리고 그 과정에서 얻은 경험까지 꾸준히 기록하며 성장하는 개발자가 되고자 한다.
