능력 있는 프로그램 개발자?

주어진 프로젝트를 기간 내에 잘 끝내는……
어려운 문제를 해결하는……
개발자로 일한 기간이 길어서 경험이 많은……

뭐 이러 저러한 능력들이 뛰어난 개발자들을 일컬어 능력있는 소프트웨어 개발자라고 얘기 하곤 한다.

오늘은 프로그래머에 대해 몇 가지 얘기해 보고자 한다.

 

코딩과 경험

예전에는 정보의 습득이 무척 힘들었다. 필자도 학교에서 전산을 전공하면서 꽤 많은 지식을 습득했다고 자부하고 사회에 나왔는데, 웬걸? 내가 알고 있었던 건 직장 선배들이 시키는 일 겨우 겨우 해결해 갈 정도의 기본 지식이었고, 그나마도 잘 알려주는 고참들이 있었기에 많이 배울 수 있었는데 개인적으로 큰 복이라 할 수 있겠다.

간단히 말해서 그동안 내가 알고 있었던 지식은 우물안 개구리, 조족지혈(새발의 피), 모기발에 워커 라고나 할까?
다만 새로운 것들을 하나하나 알아가는 그 자체가 즐거웠기에 주말이면 서점을 들락거리며 그럭저럭 개발자로서의 험난한(?) 생활에 익숙해지고 단련되었던 것 같다.

지금은 바야흐로 21C 융합과 소통의 시대다. 필요한 정보는 인터넷에 들어가 보면 차고 넘치며 없는 것 빼고 다 있으니, 서점에서 필요한 기술서적을 뒤져볼 필요가 많이 줄어든 것은 사실이다. 오히려 과하게 제공되는 정보의 홍수 속에서 거짓 정보와 제대로 된 정보를 구분하면서 걸러내야만(필터링) 필요로 하는 정확한 정보를 얻을 수 있을 지경이니 그 어느 때 보다 본인만의 정보에 대한 명확한 판단 기준이 있어야만 한다.

이러한 상황은 고급개발자와 중급, 초급개발자의 기술적 간극이 상당히 줄어 있다는 의미와 같다.
왜냐고? 기본적인 코딩능력이 있다는 전제하에 코딩의 테크닉이나 팁은 인터넷 안에 거의 대부분 있기 때문에 이 기술을 쓸 줄 아느냐 모르느냐 라는 관점 보다는, 이러한 기술이나 코드, 방식 같은 것들을 어떻게 적용하고 문제를 해결할 수 있을지를 판단하는 능력이 더욱 중요할 수도 있기 때문이다. 필요한 조각 코드를 찾는 것은 초급이든 고급이든 누구나 할 수 있지만, 그 코드를 적용하고 사용하는 방법에 따라 초급과 중급, 고급의 능력 차이가 있고 기술 수준이 높아질 수록 현재의 코드가 다른 팀/개발자/코드 등에 어떤 영향을 미치게 될지 예측하게 되기도 한다.

초급은 그대로 사용해보고, 안되면 또 다른 코드 찾아보고……
중급은 코드를 필요에 따라 바꾸기도 하며 문제를 해결하고……
고급은 아이디어를 얻어 상황에 맞는 새로운 코드를 만들어내는 Creator의 역할도 함께 한다.

고급 개발자가 되려고 한다면, 어떠한 문제든 부딪쳐 보고 많이 고민해 보기를 바란다. 라이센스에 대한 문제만 아니라면 누군가의 소스코드를 참고하고 복붙(Ctrl+C , Ctrl+V)하더라도 무엇을 해결할지 보다는 어떻게 해결할지를 먼저 고민해 보아야 할 것이다. (WHAT 보다는 HOW에 집중)

이렇게 문제 해결을 위한 많은 고민들이 쌓이고 쌓여 초급에서, 중급으로 그리고 고급으로 발전해 가는 것이고, 그 고민들이 켜켜이 쌓이게 되면 우리는 이것을 경험이라고 부르게 되며 본인의 기술적 기반이며 초석이 될 것이다.

 

모르면 창피한건가?

예전에 대학에서 몇년간 데이터베이스 강의를 했었다.
학기 초 부터 학생들에게 궁금한게 있으면 언제든 질문하라고 얘기하지만 예상대로 질문하는 친구들이 거의 없다. 그러던 중 학기 초 언젠가 한 학생으로 부터 메일을 받았다.
‘너무 기본적인것 같아서 수업 시간 보다는 이렇게 메일로 질문 드립니다……’ 로 시작하는 질문 메일이었고, 최대한 쉽게 설명해 주었던 적이 있다. 그 이후 이 친구는 수업중에도 질문을 자주 했고, 나비효과인지 다른 친구들도 조금씩 질문을 하게 되더라는…….

 

