언젠가 그런 글을 보았다. '신입 개발자'이거나 '개발자를 지망하는 사람'들에게 하는 조언같은 글이었는데, 포트폴리오나 토이 프로젝트를 진행할 때 절대 풀사이클 개발을 하지 말라는 내용이었다. 이유를 요약해보면 아래와 같다.
- 여러 부분의 작업을 진행하다보면 어떤 문제에 봉착하게 된다.
- 문제를 해결하지 못할 확률이 높아 프로젝트가 흐지부지 끝날 수 있다.
- 그러므로 자신의 분야만으로 개발을 하거나 남들과 함께 만들어라.
풀사이클 개발이란? 개발팀이 우수한 생산성 도구를 활용하여 소프트웨어 개발 수명주기(디자인, 개발, 테스트, 배포, 운영, 지원) 전체를 처리하는 모델 #
위 조언에 대한 비판적 시각
자신의 경험을 토대로 무언가 조언을 해준다는 것은 훌륭한 일이라고 생각한다. 하지만 그 결론이 '하지말라'라는 내용으로 끝나다니, 자신이 어떤 방향으로 진행했고 왜 실패했는지 성찰하여 더 나은 방향으로 나아갈 수 있도록 조언을 하는게 바람직하지 않을까 싶다.
나는 반대로 개발을 지망하는 사람이거나 신입 개발자 일수록 풀사이클 개발을 접해봐야 한다고 생각한다. 개발자를 지망하는 사람이라면 자신이 어떤 분야를 좋아하는지 알아가는 시간이 될 수 있을 것이고, 연차가 높지 않은 신입 개발자라면 지금이 적정기이자 마지노선이다!
왜냐고? 신입 개발자는 하얀 도화지이다. 이 도화지에 멋지든 후지든 붓을 대고 그림을 그려봐야 하는데, 회사에서 점차 연차가 쌓일수록 다른 분야에 대한 기준과 지식이 점차 생겨나기 시작하면서 도화지에 어떻게 멋진 그림을 그릴까 생각만 할 뿐 그림을 그리지 못하게 된다. 그럴수록 풀사이클 개발에 대해 더 높은 진입장벽(귀찮음)이 느껴지고 영영 하고 싶다는 느낌이 들지 않을 것이다. 아무것도 모를때 저지르자!
왜 이렇게까지 풀사이클 개발을 강조하냐고? 전체 프로젝트를 관리하고 만든다는 것은 매우 재밌고, 역량을 키우기 가장 좋은 방법인데 되려 나는 왜 하지 않는지 궁금하다. 그렇다고 강제하는 것은 아니다. 하지말라는 글이 있으니까 하라는 글도 하나 있어야 할 것 같아서 적어본다. 우선 위 조언에서 풀사이클 개발을 하지말라는 이유를 모두 없애보겠다.
문제에 봉착하게 된다?
어떤 프로젝트를 진행하건 언젠가는 문제에 봉착하게 된다. 내가 기획했던 모든 것들이 순조롭게 만들어질리가 없기 때문이다. 한 분야만 개발하는 경우에도 문제는 생긴다. 아마 글쓴이는 한 분야의 문제만 처리하기에도 버거울 텐데, 특히나 관련 지식이 전반적으로 낮은 개발자가 모든 범주의 문제를 해결하기에는 어려움이 많다는 것을 말하고 싶었던것 같다.
그래서 내가 생각하기에 여기서 매우 중요한 점은 자신의 가슴을 설레게하는 꿈이 있는 프로젝트여야 한다는 것이다. 내가 진정으로 만들고 싶었던, 내가 진심을 다해서 기획한 이 프로젝트에서 문제에 봉착한다면 지속적으로 동기부여가 된다. 그 문제를 해결하는 과정이 괴로워도 해결하기 위해 시간을 쏟게 된다. 그리고 그 문제가 해결되면 큰 성취감을 얻는다. 그렇게 한땀한땀 만들어지는 프로젝트를 보면 더 많은 애정과 동기가 생긴다.
아마 풀사이클 프로젝트가 흐지부지 끝났다면 주제에 큰 흥미가 없었다는 증거일 수 있다. 그렇다면 진지하게 주제를 고민해보는 시간을 가져보고 다시 한 번 도전해 보는 것은 어떨까?
진출하려는 분야만해라?
자신이 진출하려는 분야에 대한 전문성을 기르는 것은 좋다. 하지만 다른 분야를 전혀 모르는 상태로 과연 해당 분야에 전문성을 길러낼 수 있을까? 의구심이 생긴다.
백엔드와 프론트엔드 상에 통신이 이뤄지는 경우 문제가 발생했을때 어디에서 문제가 발생한 것인지 모른다면? 서버의 문제가 맞는데 클라이언트 문제라서 서버의 문제가 아니라고 생각할 수 있다. 그렇다면 프론트엔드와 백엔드 둘 다 시간을 낭비한다. 이게 전문가인가? 적어도 문제가 발생하면 어디서 발생한 문제인지 빠르게 캐치할 수 있어야 한다. 이는 생산성과도 직결되는 문제다.
다른 분야에 대한 기본적인 지식이 있고 흐름을 알아야 더 명확한 요구사항을 요청할 수 있다. 반대의 경우 수동적인 자세로 개발에 임하게 될 수 있음에 유의해야 한다. 수동적인 개발이 별다른 문제가 아니라고 생각할 수 있겠지만, 이 경우 잘못된 상황에 대한 의구심을 품지 못하게 될 수 있다.
한 분야만으로 프로젝트를 한다는 것은 그림으로 따지면 수묵화냐 수채화냐의 차이일거다. 한 분야만으로도 훌륭한 프로젝트는 나온다. 다만, 한 분야에 전문성이 높은 위대한 업적을 남긴 사람들은 다른 분야에 대해서도 통찰력이 높은 경우가 많다. 수묵화를 잘 그리는 사람은 수채화도 잘 그린다.
남들과 함께 만들어라?
글쎄... 내가 할 수 없어서 남들과 하는 것과, 높은 생산성을 위해서 남들과 함께 하는 것에는 차이가 많다. 남들과 함께 개발하는 것은 중요하다. 많은 곳에서 개발은 협업을 통해 이뤄지기 때문이다. 다만 서로 잘하는 분야에 집중하기 위해서가 아닌 내가 백엔드를 못하기 때문에, 혹은 프론트를 못하기 때문에 남들과 하는 것은 많은 문제를 야기시킬 수 있을 가능성이 높다.
대체적으로 프로젝트를 함께하는 사람들은 지식의 수준이 비슷할 것인데, 위에서 언급한 것처럼 각자의 분야에서 발생한 문제를 다른 문제로 오인하는 경우 서로의 시간을 낭비시킬 수 있는 여지가 많다. 뭐 그러면서 서로 발전하는거 아니겠냐고 반문한다면 할말은 없다...
풀사이클 개발의 장점
이제 하지 말아야 할 이유는 줄어 들었다. 이번엔 내가 생각하는 풀사이클 개발의 장점이다.
재밌다!
진짜 재밌다. 솔직히 말하면 풀사이클 개발을 하지 말라던 저 조언이 자신은 재미를 보고 남들에게는 이 재미를 못느끼게 하려는 음모가 아닌가 싶다. 나는 창작하는 것이 좋아서 이 분야에 흥미를 느꼈었고, 많은 사람들이 그럴것이라 생각한다.
내가 디자인하고, 내가 기획하고, 내가 만들고, 배포하고, 사람들이 써주고, 피드백으로 서비스를 개선하고, 개발이나 배포하면서 불편했던 요소를 개선하는, 이런 경험은 어디서나 쉽게 할 수 없는 경험이지 않은가? 심지어 회사에서도 저 모든 것을 경험하긴 어렵다. 그렇기에 풀사이클 프로젝트를 진행하며 높은 성취감을 얻을 수 있었고 그 순간들은 나에게 매우 즐거웠다.
모든게 내맘대로!
만약 자신이 전체적으로 프로젝트를 이끌어가는 경우 이 프로젝트에 뭔 짓을 해도 아무도 뭐라하는 사람이 없다. 파이썬을 쓰고 싶다? 쓰면된다. 리액트를 쓰고 싶다? 쓰면된다. 러스트를 써볼까? 문제없다. 오류가 나도, 느려져도, 아무도 뭐라하지 않는다. (물론 사용자가 있다면 ... 장인정신을 가지자!)
또한 신기술을 통해서 특정 부분을 개선해 볼 수도 있고, 서비스 유지비로 얇아져가는 내 지갑을 어떻게 하면 보호할 수 있을까 고민해보는 것도 매우 보람차다.
발전하는 자신!
프로젝트를 하며 얻어진 경험으로 다음 프로젝트에서 더 좋은 역량을 발휘할 수 있다. 더 높은 생산성을 이끌어 낼 수 있고, 더 합리적인 프로젝트 구조를 만들어 낼 수 있는 자신을 발견할 수 있다. 풀사이클 개발이 적성이라면 다시 한 번 도전해 볼 수 있을 것이고, 집중하고 싶은 분야가 있다면 타인과 협업을 통해서 더 나은 프로젝트가 만들어지는 것을 경험할 수 있다.
아 진짜 장점도 많고 재밌는데... 더 설명할 방법이 없네...
Ghost