빠른 개발은 무엇인가? 하면 좋은 건가?

Contents

요즘의 나는 "빠른 개발"을 하지 않는다가 목표이다.

사람들 마다 "빠른 개발"의 기준이 다를 것이다.

 

- 작업 속도가 빠르다는 것인가?

- release 속도가 빠르다는 것인가?

- 결정이 빠르다는 것인가?

- 업무 프로세스가 빠르다는 것인가?

 

머릿 속으로는 인지하고 있어도, 막상 작업을 위해서 키보드를 잡는 순간, "빠르게 작업해서 끝낸다"가 머릿속을 지배하는 것 같다.

성격의 영역일 수도 있고, 일정이 밀리는게 싫어서 이기도 하고, 나의 작업 때문에 다른 사람들한테 의존성이 걸리는 것이 싫어서 일 수도 있다.

 

내가 생각하는 "빠른 개발"을 하지 않는다는 "현재의 문제를 해결하기 위한, 가장 빠른 코드 수정 방법을 찾지 않는다"라는 뜻이다.

 

어느 조직이든, 기획은 바뀐다.

처음에 "절대" 바뀌지 않는다고 했던 기획도 바뀌고, 애초부터 "이건 변경될 가능성이 있어요" 라고 시작하는 경우도 있다.

 

문제는, 이 기획의 변경에 따라서 현재 상황에서 변경하는 방법이 있고, 제자리로 돌아가서 다시 쌓아오는 방식이 있을 수 있다.

당연하지만, 기획이 어떻게 변경되었냐에 따라서 다르다.

 

하지만, 초점을 맞추고 싶은 부분은, 

기능 변경에 따른, 혹은 기능 추가에 따른 코드 수정 시, 프로젝트의 구조가 변경되어야 하는 경우가 고려되었는가?가 중요한 것 같다.

즉, 기획이 변경됨에 따라서, 돌아가는 길이지만, 더 좋은 방법을 고민해봤는가?, 앞으로 변경될 수 있는 부분을 고려하면, 유지보수에 용이한 구조인가? 를 설계 해봐야 한다.

 

"할 수 있으니까" 라는 마인드로 접근 해버리면, 위에서 제시한 설계를 위한 질문들로부터 멀어지는 것 같다.

 

본인의 조직이 거대하고, 설계와 기획을 담당하는 사람이 따로 있다면, 사실 워터폴 방식으로 정해져서 내려올 가능성이 있다.

그러나, 소규모 조직이거나, 거대 조직에서도 스쿼드와 같이 서브 조직을 세분화하는 경우에는 의사결정에 모두가 참여할 가능성이 높다. 

그러다 보니, 더더욱 더 좋은 방향이 무엇인지 반드시 다같이 한번은 논의하고, 결정 후에 작업 방향을 선정해야한다.

 

예를 들면, 기존에는 실시간성을 지켜줬어야 하지만, 바뀐 기획에서는 필요 없다면, 더 단순한 구조를 만들어서 사용해도 되는 것이고, 그리고 이러한 설계는 서로 공유해서, 인지의 선을 맞춰나가야 하는 것 같다.

 

 

 

코멘트

나는 지금까지 "빨리 빨리"에 너무 빠져있었다. 여유를 가지자는 것이 아닌, 정말 "빨리 빨리" 작업 방식이 전체적으로 빠르게 만들었는가? 아니면 유지보수, 확장을 힘들게 했는가? 큰 고민을 가지게 만드는 것 같다.