신기한 연구소

안녕하세요. 신기한 연구소입니다.

최근 인공지능(AI)이 발달하면서 chatGPT에서 소스도 만들어 준다는 글을 읽었습니다.

그와 동시에 코더의 자리도 AI에게 빼앗길 수 있다. 프로그래머(개발자)도 인공지능이 대체해서 사라질 수 있는 직종이라는 얘기도 같이 들리더군요.

프로그래머(개발자)로서 그런 이슈를 보고 잠시 생각을 해봤습니다. 정말 나의 직업은 사라지는 것일까?

그전에 구분지어야 할 직업이 있습니다. 바로 개발자(프로그래머)와 코더(coder)입니다.

대부분 같은 거 아닌가?라는 생각을 하실 겁니다. 엄밀히 말하면 다릅니다.

프로그래밍 언어를 사용해서 사용자의 니즈(needs), 요구, 를 분석하고 해결해 주는 직업이 프로그래머(개발자)라고 생각합니다. 반면 코더(coder)는 정해진 규칙대로 또는 명세서대로 프로그래밍 문법에 맞게 코딩을 하는 직업입니다. 

어떤 부분이 다른지 더 쉽게 실전 프로젝트를 기반으로 설명해 보겠습니다.

프로젝트에 투입되어서 개발을 하다 보면 크게 2가지 타입의 코딩하는 사람을 볼 수 있습니다.

고객과 협의도 하고 협력사와 인터페이스를 정의하고 다양한 기능들을 어느 곳에 적용하고 공통화 및 추상화를 할지 고민하고 개발하는 프로그래머(개발자)가 있습니다. 보통 실력자라고 합니다. 개발 PL 또는 공통단 업무를 개발하는 능력자입니다.

공통화와 모듈화를 해서 표준을 만들고 각 화면마다 또는 소스마다 어떻게 개발해야 하는지 구조와 샘플링 작업을 해주고 나면 그 패턴대로 찍어내듯 코딩하는 코더(coder)가 있습니다.

코더는 보통 PL 또는 공통 리더 개발자의 지시대로 표준화된 환경에서 반복적 작업을 합니다.

조회하는 화면에서 조건에 값을 꺼내고 버튼에 이벤트를 붙이고 결과를 받아서 화면에 뿌리는 작업, 회원가입 같은 다양한 값을 화면에 입력받아서 서버에 전달하는 작업 등이 프런트엔드에서 코더가 하는 역할이라 할 수 있습니다. 

화면단에서 값이 넘어오면 컨트롤러와 서비스단을 통해 구현부에서 적절한 SQL을 호출하도록 연결하거나 값 검증 기능을 붙여서 입력 또는 출력 시 활용할 수 있도록 코딩하는 코더도 있습니다.

전체적으로 공통화하거나 큰 흐름을 모르더라도 작업할 파트(부분)만 기능적으로 샘플을 따라서 잘 적용하고 작동하게만 하면 됩니다. 

이런 역할로 인해 코더는 AI(인공지능)으로 대체가 가능하다는 의견이 있다고 봅니다. 하지만 프로그래머처럼 고객과 협의를 하고 결과를 도출한 뒤 시스템에 어떻게 적용할지 표준과 공통을 정리하고 코더가 작업할 수 있는 프레임을 만들어주는 것은 사람만이 할 수 있는 일이라고 봅니다. 그리고 실제 화면 또는 서비스에 대한 표준화된 코딩은 AI(인공지능)에게 만들어 달라고 할 수 있겠지요.

사실 프로그래머(개발자)가 처음부터 난이도 있는 업무를 할 수 없습니다. 처음에는 당연히 리더의 계획에 따라 코더로 시작해야 합니다. 그리고 꾸준한 학습(공부)을 통해 본인의 개발 능력을 향상하고 다양한 프로젝트와 경험 많은 리더에게 현장에서 필요한 노하우를 습득하고 익히는 것도 중요합니다. 프로그래머가 쉽게 되는 직업이 아니라는 의미입니다.

