회사에서 하는 일을 잘 하는 게 자신의 개발 실력을 증명해 주지는 않는다. (2)

회사에서 하는 일을 잘 하는게 자신의 개발 실력을 증명해 주지는 않는다 (1)

---------------------------

그러면 실제 개발 실력이라는 것이 어디에서 오는 것인지 생각해 보자. 실력이라는 게 구체적으로 뭘 말하는 것인지 부터 인지해야 한다. 한자 그대로 실제 힘이라는 뜻이다. 좀 더 풀어서 말해보면 실제로 갖추고 있는 힘이나 능력 정도를 얘기하는 것일 것이다. 물리적인 힘은 눈에 보이기도 하고 어느 정도인지에 대한 감이 오는데, 소프트웨어를 개발하는데 나오는 실력이라는 건 눈에 보이지도 않을 뿐더러, 주니어 개발자가 만들던 시니어 개발자가 만들던 만들어 놓은 결과물의 차이가 크게 없어 보인다면 실력을 가늠하기가 쉽지 않은 건 사실이다.

Not 코드를 짤 줄 아는 능력, but 코드를 볼 줄 아는 능력

잘 모르는 사람은 이게 실력이라고 생각할 수 있는데 오히려 코드를 볼 줄 아는 능력이 실력일 가능성이 높다. 왜 그런가 하면 주력 언어가 있고 익숙하면 어느 정도 좋은 개발 도구의 도움을 받아 어느 정도까지는 코딩이 가능한데, 그 이상은 사실 좋은 코드가 있는 구글의 도움을 받아야 하는게 사실이다. 남의 코드를 가져와서 짜는게 실력이 아니라고들 하지만 남의 코드를 가져오기 전에 볼 줄 아는 혜안을 가졌다면 가져와서 붙여넣고 만들어 나가는 건 큰 문제가 아니라고 본다. 즉 코드를 가져오는 능력의 기본은 코드를 볼 줄 아는 능력이 뒷받침 되어야 한다는 뜻이다. 또한 코드를 볼 줄 아는 능력을 갖추고 있다는 건 문제를 해결하는 방법을 알고 있거나 찾고 있다는 뜻이기도 하다.

Not 동작하는 코드에 대한 만족, but 품질을 결정하는 요소를 실천하는 능력

역시 잘 모르는 사람은 동작하는 코드를 짤 줄만 알면 되고, 그 코드가 크게 문제가 없다면 그냥 두는 걸로 만족한다. 하지만 동작하는 코드만 짤 줄 아는 능력은 이 바닥에 들어온 사람이라면 당연히 해야 하는 걸 했을 뿐이다. 즉, 동작하는 코드를 짜지 않고는 일이던 뭐던 진행이 안되기 때문에 당연한걸 해 놓고 당연하다고 하면 어떻게 반응해야 할지 잘 모르겠다. 동작하는 코드를 짰는데, 그걸 잘 다듬고 보듬어 줘서 이후 테스트가 엄격하게 통과가 되는 원칙을 잘 지키는 코드로 만들어 나갔는지 혹은 유지보수와 기능 추가가 유연한 설계를 바탕으로 만들어진 코드였는지에 따라 소프트웨어 품질이 결정된다. 그러니까 이런 품질에 대해 고민하지 않고 만족하는 개발자는 실력이 있다고 보기 어렵다는 얘기다.

Not 회사에서 해야 하는 일에 대한 성과, but 개인이 정말 해보고 싶은 걸 해본 결과

실무 경력은 사실상 실무 경력일 뿐이다. 관련된 업무를 경험해 봤고 해 봤으니 동종 업계에서 하는 비슷한 일을 잘 이해하고 해낼 수 있는 것 정도가 전부인 것이다. 업무 프로세스 이해를 잘 해서 일을 잘 해 나가는 능력은 사실상 개발 실력하고는 크게 상관이 없다. 단, 일을 해 나가면서 조금씩 다른 구현을 시도해 보고 다른 설계를 해서 평소에 알고 있던 방법 외에 이런 저런 실험도 해 보고 하면서 진행했다면 괜찮을 수 있는데, 지금 알고 있는 범위 내에서 해야 하는 일만 했다면 그 이상을 보지 않고 일을 해 왔다는 것이고, 그건 개발 실력이 향상되지 않았다는 뜻이기도 하다. 진짜 실력을 키워 보려면 자기가 따로 해보고 싶은 쪽의 분석, 설계라는 단계를 잘 거치고 문서화를 잘 해 놔서 개발을 진행해 본 경험이 있어야 조금 더 많은 걸 볼 수 있다는 뜻이다.

그러면 정말 실력은 어디서부터 오는 것일까?

보통 회사에서 하는 일은 개발, 그러니까 기능의 구현에 많은 초점이 맞춰저 있는데 문제의 해결력 보다는 구현의 방법에 대한 스킬만 늘어날 뿐이고 누군가 문제를 주면 해결을 하지 못한다. 더 나가서 해결 못할 뿐만 아니라 그걸 자기가 해야 하는 일이 아니라고 생각한다. 그럼 누가 하느냐? 기획자가 해야 할 일이라고 한다. 기획자? 기획자는 개발을 하는 사람이 아니다. 오히려 문제를 만들어내는 사람이지 해결하는 사람이 아니다.

