역할 명시·수치 근거·갈등 조율 경험 중심으로 푸는 결
캡스톤 프로젝트에서 5인 팀으로 진행한 데이터 수집·분석 시스템 개발에서 40% 정도 기여했다고 봅니다. 기여도를 이렇게 추산하는 이유는 제가 담당한 범위 때문입니다. 저는 백엔드 `API` 설계와 `DB` 스키마 설계를 단독으로 맡았고, 프론트엔드팀과의 연결 작업도 중간에서 조율했습니다. 나머지 4명은 크롤러 개발 2명, 프론트 2명으로 나뉘어 역할이 분리됐습니다. 프로젝트 중반에 크롤러팀이 수집한 데이터 형식이 제가 짜둔 스키마와 맞지 않는 문제가 생겼습니다. 처음에는 서로 "자기 쪽 구조를 바꿔야 한다"는 의견이 엇갈렸는데, 두 쪽의 실제 수정 작업량을 비교해 비용이 적은 방향으로 내 스키마를 조정하자고 제안했습니다. 크롤러 코드는 그대로 두고 제가 스키마를 바꾸는 방향으로 합의했고, 이후로는 파이프라인이 막히는 일이 없었습니다. 최종 발표에서 데이터 정합성 오류 0건이라는 결과로 확인했습니다. 이 경험에서 기여도 숫자보다 역할을 명확히 가져가고 갈등 지점에서 조율하는 것이 팀 결과물 품질에 더 직접적으로 연결된다는 것을 배웠습니다.