개발자는 어디까지 타협해야할까?

모든 개발자는 아마 유지보수가 용이하고 확장성 있는, 그리고 가독성까지 좋은 코드를 쓰려고 할 것이다.

예비 개발자인 나도, 위 사항에 대해 항상 철칙처럼 가지고 있어 매 상황마다 고려한다. 

하지만 그룹 프로젝트를 하면서 느낀 것은, 특히 내가 하고 있는 그룹 프로젝트는 프로젝트 기간이 굉장히 짧다.

 

평균 7일, 길다면 12일... 2주가 채 되지 않는다.

그런 상황에서 어쨌든 마감기한을 가지고 주요 기능을 개발해야하다 보니

마감기한을 지키려면 지금 코드보다 더 확장성 있고 클린한 코드로 리팩토링을 하지 못한 채 다음 기능으로 넘어가야 하는 상황  VS 그럼에도 불구하고 확장성있고 유지보수가 좋은 효율적인 코드로 리팩토링을 하고 다음 기능으로 넘어가다가 마감기한 내 주요 기능을 구현하는데에 어려움을 겪는 상황

을 겪게 된다.

 

이럴 땐 어떤 자세를 취해야할까? 개발자로서?

개발자는 어디까지 타협해야할까?

 

위 물음에 대해 지난 3개월 반동안의 부트캠프 생활을 하면서 답이 떠오르지 않았다.

하지만, 현재 최종 프로젝트를 하면서 더 극한의 상황 속(프로젝트 난이도가 높으면서 동시에 프로젝트 기한이 짧은)에서 최대한 빨리 MVP를 개발해야 하고 동시에 튜터님들께 코드리뷰를 받아야하는 상황 속에 있기에 조금씩 위 질문에 대한 답을 생각하기 시작했다.

 

물론, 정답은 아니다. 하지만, 누군가가 나에게 '개발자는 어디까지 타협해야할까?'라고 물어봤을때

현재 '나'의 대답은 이와 같다.

나는 개발자를 단거리 달리기 선수가 아닌, 장거리 마라톤 선수와 같다고 생각한다.

왜냐? 프로그래밍은 결국, 한번 개발이 완료되었다고 해서 그 코드로 쭉 가지 않기 때문이다.

유지보수는 필수이며, 숙명이며, 한 줄의 코드라도 한 번 적힌 이후에는 그 코드의 라이프 사이클은 언제나 유지보수되며 '수정'되는 사이클 안에 있다.

결국 개발자들은 '끊임없이' 더 나은 방법을 고민하며 보완하는 역할이라고 생각하기 때문이다.

 

따라서,  내가 생각하는 '개발자'들은 마감기한이 짧고 개발해야할 기능들이 많을 때 현재 주어진 상황에서 최소한의 유지보수가 가능하게까지만 개발을 하고 바로 다음 기능으로 넘어가야하지 않을까 싶다. 내가 개발자가 되면, 주로 팀 안에서 근무하게 될 텐데 어느 회사이든 마감기한은 있고 그 기한이 지켜지지 않는다면 클라이언트 입장에서 우리 팀을 고용할 이유가 없다. 

 

물론, 현재 나는 예비 개발자고 때론 기본적인 기능에도 시간을 많이 쓰게 되는 입장이겠지만 내가 나중에 경력이 쌓이고 어엿한 개발자로 커리어를 하고 있을 때에도 이 '밸런스'를 잡는 것에 대한 고민은 있을 걸로 생각한다.