모르는건 창피한게 아니다. 모르는 걸 아는 척, 알려고 하지 않거나 몰라도 돼~ 라고 하는 것이 창피한 것이지.

그런데 지금 생각해보니 학생이라는 배우는 입장에서 모르는 게 문제가 아니라, 자신이 뭘 모르는지 조차 모른다는 걸 더 심각하게 생각해 봤어야 할 것 같다. (물론 그렇지 않은 학생들이 더 많기는 하다!!!!!)

 

프로젝트를 진행하다 보면 맨땅에 헤딩하는 작업들이 비일비재하다. 이러한 비효율적 작업을 줄이는 가장 좋은 방법은 제대로 된 요구사항 분석과 이를 바탕으로 하는 설계는 반드시 필요하다. 이를 위해 프로젝트를 시작할 때 사용자에게 최대한 많은 질문을 하고 그 질문에 대한 피드백을 요청하게 된다. 고급개발자라고 모든 업무에 고급일 수는 없으며, 프로그램 개발능력과 업무파악 능력은 서로 다른 관점이다. 시스템을 만드는 일에는 전문가 일지라도 해당 업무의 현업 담당자만큼 Detail을 정확하게 파악하지 못한다면 프로젝트가 진행 될 수록 소스 코드 곳곳에 지뢰밭이 숨어있는 매직을 경험하게 될 것이기 때문이다. (논리적 오류의 디버깅은 무척 힘들고 지루한 업무다)

 

고급 개발자일수록 이러한 요구사항 미팅 시 현업 담당자의 합리적인 범위 내 피드백을 잘 유도해 내고 기본적인 질문도 합을 잘 맞춰 가면서 요구사항을 시스템에 잘 녹여낸다. 이러한 능력은 경험적 밑바탕이 충분해야 하고, 개발이나 분석/설계 경험이 많은 개발자를 고급 개발자로 인정할 수 있는 중요한 기준이 될 수 있다.

 

새로운 분야의 경험하지 않은 업무라면 고급개발자라 하더라도 초기 업무 파악을 위한 질문이 무진장 많을 수 밖에 없다. 양질의 질문과 그에 따른 적극적 피드백이 많을 수록 미래의 시행착오와 소통의 오류를 상당 부분 줄여준다.

이런 프로젝트가 끝나고 나면 필자에게는 두 부류의 팀원들이 기억된다.
“이런 프로젝트는 절대 안 할란다.” 와 “힘들었지만 좋은 경험이었다.”

지극히 수동적 개발에만 참여한 그룹과, 적극적이고 능동적으로 프로젝트를 수행한 그룹이 서로 상반되는 표현으로 나뉘어 진다고 느끼게 됨은 비단 필자 혼자만 그러하지는 않을 듯 싶다. 고급 개발자 라면 주어진 역할과 책임에 충실하지만, 충실하지 못한 개발자들은 오히려 회피와 핑계, 내로남불 측면이 강하다.
(개인적인 생각으로는, 사실 조용한 수동적 개발자가 협업 파트너로서는 훨씬 낫다.)

 

하지만 실력보다는 입으로 코딩하는 쭉정이 개발자나 남을 탓하는 개발자, 그리고 어수룩하게 아는 척 하는 친구들은 협업 분위기를 안 깨면 다행인 경우가 많고, 다른 팀원들의 소통 능력에 부정적 영향을 미치는 경우가 상대적으로 많으며, 권한은 최대한 누리려고 하면서 책임에 대해서는 방관하는 개발자는 팀 분위기에 쥐약이기 때문이다.

많은 질문과 피드백을 수용하고 조율하는 것이 큰 효율성을 가져다 줄 수 있음을 항상 염두에 두어야 할 것이다.
이러한 능력이나 성향은 본인의 직접적인 경험과 프로젝트에 참여하는 관심의 크기에 비례한다고 생각한다.

 

그리고 프로젝트는 사람과의 관계로부터 시작되는 일이기에 질문과 협의에는 상황에 맞는 적절한 예의가 있어야 한다.

독불장군이 아니고 혼자서 하는 프로젝트가 아니라면, 팀원이든 현업 담당자든 좋은 관계 유지가 협업의 기본이고 필수이며 이 또한 타인에게 어필할 수 있는 개발자 능력 중의 하나로서 중요한 평가 요소가 될 수 있으므로, 프로젝트 진행 시 매사에 긍정적이고 적극적인 사고방식으로 많은 경험을 접해보기를 바란다.