본문 바로가기
스타트업/운영

새로운 개발자의 법칙, 무엇이 문제인가?

by 회색연필 2018. 2. 6.

새로운 개발자의 법칙(사진 @Pixabay)


법칙이라고 이름을 붙였지만, 이 이야기는 하나의 "현상" 이자 "사례"이다.

범용사례는 아니다. 그렇지만, 적다고는 말하지 못하겠다.

좋든 싫든 업계에 적잖이 존재한다.

특히 개발자 이직이 잦은 기업들은 이 현상에 매우 잘 노출되어 있다.


새로운 개발자의 법칙

많은 개발자들이 프레임워크를 써서 개발을 한다.

왜냐하면 좀 더 빠르게 개발할 수 있으니까.

그리고, 그 시간에 개발한 것치고는 꽤 안정적이니까.


그런데, 프레임워크 의존성이 높으면 이런 문제점이 생긴다.


1. 첫번째 개발자가 아주 좋다는 프레임워크을 사용한다.

그리고 실력이 뛰어나서 프레임워크를 고쳐서 쓴다.

그러다가 퇴사를 한다.


2. 두번째 개발자는 그 프레임워크를 잘 모른다.

그런데 공부할 시간이 없다. 그리고 수정된 부분도 알지 못한다.

아주 높은 확률로 이렇다.

그래서 자신에게 익숙한 새로운 프레임워크를 이용해서 개발을 한다.

그리고 또 어느날 퇴사를 한다.


3. 세번째 온 개발자도 그 과정을 반복한다.

그래서 시스템은 새로운 개발자가 올수록 더 복잡해지고, 유지보수하기 어렵게 된다.


아직까지 시스템은 개발자 역량에 매우 의존적이다.

그래서 개발자가 바뀌면 시스템도 바뀐다.

그래서, 새로운 개발자가 올수록 시스템은 점점 더 복잡해지고 관리비용은 높아진다.

이 현상은 개발자가 나빠서 생기는 문제가 아니다.

이직이 잦은 조직은 대부분 비슷한 문제를 겪는다.

소프트웨어 분야가 아니라도 말이다.


하지만, 인터넷 서비스는 소프트웨어 기술사업이다.

프레임워크를 도입할 때 기술 종속성과 개발자 종속성이 생긴다.

그래서 개발자가 없어지면, 꽤 큰 변경 비용이 발생된다.


해결책은 있을까?

기술적인 해결책은 간단하다.

아예 다 바꾸던지, 아니면 기존 프레임워크를 유지한다.

물론 둘다 난이도는 높다.

기존 프레임워크를 유지한다면, 위키나 git 등이 도움이 될 수 있다.


간혹, 프레임워크부터 개발하는 경우가 있는데 이 경우는 제작자가 나가면 더 힘들다.

오픈 소스는 물어볼 곳이라도 있지만, 개인작품은 그 사람 밖에 없다.

채용이 쉬운 대기업이라면 몰라도, 작은 기업은 타격이 크다.


사업적 해결책은 복잡하다. 기존 시스템은 복잡해져 새로운 일을 하기 힘들다.

하지만, 사람을 쉽게 내보내선 안된다.

기존 시스템을 정리해도 돈이 더 벌리진 않는다.

고객은 일정여유를 주지 않는다. 그냥 총체적 난국이다.


새로운 개발자가 오면 기존의 문제점을 깡그리 해소하고 우리를 구해줄 것이라고 생각할 수 있다.

하지만 경험적으로 그런 경우는 거의 없다.

문제는 복합적으로 나타난다.

기존 멤버가 벽에 부딪혔다면, 새로운 개발자도 똑같은 지점에서 벽에 부딪힌다.


작은 문제가 복잡한 과정을 거쳐 큰 문제로 나타난다.

원인을 찾아 끈기 있게 풀면 대부분 풀리기는 한다.

하지만, 적지 않은 시간과 비용을 소비한다.


그래서, 어떤 CEO는 그냥 원래 이런 사업이라고 받아들이기도 한다.

디테일하게 통제할 수 없으니까, 때가 되면 전체를 버리거나 적정선에서 일부를 포기한다.

그렇게 그냥 새로운 개발자를 포기한다.


지켜야 할 룰, 데이터

리누즈 토발즈가 이런 이야기를 했다.

2006월 6월 22일. "git mailing list"에 보냈던 편지다.


"나는 좋은 개발자와 나쁜 개발자의 차이점을 코드와 데이터에 대한 생각차이라고 본다.

나쁜 프로그래머는 코드를 더 걱정하지만, 좋은 프로그래머는 데이터 구조와 그 관계들을 더 걱정한다."


엔진개발을 제외하면, 대부분의 응용 프로그램들은 비즈니스 데이터를 만들어내는 일련의 과정이다.

그래서 프레임워크가 바뀌어도 데이터의 연속성이 보장되어야 한다.


데이터가 파괴되면 비즈니스가 파괴된다.

새로운 개발자가 데이터에 관심이 없다면 사업에 관심이 없을 수 있다.

사업에 관심이 없다면 시스템을 올바로 설계하기 힘들다.


사실, 제일 좋은 것은 시스템 아키텍쳐를 최초로 설계하는 시점에,

기능과 데이터를 어떻게 분리하고 어떻게 진화시킬지 전략을 짜두는 것이다.

물론 예외 상황을 듬뿍 고려해서 말이다.

시스템이 커지고 복잡해질수록 뭔가 만지기는 더욱 힘들어진다.


새로운 개발자가 와도 데이터는 지켜져야 한다.

시스템은 복잡해져도 데이터는 복잡해지지 않는 것이 좋다.


끝.

반응형

댓글