시니어 개발자의 조건

2017년 7월 4일 1차 개정
2016년 1월 4일 초안 작성

• 서론
• 본론
  • 서비스 개발
  • 기반 기술
  • 오버 엔지니어링
  • 클린 코드
  • 애자일
  • 오픈소스
• 결론

서론

지난 며칠간 내 글로 인해 온라인에서 상당한 논란이 일었다.

• 깊이 보다 넓게…
  • 나는 완전히 다른 생각을 갖고 있다.
• 클린 코드를 다시 읽고
  • “클린 코드를 다시 읽고”를 읽고

그동안 꾸준히 주장해온 의견의 연장선이었는데, 짧은 글로 의견을 개진하다 보니 잘못 받아들이는 분들도 있고, 다소간의 오해가 있는듯 하다.

논란의 근본적인 원인은 다소 과격한 표현을 사용했기 때문임을 인정한다. 오랫동안 글쓰기를 해왔지만 여전히 부족함을 느낀다. 이 부분은 변명의 여지 없는 내 잘못이다.

그러나 주장 자체는 지난 몇 년간 꾸준히 개진해온 바다. 하루 아침에 생각해낸 얘기가 아니다. 표현 때문에 주장의 핵심이 묻히지 않았으면 좋겠다. 내 생각들은 오랫동안 블로그 곳곳에 드러나 있으며 계속 일관되어 왔다. 2014년 5월에 이미 기본에 충실한 소프트웨어 개발을 얘기했다. 그 해 7월에는 좋은 개발자에 대한 생각도 피력한 바 있다. 또한 실력이 가장 중요하다는 훌륭한 개발자란 얘기도 했다. 좋은 개발자, 훌륭한 개발자가 경력이 쌓이면 이 글에서 말하는 시니어 개발자가 된다. 그게 주장의 요지다.

어쨌든 이번 논란을 통해 내 주장을 좀 더 많은 분들께 검증 받을 수 있었으며, 훌륭한 피드백을 통해 의견을 다듬는 계기가 됐다. 많은 도움이 됐으며, 감사드린다.

본론

서비스 개발

주장하는 바가 서비스 개발을 매도하고 시스템 개발이 최고라는 얘기가 아니다. 완전히 잘못된 오해를 하고 있다. 알고리즘이 최고이며 과학자가 되라는 얘기도 아니다. 내 주장은 서비스 개발자를 타겟으로 하고 있다. 나 또한 서비스 개발을 주 업무로 하고 있으며 서비스를 개발할 때가 가장 즐겁다. 주장의 핵심은 시스템 개발을 이해하고, 서비스 개발을 해야 한다는 것이다. 시스템을 몰라선 안된다. 당연히 시스템을 얼마나 잘 이해하느냐에 따라 서비스 품질에도 차이가 난다.

프론트엔드 개발자에 하는 충고 중 이런 말도 있다.

“30년간의 소프트웨어 엔지니어링을 무시하면서 개발하지 마라(Pretty much creating Software while Ignoring 30 years of Software Engineering, 번역)”

컴퓨터 과학이 프론트엔드 개발을 하는데 필수 조건은 아니다. 그러나 컴퓨터와 소프트웨어의 기본적인 동작 원리는 브라우저나 자바스크립트로 코딩을 할때도 동일하게 적용된다.

“아는 만큼 보인다.”

기반 기술

시스템을 공부하는 것이 꼭 좋은 학교에서 좋은 교육을 받아야 한다는 얘기는 아니다. 실무에서 서비스를 만들면서도 얼마든지 시스템에 대한 학습을 할 수 있다.

출발은 ‘왜?’ 라는 물음에서부터 시작된다. 구현한 서비스가 왜 이렇게 동작하는지 원리를 탐구하는 자세가 모든 출발의 시작이며, 좋은 개발자의 기본이다. 시스템의 동작원리를 속속들이 파악하여 최적화를 고민하고, 꾸준한 학습으로 지난 수십년 간 컴퓨터 과학의 베스트 프랙티스를 효율적으로 적용하려는 노력이 품질 좋은 서비스를 향한 첫걸음이다.

시스템은 기반 기술과 비슷한 의미다. OS, 컴파일러, 알고리즘, 자료구조 등 컴퓨터 과학을 포함하여 기본 또는 기반이 되는 모든 기술을 지칭한다. 기반 기술은 어렵고 그만큼 꾸준히 공부해야 한다. 그러나 과실은 달콤하다. 기반 기술에 대한 이해도에 따라 전혀 다른 품질의 결과물이 나온다. 지속 가능한 훌륭한 개발자가 되는 길에 한걸음 더 다가설 수 있다. 그러기 위해 배움은 꾸준해야 한다. 그게 싫다면. 좋은 개발자는 될 수 없다. 경력만 쌓인다고 결코 시니어 개발자로 부를 수 없다.

