코더
1. 개요
Coder(코더) ・ Scripter(스크립터)
의사 코드나 명세서로 만들어져 있는 알고리즘 또는 로직을 실제 컴퓨터가 이해할 수 있는 형태로 번역하는 직업이다. 과거의 '코더'가 하던 일은 단순했기 때문에 컴퓨터에 의해 여러 차례 도태당했다.
- 1960~1980년대: 천공 카드 시절에는 먼저 프로그램을 짠 후 천공 카드에 구멍을 뚫어 컴퓨터가 이해할 수 있는 형태로 만들어야 했다. 자연스럽게 프로그래머와 단순 작업자 사이의 분화가 이루어졌다. 프로그래머가 코딩용지에 기입을 하면 작업자는 내용은 잘 모르지만 펀치 카드에 구멍을 뚫는 역할만 하는 것이다. 입출력 장치가 발전하면서 도태되었다.
- 1950~1990년대: 쓸만한 성능의 컴파일러가 아직 발명되지 않아 고급 프로그래밍 언어를 사용하면 실행 속도가 형편없던 시절이 있었다. 이 때 사람이 수작업으로 어셈블리어 코드를 작성한 뒤 병목 구간에 일일이 붙여넣는 작업을 했다. 컴파일러와 CPU 성능이 발전하면서 도태되었다.
2. 확장된 의미
'''제 실력이 없는, 무늬만 프로그래머인 단순 코딩 노동자'''를 일컫는 말.
본래 사전적인 의미만 놓고 본다면 코더(coder)는 '코딩(coding)을 하는 사람'으로, 개발자 가운데 현장에서 일하는 사람들은 코더의 정의를 만족시킨다고 할 수 있다. 하지만 고전적인 직업(목차 1.)으로서의 코더가 사라지면서 '코더'라는 말이 '오직 코드 치는 것 밖에 할 줄 모르는 부분집합・하위 분류들' 이라는 의미로 변하게 되었고, 결국 프로그래머 중 무능한 사람을 비하하는 멸칭으로 쓰이게 되었다. 비슷한 느낌으로 해외에서는 '''Code Monkey(코드 몽키)'''라는 경멸적 용어가 쓰이고 있다. 선진국에서도 부트캠프 출신이면 가능한 한 이력을 숨기려고 한다. 한국에서는 장작, 땔감 등이 이를 지칭하는 은어로 사용되곤 하며, 더 노골적으로는 '코딩 노예' 따위로 부르기도 한다.
의사 코드(Pseudo code)가 주어졌을 때 다른 사람이 만들어 놓은 소스 코드를 복사해서 문맥에 맞게 수정해서 그 의사 코드를 실제로 동작하는 코드로 구현할 수 있으면 직업을 가질 수 있다. 고졸, 문과 대졸 등 이공계 기초가 없는 사람이 6개월 정도 Full-time으로 학원 수업 또는 국비교육을 받거나 IT쪽 공업고등학교를 나오면 이 정도는 2000년 이후에는 누구나 할 수 있다. 하지만 이 정도 수준으로는 코더 소리나 들으며 저임금도 벗어나기 어렵다. 무엇보다도 30-40대가 넘어 슬슬 전문가로서 힘이 붙고 노후를 준비해야 할 때 유능한 신입이 쏟아져 들어오면 언제든지 늙고 병든(...) 자신이 대체될 수 있다는 불안에 떨게 된다.
2.1. 이들이 일으키는 문제
- 자신의 힘으로 프로그래밍을 할 수 없다. 프로그래머가 의사 코드를 만들어 줘야 한다.
- 코드를 최신 버전으로 개선할 수 없다. 영어가 안 되어서 한국어 번역 문서만으로 공부하다 보니 최신 정보에 소홀한 탓인 경우도 있다. 따라서 지원이 끊긴 라이브러리를 억지로 가져다 쓰는 막장 상황을 자주 일으킨다. 고객의 '레거시' 시스템에 호환성 레이어를 설치하다 안 돼서 OS 다운그레이드를 권유하는 상황까지 오면 답이 없다.
- 속도가 중요한 프로그램에서 프로그램 최적화를 하지 못 해 고객들의 불신을 받는다.
- 프로그램이 갑자기 꺼지거나 잘못된 결과를 내놓는 등의 오류가 생긴다. 왜 문제가 생겼는지 모르기에 해결도 못 한다. 그리고 보안 취약점을 막지 못 해서 중요한 비밀을 해커에게 털리거나 랜섬웨어에 감염당하고 협박을 당한다.
- 코딩 업무를 해내겠다고 약속하지만 예산과 시간만 쓰고 해내지 못 한다. 잘리고 손해배상 소송 당하기 전에 이직하려 든다. 후임자가 들어오면 전임자의 삽질에도 불구하고 마감일에 맞춰 맡은 업무를 끝내야 하기에 전임자의 욕을 한다.
- 해커라고 으스대고 싶지만 현실은 스크립트 키디에서 끝난다.
2.2. 코더를 벗어나지 못하는 이유
2.2.1. 완성된 개발 경험의 부족
입문자들 중 굉장히 많은 사람들이 기초적인 문법 공부에서 더 나아가질 않는다. 프로그래머는 기술직이다. 후술되어 있듯이, 과정이 어떻게 되든 눈으로 보이는 결과물을 만들어내는 게 가장 중요하다. 이러한 능력을 키우려면 간단한(CLI 수준에서 동작하는) 프로그램을 실제로 만들어 보는 것이 코드를 자신의 의도대로 작성하는 방법을 키우는 데 유리하다. 그리고 이산수학과 자료구조 공부를 통해 이론적인 지식까지 갖춰야 더욱 효율적으로 프로그래밍을 하는 방법을 깨우치게 되는 것이다.
C/C++, Java처럼 문법이 어려운 언어만 고집하는 것은 자칫 시간 낭비가 될 수 있다. 알고리즘 구현이나 관련자료 검색 등 다른 부분에 쓸 수 있는 시간을 굳이 문법 성분 구현에 낭비하는 꼴이기 때문. 소설가로 치면 스토리 구상할 시간에 문장 하나 완벽하게 쓰려고 쩔쩔매는 꼴이다. 그리고 이렇게 낭비된 시간은 당연히 업무 효율에도 악영향을 끼치며, 나아가 인사고과에도 불이익이 된다. C/C++와 Java는 목적 의식을 분명히 갖고 공부해야 한다. 그렇지 않으면 복잡한 메모리 관리와 OOP 기법, 수많은 라이브러리 및 모듈, 그 외 각종 비즈니스 로직에 사용되는 여러 기능들만 배우다가 제대로 된 기초를 다지지도 못한 채 끝나버리는 수가 있다. 그럼에도 불구하고 이런 언어만 하는 것은 주로 대학교에서 관련 전공을 하면 듣는 공통적인 언어들이기 때문.
많은 숫자의 서드파티 HW/SW가 함께 작동하는 복잡한 시스템 개발[1]이나 공학적인 알고리즘 개발 등 어려운 작업에서 문제가 더욱 두드러진다. 어차피 소프트웨어 엔지니어는 몇 가지 규격 문서 정도만 받을 뿐이므로, 여러 다른 HW/SW의 작동방식을 Low level에서 전부 이해하면서 개발하게 되는 경우는 사실상 전무하다. 중요한 것은 실질적으로 작동하는 최종 단계의 애플리케이션인데, 대다수의 코더들은 완성된 결과물을 만들어 본 경험이 별로 없어 혼자서는 일을 진행시키지 못한다.
이런 문제를 좀 더 잘 접근하는 방법 중 하나가 문법적으로 쉬운 언어로 working-prototype을 구현해서 테스트하는 것이다. 시스템의 복잡도 때문에 새로운 아이디어가 있다 해도 working-prototype을 구현해보기 전에는 가능한 지 아닌지 여부를 예측하기가 거의 불가능하다. 따라서 이런 작업을 할 때 가장 중요한 것은 시스템 내의 여러 서드파티 HW/SW와 함께 작동시켰을 때 '''작동하는지 안 하는지'''다. 최소한의 시간과 노력으로 알고리즘을 구현할 수 있어야만 working-prototype을 만들 수 있고 이를 통해 GO/NO-GO 타입의 의사결정을 할 수 있게 된다. 따라서 이런 종류의 프로젝트에서는 문법이 쉬운 언어로 개념을 검증한 뒤 실제 개발은 (빠른 성능이 필요할 때) 코어 부분만 C/C++를 이용하여 개선하는 식으로 이루어진다. 그런 코드가 얼마나 지저분하고 비효율적으로 만들어졌든 간에, 결과물을 내놓지 못하는 것보단 훨씬 낫다. 게다가 대학원, 또는 연구소가 아닌 일반 현업에서 프로그래머가 알고리즘을 '''직접''' 개발할 일은 거의 없다. 전부 기존에 나와 있는 것을 가져다 쓰는 것이다. 따라서 Python이나 JavaScript처럼 입문이 쉬운 언어로 '무언가가 돌아가는' 프로그램을 만들어 보는 것이 가장 중요하다.
다만, 문법적으로 어려운 언어만 알더라도 재능이 있다면 상관 없다. 정보올림피아드 출신들을 보면 문법적으로 어려운 언어들 밖에 할 줄 모르는데도 복잡한 시스템을 곧바로 만들어내기도 한다. 물론 이게 가능한 사람은 애초에 이런 글을 볼 필요가 없겠지만.
2.2.2. 직업에 대한 안일한 인식
코더들은 보통 '평생학습'보다는 '국비교육으로 3~6개월 배워서 안정적인 평생직장 갖기'를 선호한다. 하지만 프로그래머라는 직업은 결코 안정적인 직업이 아니다. '''기술이 계속 발달하는 한 프로그래머가 안정적인 직업이 되는 날은 영원히 오지 않는다'''. 게다가 최근 컴퓨터공학 관련 학과의 경쟁률이 급격히 올라가고 있고, 어문계열 전공자까지 IT 업계로 뛰어드는 마당이라 어중간한 레벨의 프로그래머는 앞으로 몸값이 더 낮아지면 낮아졌지, 높아지기는 힘들다고 예상할 수 있다. 단시간에 배워서 안정적인 평생직장을 가질 생각이라면 공무원이나 일반 사무직으로 가는 게 좋다.
프로그래머는 평생학습으로만 명줄을 이을 수 있는 직업이며, 이 때문에 억대 연봉을 받는 탑 프로그래머들도 40대, 50대까지 신기술에 적응하기 위해서, 시장에서 퇴출되지 않으려고 예외없이 학습에 엄청난 시간을 투자한다. 보통은 학습 시간이 업무 시간의 절반에 가까우며, 20%도 안 되면 현상을 유지조차 하지 못한다. 공부하기 싫어도 프로젝트를 하다보면 일이 막히니 강제로라도 배우게 되어 있으며, 이 때문에 학습과 업무가 순환 구조를 이룬다. 스스로 공부를 하든, 공부해서 얻은 지식을 다른 사람에게 전파하든, 업무의 일부이자 연장선으로 공부해야 한다. 결국에는 개발을 진정으로 사랑하고 이 분야를 즐기는 사람만이 성공할 수 있고, 살아남는 곳이다.
물론 공부할 시간이 명시적으로 주어지는 건 당장 주어진 프로젝트가 없을 때 뿐, 프로젝트를 진행하는 동안에는 그 프로젝트와 관련된 지식을 위주로 습득해야 한다. 지금 하고 있는 프로젝트와 관련없는 학습은 또 다른 시간 낭비일 뿐이다. 프로그래밍은 꾸준한 학습을 통해 두뇌를 훈련시킨 사람이 잘 하는 것이지, 굳이 천재적인 지능이 있어야만 하는 것은 아니다. 프로그래머가 마주치는 일반적인 문제들은 지능 부족이 아니라 공부를 안 해서 해결법을 모르는 경우들이다.
2.2.3. 우물 안 개구리
2020년에 아직도 네이버 위주로 검색을 하고 있다면 사실 반쯤 프로그래머라고 하기는 글렀다. 네이버는 여러가지 이슈나 후기 등을 종합하는 식의 생활정보 쪽에 특화된 포털 사이트로, 빅 데이터 기술을 이용한 정보 처리나 원하는 자료를 찾도록 검색을 도와주는 AI 시스템도 '''매우 미흡하다'''. 여기에 회사 정책상 네이버(블로그,카페) 내부의 정보를 우선적으로 보여주고, 외부의 정보는 우선도를 떨어트리거나 아예 잡히지 않기도 한다.
따라서 대부분의 전문・학술적 정보는 구글을 통해 검색한다. 이것은 '''전문대 1학년 또는 부트캠프 1개월차''' 새내기에게도 기본 중의 기본이다. 네이버 검색과 구글 검색을 비교하면 검색 결과의 질이 크게 달라진다. Stack Overflow나 Statalist 등 중견급 프로그래머들이 서로 문제와 답변을 주고받는 커뮤니티에 들어가서 필요한 트릭을 찾아내는 편이 훨씬 유익한데, 이런 개발자 커뮤니티의 게시글에 대한 접근성은 구글이 압도적으로 높다.
특히 해외 사이트 검색을 위한 기초 영어 실력은 매우 중요하다. 어느 정도 실력이 있는 프로그래머들이 많이 상주하면서, 동시에 유동인구도 많고 활성화도 잘 되어 있는 개발자 커뮤니티는 한국에선 전멸 수준이라 영어권 국가의 사이트들을 살펴봐야 한다. 이런 곳에서 최소한 눈팅이라도 하려면 일정 수준의 영어 실력은 갖추고 있어야 한다. 영어 공부를 안하면 절대로 코더 수준에서 벗어날 수 없다. 물론 영어를 몰라도 코딩 자체는 가능하나, 프로그래밍을 원활하게 해 주는 라이브러리, 프레임워크 등의 공식 문서는 대부분 영어로 쓰여 있다. 한국에서 나온 프레임워크는 거의 없는 거나 마찬가지이기에, 공식 문서를 읽지 않고 한국어 번역이나 블로그만 찾아다니면 단편적인 지식만을 얻을 뿐이다. 하다못해 Stack Overflow에만 들락거릴 때에도 영어는 필수이다.
2.2.4. 기타 지식 및 커뮤니케이션 부족
개인정보를 다루는 시스템 등 민감한 시스템을 만드는 경우에는 법률적 지식 및 규제도 어느정도 숙지하고 있어야 한다. 그러나 코더들은 이러한 지식을 곁다리 식으로 취급하기에, 굳이 숙지하려 하지 않는다. 때문에 이런 시스템을 전문적으로 개발하는 업체들은 단순 코더나 신입 프로그래머 보다는 경력이 어느정도 쌓인 프로그래머를 선호한다. 단순 코더가 이런 업체에 들어갔다가는 회사 자체가 공중분해될 수도 있다.
다만 이런 경우는 보통 중소기업에 해당되는 얘기이다. 대기업의 경우 대개 법무를 검토하는 부서가 따로 있기 때문에 일반 프로그래머가 프로그래밍할 때는 그에 걸맞게 분업을 실시하며, 이를 시험하는 부서 역시 그에 맞게 분업을 수행한다. 하지만 중소기업의 경우 그럴만한 여력이 되지 않기 때문에, 프로그래머가 법적인 문제까지 모두 검토해야 하는 가능성이 높다.
하지만 팀 내 또는 팀 사이의 커뮤니케이션이 제대로 이뤄지지 않는 경우는 분업이 제대로 되지 않을 수 있기에, 이런 경우는 대기업이라고 안심할 수 없게 된다. 분업이 되지 않으면 법률팀에서 요청한 요구사항이 개발팀 프로그래머에 제대로 하달되지 않을 수도 있기 때문에, 결과적으로는 필수 기능의 결여로 인하여 프로그램 자체가 위법 프로그램이 되는 치명적인 문제가 발생할 수 있다. 뿐만 아니라 개발 과정에서는 어떻게든 팀원 교체가 일어나기 마련인데, 이 과정에서 인수인계가 제대로 되지 않으면 코딩 스타일 분쟁 등으로 분업이 실패할 수 있다. 확산성 밀리언아서의 서비스가 종료된 것도, EZ2AC의 음파공격 버그도 작업의 인수인계가 제대로 이뤄지지 않은 것이 결정적인 원인이었다.
2.3. 코더가 주로 종사하는 직종
SI 중에서도 하청업체로서 인건비 절감을 통해 이익을 챙기는 속칭 보도방에서 경력을 쌓는다. 하지만 이런 곳에서 쌓은 경력으로는 연봉 높은 곳으로 이직이 안 된다. 잘 풀리더라도 공공기관 인프라 구축을 맡는 SI 중소기업을 못 벗어난다. 또한 주로 스프링 프레임워크를 기반으로 하는 Java 웹 개발(전자정부표준프레임워크 등)이나 모바일 앱 개발 위주로 활동하는데, 이 쪽은 버그가 났다 해도 단순 불편사항인 경우가 많지만 연봉이 상대적으로 낮다. 상대적으로 연봉이 높으나 버그 하나로 사람 목숨이 오갈 수 있는 임베디드 시스템 쪽 업계로는 가려 하지도 않으며, 굳이 간다고 해도 업계에서 받아주지 않는다.
3. 코더라고 비방하는 것도 문제
3.1. 욕하는 사람이 오히려 실력 부족인 경우
자신은 실력 있는 프로그래머라고 주장하지만 자기 회사 내의 '코더' 때문에 힘들다고 말한다면 일단 한 번 의심해 보자. 실제로는 이런 상황일 수도 있다.
- 스스로의 코드 리딩 능력이 떨어져서 남이 쓴 코드를 해독하지 못한다.
이 경우는 그 사람의 주장과는 정반대로 스스로가 팀 내에서 제일 실력이 떨어지는 프로그래머다.
- 리더십의 부재로 팀 내에 코딩 스타일이 합의되지 않았다.
팀 내 모든 팀원이 다른 사람을 실력이 떨어지는 사람으로 생각하고 있을 것이다.
- 팀원이 너무 많다.
정치적인 이유 등으로 무능한 인력을 억지로 끌어안고 있는 팀이 있을 수 있다. 사실 본인이 이직하지 않은 탓이 제일 크다.
프로그래밍에 절대적인 진리나 정답 같은 것은 없다. 심지어 수학에도 '나누기 2'와 '곱하기 0.5'라는 똑같은 답을 얻는 두 가지 연산법이 있다. 간결한 코드가 유리한 곳도 있고 장황한 코드가 유리한 곳도 있으며 사람에 따라 본인에게 편한 스타일이 각기 다를 수도 있다. 팀 내 코딩 스타일 같이 일정 부분 양보는 할 수 있겠지만 완벽히 자신의 스타일에 맞추라고 하는 건 가능하지도 않고 팀내 불화만 일으킨다.
요약하자면, 역지사지. 현 직장도 문제가 있고 전 직장도, 전전 직장도 문제가 있다면 문제는 직장에 있는 게 아니다. '''자신'''에게 있는 것이다.그리고 그 사람의 주장이 정말이라고 하더라도 본인 책임이 전혀 없다고 할 수도 없다. 그렇게 실력차가 심해서 본인을 괴롭힌다면, 자신이 사수가 돼서 못 하는 사람을 교육시켜줄 수도 있는 것이다. 해당 코더가 교육까지 거부하고 있다면 '코더 때문에 힘들다'가 아니라 '그놈 말 더럽게 안 듣는다'라고 말하고 있을 것이다.
3.2. 잘못된 직장 때문
이 때는 동료들을 코더라고 비방하는 것보다 이직이 우선이다. 그렇지 않으면 허송세월할 가능성이 매우 높다. 필요하다면 연봉을 좀 낮춰서라도 자가학습이 잘 되는 회사로 가는 것이 더 낫다.
먼저, 공부할 시간을 주지 않는 소프트웨어 개발 회사에서 일하고 있다면 SI/SM 외의 일감을 따 올 확률이 거의 없기 때문에 미래가 없다고 봐도 좋다. 현재 진행중인 프로젝트와 관련된 기술 서적을 도서관에서 빌려와 읽는 것마저도 불허하고 '집에서 읽어라' 같은 말을 한다든지 하는 경우다. 하다못해 Baekjoon OJ 같은 곳에서 문제를 풀 시간조차 주지 않는 것도 포함된다.
그리고 특별한 사정[2] 없이 구글을 방화벽에서 차단하고 있는 회사라면 아주 이상한 곳이므로 그만두는 게 좋다. 네이버의 경우는 Stack Overflow로 가는 링크를 제공하지 않는 경우가 많아 어쩔 수 없이 구글을 통해야만 하는데, 이걸 막는 것 자체가 공부할 기회를 안 준다는 의미이다. 게다가 CPU 스펙, 최신 보안 이슈 등의 고급 자료는 구글 검색이 아니면 제공조차 하지 않는 경우가 많은데, 이런 걸 막는 건 그 자체로 '우리 회사는 그 수준에서 남겠다'고 자폭하는 꼴이다. 이런 경우는 가급적 빨리 사직서를 제출하고 다른 곳을 찾아야 한다. 금융권의 경우 보안이라는 명목으로 구글, 네이버, 심지어 개발 툴까지 차단하는 경우가 있다. 개발자 개인의 실력 향상을 생각한다면, 은행과 금융에 관련된 기업은 피해야 한다.
그리고 장비의 성능이 부족해서 성능상 한계에 도달하고 있는데도 회사가 돈드는 게 싫다며 업그레이드를 해 주지 않는다면 그 회사는 발전 가능성이 제한된 곳이니 돈 더 받고 싶으면 이직을 알아보는 게 좋다. 그 회사의 동료들이 실력이 떨어지는 것도 회사가 장비에 돈을 안 쓰기 때문일 것이다. 돈을 아끼는 데만 집중한 나머지 꾸준히 지속적으로 더 큰 돈을 벌 기회를 걷어차고 있는 것이다. IT 개발 부서는 프로그래머의 시간이 곧 돈 버는 수단이다. 예를 들어, 대용량의 컴파일이 필요하면 안정성 높은 ECC 램이 대용량으로 장착되어 있는 워크스테이션을 써야 한다. 그 외에도 요청이 들어와도 대형 모니터를 사주지 않는다든지, 상용 개발 툴 대신 공짜 툴만 쓰라고 강요한다든지, 사내 솔루션 없이 주먹구구식의 해결법을 강요한다면 이런 회사에 속한다. 그리고 이런 회사는 결코 좋은 소프트웨어 회사로 인정받을 수 없으며, 그 민낯은 결국 높은 이직률로 드러난다.
4. 대안 직업
프로그래머라는 직종은 공부를 쉴 수 없는 직종이다. 이것은 단점이 되기도 하지만 장점이 되기도 하는데 중간에 오랫동안 일에서 손을 놓고 있었어도 비교적 단시간의 학습으로 현업 프로그래머와 동등한 실력을 발휘할 수 있는 직종이기도 하기 때문이다. 하지만 그 학습 자체가 뇌 개조를 방불케하는 큰 고통을 수반하는 게 문제다.[3] 그래서 공부를 계속하고 싶지는 않은데 컴퓨터 분야에 종사하고 싶고 코더 소리는 듣고 싶지 않다면 SM 쪽에서 오퍼레이터 직종을 추천한다. 둘은 상하위의 개념은 아니고 동등한 전문성을 갖춘 직업이지만 오퍼레이터는 '''현장 경험'''과 '''순발력'''을 더 중요하게 보기 때문에 따로 학습을 할 필요가 없다.
5. 여담
프로그래밍 언어도 인간 언어와 비슷한 면이 있기에, 인간 언어를 못 하는 이유와 유추해서 살펴보면 비슷한 면이 발견된다. 논리력이 부족하고 연습이 부족하면 문법을 외우고 있다 한들 작문, 회화 등에서 유용한 결과물을 내놓지 못한다는 점에서 비슷하다. 자세한 내용은 프로그래밍 언어 항목에 서술되어 있다.