구인 사이트를 보면 초급, 중급, 고급에 자바, 리액트 등등을 언급하면서 프로젝트 인력을 구합니다. 코로나 시즌에 갑작스러운 개발 수요가 높아서 등급별 인건비도 오르면서 억대 연봉 이야기가 여기저기 들리기도 했고 인력 수급에도 어려움을 겪었습니다. 하지만 지금은 프로젝트도 별로 없고 그로 인해 인건비도 내려가고 권고사직을 하는 회사들도 종종 보이기도 합니다. 특히 개발자 포털이나 구직 사이트 보면 몇 개월 동안 일이 없다는 이야기가 많이 들려옵니다.

사실 여기서 한 가지 생각할 부분이 있습니다. 진정 프로그래머의 수요는 항상 있습니다. 그리고 유행 따라 주가처럼 오르락내리락하는 인건비와 구인에 대한 상황에 휘둘리는 직업은 코더입니다. 

경력이 10년이 넘은 프리랜서 몇 명을 만난 적이 있습니다. 같이 프로젝트를 하는데 PM 인맥으로 뽑았더군요. 개발을 정말 잘한다고 하더군요. 그러던 어느 날 내가 공통으로 만들어준 프로그램을 호출하는데 오류가 났는데 도와달라고 하더군요. 가서 기본적인 디버깅을 하고 오류를 체크해서 알려줬는데 그런 작업을 할 줄 모르더군요. 일 잘하는 개발자들이라 하는데 오류 디버깅도 못하는 것을 보고 잠깐 당황했습니다. 고급 등급이었거든요. 그래서 좀 지켜보니 등급만 높은 코더였습니다. 고급인데도 주체적으로 진행하지 못하더군요.

프로젝트에서 초급 개발자들을 만나면 항상 이런 이야기를 합니다. 우리의 업은 꾸준히 공부하고 연습해야 직급이나 등급이 올라가서 자기 역할을 잘할 수 있다고.

지금 내 옆에 있는 사원 개발자는 개발자가 되고 싶다면서 하루 종일 놉니다. 퇴근하고도 논답니다. ^^

자기 인생은 본인이 책임지는 것이기에 그러려니 하고 있습니다.

성공하는 길은 어찌 보면 어렵지 않습니다. 많은 사람들은 현실에 적응만 하고 미래를 위한 학습은 하지 않습니다. 또한 학습은 하지만 잘못된 학습(성장과 성공에 필요 없는)으로 시간만 낭비하는 경우도 있습니다.

정확한 목표를 세우고 프로의식과 목적을 가지고 꾸준히 학습한다면 성공은 따라올 수밖에 없습니다.

이제 코더(coder)로 돈 벌고 등급 높은 코더(coder)가 되지 말고 꾸준한 학습을 통해 프로그래머(개발자)로 성장해서 멋진 직업인이 되었으면 합니다.

이 포스팅이 끝나면 리액트 학습을 시작합니다.

학습이 끝나면 리액트를 처음 하는 친구들을 위한 포스팅도 준비하고 있습니다.

우리 모두 멋진 프로그래머가 됩시다.

최근 프로젝트를 몇 번 실패하고 퇴사한 직원이 있었다.

입사한 지 갓 1년을 넘은 경력직으로 이전에 대기업 전산직으로 근무했던 사람이었다.

나도 같이 프로젝트를 한 번 같이 했다.

내가 리더였고 그 직원은 팀원이었다.

처음 분위기는 좋았지만 한 달 정도 지나면서 다른 프로젝트에서 실패하고 리젝(reject)된 이유가 슬슬 보이기 시작했다.

내 장점 중 하나라고 한다면 프로젝트를 하면서 만나는 팀원들의 장단점을 빨리 알아차린다는 것이다. 물론 나 또한 장단점이 명확하다. 특히 야근과 주말근무를 엄청 싫어하기에 윗 분들은 별로 좋아하지 않는 타입니다. 

위에선 큰 기대를 하고 경력직으로 뽑은 이 직원은 입사 후 첫 프로젝트에서 리더로 들어갔지만 두어 달? 정도 있다가 리젝 되었다. 물론 보통 사람들은 자신의 잘못을 쉽게 인정하지 않는다. 나도 그렇기에..

작은 프로젝트 리더를 맡고 그 직원이 같이 참여하게 되었다. 리젝된 후 두 번째 프로젝트인 것이다. 리더가 나였기에 팀원으로 들어왔다. 왜 리젝 되었는지 이야기를 들어보니 본인의 잘못은 없었다. 그저 고객사의 문제를 강조했다. 그 고객사는 최근 나도 프로젝트를 진행했기에 어떤 상황인지 금방 이해하게 되었다.