오버 엔지니어링

지나친 기술 집착은 오버 엔지니어링으로 귀결된다는 의견이 있다. 그럴지도 모른다. 하지만 반대로 생각하면 기술에 대한 이해도가 낮으면 언더 엔지니어링이 될 수도 있다. 우리가 두려워 해야 할 것은 오버 엔지니어링인가, 언더 엔지니어링인가. 물론 가장 좋은 것은 상황에 맞는 적절한 엔지니어링을 택하는 것이고, 그게 최우선임은 당연하다. 그러나 적절한 엔지니어링을 택하는 것도 많이 알고 있을때나 가능한 일이다.

클린 코드

시니어 개발자에게 깨끗한 코드는 당연한 필수 조건이다. 책 『클린 코드』는 좋은 코드를 위한 훌륭한 지침서다. 그러나 모든 지침이 절대적인 사항은 아니며 주관적인 내용이 많은 부분을 차지한다. Java 언어에 제한적인 부분도 많으며, 지금 시점에서 맞지 않는 부분도 있다. 책에서도 ‘적어도 내게는 그렇다’는 문장이 수시로 등장한다. 저자는 책 내용이 주관적일 수 있다는 점을 분명히 하고 있다. 또 다른 프로그래밍 명서인 『프로그래밍 수련법』과는 전혀 다른 얘기도 잦다. 한 마디로 코딩 스타일에 정답은 없다.

클린 코드의 규칙 일부는 다른 언어에는 적용하기 힘든 언어의 제약이나 비지니스 구현에 한정된 얘기도 있다. 서비스 개발이라고 단순한 비지니스 구현만 하는 것은 아니며, 단순 구현만 해서도 안된다. 최신 논문의 알고리즘을 구현하면서 실험할 수도 있고 절차적으로 알고리즘의 가독성을 높이고 최적화 해야 할 때도 있다. Java와 Spring만 하면서 단순히 비지니스 구현만 한다면 클린 코드 책 정도에 만족할 수도 있다. 그러나 언어나 프레임워크는 절대적이지 않다. 언어마다 프레임워크마다 지향점이 다르며, 클린 코드의 기준도 제각각이다.

가독성 또한 도메인 지식에 따라 달라질 수 있다. 도메인 지식이 필요 없어도 읽히는 코드를 작성해야 한다는 의견이 있지만, 모두가 도메인 지식 수준을 높이는 편이 더 낫다. 영어 초급반과 고급반이 같은 클래스에서 수업을 진행할 수 없듯이 모두가 영어를 고급반 수준으로 높이는 편이 훨씬 더 낫다. 무엇보다 이 모든 것은 주관적이고 다를 수 있다. 그런데 마치 클린 코드를 맹신해(또는 클린 코드 밖에 알지 못해) 이 것이 정답이고 다른 것은 오답이라는 이분법적 논리로 잘못 접근하는 경우가 있다.

깨끗한 코드는 당연한 것이지만 클린 코드의 내용은 주관적인 지침이다. 시니어 개발자라면 클린 코드의 지침만을 맹신하고 강요해선 안된다. 클린 코드 밖에 모르고 단순히 비지니스 구현만 하면서 시니어 개발자라고 부를 수 없다. 세상에는 클린 코드 뿐만 아니라 뷰티풀 코드를 비롯해 수십년간 이어져 내려온 다양한 코딩 스타일이 존재한다는 점을 분명히 인식해야 한다.

애자일

애자일을 논하지 않고 넘어갈 수 없다. 애자일의 철학은 훌륭하다. 그러나 전형적인 사업 주도의 엔지니어링은 개발자의 창의성이 필요한 분야에 오히려 상황을 악화시킨다. 애자일은 깊이 있는 생각 기반과 맞지 않으며, 특히 스크럼에서는 시니어의 역할이 불분명하며 역량을 발휘할 수 있는 기회 조차 제한적이다. 10년 경력의 개발자도 1년 경력의 개발자에 비해 아무런 경쟁력이 없으며, 그저 평범한 회사원으로 만들 뿐이다. 이 부분에 있어서는 나보다 훨씬 더 강하게 비판한 글이 있으며, 번역또한 잘 되어 있으므로 참고하기 바란다.

