brunch

You can make anything
by writing

C.S.Lewis

by 서준수 Apr 20. 2019

훌륭한 개발자란 무엇일까

주니어 개발자의 단상 (1)

훌륭한 개발자란 무엇일까


나는 뛰어난 개발자가 아니다. (그렇게 되고 싶은 개발자이다.) 그래서 훌륭한 개발자란 어떤 것이라고 감히 말할 수 없다. 어쩌면 그 누구도 정의할 수 없는 문제이기도 하다. 그냥 가볍게 내 생각을 정리해보려 한다. 그러면 과연 나는 어떻게 훌륭한 개발자가 될 것인지 조금 알 수 있지 않을까 싶다.


온라인에서 코더와 프로그래머의 차이가 무엇이냐는 질문을 종종 마주한다.


개인적으로는 참 의미 없는 구분이라고 생각한다. 하지만 질문에 대한 답변 분위기를 보면 '코더 < 프로그래머'의 보이지 않는 등급이 존재한다.


나무위키에서는 코더를 다음과 같이 말하고 있다.


Coder. 원래는 의사 코드나 명세서로 만들어져 있는 알고리즘 또는 로직을 실제 컴퓨터가 이해할 수 있는 형태로 번역하는 사람을 뜻한다.


의사 코드를 단순히 완전한 코드로 변경하는 역할이 코더라는 것은 충격적이다. 이것은 마치 타자를 칠 줄 모르는 베스트셀러 작가가 내용을 불러주면 받아치는 역할과 다를 게 없다는 소리다.

명세서를 보고 개발하는 것은 흔한 일일 텐데 이 마저도 프로그래머가 아니라고 한다면 글쎄, 이렇게 말하신 분은 과연 코더일까 프로그래머일까.



여기서 '코더와 프로그래머'의 차이점이 뭔지 논쟁을 펼치자는 것이 아니다. 앞서 말한 것처럼 코더보다 프로그래머가 더 능력 있는 개발자라는 미묘한 분위기가 진짜라면 프로그래머는 훌륭한 개발자인가. (프로그래머와 개발자를 구분해서 쓴 것도 참 우스운 일이다. 시적 허용 같은 느낌으로 보자.)


그렇다고 할 수 없다. 프로그래머 중에서도 실력이 천차만별이기 때문이다. 그리고 그 실력에 대한 기준도 관점과 분야에 따라 다를 수 있다.


다음 두 가지 관점에서 생각해보자.


1. 빠른 구현 vs 빠른 동작


요구조건을 빠르게 구현하는 사람과 최적화를 잘해서 빠르게 동작하도록 개발하는 사람 중 누가 실력이 좋은 사람인가? 둘 다 잘하면 좋겠지만 굳이 따지자면 말이다. 사람마다 다른 답이 나올 것이다. 왜 그럴까? 본인이 하는 업무나 연구하는 분야에 따라 필요한 영역이 다르기 때문이다.


프로토타입이나 데모용 프로그램을 개발하는 조직이라면 빠른 구현 능력을 선호할 가능성이 크다. 이런 상황에서 빠른 구현보다 빠른 동작을 위해서 최적의 알고리즘을 구현하느라 시간을 지체했다면 좋은 평가를 받을 수 없다.



게임과 같이 성능이 중요한 분야였다면 아무리 단시간에 구현했어도 반응속도가 느리면 실력 있는 개발자라고 인정해주지 않는다. 무지막지하게 빠른 알고리즘을 개발했어도 리소스를 많이 먹는 방법이라면 임베디드 시스템과 같은 분야에선 이상에 불과할 뿐이다.


결국 상황에 따라서 요구되는 능력이 다르기 때문에 어떤 것이 더 낫다고 말할 수 없다. 실제 현업에서 이걸 벌써 구현했다니 대단하다고 놀란 적도 있고 이걸 이렇게 구현하다니 감탄한 적도 있다.


2. 라이브러리 활용 vs 구현


