SI/SM 개발자로서 갖춰야될 기본소양 (대인관계가 좋아야 진정한 실력자다)

개발을 하다보면, 회사 내에서도 뛰어난 선배 개발자들이 여럿 있을 것이다.

여러분들은 이분들에게 개발 관련 및 업무적 궁금증을 물어보면서 그들만의 노하우를 배운 경험이 있을 것이다.

그러나, 이중에서도 다가가기 힘든 선배 개발자들도 분명히 존재하였을 것이다.

 

꼭 개발자가 아니더라도, 회사생활 하면서 같이 말을 섞기 싫은 사람은 주변에 꼭 존재했다.(직급이 너무 높아서 대하기 어려운 경우는 제외)

이들의 공통점은 아래와 같다.

 

그 사람과 얘기하고나면 기분이 좋지 않다. 

 

같이 얘기하는 사람들의 기분을 나쁘게 하는 경우는 여러가지가 있지만,

이 글의 내용은, 듣는 사람의 기분을 나쁘게 하는 말투를 가진 사람이다.

(개발자로서 예시들 들겠지만 어떤 직업이던 다 똑같은듯 하다.)

 

아래는 이런 사람들에 대한 예시이다. 또한, 자신이 이런 사람인지 한번 생각해보자. 개발자라면 다 아는 삼항연산자에 대한 이야기다.

let num = 0;

if(num == 1){
	...
} else {
	...
}

위의 코드를 봤을때, 상대방을 기분나쁘게 하는 말투는 아래와 같다.

  > "요즘 누가 '==' 를 쓰냐?? 타입까지 확인하는 '==='를 써야지... 너 옛날사람이야??"

또한 이런 얘기를 할 수도 있다.

  > "보기 깔끔하게 삼항연산자를 써야지 코드 줄 낭비하게 if~else를 쓰면 어떻하냐? 공부 안하지??"

 

 

물론 친절하게 알려주면 도움이 되는 부분인것은 맞다. 하지만 위와같이 하나하나 모두 꼬투리 잡아서 계속 공격적인 말투, 또는 비웃는 말투로 얘기를 하는 사람들이 있다.

이 글을 보는 여러분들 모두 동의할 것이다. 주변에 이런사람 한명 이상은 꼭 있었다는 것을 말이다.

 

이런 말투를 가진 사람들은 위와같은 상황이 끝난 후 본인은 후배에게 좋은걸 알려주었다고 생각함과 동시에 '이번에도 역시 나의 개발실력을 뽐냈다' 라고 자화자찬하며 자기만족감에 심취해하고 있을 것이다.

 

또다른 예시를 들어보겠다. 내가 알고 지내는 개발자 지인이 회사를 구하고 있을 때 특정한 회사의 면접시 대화 내용이다.

최근의 웹개발 트렌드인 React에 대한 면접 내용이다.

 

면접관 : 경력서를 보면 리액트 써보셨네요. 리덕스를 안쓰신거같은데 상태관리는 어떻게 했죠?

지인 : Context API 썼습니다.

면접관 : (입꼬리 한쪽 올라가며 피식)... 리덕스 안쓰면 리액트가 아닌데...

 

지인은 할말이 많았지만, 면접자리이므로 '아 그렇습니까' 라고 대답만 하였다고 한다.

 

물론 리덕스가 좋은 라이브러리임은 동의한다. 현시점에서 대규모 리액트 프로젝트의 경우 리덕스는 거의 반 필수이다.

하지만 내가 지적하고 싶은것은 바로 면접관의 태도이다.

 

저 질문을 한 면접관은 기술면접자였고, 일을 하게 된다면 그사람과 같이 일할 확률이 높은 상황이었다.

지인은 저런 면접관의 태도를 보자마자 그 회사는 들어가고 싶지 않았다고 한다. 같이 일하게 된다면 개발현장에 대한 그림이 뻔히 그려지기 때문이다.

입사를 위한 면접의 경우, 면접자는 아직 회사 소속이 아니기 때문에 갑/을 관계가 아니다. 그럼에도 불구하고 이미 면접자를 낮춰서 보는 경향을 보였으므로, 예단은 할 수 없지만 추측을 하자면 그와 일하는 팀의 분위기는 대충 예상을 할 수가 있다.

 

경력개발자들은 한번 생각해보자. 당신은 위와같은 두가지 유형 중 하나에 해당하는가?

 

해당된다면 당신에게 이렇게 얘기해주고 싶다. 자신이 생각하는 것이 모두 정답은 아니다. 개발 스킬이 물론 중요하지만 프로젝트를 성공적으로 마치는 효율적인 방안이 우선순위가 더 커야 한다는 것이다.

연구개발실에 들어가서 불특정 다수가 사용하는 생산성이 뛰어나고 실행속도가 뛰어난 개발용 프레임워크를 만드는 것이 아닌 이상, 다수의 작업자들이 모여 협업이 필수인 SI/SM 업무에서는 어느정도의 융통성이 필요하다. (물론, 연구개발팀에 있더라도 팀원이 나 혼자가 아니라면 이러한 태도는 당연히 좋지 않다.)

 

SI/SM업무는, 고객사 프로젝트의 성공을 통해 회사에 돈을 벌어다주고, 그로 인해 급여를 받는 '소프트웨어 비즈니스'를 하는 것이다.