작은 프로젝트는 시작되었다. 역시 말도 안되는 개발팀을 구성해 주었고 정말 답답한 마음이 앞섰다. 하지만 크고 작은 모든 프로젝트가 거의 완벽에 가까운 팀을 구성하긴 힘들다.

요구사항을 정리하고 기획을 시작하면서 단점이 드러나기 시작했다. 사실 이 직원뿐만 아니라 비슷한 또래의 임직원들의 고질병 같은 상황이 나타나기 시작한 것이다. 최근 시작하는 프로젝트에도 비슷한 나이대의 임원과 회의를 하는데 한마디로 꼰대다. 90년대 스타일의 개발 방식을 내세우면서 요즘 트렌드를 이해 못 한다고 했다. 굴삭기가 있는데 배우는데 복잡하다고 삽질이 최고다를 외치는 그런 분위기다.

여하튼 이 직원도 업무를 진행하는데 약간의 문제를 만들기 시작했다. 사실 리더의 역할 중 하나는 고객과 개발팀과의 적절한 업무적 조율을 잘해야 한다. 고객 편에 서면 개발팀의 개고생과 반발이 심해지고 프로젝트는 지옥의 나락으로 떨어진다. 최종적으로 지연과 함께 회사의 이익과 신뢰는 떨어질 수밖에 없다. 반대로 개발팀 편이나 본인 편을 강조하게 되면 고객사는 엄청난 불만이 발생하고 결국 리젝 되는 상황까지 발생하는 것이다.

이 직원은 그 동안의 경력을 기반으로 정말 많은 기능을 추가하고 있었다. 처음 이야기 한 것처럼 이 프로젝트는 작은 사이즈이다. 많은 기능을 넣으면 좋겠지만 고객의 요구도 아니고 기간, 팀 능력 및 금액적으로 봐도 불필요한 상황이었다. 사이즈에 맞게 적절한 기능을 고객과 협의해서 구현하는데 최적의 상황인데 마치 대형 프로젝트인 듯 상황을 만들어갔다. 고객의 입장에서도 해주면 좋겠는데 할 수 있겠냐는 우려를 표현했다. 그런 상황이 고객과 개발팀원들의 문의로 알게 되었고 내가 고객과 다시 조율해서 현실성 있는 구도로 다시 각을 잡았다. 그리고 그 직원에게 이래저래 상황을 설명하고 협의된 내용대로 진행하자고 했다. 그런데...

그런 상황을 그 직원은 자존심이 상했는지 리더인 나 몰래 다시 고객을 만나 설득하기 시작했다. 세상에...

그런 사실을 모르고 있다가 다음날 고객이 다시 메시지로 연락이 왔다. 불편하다고...정리가 안되는 거 같다고...

그래서 그냥 나랑 얘기한대로 진행할 테니 그 직원과 한 이야기는 넘기라고 했다.

그 뒤로도 업무의 역할 때문에 다툼이 있었다. 본인이 할 일이 아니라면서 짜증을 냈다. 가장 큰 문제는 개발 팀원 중 한 명의 요청 때문에  중요한 변경에 대해서 리더나 설계자와 전혀 상의하지 않고 임의로 변경하고 보고도 하지 않았다. 그것 때문에 다들 많은 시간 고생했다. 바뀌었는지 모르고 잘 실행되던 것이 계속 오류가 났기 때문이다. 결국 내가 발견했고 누가 이걸 변경했냐고 하니 그 개발 팀원이 알려줬다. 이래저래 요청하니 저분이 수정해 줬다고. ㅎㅎㅎ

같은 내용에 대한 반복적인 문의와 잘 삐지는? 그런 성향때문에 고객도 좀 힘들어했다.

그런 과정을 지켜보니 왜 이전 프로젝트에서 리젝되었는지 이해가 되었다. 그 뒤로도 몇 번의 기회가 있었지만 프로젝트에서 모두 리젝 되었다고 들었고 결국 퇴사하게 되었다.

다들 그 직원 탓만 하고 그 직원이 문제가 많아서 퇴사하게 되었다고 생각한다. 과연 그렇게 말하는 본인들은 잘 하는가?

물론 그 직원은 프로젝트 리더로서 자격이 부족함은 맞다. 반면 장점도 있었다.

다들 그 직원의 단점만 가지고 평가하고 선입견을 가졌기에 장점을 활용할 생각을 못한것이다.

모든 직원이 완벽하기를 기대한다는 것은 잘못된 생각이다. 그렇게 평가하는 본인은 정말 완벽하냐는 것이다.

사실 나에 대한 평가도 대충 알고 있다. 장점을 아는 사람들은 내 능력을 잘 활용하는데 그저 단점만 보는 리더들 때문에 답답한 늪에 빠지고 있다는 생각이 종종 든다.

나는 작은 프로젝트를 하면서 그 직원의 단점만 본것이 아니라 장점도 봤다. 그래서 그 장점을 최대한 활용하고 그 직원의 능력을 높이 평가해 줬다. 감정적으로 부딪힌 적도 있지만 최대한 빨리 정리했다. 그것도 리더의 능력이다.

하지만 보통 리더들은 자신의 주장과 자존심이 강해서 조금만 다른 의견을 보이면 화를 내거나 짜증을 내고 가버린다. 팀원들에게 엄청 무례한 행동이다. 그리고 자신에게 다른 의견을 제시하거나 바른 정보를 제공하면 감정적으로 대하기 시작하고 결국 진급이나 연봉에 영향까지 주기도 한다. 흔히 꼰대라고 한다.

진정한 리더라면...

우선 리더는 팀원을 존중해야 한다. 근태나 업무진행에 문제가 있는 경우는 당연히 조치를 해야 한다. 그리고 그 직원의 장점과 단점을 빨리 파악해서 장점을 잘 활용할 수 있도록 도와줘야 한다.

IT는 정말 빠르게 변하고 발전한다. 스마트 폰 앱을 만드는데 2G 폰 시절 개발방식을 라떼는~ 하면서 요구한다면 프로젝트는 산으로 갈 것이고 팀원들은 실망하게 될 것이다. 리더라면 직접 개발하지 않더라도 최신 트렌드는 꾸준히 이해하면서 팀원들과 커뮤니케이션을 해야 한다. 회의를 하는데 현재 프로젝트에서 요구하는 신 기술과 전혀 관계없는 라떼를 외친다면 빨리 그만둬라. 최근에도 회의를 하는데 엉뚱한 옛날이야기를 하길래 이 부분은 이런저런 신기술에 대한 부분이다라고 이야기해 주니 살짝 삐져서 가버렸다.

리더라면 회의 시간에 좋은 의견을 주는 팀원에게 긍정적 리액션을 해줘야 한다. 그런데 의견을 제시하는 것에 샘이 나는건지 무슨 의견만 내면 "그럼 니가 해" 라는 말을 툭툭 던지는 리더가 있다. 실제로 내가 일하는 곳에서도 있다.

그렇게 대응하면 어떤 팀원도 좋은 의견이 있어도 이야기 하지 않을 것이다. 발전도 없고 시간 낭비 회의가 될 것이기 때문이다.

프로젝트가 잘 진행되기 위해서는 리더의 역할과 능력이 정말 중요하다. 고객과 팀원과의 관계가 엄청 중요하기 때문이다. 그리고 리더는 항상 공부를 해야 한다. 라떼는 카페에서 맛있게 주문해서 먹는 걸로 끝내야 한다. 

그렇다고 그들의 오랜 경력과 경험을 무시하면 안된다. 프로젝트가 꼭 기술력으로만 성공하는 것이 아니기 때문에다.

멋진 리더가 되는 방법 중 하나는 팀원의 장점도 잘 살펴보고 응원하고 잘할 수 있도록 활용하는 것이다.

요즘은 정말 답답한 상황이 많이 발생하고 있다. 무엇이 중요한지 그래서 어떻게 해야 하는지 꼼꼼히 챙기고 진행하는 것이 필요한데 그저 대충대충 아무나 아무나 식으로 프로젝트를 준비하는 것을 보면서 정말 되기를 바라는 것일까 의문이 든다.

오늘도 열심히 스킬을 업 하는 신기한 연구소였습니다.