스크럼은 긴급한 상황에서 빠르게 업무를 처리하기 위한 특수한 방법론이다. 적절한 장소와 시간에 사용해야 하는 것인데, 그게 마치 만능인 것 마냥 맹신하고 “우리는 항상 스크럼으로 개발합니다.”라는 얘길 들을때마다 깜짝 놀라게 된다. 애자일을 추구하면서도 창의력을 저하시키지 않도록 상황에 맞게 적절한 방법론을 택하는 것이야 말로 시니어 개발자의 필수 조건이다.

오픈소스

현대의(modern) 소프트웨어 개발은 이제 오픈소스를 빼놓고 얘기할 수 없다. 오픈소스는 기술 혁신의 상징이다. 하지만 앞서 계속 기반 기술을 강조해왔으나 기반 기술에 대한 이해 없이도 오픈소스를 잘 활용하면 그럴듯한 결과물을 만들어낼 수 있는 것 또한 사실이다. 그래서 아래와 같은 비판을 하는 분도 있다.

페이스북 원문이 삭제되어 더 이상 보이지 않는데, 오픈소스를 갖다 쓰기만 하면 배우는게 없으니 오픈소스를 쓰지말고 기반 기술을 모두 직접 만들어 쓰자는 주장이었다.

비판 자체는 충분히 이해가 된다. Spring을 잘 쓸 줄 안다고 Spring 전문가가 아니다. Spring 사용자일 뿐이다. Spring 같은걸 만들 수 있어야 Spring 전문가다. 앞서 꾸준히 강조한 ‘기반 기술을 이해해야 한다’는 내 주장과도 일맥상통한다. 그러나 결론이 엉뚱하다. 쓰지 말자는 완전히 잘못된 결론을 내리고 있다. 마치 문물을 개방하면 나라가 망한다는 그 옛날 쇄국정책을 보는듯 하다. 그리고 그 결과는 우리 모두가 잘 알고 있다.

여기에는 임정택님(Apache Spark 커미터, Databricks 소속)이 명쾌한 정의를 내려준바 있다. 프로슈머가 되어야 한다는 주장이다. 오픈소스를 쓰지 않는다고 경쟁력이 확보되는게 아니다. 오히려 반대다. 다만, 오픈소스의 내부 동작 원리를 속속들이 알고 있고 용도에 맞게 정확하게 사용할 수 있는 수준이 되어야 한다. 무엇보다 부족한 부분은 찾아서 기여도 할 수 있어야 한다. Spring을 새롭게 만들라는 얘기가 아니라 Spring의 구조를 훤히 꿰뚫고 버그나 개선 사항을 업스트림(Upstream)에 컨트리뷰션(Contribution) 할 수 있어야 한다는 얘기다. 프로슈머가 될 정도로 실력을 갖추어야 한다는 얘기다. 그게 바로 전문가다. Spring을 20년 동안 사용해와도 단 한 줄도 업스트림에 컨트리뷰션 하지 못한 사람은 전문가가 아니다. 다시 말해 그저 갖다 쓰기만 하면서 경력만 쌓이는 사람은 절대 시니어 개발자가 될 수 없다.

결론

나는 기반 기술에 대한 이해도 차이가 서비스 개발의 주니어와 시니어를 구분하는 결정적인 차이라고 생각한다. 그리고 이는 서비스 품질과도 연결된다. 그렇지 않다면 기업은 시니어를 고용할 이유가 없다. 간혹 시니어가 되어서도 주니어와 같은 일만 꾸준히 하고 싶다는 사람들이 있는데, 개인은 그렇게 하여 행복할지 모르겠으나 기업은 그렇지 않다. 주니어와 시니어가 같은 일을 하고 같은 품질의 결과물을 만들어 낸다면 나이는 많고 연봉은 높은 시니어를 반길 이유가 전혀 없다.

시니어는 그래선 안된다. 시니어는 기반 기술에 대한 높은 이해도를 바탕으로 주니어와는 차원이 다른 고품질의 결과물을 만들어 낼 수 있어야 한다. 주니어가 성장하고 본받을 수 있는 높은 기술력을 갖추고 기술을 리딩할 수 있어야 한다. 단순히 1년의 경력을 10번 반복한 시니어는 아무런 경쟁력이 없다.

안타깝게도 우리나라에서 시니어 개발자라 부르는 이들 대부분은 1년짜리 경력을 10번, 20번 반복한 이들이다. 상황이 이렇다 보니 시니어 개발자는 없다는 잘못된 결론을 내리고 있다. 단순 서비스 개발만 반복해 기술력이 부족하니 이런 얘기를 듣는다. 시니어가 더 이상 주니어들에게 이런 얘기를 들어선 안된다. 기업에게도 이런 시니어는 필요치 않다.