고객사에서 프로젝트의 성공 및 실패를 결정하는 임원진들이 기술력을 따질까? 아니다. 그 시스템을 만드는데 들었던 비용과 그 시스템으로 벌어들인 수익률, 즉 벌어들인 돈을 계산할 것이다.

 

개발사 입장에서는 고객사와 계약한 납기일을 준수해야 프로젝트가 성공으로 끝났다고 보며, 이로 인한 수익창출을 하기 위한, 최적화된 프레임워크 및 기술을 사용해야 하는 것이다.

다시 말하지만 프로젝트의 성공을 위한 첫번째는 '납기일 준수' 이다. 그렇다고 코드를 하드코딩으로 도배하면서 개발하라는 것은 아니지만, 어느정도의 핵심적인 규칙만 지킨다면, 최우선의 과제는 개발 철칙을 지키는것이 아닌 목표일 안으로 개발을 끝내서 고객에게 인도하는 것이다.

 

또한 시스템의 사용자는 개발자들이 아니다. 그들은 어떤 기술을 사용하였는지는 중요하지 않다. 속도와 UX 등을 통해 실생활 및 업무에 도움되는지를 통해 해당 서비스를 판단하게 된다.

 

무조건 최신 기술 및 남들이 많이 쓰는 기술들이 좋은것은 아니다. 금융권에서도 아직까지 오랜기간 검증된 JAVA를 사용하는것과 같이, 프로젝트마다 효율적인 기술들은 모두 다르다. 최신 기술은 예전 기술의 단점에서 배워, 이를 개선한 플랫폼이므로, 여러면에서 더 좋을 확률이 높은 것이지만, 모든 프로젝트에서 다 좋은것은 아니라는 뜻이다.

 

개발자로서 본인의 프라이드가 있다는 것은 좋은 마음가짐이다. 우리들은 돈을받고 일하는 프로들이므로, 내가 개발적 지식이 풍부하다면, 이를 남들에게 좋게 비춰질 필요는 당연히 있다.

다만, 내가 다른 사람보다 더 잘 안다고 해서, 그사람을 까내리거나 무시하면 안되는 것이다. 그렇다면 아무리 실력자여도 나와 같이일하는것을 좋아하는 사람은 없을것이다. 이것은 개발scene 에서 뿐만 아니라 살면서 모든 상황에 적용이 된다.

 

 

이처럼 다른 사람을 대하는 방식이 잘못되었다고 생각하지 않고 다른 사람을 무시하는 경향을 계속 고수할 경우, 결국에는 아래와 같은 상황이 벌어질 것이다.

 

PM : PL님 프로젝트 시작이 얼마 안남았습니다. 개발자 리스트가 있는데요. 이분이 새로 추가됬습니다. 예전에 같이 하신적 있지 않나요??

PL : 아... 이분이군요?? 이분 잘해요.

PM : 잘됬네요. 한번 연락해볼까요??

PL : 아 그건 좀... 잘하긴 하는데 주변사람들이 싫어합니다. 본인에 개발자 프라이드가 너무 강해서 제말도 안들어요.

 

어렵게 프로젝트에 투입 되었다고 해도, 같이 있는 동료들은 불편할 것이다. 이렇게 나의 자리는 서서히 없어질 것이다.

 

직장 생활은 나 혼자서만 일을 하는것이 아니므로, 서로간의 이해 및 양보를 통한 존중이 있어야지만 다른 사람들과의 협업이 부드럽게 되며, 나와 일하는것을 즐겁고 좋아하게 된다.

 

 

아무리 후배 또는 동료가 내가 아는것을 모른다고 하대하면 안된다는 것이다.

모르는 것은 죄가 아니다. 사실 고급 개발자가 초/중급 개발자보다 모든 기술을 더 잘하는것은 아니다.

최신기술이 나왔을 때, 신입사원이 제일 먼저 그 최신 기술에 대한 책을 사거나 동영상 강의를 통해 스킬을 익혔다면, 그 신입사원이 경력자보다는 해당 기술을 더 잘하는것이 된다.

 

나는 오랫동안 IT업계에 몸담으면서 경력자와 신입의 차이점의 핵심은 아래와 같다라고 결론내렸다.

경력이 쌓일수록 대우가 더 좋아지는 이유는, 많은 경험을 통해 쌓아온 노하우를 통해 프로젝트를 성공적으로 이끌 수 있는 확률이 놓기 때문에 대우를 받는 것이다. 일반적으로는 이러한 가치/경험치가 경험이 쌓이면 높아지게 되며, 그래서 경력이 쌓일수록 회사는 높은 연봉으로 대우를 해주는 것이다.

 

내가 아는것을 다른 사람이 모를때, 성심성의껏 친절하게 가르쳐주게 되면, 위에 부정적인 상황과는 반대로 나의 자리에 대한 선택의 폭은 더욱 넓어질 것이다.

혹시 아는가? 그들이 나보다 더 좋은 회사에 들어갔을 때, 나를 추천해줄지 말이다.

 

뛰어난 개발자란, 같이 일하는 동료가 인정해주는 개발자다. 우리는 협업을 하는 환경에서 일하고 있으며, 홀로 개발을 하는것이 아니다.

개발자로서 지식에 대한 프라이드를 가지고 있더라도, 본인의 원칙을 다른 사람에게 그릇된 방식으로 강요하게 되면 이는 자칫하면 고집이 될 수 있고, 아집이 될 수 있다.

 

최대한 모든 사람들에게 따뜻하게 대하라.