그런 문제를 해결하는 사람은 소프트웨어 개발자가 해야 할 일이며, 문제가 주어지면 잘 이해하고 분석해서 소프트웨어로 어떻게 만들면 좋을 지에 대한 설계는 사실 훈련을 많이 해야 한다. 단순히 코드를 잘 짜는 게 실력이 아니라는 뜻이다. 그런 분석 설계에 대한 훈련을 해서 그 문서를 도출해 내고 그걸 바탕으로 개발을 진행해 보면 다시 분석, 설계가 잘 되어 있는게 중요하다는 걸 뼈저리게 느끼게 된다. 이쯤에서 분석 설계에 들여야 하는 시간이 코딩하는 시간보다 많아야 한다는 걸 깨닫게 된다면 말 그대로 소오름이 돋을 것이다.

그래서 내가 정의하는 개발 실력이란

"주어진 혹은 해결해야 할 문제를 잘 분석하고
그걸 소프트웨어로 잘 만드려면 어떻게 해야 좋을까 하는 고민을 자신의 경험과 역량을 모두 쏟아내서 설계를 잘 해 내고
버그와 문제가 없는 코드를 작성해서
예상한 기간 내에 만족할 만한 수준의 결과를 내고
이후 추가 기능 개발 혹은 버그 수정이 잘 될 수 있도록
퀄리티 있는 소프트웨어 제품을 만들어 내서
이 소프트웨어를 쓰는 사람의 만족도를 높이고
계속 사용할 수 있는 소프트웨어로 만들기 위해 생명을 불어 넣을 수 있는(엔지니어링을 할 수 있는) 능력"
이라고 얘기하고 싶다. 아홉줄에 걸쳐서 썼는데 코딩 얘기는 한 줄 밖에 없다는 점에 주목하자.

분석은 문제 해결 능력에 가깝다. 실제 만들어 내야 하는 소프트웨어 요구에 대한 내용을 잘 이해하고 정리해서 소프트웨어로 만들어 낼 수 있도록 각을 잴 수 있는 능력이 요구된다. 이게 사실 제일 어렵다. 여기에서 실력이 가늠되기도 하는데 세상의 많은 문제를 소프트웨어 시스템으로 만들기 위한 요구를 분석해 내는 경험을 많이 하는 수 밖에 없다. 이건 경험치로 가늠할 문제지, 공부의 양으로 가늠할 수 있는 문제는 아니라고 본다.

설계는 사실상 소프트웨어를 만들기 이전에 잘 만들어 놔야 할 시스템 구성, 모듈간의 통신, 잘 정의되어야 하는 명세, 실제 데이터의 구성, 프로세스에 따라 데이터가 어떻게 흘러가는지에 대한 내용, 사용해야 하는 라이브러리나 프레임워크, 그걸 기반으로 지켜야 하는 기본적인 원칙, 테스트를 해야 하는 방법, use case, GUI 화면 인터페이스 등 소프트웨어를 개발하는데 필요한 모든 요소 대한 걸 몽땅 만들어 놔야 하는데 있다.

이 두 가지를 잘 하면 코드로 소프트웨어를 만들어 나가는 건 본인 역량 껏 해 나가면 된다. 주니어는 조금 더딜 것이고 시니어는 경험자이므로 상대적으로 빠르게 만들어나갈 수 있다. 이게 실력의 차이 아닌가? 라고 생각된다면 여태 내 글을 잘못 읽은 것이다. 주니어는 상대적으로 분석, 설계에 대한 경험이 없기 때문에 분석, 설계에 대한 결과를 잘 못 뽑아낼 가능성이 높고 잘 못 만든 설계서로 날고 기는 코드로 짜 봤자 원하는 소프트웨어의 기능을 만들어 내지 않았거나 못했다면 엄한테 힘쓴 꼴 밖에 되지 않기 때문이다. 여기서 구현에 관련된 부분 예를 들면 리액티브 프로그래밍 기법으로 짰느니 객체지향적인 방법으로 짰느니 하는 얘기를 해 봤자 아무 쓸모도 없다는 얘기다.

<흔히 볼 수 있는 생명주기에 대한 그림, 이런 그림을 이해하는게 실력하고 상관이 없다고 생각하는가? 그러면 진짜 소프트웨어를 이해하고 만들어 본 경험이 없을 가능성이 높다고 본다.출처: Introducing Systems Analysis, Design & Development Concepts>

전공자라면 소프트웨어 공학을 배웠을 것이고 거기에서 필요한 요소가 뭔지는 다들 배웠을 것이다. 이제 코드를 잘 짜는 능력만을 개발 실력이라고 착각하지 말고 전체 소프트웨어 생명 주기를 잘 이해하고 세상 혹은 내가 만들어 낸 문제를 훌륭한 소프트웨어로 만들려면 어떻게 하면 좋을지 고민해 보자.

나는 이걸 잘 해낼 수 있는 개발자가 진짜 실력을 갖춘 개발자라 보고 싶다.