9장. 코드 리뷰보다 설계 리뷰가 중요하다①

팀 내 설계 공유와 피드백

AI가 코드 생성을 담당하는 시대가 되면서 개발팀의 리뷰 문화도 변화하고 있다. 과거에는 작성된 코드의 품질을 검토하는 것이 핵심이었다면, 이제는 그 코드가 왜 필요한지, 어떤 구조로 설계되었는지를 검토하는 것이 더 중요해졌다. 마치 건물을 짓기 전에 설계도면을 검토하는 것처럼, 코드를 작성하기 전에 설계를 검토하는 문화가 필요한 시점이다.

LMS(Learning Management System) 프로젝트를 예시로 생각해 보자. 5명으로 구성된 개발팀에서 각자 다른 기능을 담당한다고 가정하자. 처음에는 전통적인 방식으로 접근할 것이다. 각자 맡은 기능을 개발한 후 코드 리뷰를 통해 품질을 점검하는 방식이다.

프로젝트 초기에 이런 상황이 발생할 수 있다. 한 개발자는 강의 관리 모듈을, 다른 개발자는 수강생 관리 모듈을, 또 다른 개발자는 과제 관리 모듈을 각각 개발한다. 코드는 모두 깔끔하고 기능도 정상적으로 동작한다. 하지만 세 모듈을 통합하는 과정에서 문제가 드러날 것이다.

각자 다른 방식으로 사용자 인증을 처리하고 있고, 데이터 구조도 미묘하게 다르다. 강의와 과제를 연결하는 부분에서는 서로 다른 ID 체계를 사용해서 데이터 연동이 복잡해진다. 개별 코드는 완성했지만 전체 시스템의 일관성이 부족한 상태다.

이런 상황을 통해 코드 품질보다 설계 일관성이 더 중요하다는 것을 알 수 있다. 아무리 훌륭한 코드라도 전체 시스템의 맥락에서 벗어나면 오히려 복잡성을 증가시킨다. 각각의 나무는 건강하지만 숲 전체의 생태계는 불안정한 상태가 되는 것과 같다.

팀 내 설계 공유와 피드백

개발팀에서 설계 리뷰를 정기화하는 방법을 생각해 보자. 매주 금요일 오후 2시간을 설계 검토 시간으로 정하는 것이다. 각자가 담당한 모듈의 설계 의도와 구조를 다른 팀원들에게 설명하고 피드백을 받는 시간이다.

처음에는 이런 시간이 비효율적으로 느껴질 수 있다. 코딩할 시간에 회의를 하는 것 같다는 생각이 든다. 하지만 경험상 1, 2시간의 설계 논의가 나중에 며칠간의 수정 작업을 줄여주는 효과가 있다는 것을 여러 팀에서 확인할 수 있었다.

설계 리뷰에서 가장 중요한 것은 기술적 세부사항보다는 설계의 의도와 맥락을 공유하는 것이다. 왜 이런 구조를 선택했는지, 어떤 문제를 해결하려고 했는지, 다른 모듈과 어떻게 연결되는지를 설명하는 것이 핵심이다.

LMS 시스템에서 강의 관리 모듈을 담당한 개발자가 이런 방식으로 설계를 공유한다고 생각해 보자. "강의는 단순히 동영상 파일이 아니라 학습 경험의 단위입니다. 강의마다 학습 목표, 선수 지식, 예상 학습 시간, 난이도 등의 메타데이터가 필요합니다. 수강생이 강의를 선택할 때 이런 정보를 바탕으로 적절한 학습 경로를 제안할 수 있도록 설계했습니다."

이런 설명을 들으면 다른 팀원들도 자신의 모듈과 어떻게 연결되는지 이해할 수 있다. 과제 관리 모듈 담당자는 "그러면 과제도 강의의 학습 목표와 연결되어야겠네요. 과제 난이도를 강의 난이도와 매칭시키는 기능을 추가하면 어떨까요?"라는 피드백을 줄 수 있다.