POP - 성능 개선을 시도하는 프로젝트 (1)

프로젝트를 진행하는 의도

적어도 스스로를 속이지말자 !!!!!!!

언제나 의도와 목적을 가지고 프로젝트를 진행하자!!(🌟🌟🌟🌟🌟)

• 의도와 목적 :
  • 의도: 이 프로젝트를 통해 성능 개선 경험을 쌓고 싶다는 생각, 방향성
  • 목적: 실제로 달성하려는 구체적인 결과 ( 포폴? )
• 아는 척 하지말자 (모르면 확실히 하고 가자)
• 우리는 서비스가 완성이 된 회사에 갈 가능성이 많고, 그걸 유지보수하고 개선할 줄 아는 사람이어야 한다.
• 단순한 구현이 아닌 실제 운영/유지보수 상황에서 겪는 성능 이슈를 직접 마주하고 개선하는 경험
• 포트폴리오에 단순 기능 나열이 아닌 트러블슈팅, 문제 해결 중심 프로젝트로 어필
• 말 예쁘게 하는 습관 기르기(🌟🌟🌟🌟🌟)

---

👥 팀 구성

• 백엔드 1명 + 프론트엔드 1명
• 기술 스택: Java(Spring Boot) / React
• DB, Redis, Docker, CI/CD 등 실제 배포 환경 고려

---

🧭 프로젝트 진행 전략

1단계. 기능 우선 MVP 구현

• 도메인은 아직 미정 (쇼핑몰/예약 시스템/게시판 등 범용적인 구조) ->
• 전체 흐름을 빠르게 구현 → 전체 서비스 시나리오 경험
• 이 단계에선 성능보단 기능 완성이 우선  (그렇다고 성능을 아예 고려 안하는 기능 구현은 아님)

2단계. 의도적인 부하 발생

• 부하 테스트 도구(JMeter 등) 사용
• 병목, 느린 응답, 오류 등 유도 → 문제점 파악

3단계. 성능 개선 & 반복 최적화

• 백엔드/프론트 각자에서 개선 포인트 도출
  
  • 백엔드: DB 인덱스, 쿼리 최적화, 캐싱, 구조 리팩토링, 비동기 처리, 낙관적, 트랜지션 락
  • 프론트: 렌더링 최적화, lazy loading, chunking, 프론트도 비동기 처리
• 성능 개선 전후 비교 및 수치 기록
• 이 과정을 2~3번 반복 → 성장 곡선 강조

---

 내가 얻을 것

• 기획 → 구현 → 부하 → 트러블슈팅 → 개선이라는 실제 회사와 유사한 사이클 경험
• 단순 CRUD 포트폴리오와 차별화된 "문제 해결 중심 프로젝트"
• 문제 상황을 발견하고, 개선 방법을 제안하고, 직접 개선해본 경험
• 팀 협업에서 성능을 함께 고민하는 시선 확보

---

🙇‍♂️ 마무리

 

이번에도 프로젝트가 중간에 엎어졌다.
이유는 팀원 간의 갈등이었고, 그 갈등의 근본적인 원인은 결국 소통의 오류라고 생각한다.

개발이라는 건 혼자서도 충분히 할 수 있지만, 어찌 됐든 이 직무는 협업이 기본이 되는 일이다.
개인의 실력도 물론 중요하지만, 그 못지않게 팀원들과의 커뮤니케이션 능력 역시 굉장히 중요한 요소라는 걸 다시 한번 느꼈다.

 

이번 갈등의 중심에 내가 있었던 건 아니다.
하지만 그렇다고 해서 나에게 아무런 책임도 없는 건 아니었다.
내가 조금 더 신경 써서 중간에서 조율을 할 수도 있었으니까.그리고 이번 일을 겪으면서 나 스스로 조심해야겠다고 느낀 부분도 있었다.
나는 말을 조리 있게 잘하는 편이라고 생각한다.
그래서 누군가와 대화할 때, 내 논리를 차근차근 설명하고 나면 "자, 이제 네가 반응해봐" 같은 식으로 대화를 하는 경향이 있다.
내 의견은 전달했으니, 이제 네가 답할 차례라는 식이다.

이런 방식이 잘 맞는 사람들도 있었다. (T 성향이라 해야 하나...)

 

하지만 세상엔 다양한 사람이 있고, 내가 조금 더 유하게 말한다고 해서 내 의견이 약해지는 것도, 무시되는 것도 아니다.

앞으로는 말을 더 부드럽게 하면서도, 잘 전달되는 방식을 연습해야겠다고 생각했다.
같이 팀을 하고 있는 현우님이 INFP라고 하니까, 일단 이분에게 한 번 실험을... 아니, 연습을 해봐야겠다. 푸핫.

랜더스필드에 직관을 다녀왔어요 푸합