오래된 프로젝트, 새로운 요구사항
현재 회사는 A 팀에서 수주된 프로젝트의 개발을 진행하고 안정화 기간을 거치면 B 팀으로 해당 프로젝트 인계된다. 그러다 인계된 프로젝트에서 계약을 동반하는 추가 개발 건이 발생하면, 다시 A 팀에서 해당 추가 개발 건의 개발을 진행하게 된다.
내가 맡은 파트에서 최근 앞서 이야기한 현재 회사의 프로세스상 B 팀에서 관리 중인 한 프로젝트의 추가 개발 건을 맡게 되었다. 여러 개의 요구사항 중 얼마 남지 않은 8월 말까지 임시 적으로나마 특정 Call Back 처리에 대해 분기 처리를 추가하는 작업이 필요했다.
프로젝트 분석과 첫 번째 고민 그리고 결정
하나 문제가 있다면, 해당 프로젝트는 3~4년 전쯤에 진행되었던 것으로 기본적인 프로세스 흐름이 현재 회사 코어 소스와 약간씩 다른 상태였으며 오랜 기간 동안 여러 사람의 손을 거치며 최근까지 해당 프로젝트를 담당하였던 담당자도 모르는 변경점이 존재하는 상태였다.
나는 천천히 추가 개발건에 대한 요구 사항을 분석하며, 코드를 읽어갔다. 그리고 얼마 지나지 않아 결정했다.
“추가 개발건에 대한 코드는 기존 Class가 아닌 신규 Class를 생성하여 작성해야겠다.”
이유는 단순했다.
- 기존에 얽히고설켜있는 코드를 100% 분석하기에는 개발을 할 수 있는 기한이 촉박했으며
- 현재 코드에 대한 분석을 완벽하게 하지 못한 상태에서 기존 로직을 건드리는 것에 대한 두려움
- 개발이 완료된 이후 다시 B 팀으로 인계되었을 때 해당 팀에서 인지하고 있는 기존 로직에 변경점이 생기는 것보다 신규 개발 건에 대한 코드는 새로운 Class에 작성되어 있는 것이 관리하기도 용이할 것이라는 생각이었다.
”~ 하시면 될 거 같은데요?”
이러한 생각을 혼자서 마무리하고, 오늘 해당 프로젝트의 담당자(앞서 말한 B 팀에 해당하는 팀원)과 기존 프로세스에 대한 질의응답 형식의 회의를 진행했다.
회의는 구체적인 안건 선정 없이 시작되었기에, 회의가 중구난방으로 진행되는 것을 막고자 현재 우리 파트가 진행하여야 하는 요구사항에 대한 간단한 설명과 내가 궁금한 점에 대해서 질문을 하였다.
그리고 얼마 시간이 지나지 않아 담당자가 말했다.
“OOO 서비스에서 OOO 변환하는 부분만 변경하시면 될 거 같은데요?”
머리가 띵했다.
회사 코드/프로세스이기에 구체적으로 서술하지는 못하지만, 워낙 레거시 한 코드 인지라 아주 많고 명확하지 않은(한눈에 읽히지 않는 의미를 알 수 없는’equals()‘의 향연 ) 조건절로 이루어진 수많은 분기 처리를 모두 건너뛰고 거의 맨 마지막 로직에서 특정 코드만 변경하면 될 것 같다는 의견이었다.
그리고 담당자는 이어서 말했다.
“이 부분만 변경하는 게 저희 팀에서도 다시 프로젝트 인계받아서 관리할 때 편할 거 같습니다."
"체스는 지난 500년 동안 변하지 않았다.”
담당자의 말을 들은 나는 한 번 더 머리가 띵했다. 그리고 문득 이전 ‘파이브 라인스 오브 코드’라는 책에서 읽었던 내용이 떠올랐다.
ㅤ
한번은 개발자와 체스를 구현하는 방법에 대해 논의한 적이 있습니다.
나는 그가 어떻게 할 것인지 물었습니다.
객체 지향 프로그래밍에 정통한 그는
”인터페이스와 클래스를 사용한다” 라고 답했습니다.
나는 “하드코딩하는 편이 더 쉽지 않을까요?”
라고 운을 뗐습니다.
그는 “물론이죠. 하지만 잘 유지 보수하시기 바랍니다.”
라고 말하면서 내가 농담을 한 것처럼 씩 웃었습니다.
”체스는 지난 500년 동안 변하지 않았습니다.”
내 말에 그의 눈이 커졌습니다.파이브 라인스 오브 코드 중.
그렇다. 이 프로젝트에 기존 존재하는 분기 처리는 처음 개발된 이후 지난 4년간 큰 변화가 없는 상태인 동시에 문제 또한 존재하지 않았다.
앞서 인용한 책의 일화가 독자에게 던지고자 하는 메시지는 절대 아니지만(위 내용은 그냥 문득 생각난 책의 한 구절일 뿐이다.), ‘코드가 잘 읽히지 않고, 객체 지향적으로 구성되어 있지 않고’ 는 어쩌면 누군가에게는 중요한 포인트가 아닐 것이다. 중요한 것은 ‘기존에 문제없던 프로세스가 앞으로도 문제가 없는 것.’
담당자의 조언대로 개발을 진행할 경우 촉박하게 느껴지던 마감 기한은 오히려 여유로워진다. 그렇지만 스스로 질문을 던졌을 때 ‘이건 절대 옳은 방식의 개발이 아니다.’ 라는 대답이 돌아왔다.
나는 회의가 끝나고 회의록을 작성하면서 나름 생각을 정리하고 이후 담당자의 조언대로 코드를 작성하고 커밋 했다.
하지만 퇴근 전까지 PR을 보내지는 못했다. 그리고 나는 지금 하루를 마무리하며 이렇게 글을 쓰고 있다.
하 .. 어렵다.