이번 학기 회고: 기술, 테스트, 협업 그리고 깨달음

이번 달이 많이 남았지만, 큰 프로젝트가 마무리되었고 이번 학기가 끝을 향해 달려가는 것 같아 글을 남겨본다.
이번 학기와 이번 달에 느끼고 배운 점이 많았는데, 그중 인상 깊었던 부분 위주로 정리했다.

서비스의 주체가 누구인가

이번 학기의 캡스톤 경진대회 참가를 결정할 때,
"무엇을 만들고 싶은가?"보다는 "기술적으로 얼마나 배울 수 있는가?"에 초점을 맞췄던 것 같다.

그래서 프로젝트는 사용자 필요 충족보다는 내 기술 역량을 끌어올리는 데 집중했다.

최종적으로 완성된 산모 일기 프로젝트는 계획한 기능들을 모두 구현했고, 개인적으로 기술적 성취감도 얻었다.
하지만 심사위원들의 평가는 냉정했다.

"구현된 기능이 정말 산모에게 정서적 안정감과 유대감을 제공할 수 있나요?"

돌이켜 보면, 캐릭터 생성/상호작용, 일기 감정 분석 같은 기능은 잘 동작했지만
정작 서비스의 본래 목적과 실제 필요는 놓쳤던 것 같다.

Spring Boot, AI 기술, Typescript, React 같은 새로운 기술을 배우는 데 많은 에너지를 쏟느라
정작 서비스 설계의 본질적인 고민을 충분히 하지 못했다.

👉 이번 경험을 통해, 기술 그 자체보다도
**"누구를 위해, 어떤 가치를 제공할 것인가?"**가 더 중요하다는 사실을 깨달았다.
앞으로는 반드시 사용자 경험과 필요성을 먼저 고민하며 설계해야 한다.

테스트 코드 작성에 익숙하지 않았고, 학교 수업에서도 개발 방법론을 깊게 다루지 않아
테스트 작성은 거의 비어 있었다.

중간 발표에 맞춰 급하게 기능을 맞추느라 코드가 누더기처럼 이어졌고,
버그투성이 상태로 발표를 했다.

최종 발표 전까지 계속 고치고 또 고쳤지만,
테스트 코드의 부재로 인한 지옥을 피할 수 없었다.

Docker로 서비스가 분리돼 있어서 문제 지점을 찾는 속도는 빠른 편이었지만,
테스트가 없으니 고치고 나면 또 다른 문제가 계속 생겼다.

이런 문제들은 전부 테스트 코드로 미리 잡을 수 있었던 부분이었다.

👉 결론: 테스트 없는 개발은 빨라 보이지만, 결국 훨씬 느린 길이다.
앞으로는 기능 구현과 동시에 테스트 코드를 작성해, 버그를 사전에 방지하겠다.

이번 프로젝트에서 git과 Docker를 도입했는데,
솔직히 말하면 내가 쓰고 싶었던 기술을 무리하게 적용한 부분이 있었다.

git을 처음 쓰는 팀원은 어려움과 부담을 느꼈지만,
나는 일정에 쫓겨 충분히 설명하거나 장점을 설득하지 못했다.

결국 그 팀원은 zip 파일로 코드 전달이라는 방식에 의존했고,
협업 효율과 생산성은 당연히 떨어졌다.

👉 깨달은 점: 새로운 도구나 기술을 도입할 때는
팀원이 부담 없이 접근할 수 있도록 설명과 합의 과정이 필요하다.
그 과정을 건너뛰면 팀워크 자체가 무너진다.

이번 학기 동안 부족함을 너무 많이 느꼈고, 갈 길이 멀다고 생각했다.
너무 늦게 시작한 건 아닐까 하는 생각도 들었지만,
이미 지난 시간을 후회하기보다는 앞으로 최선을 다하려 한다.