개인적으로 학부생 때는 지금보다 구글 검색을 많이 하지 않았다. 필요한 부분은 가급적 직접 코딩해야 내 것이라고 생각했기 때문이다. 그래서 늘 어려웠고 잘하지 못했다. (지금 돌이켜보면 다소 어리석었다. 수많은 선배 개발자들이 오랜 시간 닦아 놓은 좋은 길을 감사하며 걸어갔어야 했다.)



그래서 라이브러리를 거의 사용하지 않았다. 하지만 알다시피 검증된 라이브러리는 그것 이상으로 좋게 구현하기 매우 어렵다. 자바를 사용하면서 sort 함수가 기본적으로 제공될 때 느낀 편리함은 아직까지 잊히지 않는다.


그렇다면 다양한 (외부) 라이브러리를 아주 잘 다루는 개발자와 라이브러리 자체를 구현할 줄 아는 개발자 중 누가 더 뛰어난 개발자인가?


라이브러리를 잘 다룬다면 빠른 개발이 가능하다. 성능 또한 준수할 것이다. 캡슐화된 상태에서 굳이 동작 원리를 알 필요는 없다. 어떻게 사용하는지만 알면 충분하다. 심지어 라이브러리도 사용법을 공부해야만 익숙하게 사용할 수 있다. 이러한 관점에서라면 굳이 라이브러리와 같은 동작을 하는 코드를 구현할 줄 몰라도 상관없다.


문제는 커스터마이징을 할 필요가 있을 때이다. 라이브러리가 개발자가 원하는 모든 기능을 구현해주지는 않는다. 기본적인 로직을 구현할 줄 모르는 채로 라이브러리에만 의존한다면 언젠가 한계점을 맞이할 것이다. (사실 라이브러리로만 개발하는 개발자는 없을 것이다.)


이런 경우 라이브러리에서 제공하는 수준의 기능을 직접 구현할 줄 아는 능력도 필요하다. 그러면 라이브러리를 개발할 줄 아는 개발자는 당연히 그 라이브러리도 자유자재로 다룰 수 있으니 더 뛰어난가?


이미 이야기 했듯이 수많은 사람들이 다양한 환경에서 사용하면서 검증된 라이브러리를 개인이 만든 코드가 따라가기엔 역부족이다. 따라서 선뜻 그렇다고 답할 수 없다.


또한 많은 기업에서 특정 라이브러리(ex. Glide, Retrofit, RxJava 등) 사용경험을 필수 혹은 우대하고 있다. 그렇다고 라이브러리만 기가 막히게 사용할 줄 알면 입사할 수 있을까?



기업마다 다르겠지만 기술면접에서 라이브러리 사용법이 아닌 그 기술에 대한 기초지식을 물어볼 수도 있다. 예를 들면 앞서 언급했던 자바의 sort 함수를 손 코딩해보라고 할 수 있다. 반대로 직접 멋지게 구현할 줄 알아도 자바에 sort 함수가 있는지도 모르는 사람이라면 면접관이 고개를 끄덕일지는 의문이다.


결국 라이브러리도 잘 알아야하고 구현도 어느 정도 할 줄 알아야 한다.


실제 개발은 기본적으로 제공되는 수많은 API 사용의 연속이다. 라이브러리가 좀 더 사용하기 편리하도록 업데이트된 문법이라고 생각해도 재미있을 것 같다.


이렇게 보니 결국 기본기로 돌아간다. 기초 지식(문법, OS, 자료구조, 알고리즘 등)도 잘 알아야 하고 좋은 로직을 떠올릴 논리력도 있어야 하기 때문이다.


결론적으로 훌륭한 개발자란 정해진 게 없고 그 분야, 조직 특성에 맞게 역량을 키우면 될 것 같다.


훌륭한 개발자가 아니라 어떤 개발자가 될지를 정하고 그 길 꾸준히 달리다 보면 언젠가 주변에서 좋은 개발자라고 인정해주는 순간이 오지 않을까 하는 생각이 든다. 그 순간이 바로 각자가 생각하는 훌륭한 개발자 탄생의 순간이 아닐까 싶다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari