ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 풀스택 개발, 그 이상과 현실 사이에서.
    카테고리 없음 2017. 4. 19. 03:49

    현재 팀에서 풀스택 개발을 목표로 하고 실천하지 어언 만 3년이 지났습니다. 개발 영역은 DB기반의 웹 서비스였고 여기에 풀스택 개발을 용이하게 하기 위해 세가지를 행동을 했습니다.


    첫째 개발자간의 커뮤니케이션 비용을 줄이는 것입니다. 제일 개발 효율이 나는 것은 혼자 모든 것을 개발할 때라고 생각합니다. 그러나 각 개발 요소들의 난이도가 올라가고 양이 많아지면서 여러명이 협업을 하게 되고 협업자의 수는 증가하며 이 때 커뮤니케이션 비용 또한 올라가게 됩니다. 커뮤니케이션 비용을 낮추는 방법중의 하나가 바로 개발 환경의 통일입니다.

    그 중의 가장 유력한 방안으로 제가 채택한 개발 환경을 추천합니다. 현재 개발 환경은 빌드툴로 webpack, fe 언어로 es2015(babel 사용), fe framework로 reactjs, be 언어로 nodejs, be 프레임워크로 expressjs, data storage로 mongodb, search engine으로 elasticsearch를 사용하고 있습니다. 각 부분마다 어려움이 있지만 학습 난이도를 최대한 낮추기 위해서 javascript 기반으로 모든 환경을 통일했다는 것이 포인트입니다. 각 기술 영역마다의 진입 장벽을 최대한 낮춤으로써 풀스택 개발 가능성을 끌어 올렸습니다.


    둘째 특정인의 소스 코드의 오너십을 인정하지 않는 것입니다.  제일 무서운 개발 문화 중에 전체 기능을 1/n해서 자기 것만 개발하는 문화가 있습니다. 얼핏 굴러가는 것 같지만 자기 모듈 중심으로 지역적 최적화되어 있는 코드가 양산될 가능성이 농후하고 개발자 역량에 따라 엄청난 편차 있는 코드가 생기게 마련입니다. 이런 문화에 위계적인 문화가 섞여서 몇 년이상 흐르면 악취가 흘러나는 경우를 아주 많이 봤습니다.(물론 훌륭한 리더가 있어서 이를 미연에 적절히 방지한 경우도 있을 수 있지만 아주 드뭅니다.)

    개발을 하다 보면 비지니스 도메인의 깊이도 깊어지고 기술도 분화를 해 나가면서 모듈 요소들을 모두 이해하지 못하는 단계가 필히 발생하게 됩니다. 따라서 각 분야마다 전문성 있는 개발자가 집중적으로 보는 것은 좋으나 그 사람에게 오너십을 주고 해당 사람만이 해당 모듈을 보게 하는 것은 혁신을 막는 것이라 생각합니다. 모든 사람이 모든 소스 코드를 수정할 권리가 부여되어야 합니다. 


    셋째 코드를 통한 나눔의 활성화입니다. 개발자는 회의를 통해서 의견을 나누는 것도 중요하지만 코드를 나눌 때 가장 잘 이해하고 많이 배웁니다. 가급적 무슨 주장을 할 때는 pull request를 만들어 제시하는 것이 가장 좋습니다. 개발자가 많이 배우는 때는 본인이 작성한 pr에 달린 커멘트에서 입니다.  코드를 통해 서로 나눌 수 있는 문화가 풀스택 개발에 가장 필요한 요소입니다. 이러한 나눔을 활발히 하기 위한 전제조건은 나눔에 방해가 되는 장벽을 없애는 것이고 동일한 빌드/언어는 큰 도움이 됩니다.


    지금 결과는 어떨까요? 개발자마다 처한 상황과 기호, 능력의 차이로 인해 모든 기술 요소에 대한 이해도는 제각각이 맞습니다. 그러나 한가지 중요한 점은 최소한 본인이 직접 작성하지 않은 부분에 대해서도 간단한 패치 수정은 가능하다는 점입니다. 또한 pull request가 발생했을 때 최소한 로직 이해는 쉽게 가능하므로 리뷰 작성하기기 쉽습니다. 그리고 각 모듈에 대한 접근 허들이 작기 때문에 horizontal한 리팩토링이 매우 빈번하게 작성되어져서 코드의 효율화가 매우 진전되었습니다.


    웹개발에는 풀스택 개발을 적극 추천합니다.

Designed by Tistory.