최근 수정 시각 : 2024-12-18 16:07:22

프로그래머

소프트웨어 개발자에서 넘어옴
1. 개요2. 종류
2.1. 컴퓨터 과학자2.2. 보안 개발자2.3. 보안 오퍼레이터2.4. 소프트웨어 아키텍트(SA)2.5. 게임 개발자2.6. 웹 개발자
2.6.1. 프론트엔드 개발자
2.6.1.1. 웹 퍼블리셔(UI 개발자)
2.6.2. 백엔드 개발자2.6.3. 풀 스택 개발자
2.7. 모바일 개발자2.8. 전산 정보 시스템2.9. 계산과학자2.10. 데이터 전문가2.11. CI/CD2.12. 코더
3. 되는 방법
3.1. 프로그래밍 언어3.2. 필요한 장비
3.2.1. 운영체제3.2.2. 모니터3.2.3. 키보드
3.3. 분야에 따라 필요한 지식3.4. 꾸준한 공부3.5. 기술영어
4. 현실
4.1. 연봉과 근무4.2. 인사고과
5. 기타6. 유사 용어7. 관련 문서

1. 개요

Programmer

컴퓨터 프로그램의 논리나 알고리즘을 설계하고 프로그램을 작성하고 테스트하는 사람. 프로그래머는 소프트웨어 엔지니어, 컴퓨터과학자, 해커[1]로 간주되기도 한다.

후술될 코더나 스크립터라는 명칭으로 부르는 경우도 있는데, 실제로는 차이가 있으므로 구분해 부르는 것이 좋다. 특히 국내에 한정해서 코더는 주도적인 개발 능력 없이 주어진 일만 하는 프로그래머를 비하하는 용어로 쓰이기도 하므로, 상대방에게 깊은 유감을 줄 목적이 아니라면 굳이 코더라고 부르지 말자. [2]

2. 종류

'프로그래머' 라는 단어 하나로 간편하게 통칭하여 부르고 있긴 하지만, 프로그래머에도 여러 분야가 있다. 컴퓨터과학을 연구하는 학자부터 고급 언어와 툴을 다루는 프로그래머, 추가로 저급 언어까지 다루는 프로그래머까지 그 스펙트럼은 어마어마하게 넓다.[3]

컴퓨터 프로그래밍 기술에 능숙한 사람들은 유명세를 타기도 한다. 그리고 종종 저명한 프로그래머들 중에는 "해커"라는 이름으로 불리는 사람들도 있다.[4]

프로그래머라는 직종이 이런 넓은 스펙트럼을 가지고 있기 때문에 단순히 뭉뚱그려 부르기에는 상당히 무리가 있다. 비유를 하자면 트럭, 택시, 버스, 중장비 기사를 전부 뭉뚱그려 '운전자'라고 표현하는 것과 같다.

2.1. 컴퓨터 과학자


[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]
[ 펼치기 · 접기 ]
||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 || 수학( 해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학( 환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학( 형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU( 그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
기술 기계어 · 어셈블리어 · C/ C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시( SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속
연구

기타
논리 회로( 보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{ 컴파일러( 어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩( 유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도( 최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리( 기계 번역 · 음성인식) · 버전 ( 버전 관리 시스템 · Git · GitHub)

''' 이론 컴퓨터 과학
{{{#!wiki style="display: inline-block; font-family:Times New Roman, serif;font-style:italic"'''
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px)"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px"
<colbgcolor=#a36> 이론
기본 대상 수학기초론{ 수리논리학( 논리 연산) · 계산 가능성 이론 · 범주론 · 집합론} · 이산수학( 그래프 이론) · 수치해석학 · 확률론 통계학 · 선형대수학
다루는 대상과 주요 토픽
계산 가능성 이론 재귀함수 · 튜링 머신 · 람다대수 · 처치-튜링 명제 · 바쁜 비버
오토마타 이론 FSM · 푸시다운 · 튜링 머신( 폰노이만 구조) · 정규 표현식 · 콘웨이의 생명 게임 · 형식언어
계산 복잡도 이론 점근 표기법 · 튜링 기계^ 고전, 양자, 비결정론적, 병렬 임의접근 기계^ · 알고리즘 · 자료구조 · 알고리즘 패러다임( 그리디 알고리즘, 동적 계획법)
정보이론 데이터 압축( 무손실 압축 포맷 · 손실 압축 포맷) · 채널 코딩(채널 용량) · 알고리즘 정보 이론(AIT) · 양자정보과학
프로그래밍 언어이론 프로그래밍 언어( 함수형 언어 · 객체 지향 프로그래밍 · 증명보조기) · 메타 프로그래밍 · 유형 이론 · 프로그래밍 언어 의미론 · 파싱 · 컴파일러 이론
주요 알고리즘 및 자료구조
기초 정렬 알고리즘 · 순서도 · 탐색 알고리즘
추상적 자료형 및 구현 배열^ 벡터^ · 리스트^ 연결 리스트^ · 셋(set)^ 레드-블랙 트리, B-트리^ · 우선순위 큐^, 피보나치 힙^
수학적 최적화 조합 최적화 외판원 순회 문제 · 담금질 기법 · 유전 알고리즘 · 기계학습
볼록 최적화 내부점 방법 · 경사하강법
선형계획법 심플렉스법
계산 수론 및 암호학 밀러-라빈 소수판별법 · Pollard-rho 알고리즘 · 쇼어 알고리즘 · LLL 알고리즘 · 해시( MD5 · 암호화폐 · 사전 공격( 레인보우 테이블) · SHA) · 양자 암호
대칭키 암호화 방식 블록 암호 알고리즘( AES · ARIA · LEA · Camellia) · 스트림 암호 알고리즘(RC4)
공개키 암호화 방식 공개키 암호 알고리즘( 타원 곡선 암호 · RSA) · 신원 기반 암호 알고리즘(SM9)
계산기하학 볼록 껍질 · 들로네 삼각분할 및 보로노이 도형^Fortune의 line-sweeping 알고리즘^ · 범위 탐색^vp-tree, R-tree^ · k-NN
그래프 이론 탐색^ BFS, DFS, 다익스트라 알고리즘, A* 알고리즘^ · 에드몬드-카프 · 크루스칼 알고리즘 · 위상 정렬 · 네트워크 이론
정리
정지 문제 대각선 논법 · 암달의 법칙 · P-NP 문제미해결 · 콜라츠 추측미해결
틀:이산수학 · 틀:수학기초론 · 틀:컴퓨터공학 }}}}}}}}}


컴퓨터과학을 전문적으로 연구하는 사람. 대개 이쪽은 컴퓨터과학 학위 또는 컴퓨터과학과 관련된 다른 전공의 학위를 가지고 엔지니어, 연구원, 교수로 일한다.

신호처리, 선형대수, 암호학 같은 알고리즘들은 분야를 가리지 않고 널리 쓰이기 때문에, 논리적 엄밀성과 성능만이 최우선적 고려 사항이고, 성능 좋은 수학 라이브러리 몇 가지를 개발해 놓으면 몇십 년이 지나더라도 별로 변하지 않는 편이다.

2.2. 보안 개발자

해킹 및 정보 보안 관련 기술들을 다루는 프로그래머를 의미하며, 이를 위해서는 많은 기반 지식이 필요하다. 필요하면 서버 등의 플랫폼의 보안성 향상을 위해 툴을 준비하거나 서버 프로그래밍 자체를 튜닝하고 감시할 체제를 준비해야 하기 때문에 오랜 소프트웨어 개발 경력을 자랑하는 노련한 경력자들이 대부분이다. 업무에 비해 책임이 막대하며 특히 보안 사고가 터지면 모든 책임을 뒤집어쓰는 직종이기 때문에 IT업계에서도 급여는 잘 쳐줄지언정 업무상 대우는 여타 소프트웨어 개발자들에 비해 극한직업으로 꼽힌다.

운영체제, 네트워크( TCP/IP)에 대해 매우 깊은 이해가 필요하고 C언어를 매우 잘 다룰 줄 알아야 한다.[5] 최소한 한 종류 이상의 어셈블리어를 다룰 수 있어야 한다. 현대 암호학에 대해 개념 정도는 알고 있어야 하며(반드시 암호 알고리즘을 만들 줄 알아야 하는 건 아니다) 높은 수준의 리버스 엔지니어링 실력도 요구된다.

2.3. 보안 오퍼레이터

국내에서는 보안 관리자, 보안 시스템 유지보수 전문가 등으로 부른다. 하지만 영어권에서는 개발자가 아니라 Operator라고 분명히 구분한다. 국내에 이런 오퍼레이터 전문 육성 코스가 없어서 다들 프로그래밍을 하다가 이쪽으로 넘어오는데 전공 지식을 거의 활용할 수 없어서 기초부터 새로 배워야 하는 경우가 부지기수다. 오퍼레이터는 프로그래머의 하위 분류가 아니라 이웃 분류이다. 동등한 전문성을 갖추고 있는 반면 그 전문 영역이 별로 겹치지 않는다.

이들은 개발자와 달리, 운영 중인 시스템을 지속적으로 모니터링하다가 보안침해가 의심되면 신속하게 차단하고 피해 정도를 파악해 복구하는 일을 한다.

2.4. 소프트웨어 아키텍트(SA)

마이크로소프트의 정의에 따르면, 전략, 조직 역학, 프로세스, 커뮤니케이션, 리더십 등 관리능력과 엔지니어링에 대한 깊은 이해를 갖춘 개발 지휘자를 아키텍트라 부른다. 여길 참고하자

프로그래밍과 기획 능력이 둘 다 필요하다. 둘 중 하나라도 부족하면 정상적으로 업무를 진행하기 어렵다.
  • 컴퓨터: 시니어 프로그래머 이상의 컴퓨터 구조에 대한 지식, 각 언어 특성에 대한 이해, 유지보수를 감안한 클래스 구조 설계 능력
  • 기획: 요구사항 수집, 분석, 조직 관리 능력, 리스크 관리 능력 등

2.5. 게임 개발자

파일:상세 내용 아이콘.svg   자세한 내용은 게임 프로그래머 문서
번 문단을
부분을
참고하십시오.
파일:상세 내용 아이콘.svg   자세한 내용은 비디오 게임 제작자 문서
게임 프로그래머번 문단을
부분을
참고하십시오.

2.6. 웹 개발자

웹 개발자는 HTTP 프로토콜, TCP 등 네트워크를 매개체로 사용하는 웹 서버, 웹 사이트와 관련된 소프트웨어 개발자, 소프트웨어 엔지니어를 말한다. 대다수의 웹 개발자들은 웹 디자인, 정보 설계, 사용자 인터페이스 설계, 프로젝트 관리, 웹 서버 및 데이터베이스 관리, 웹페이지 코딩 및 프로그래밍 관련 기술을 가지고 있다. 일반적으로 프로그래머나 개발자라고 하면 웹 개발자를 의미할 정도로 비중이 높은 편이다.

외국에서는 각자의 역할이 크게 분리되고 웹 디자인 분야까지 상당한 투자가 이루어지지만, 국내에서는 대부분이 풀스택 개발자들로 해결을 보려는 경향이 강하다. 그것과는 별개로 국내외를 가리지 않고 웹 개발자라면 기본적으로 풀스택 및 데브옵스 관련 기술을 지녀야 하며, 이러한 기술들이 있어야만 적재적소에 필요한 곳에 투입될 수 있다. 기술을 분리하는 것은 결국 역할일 뿐이지 다른 역할의 기술을 이해하지 못하면 협업이 불가능하기 때문이다. 디자이너와 개발자의 싸움은 앞으로도 계속될 것이다.

2.6.1. 프론트엔드 개발자

정적인 마크업을 제외하고 브라우저 위에서 동작하는 코드를 작성하는 개발자. 좀 더 자세히 말하면 프론트엔드 개발자는 백엔드 API에서 가져온 데이터의 출력, 입력을 통한 비지니스 로직 구성과 사용자와 대화하는 사용자 인터페이스 부분을 작업하는 개발자를 말한다. 디자이너가 준 디자인을 구현하고 아니면 직접 디자인도 해결하고 State Management 및 Lifecycle, 비동기 처리에 대한 충분한 이해가 필요하다.[6]

유사한 직종으로 아래의 웹 퍼블리셔가 있다. 프론트 엔드 개발자는 프론트 엔드와 백 엔드의 완전한 분리 구조를 지향하는 업무 스타일의 직군으로서 (웹 퍼블리셔와 같이 인터페이스의 디자인 관점도 있지만) 웹 퍼블리셔와 달리 컴포넌트 아키텍처를 지향하며, 이벤트나 서버와 API 통신해서 로직을 어떻게 푸는 관점을 중시한다. 둘의 차이점은 사용하는 언어와 어떤 것에 특화되어 있는 지를 보면 된다. 퍼블리셔는 HTML, CSS 같은 마크 업 언어와 약간의 JavaScript를 사용하여 디자인을 정적인 페이지로 표현하는 것에 특화되어 있지만, 프론트 엔드 개발자는 JavaScript 계열의 언어를 사용하여 서버 간의 상호작용(Interaction)을 로직으로 풀어나가는 것에 집중한다.

웹 브라우저 프로그램 위에서 동작하는 JavaScript를 사용하므로, 프론트엔드 개발자가 되고 싶다면 깊은 수준으로 이해하고 있어야 한다. 최근 나오는 프론트엔드 프레임워크도 거의 대다수가 JavaScript에서 파생되어 있다. 최근에는 WASM으로 컴파일되는 경우가 있어[7] 무조건적인 JS 사용은 지양되지만 그럼에도 배워두고 알아두는 것과 전혀 모르는 것은 차이가 크다.
2.6.1.1. 웹 퍼블리셔(UI 개발자)
HTML 중심이거나, 서버 사이드가 감싸는 웹 구조의 형태를 지향하는 업무 스타일의 직군으로서 웹 퍼블리셔는 사용자에게 보여지는 인터페이스 영역을 작업하고, 개발자는 데이터의 비지니스 로직을 전반으로 담당한다.

사실상 국내에서만 존재하는 명칭이기 때문에 해외에서는 UI개발자 등으로 불린다.

2.6.2. 백엔드 개발자

백 엔드란, 요청을 받는 서버 프로그램을 지칭하며, 이 프로그램을 작성하는 개발자를 백엔드 개발자라고 한다.

백 엔드 개발자도 기존 개발자와 스펙이 조금 다르고, 백 단에서 모든 작업을 완료해야 하며, 데이터베이스 분석과 API서버를 개발한다. 프론트 엔드에서 전달된 데이터의 포맷이나 데이터베이스 입출력 및 다양한 비즈니스 프로세스를 프로그래밍 코드로 구현하는 역할을 한다. 데이터베이스, 웹 서버, 네트워킹 등 웹 서버의 인프라에 대한 이해가 필요하다.

일반적으로 클라이언트에서 들어온 요청을 효율적으로 DB에 쿼리하여, 응답할 수 있는 코드를 작성하는 것이 주 업무이며 널리 쓰이는 언어로는 Java[8], PHP[9], Rust, C#[10]등이 있는데 요즘은 JavaScript Node.js를 통해 사용이 가능하게 되었다.[11] 다만 백엔드 단의 설계 개념은 jdbc를 비롯 자바에서 나온 경우가 많기에 자바를 사용하지 않더라도 배워두고 알아두면 유용하다. 이외에도 Python[12]이나 Ruby[13], Go를 사용하는 경우도 있지만 국내에서는 찾기가 힘들기에 해외 취업을 노린다면 이러한 언어들도 고려할만한 대상이다.

보통 이런 언어를 다루고 SQL을 통해 하나 이상의 RDB를 다룰 수 있어야 업무가 가능하다.[14] 고급 개발자로 갈수록 DB관리 및 성능튜닝, 서버에 대한 직접적인 관리 능력이 요구되며 ERP나 금융계열 회사로 취업할 경우 비즈니스 로직을 이해하는 것이 상당히 중요해진다. 한국의 학원에서 제일 많이 양산되는 것이 스프링, 전자정부표준프레임워크를 속성으로 배운 서버 개발자이다.

아래의 풀 스택 개발자를 제외하면 주로 백 엔드 개발자들의 평균 연봉이 프런트 대비 상대적으로 조금씩 높아지는 경향이 있다. 하지만 개발자는 같은 직종이라도 능력치나 회사에 따라 케바케가 극심하게 갈리기 때문에 단순히 이것만 보고 백 엔드를 선택하지는 말자. 자칫하면 멋 모르고 SI로 끌려갈 수도 있다.

2.6.3. 풀 스택 개발자

프론트 엔드와 백 엔드를 둘 다 프로그래밍 할 수 있는 능력자로서, 일반적으로 스타트업 같은 소기업에서 인건비를 줄이기 위해 많이 필요로 한다. Node.js의 등장으로 JavaScript를 사용한 서버 프로그램 작성이 가능해지고, 또 JavaScript를 활용한 React, Angular 같은 프론트 엔드 프레임워크도 급속도로 발전하면서 JavaScript 언어 하나로 백 엔드, 프론트 엔드 모두 프로그래밍이 가능하게 되면서[15] JavaScript를 할 수 있는 인력을 채용하여 한 사람이 두 영역 모두 담당하는 경우가 많아지게 되었다. 일은 두 배지만 월급은 한 사람분 다만 자바스크립트 자체가 워낙에 속터지는 언어이기에 최근에는 Flutter 등을 이용해 웹앱 풀스택을 해결하는 경우도 적지만 있다. 레거시에 대응이 안 된다는 단점이 있지만 스타트업의 경우 전혀 문제가 없고, 자바스크립트와는 비교 자체가 안 되는 속도로 개발을 하기에 훨씬 적은 인원으로도 충분하다는 장점이 있다. 최근에는 Flutter로 프론트 부분을 빠르게 해결한 뒤 서버와 데이터베이스 부분에서는 PHP 또는 스프링부트와 같이 다양한 솔루션을 도입하는 도전도 부분적으로 이루어지고 있다. 기술의 파편화가 오히려 줄어들고[16] 디자인 패턴도 간결해지며 단순 웹서비스가 아닌 모바일, 임베디드 등에서도 사용 가능하다는 점이 강점이다. 이외에도 Blazor 또한 ASP.NET부터 다져진 경험으로 훌륭한 서비스를 만들 수 있다.

최근에는 기술이 급속도로 발전하는 동시에 개발 장벽은 더욱 내려가 현재는 아래의 DevOps 능력까지 겸비해야 진정한 풀 스택으로 평가해주는 인식도 늘어나고 있다. 대표적으로 Docker, 클라우드 컴퓨팅 등등의 배포 및 운영 관련 기술이 더욱 많아지고 동시에 예전처럼 Linux 서버를 손으로 구축하고 온 프레미스로 배포 환경을 만들어줄 인프라 전문가에 대한 수요가 줄었기 때문. 거기에 더해 웹 디자인까지 풀스택 개발자가 배워서 해결하는 경우도 늘어났다.[17]

만약 웹 개발을 주력으로 한다면 풀스택 능력은 취업시장에서 기본 중의 기본이라고 생각하면 된다. 물론 현실은 그렇지 못한 인력이 훨씬 많기에 풀스택을 못하더라도 구인하는 경우는 심심치 않게 있다. 다만 그런 개발자의 경우 장기적인 미래를 보장받기가 매우 어렵다.[18] 풀스택은 웹 개발이 아닌 직종에서도 기본 소양으로 취급하는 경우가 많고, 대개는 풀스택에 더해 임베디드나 인공지능 등의 추가적인 능력을 요구하게 된다.[19]

2.7. 모바일 개발자

스마트폰 애플리케이션을 개발하는 사람이다. 2010년 이후 지금까지 가장 많이 사용되는 안드로이드, iOS 두 가지 모바일 운영체제의 소프트웨어를 개발한다. 사람, 조직에 따라 한 종류만 개발하기도 하고 둘 다 개발하기도 한다. 상술한 풀 스택 개발자 중에서는 모바일 개발자 또한 겸하는 경우가 종종 있다.
  • 안드로이드 APP 개발: 안드로이드는 Java를 기반으로 하는 언어이기 때문에 Java에 대한 지식이 필요하며 2017년부터 구글에서 표준 언어로 채택하고 있는 Kotlin 또한 학습해야 한다.[20] 단, 유니티 엔진으로 개발하는 대다수의 인디 모바일 게임 개발자의 경우는 C#에 대한 지식이 필요하다. 물론 Java도 쓸 수 있지만 대부분의 유니티 개발자들은 C#을 애용하기 때문. 안드로이드 앱은 이클립스로 개발이 가능했다가, 구글의 정책으로 안드로이드 스튜디오에서만 개발이 가능하도록 변경됐다.
  • iOS APP 개발: iOS macOS의 언어와 동일하게 Objective-C Swift에 대한 지식이 필요하다. 두 가지 언어의 컴파일러로는 대부분 macOS의 Xcode를 사용하며 이는 macOS에서 앱스토어를 들어가면 설치할 수 있다. 단, 유니티 엔진으로 개발하는 대다수의 인디 모바일 게임 개발자의 경우는 안드로이드와 마찬가지 이유로 C#에 대한 지식이 필요하다.
  • 하이브리드 APP 개발 (안드로이드와 iOS 모두 호환 가능): HTML5로의 발전, CSS3의 발전 등을 통해 제약이 많던 이전 웹 언어들과 달리 현재는 다양한 애니메이션과 기능이 추가되었으므로 이를 활용해 OS의 제약 없이 개발할 수 있게 되었다. 그러나 한 종류 언어 위주로 개발하는 데 비해 출력이 매끄럽지 않아서 대다수 스마트폰 앱으로 먹고사는 벤처기업은 하이브리드 앱을 개발하지 않고 네이티브 언어를 채택한다. 스마트폰 앱이 주력사업이 아닌 대기업들의 경우엔 개발 비용을 줄이고자 하이브리드 APP을 많이 채택한다. 오픈 소스로 Sencha 등을 활용하는 편이다. 이쪽 분야에서는 Xamarin이나 Flutter 등의 프레임워크가 유명하다. 물론 여기서도 거지 같은 Xcode의 사용은 불가피하다.

2.8. 전산 정보 시스템

  • SI(시스템 구축) 문서 참고.
  • SM(시스템 유지보수) 문서 참고.
  • ERP

2.9. 계산과학자

계산과학 방법론으로 생물학, 물리학, 경제학 등 타 분야 과학을 연구한다.

프로그래밍에 특정 분야의 전문 지식이 요구될 경우 프로그래머는 프로그래밍을 해내기 어려운데, 이런 영역에서는 해당 분야의 전문가가 프로그래밍을 배워서 직접 코딩한다.

의사가 직접 의료 프로그램을 통계화, 수치화한다든가, 국과수 직원이 치아 감별을 통한 개인 식별을 위한 프로그래밍을 한다든가, 이과 대학 교수가 모델링-시뮬레이션 툴을 만든다든가, 병리학자가 조직 샘플에서 정상 조직과 병변 조직을 나눠서 분류하고 정상인의 샘플과 대조하여 질병 진단 및 질병의 진행 단계 파악에 활용하는 등의 경우(실제로 있는 케이스)가 이에 속한다.

이들은 프로그램을 구현할 수만 있으면 프로그램 최적화 능력은 코더 수준이라도 상관없다. 어차피 전문가들은 해당 분야에 대한 지식이 없어서 이런 프로그램을 만들기 어렵기 때문이다. 프로그램에 불필요한 부분이 덕지덕지 붙어 있든 개발에 시간이 오래 걸리든 상관없다. 프로그램이 성공하면 프로그래머에게 맡겨서 개선시키면 그만이다.

어디까지나 본업이 따로 있기 때문에 실제 프로그래밍은 최소한도로만 수행하거나 아예 수행하지 않는다. 대부분 한 종류 이상의 프로그래밍 언어에 능숙하지만 결과물을 프로그램으로 발표하는 게 아니라 논문으로 주로 발표하는 것도 큰 차이다. 프로그래밍 언어도 정말 순수하게 도구로서 다루는 것이지 그것이 생계 수단인 건 아니다.

2.10. 데이터 전문가

통계학과 데이터베이스관리시스템, 빅데이터 통계분석 기법을 배운 전문가. 통계와 수치 연산에 특화된 R이나 Python( NumPy)을 선호한다.

빅데이터 통계분석은 전공과목일 뿐만 아니라 수학적인 지식은 물론 프로그래밍 지식 또한 동시에 필요로 한다. 분야에 따라 사회과학 및 경제학이 필요하기도 하기에 융합학문이 필요한 경우가 많다. 머신러닝과 딥러닝의 처리도 이루어지기에 인공지능에 있어 관문 역할도 한다. 아예 인공지능 개발을 하는 경우도 많기에 대개는 석사 이상의 졸업자 혹은 시니어 이상 개발자를 선호하는 경향이 있다.[21]

2.11. CI/CD

Continuous Integration/Continuous Deployment

개발(Development)과 운영(Operations)에 대해 통합 (지속적 통합 / 지속적 배포, CI/CD) 관점으로 보는 개발 방법론 및 문화를 의미하는 단어로, 해당 방법론을 적용하여 개발하는 프로그래머나 시스템 엔지니어들을 의미하기도 한다.

데브옵스 분야의 전문가로 일하는 사람들은, 개발된 프로그램이 실제 사용자에게 배달되기까지의 과정을 자동화하고, 운영 및 테스트에서 나타나는 이슈들을 모니터링하며 장애를 감지하는 등의 역할을 수행한다. 특이한 점은 이러한 직무가 회사에 따로 존재하는 경우는 거의 없는 점인데, 보통 귀찮은 일들을 개발을 통해 자동화하는데 맛들린 시스템 운영자나, 빌드 및 배포, 모니터링에 주로 관여한 소프트웨어 개발팀 인원들이 스스로를 데브옵스로 자처하곤 한다. 간혹 개발도 하고 운영도해야하는 K-SI 산업의 현실을 데브옵스라고 자조적으로 칭하기도 한다. 데브옵스는 주로 클라우드 컴퓨팅과 연관되어 있는 경우가 많다.

실무적으로 볼때 이 분야의 종사자들은 각종 툴과 언어를 익히는데 익숙하고, 다양한 시스템과 네트워크에 대해 많은 지식을 갖고있는 경우가 대부분이다. 최근에는 DevOps 개념에서 발전된 SRE(Site Reliability Engineering), OpsDev, DevSecOps 등이 포함되기도 한다. 간단하게 특징을 나열하면 아래와 같다.
  • DevOps: 주로 개발 및 소프트웨어 운영에 있어서의 자동화 / 빌드 / 배포 / 모니터링에 관여한다.
  • SRE: 서비스의 장애를 감지하고, 예측하여 서비스의 유지 및 안정성 향상에 집중한다.
  • OpsDev: 서비스를 운영하는데에 있어서 필요한 시스템 부분을 자동화한다. 최근 클라우드와 맞물려서 대두되는 분야이다.
  • DecSecOps: DevOps에 보안적인 요소가 접목된 분야. 각종 암호화 및 보안 솔루션을 접목하는 역할을 한다.
  • MLOps/AIOps: 기계학습, AI 모델링에 특화된 DevOps 모델.
  • MLSecOps/AISecOps: MLOps 및 AIOps에 보안 관리가 추가된 CI/CD 모델.
  • FinOps: 운영에 비용 최적화 기술을 도입하여 개발진에게 피드백을 주는 개발 모델.

2.12. 코더

과거에는 '의사 코드'와 코드의 차이가 컸기 때문에 코더도 충분한 월급을 받으며 일할 수 있었다. 가령, 60년대에는 단순히 천공카드에 자료를 펀치하는 사람도 고급 인력이었다. 하지만 프로그래밍 언어가 많이 발전해서 현대의 프로그래밍 언어는 의사 코드에 매우 가까워졌다. 따라서 프로그래머가 수도(Pseudo) 코드를 만들어서 코더한테 던져주는 저수준 작업은 요즘에 거의 사라졌다. 하지만 임베디드나 DSP, HDL 같은 경우는 코딩이 워낙 고난이도이고 신경쓸 게 많다 보니 여전히 이런 코딩만 전문으로 하는 프로그래머들이 많이 남아있다.

반면, 코더의 수는 늘어나고 있다. 기술의 발전으로 코딩 툴도 입문 난이도가 내려갔다. 이 덕분에 코더의 진입 장벽은 학원에서 배우거나 IT쪽 고등학교에서 컴퓨터과를 졸업해서 일자리를 구할 수 있을 정도로 낮다.[22]

Pseudo code가 주어졌을 때 그걸 실제로 동작하는 코드로 구현하는 것에 그치는 사람, 소스 코드를 복사해서 문맥에 맞게 수정하는 것밖에 할 줄 모르는 사람은 코더[23]다. 이것도 쉽지 않다.

코더를 벗어난 프로그래머는 자료구조, 알고리즘, 디자인 패턴에 대해 이해하고 있다. 이는 스스로 코드를 읽어서 작동원리를 이해할 수 있게 해 준다. 또 어떤 함수의 입력과 출력이 정의된 명세서가 주어지면 그 명세를 만족하는 코드(실제 컴파일 가능한 코드 또는 의사 코드)를 만들어낼 수 있게 해 준다. 더 나아가면 일상적인 문제에 대해서 스스로 코드를 짤 수 있게 된다. 더 나아가 자신의 프로그램의 문맥에 맞게 튜닝해서 최적화 할 수 있다.

코더라는 직업이 존재하는 것이 아닌, 프로그래머에 대한 비하적인 멸칭이다. 이러한 용어는 개발자에게 있어 상당한 모욕이자 실례이기에 대놓고 루팡짓을 하는 사람이 아닌 이상 사용을 삼가는 것이 좋다. 대개의 개발자들은 들으면 싫어하지만 때때로 초급 개발자들이 코딩이 잘 안 풀릴 경우 스스로 코더라고 자조하기도 한다.

3. 되는 방법

파일:attachment/프로그래머/1.jpg
vi로 개발하고 있으니 야근이 필수지

[24]

3.1. 프로그래밍 언어

학교와 전공 분야에 따라 많이 다르지만 아는 게 많을수록 좋다. 프로그래밍 언어는 기본적으로 개발하고자 하는 것에 따라서 선택되어지는 것이다. 하나의 언어라도 깊게 알고 있으면, 나중에 필요에 의해서 다른 프로그래밍 언어를 공부할 때 쉽게 익힐 수 있다. 프로그래밍 언어는 전체 개발에서 일부에 불과하다. (다만 좀 많이 중요한) 예를 들어, 본인이 게임 개발을 하고 싶다면 C 계열 언어를 깊게 하는 게 제일 중요하다. 하나의 프로그래밍 언어를 깊게 하는 것도 쉽지 않은데 굳이 사용하지도 않을 언어를 공부할 시간 여유 따윈 존재하지 않는다.

첫 번째 언어에서 디자인 패턴을 공부할 수준까지 가면, 틈 나는 대로 다른 언어들도 공부하는 것이 좋다. 1~2개의 언어만 붙잡고 다른 언어를 외면한다면 어느 순간 도태될 수도 있다. 현실의 외국어와 달리 프로그래밍 언어는 문법이나 용어들이 비슷하므로 C++ 같이 복잡한 언어가 아니라면 습득하는 데 큰 노력이 들지 않는다. 물론 그 많은 언어들을 다 유창하게 사용할 능력까지는 필요 없고, 간단한 프로그램을 만들 정도만 익혀도 부족하지 않다. 나중에 그 언어를 주력으로 사용하게 될 때, 나머지 상세한 부분을 공부해도 좋다.

누구나 그렇듯이, 트렌드를 지속적으로 따라가는 건 어렵다. 라이브러리나 프레임워크를 뺀 순수 '언어'들만 해도 200여 종이 넘는다. 점유율 3% 넘는 것들만 쳐도 6종이다. 그 중에서 다음 프로젝트에 무슨 언어가 쓰일 지는 확정지을 수 없다.[25] 게임 개발의 경우 C++이나 C#이 보통이지만, 갑자기 Python을 같이 사용해야 하는 경우도 있다.[26]

심지어는 갑자기 언어에 변혁이 일어나기도 한다. 1983년부터 Objective-C가 개발되어 맥과 iPhone 앱에서 잘 쓰이고 있었는데, 2014년 애플에서 더효율적인 Swift를 발표했다. Objective-C로 코딩한 결과물이 쓸모없어지는 건 아니지만, Objective-C는 레거시가 돼서 지원이 점점 끊긴다.

그러니 그때그때 몸담고 있는 영역에서 유리한 언어를 사용하는 게 편리하다. 아주 오래전에는 기계어 어셈블리어밖에 없었으나, 각 언어에는 장단점이 있기 때문에 분야마다 쓰는 언어가 다양해졌다. 이제 한 언어가 모든 분야에 절대적으로 유리하지는 않다. 대개 웹 프로그래머라면 Java JavaScript, PHP, 시스템 프로그래머라면 C, C++, Rust를 주력으로 삼는다. 한국 내에서도 이런 수요가 가장 많다. 시장의 수요에 따라 특정 언어를 할 줄 알면 몸값을 올릴[27] 수 있기 때문에 다양한 언어를 다룰 줄 아는 것이 중요하다. 가령 아두이노를 사용한 IoT 디바이스를 웹과 연결하는 프로그램을 짜고 있다고 하자. 웹에서 예를 들면 쇼핑몰을 구축해야 할 때 PHP가 적합한데 C/C++로 CGI로 홈페이지를 구축하는 것은 생산성만 떨어뜨리는 어리석은 접근이다.

프로그래밍 언어/예제 문서에 가보자. "Hello, World!" 외에도 그 아래쪽 것들을 구경해볼 것. 열 줄짜리 구구단 출력 자바 코드가 Ruby 언어에 가면 매우 줄어든다.

Java의 예를 들어보자. 처음엔 날코딩에서 시작해 IDE를 쓰게 되고, 서드파티 라이브러리를 사용하다가 스프링 프레임워크라는 것이 있다는 걸 알게 되고, 프레임워크의 유연성에 감동하다가, 그 프레임워크를 만든 근간 기술인 디자인 패턴에 대해 공부하게 되고… 그렇게 차츰 자기도 모르게 고급 프로그래머가 되어 간다. 그러나 학습량은 결코 적지 않다. 위에서 트렌드를 이해해야 한다고 했는데, Java 쪽의 트렌드를 따라가려면 읽어야 할 자료가 엄청나게 많다.[28] 그래서 다른 것에 한눈팔 여유가 없다. 그래도, Java의 인기와 점유율은 여전히 상당하다.

최신 트렌드를 접하다 보면 스프링 프레임워크를 접할 때 즈음엔 함수형 언어에 대해 알게 된다. 일급 객체, 클로저 등에 대해 10분만 검색하면 인터페이스가 불필요할 수도 있다는 걸 알고 멘붕할 것이다. 객체지향이 진리라고 믿었더라도, 메서드 체이닝과 고차 함수 개념을 접하고 나면 객체를 상속하듯이 행동을 확장할 수 있는 함수형 언어의 설계 패러다임을 접하고 다시 멘붕할 것이다. 그리고 멀티 스레드는 금단의 사과 같은 테크닉이라고 믿었더라도 GPGPU를 배우면 스레드가 다다익선일 수도 있음을 알게 된다. 리턴 값을 두 개 세 개 막 넘길 수 있는 Python Go를 보고, 숫자에 메소드를 붙이고 문자열 자체를 메소드 명으로 해석해서 실행시키는 테크닉이 가능한 Ruby를 보고[29], 심지어 같은 자바 가상 머신을 사용하는데도 유연성이 훨씬 뛰어난 Scala Groovy를 접해보게 된다. 이러한 점 때문에 프로그래밍에 흥미만 붙인다면 여러가지 다양한 개념과 사고를 접할 수 있기 때문에 정말 프로그래밍 공부가 재미있어진다.[30]

이런 경험을 아예 하지 않으면 더 문제다. 일할 때 속도가 심하게 느려지기 때문이다. 남들이 2주에 400만원이면 충분하다고 하는 프로젝트를 본인 혼자서 2년에 2억을 부른다면 시장에서 도태되고 말 것이다.

이런 과정을 거치다 최정점에 서게 되면 이거고 저거고 다 비슷해 보이는 언어의 한계를 돌파한 polyglot이 된다. 무슨 언어를 쓰든 거기서 거기처럼 느껴질 수도 있겠지만 이 경지까지 가면 스스로 컴파일러를 제작해서 사용할 정도의 초월자가 되어있을 것이라 논외.
파일:상세 내용 아이콘.svg   자세한 내용은 프로그래밍 언어 문서
번 문단을
부분을
참고하십시오.

3.1.1. C/ C++

C/ C++은 컴공과에서 대부분의 전공 교수들이 프로그래밍의 기본이라고 생각해 무조건 가르친다. 현직에서 많이 사용되는 C#, Java 등의 고급언어의 모태가 된 언어이기 때문이다. 과거에는 성능과 최적화가 중요한 운영체제, 게임, 임베디드 분야에서 주로 사용했지만 최근에는 사물인터넷(IOT)가 급부상하면서 AI분야의 파이썬과 함께 다시 인기가 상승 중인 언어이기도 하다.

3.1.2. Java

간혹 파이썬을 처음 배우는 경우도 있지만 아직까지는 컴공 비전공자들이 일반적으로 처음 배우게 되는 언어다. 대한민국의 대부분, 특히 공공기관 쪽의 프로젝트는 백이면 백 Java를 사용하기 때문에 실무 투입에 유용해 전문학교 단골 언어다. 교육생 입장에서는 현장에서 안 쓰는 언어를 교육용으로 배우는 것은 쓸데없어 보이니 수강을 거부한다. 교육기관은 교육생의 요구에도 맞춰줘야 하고, 교육용 언어와 실무용 언어 두 종류를 가르치기보다는 실무용 언어 하나만 가르치는 것이 최단 기간에 진도를 빨리 뺄 수 있으니 실무용 언어부터 가르치려고 한다.

그러나 Java를 배웠으니 무조건 취직을 할 수 있을 것이라고 생각하는 것은 금물이다. 잡코리아나 사람인에서 Java라고 검색만 해보면 알 수 있는 사실이 있는데 구인광고에서 Java 하나만을 요구하는 회사는 거의 없다. Node.js, AngularJS, jQuery, JSTL, .NET 등등 다른 언어를 추가로 요구하는 회사는 심심하면 나타나는 수준이고,[31] 심하면 Java는 자격요건에 나와있지도 않는 경우가 있다. Java는 기본이고 Node.js, JQuery[32] 등을 알고 있는지 모르는지로 취직이 되냐 안 되냐가 결정되는 것이다. 개발하는 데 있어 당연히 Java 하나만을 사용하지는 않고 비슷한 여러 언어를 같이 쓰기 때문이다. 자격요건으로 적힌 언어는 그 회사에서 주로 사용하는 언어를 적어놓기 때문에 해당 언어의 기본 문법 정도는 알면 취업에 도움이 될 것이다. 권장 요건에 불과하기 때문에 적힌 내용 중 조금만 안다고 해도 뽑힐 수 있다.

Java는 객체지향 언어이기 때문에 소스를 보면 직관적으로 눈에 들어온다. 메서드[33]를 보면 이 메서드가 무슨 역할을 하는지 이 변수가 어디에서 사용되는지 등이 한눈에 들어오기 때문에 이해하기가 쉽다. 그리고 Java는 너무나도 유명하기 때문에 가능한 한 쉽게 설명해주는 강의들도 많으니 인터넷에서 검색하면 쉽게 배울 수 있다. 또한 객체가 무엇인지만 알면 Java로 코딩하는 데에 어려움은 적다. 그걸 이해하기까지가 고통이지만

한편 Java는 다른 언어에 비해 코드량이 더 많다. 이에 대해 아래쪽 문단에서 주장하는 것처럼 Java에 대해서 이상할 정도로 부정적으로 생각하기도 하고, Java가 다른 언어에 비해 코드량이 더 많은 것을 단점으로 치부하기도 한다. 확실히 Java는 다른 언어에 비하면 쳐야 하는 코드가 더 많지만 그것을 개발자가 일일이 치지는 않는다. IDE의 자동 완성을 쓰면 쉽게 해결될 문제라서 실무에서는 아무 문제가 안 된다.

개발 속도 외에도 정확성 문제 때문에 자동완성이 우월하다. 사람이 치면 정말 타자 실력이 뛰어나지 않고서야 오타가 발생하게 되어 있다. 하지만 자동완성을 사용하면 이름을 지어줘야 할 때 빼고는 오타가 생길 일이 거의 없다. 논리적 에러보다는 오타로 인해서 에러가 생기는 경우가 일상다반사이다. 출력 메서드 이름이 제일 길다고 하는데 IntelliJ IDEA의 경우 sout이라고만 치면 System.out.println();이 자동으로 완성된다. 이클립스의 경우 syso를 치고 ctrl+space를 누르면 된다. 그리고 이러한 자동완성 기능은 메소드의 호출이나 객체 생성 등 내가 지금 작성하는 코드가 올바른지 실시간으로 확인해주는 역할이라고도 할 수 있다. 올바르지 못한 코드를 작성하면 자동완성 기능이 동작하지 않을 것이기 때문이다. 아래 문단을 보면 초보자에게 IDE를 주는 걸 부정적으로 말하고 있는데 대부분의 유명 IDE는 직관적인 GUI를 지원하므로 단축키나 복잡한 기능 하나하나를 외울 필요 없이 보이는대로 클릭해서 실행시킬 수 있다. 순수하게 텍스트 편집 기능만 제공하는 vim과, 잘못된 코드 구조를 분석하여 컴파일하기 전에 경고를 띄우고 올바른 예시 코드로 리팩토링해주는 IntelliJ IDEA 중 어느 쪽이 초보자 입장에서 쉽고 생산적일지는 굳이 따질 필요가 없을 것이다. 때때로 IDE의 기능에서 벗어나 프로그래머가 직접 튜닝을 해야 하는 복잡한 상황이 생길 수는 있으나, 이것 역시 초보자에게 해당되는 이야기는 아니다.[34]

프로그래밍에 있어 중요한 것 중 하나는 얼마나 코드를 논리적으로 최소화시킬 수 있냐는 것인데 이것을 단순히 코드량이 적을수록 좋다고 생각하는 것은 어리석은 생각이다. 코드량보다는 얼마나 쓸데없는 코드를 제거할 수 있는지가 중요한 것이다. 그리고 쓸데없는 코드를 제거하고도 코드량이 많은 경우는 얼마든지 있다. 왜냐면 실무에서 사용되는 코드는 적게 잡아도 몇백 줄이고 보통은 몇천 줄 이상이다. 그것도 파일 하나 당. 그것을 코드량이 많다고 해서 안 좋은 코드라고 볼 순 없다. 우리가 말을 할 때 명사와 동사의 기본형만 가지고 말을 해도 말은 통한다. 하지만 그 말을 우리가 효율적이라고 생각하는지, 실제로 그렇게만 말하는지 생각해보면 단순히 코드량으로 효율을 따지는 것이 옳기만 한 것인지 답이 나온다. 프로그래밍 '언어'라는 것을 다시 한번 생각해볼 필요가 있다. '좋은 말'이란 너무 짧아서 알아듣기 힘든 말이 아니라 군더더기가 없는 말이며 이것이 뜻을 전달하는 데 있어 가장 좋은 말이라는 것에 동의할 것이다.

물론 Java가 쉽다고는 할 수 없다. Java는 객체 지향 프로그래밍 언어이기 때문이다. 객체 지향적으로 프로그래밍 하는 방법을 물어보면 대부분의 개발자들이 모른다고 할 것이다.[35] 정말 어려운 개념이기 때문에 전문적 연구자가 아닌 한 객체 지향이라는 개념에 대해 실질적, 구체적으로 정의할 수 없다. 사전적 정의는 누구나 말할 수 있지만 어디까지나 사전적 정의일 뿐이다. 이렇게 어려운 개념이라고 해서 너무 걱정하지는 않아도 괜찮다. 객체 지향이라는 것을 조금이나마 이해하고 있다면 당신은 전혀 신입 개발자가 아니라는 뜻이니까. 그리고 아래쪽 문단에서 추천하는 Python도 결국 현업에서는 OOP 언어로 활용한다.

Java와 비슷한 언어로는 C#이 있다. 시니어들은 거의 같은 언어라고 생각할 정도로 구조가 유사한데, 사용되는 분야가 같은 곳도 있고 다른 곳도 있다. 단순 코딩 입문이라면 C#으로 시작하는 것이 오히려 더 쉽고 효율적이다. 다만 취업을 지향한다면 제어 계통으로 나아가는 경향이 많기에 웹을 원하면 자바가 더 나은 선택이다. 물론 프로그래머의 특성상 하나만 배우고 하나는 안 배우고 하는 경우는 거의 없기에 나중에는 어떻게 되건 다 배우는 경우가 많다.

3.1.3. Python

Python을 많이 쓰는 곳에 취직하고 싶으면 파이썬을 공부하는 식으로 언어를 선택해도 상관은 없다. 단, 취직이 될 경우에 한해서이다. 파이썬이 많이 쓰이기도 하고 Java에 비해서 쉽다고는 하지만 대한민국의 현실상 파이썬의 비중이 높은 회사가 아니고서야 취직하기가 어렵다. 당장 공공기관만 하더라도 Java를 쓰고 있고 해당 공공기관의 피고용인 입장인 회사들(을), 그 하청업체 회사들(병)이 많기 때문에 Java 일자리가 훨씬 많다. 그리고 SI에 대해서 들어본 적이 있다면 알고 있을 SI의 피라미드 구조를 생각해보면, 대한민국에서 Java나 C/C++는 배우지 않은 상태에서 다른 언어만 배웠을 때 취직할 가능성이 얼마나 낮은지 알 수 있을 것이다. 실제로도 파이썬을 사용하는 사람을 구인하는 기업은 십중팔구 시니어를 구하며 그마저도 통계와 AI쪽으로 전문적인 지식을 지닌 최소 석사 이상의 인력을 모집한다. 이러한 현실에서도 파이썬을 배워서 취직하고 싶으면 해외로 눈을 돌리는 것이 좋다.

파이선은 자바나 C 언어보다 입문하기 쉽다. 한국의 컴퓨터 교육 현장에서 무작정 자바와 C를 주입하면서 수많은 낙오자가 발생하고 있으며, 간신히 통과한다 해도 기본을 닦지 못한 코더가 양산될 뿐이다. 그래서 전체적인 프로그래머 인력 풀의 질과 양 둘 다 떨어뜨리는 악영향을 끼치고 있다. 실제로는 첫 언어만 Python으로 바꿔도 쉽게 갈 수 있다. 그나마 Python이 인지도를 많이 넓혀놔서 2019년 현재는 상황이 많이 나아지긴 했다. 하지만 제대로 코딩을 가르치는 경우 동적 언어로 코딩 공부를 스타트하는 경우는 제로에 수렴한다. 동적 언어의 최대 맹점은 바로 타입에 대한 임의추론인데, 이러한 개념에 익숙해지면 나중에 정적 언어에 대해 접근조차 할 수 없을 정도로 공부에서 이탈이 심각해진다. C#이나 Dart와 같은 고생산성 정적 언어가 많이 나왔는데 굳이 파이썬으로 코딩 입문을 스타트하며 고생길을 여는 경우 이후 진로에 있어 상당한 악영향을 끼친다. 이는 JavaScript로 코딩 공부를 스타트하는 경우도 마찬가지다. Python 및 Javascript는 특히 로우 레벨 개념들과 객체지향을 배우더라도 늦은 시점에 배우거나 혹은 완벽히 배우기가 쉽지 않다. 그리고 이를 독학으로 해결하기는 불가능에 가깝기에 Python 입문 및 Python만으로 코딩을 고집하는 사람에 대한 인식은 그다지 좋지 않은 편이다.

C언어를 만든 목적은 유닉스 운영 체제에서 사용하기 위해서이다. 언어 설계자의 기본 가정이 C를 사용할 사람은 이미 컴퓨터 아키텍처의 세부사항을 잘 알고 있다는 것이었다. 그래서 C언어는 프로그래머가 이상한 짓을 해도 최대한 그대로 하려고 들고, 명백하게 망가지기 전까지는 아무런 경고도 하지 않는다. C로 시작하는 데에 한 가지 문제가 더 있는데, 한국 대학 교육 현실상 구세대 표준을 강요하는 곳이 적지 않다.

Java 역시 객체 지향 개념이 난해하고 언어가 장황해서 힘들다. 먼저 Boilerplate 문제를 보자. 함수 하나, 연산식 하나를 테스트하려고 해도 public class GuguClass로 시작하는 십여 줄의 코드를 일일이 작성해야 한다. 특히 화면 출력 메소드의 이름이 System.out.println이라는 긴 이름이다.[36][37] 인기 있는 프로그래밍 언어 중에서 이 정도로 출력 메소드가 긴 언어는 Java가 유일하다. 이게 문제가 되는 이유는 이제 막 코딩에 입문하는 초보자는 코드를 입력하는 과정에서 필연적으로 오타를 치게 되는데 자바는 이 오타 지점을 찾기가 상대적으로 매우 어렵기 때문이다.[38]

거기다 문법이 쉽다-어렵다에 더해 한 가지 차이점이 더 있다. Python은 인터프리터 언어고 C/C++/Java는 컴파일 언어다. 초심자는 인터프리터 언어부터 배우는 게 유리하다. 왜냐하면 인터프리터 언어는 코드의 실행 결과를 즉시 확인해볼 수 있고, 컴파일 언어는 컴파일이 끝나야 결과를 확인할 수 있다. 컴파일 언어는 컴파일이 실패하면 코드의 첫 줄도 실행할 수 없다. 컴파일 오류 메시지가 나오긴 하지만, 그 컴파일 오류 메시지를 해독해내는 시점에서 이미 초보가 아니다. 이 때문에 초보자는 잘못된 곳을 찾기 위해 코드의 모든 줄을 검사해야 하고 심지어는 컴파일 명령 자체에 오타가 있는지까지 확인해야 한다. 반면 인터프리터 언어는 에러가 나기 전까지는 코드를 꾸역꾸역 실행하므로 오류가 난 줄 바로 직전까지 코드를 실행할 수 있다.

Python 강의는 도처에 널렸으므로 적당한 강의 하나 골라잡고 따라하다 보면 일단 코더 수준은 될 수 있다. 80년대생 프로그래머는 BASIC부터 시작했던 경우가 많은데, 21세기의 Basic이라고 할 만한 것이 바로 Python이다. 문법 자체도 영어로 글 쓰듯이 만들어져 있어 접근성이 굉장히 높다. 영미권에서 먼저 배우는 이유가 그만큼 친숙한 영어를 기반으로 되어 있기 때문. 사실 미국에서 진짜 입문용으로 가르치는 것은 Scratch라는 언어인데, 이 스크래치는 철저히 교육용이기 때문에 실용적인 프로그램을 만들기는 어렵다. Python은 매우 고성능이기 때문에 과거의 BASIC이나 오늘날의 Scratch와 달리 입문 이후에도 주력으로 사용할 수 있다.
다만 파이썬 자체의 속도가 매우 떨어지며, 주력 라이브러리들도 대부분 C로 작성된 경우가 많다. 어찌되었건 C보다는 편하긴 하지만 그마저도 시니어가 아니면 파이썬을 쓰는 경우가 거의 없다는 점을 고려하면 무의미할 정도. 파이썬을 잘한다는 것은 결국 메타클래스로 커스텀 클래스를 마구잡이로 뽑아낸다는 뜻인데, 여기까지 배운 사람이라면 굳이 파이썬이 아니더라도 다른 언어로도 같은 짓을 밥먹듯이 할 수 있으며, 파이썬의 생산성은 반대로 보면 로우 레벨에서의 속도를 희생하기에 결과적으로 안 쓸 수밖에 없는 것이다. 그나마 쓰는 데이터 및 인공지능 직종은 C로 작성된 라이브러리를 이용하기에 의미가 없지만 상술했듯이 이걸 하는 사람은 전부 시니어이며, 시니어들은 굳이 파이썬이 아니더라도 모든 언어를 자유자재로 다룬다. 따라서 오직 파이썬만을 파서 밥벌이를 한다는 것은 불가능에 가까운 일이다.[39]

3.1.4. 기타

  • R은 통계학 및 사회조사 방법론으로 쓰이는 언어이다.
  • MATLAB은 공대 연구실에서 주로 사용한다. 공학 연구자가 아니라 일반 프로그래머라면 배울 필요는 없다.
  • Scratch: (미국)초등학생 교육용으로 개발된 언어인데 국내에선 업계는 물론이고 교육계에서도 쓰이지 않는다.[40]

3.2. 필요한 장비

개발자들은 모두 최고급의 장비를 사용하는 것처럼 보이거나 그러한 형태의 사회적 인식[41]이 있지만, 하술할 게임 개발, CV, 머신러닝 등등의 작업이 아닌 이상 최근 수준의 하드웨어 성능으로는 거의 문제가 없다.

프로그래밍 공부를 시작한 정도이거나 타 분야에 종사하는 사람이 간단한 프로그래밍을 적용하는 정도라면 그냥 지금 쓰고 있는 컴퓨터를 사용하면 된다. 요구되는 장비의 성능은 종사하는 분야에 따라 다르다.

크로뮴이나 리눅스 같이 대규모 프로젝트를 관리하는 전문 프로그래머라면 생산성 향상을 위해 컴파일 속도가 중요해지므로, CPU 성능이 좋아야 한다.

영상 처리, 3D 그래픽, 시뮬레이션, 머신러닝 같은 병렬 처리가 필요한 분야의 경우 그래픽카드의 성능이 많이 요구된다. 내장 그래픽을 쓰는 사무용 노트북에다가 이런 것을 돌리면 매우 오래걸리거나 메모리 초과로 뻗어버린다.

2010년대 후반 이후의 요즘에는 노트북 한 대로 퉁치려는 경향이 강하다. 화면 크기를 제외하고 나머지 스펙은 프로그래머가 개발용으로 쓰기에 충분할 정도로 기술이 발전했기 때문이다.

대부분의 상황에서는 인텔 i5 이상이나 AMD 라이젠 5 이상 정도면 충분하다.

3.2.1. 운영체제

입문자의 경우, 프로그래밍을 위해 자신이 쓰던 운영체제를 무리하면서까지 바꿀 필요는 없다. IDE 개발사 JetBrains가 자사 제품의 사용자들을 대상으로 진행한 설문조사에 따르면, 2019년 기준으로 개발자들이 가장 많이 사용하는 운영체제는 윈도우였다. # JetBrains의 툴들이 운영체제에 비종속적인 웹 개발에 많이 쓰인다는 점을 생각하면, 세간에 널리 퍼진 "윈도우는 개발용으로는 잘 안 쓰인다"는 말은 틀린 부분이 있다. 윈도우가 많이 쓰이는 이유는 어찌보면 간단하면서도 당연한데, 리눅스 등이 개발자 친화적이라 한들 윈도우 이용자가 많으니 당연히 윈도우 환경 개발도 많아질 수밖에 없는 것이다. 특히 닷넷의 경우 윈도우 점유율이 절대적이며, 이외에도 윈도우를 좋아하는 개발자 또한 상당히 많다. 개발자라면 리눅스, 맥을 좋아한다는 말 또한 틀린 말이며. 이러한 개발자들은 굳이 서버사이드 직군이 아님에도 맥을 지급해주는 회사에 들어가면 고통이 시작되기도 한다.

일반적으로 널리 쓰이는 윈도우, macOS, 리눅스 환경에는 프로그래밍 입문에 필요한 환경을 쉽게 구축할 수 있다. 다만 서버 프로그래밍 분야는 리눅스 환경이 타 OS보다 압도적으로 개발환경 구축이 쉽다.[42] 최근에는 wsl 2 의 등장으로 많은 서버 개발자들과 시스템 엔지니어들이 윈도우로 개발 및 작업환경을 꾸미고 있다. 가상화를 이용하여 윈도우에서도 완벽한 리눅스를 쉽게 사용할 수 있게 되었기 때문이다. macOS의 경우 bash, zsh 등 리눅스와 비슷한 쉘 환경을 제공하지만, 어디까지나 리눅스가 아닌 BSD와 연관이 깊은 다윈 커널이기 때문에 사소한 명령어에서 오는 차이가 크다.[43]

실전에서 리눅스를 자주 쓰니 자신도 리눅스로 바꿔야 하는 건 아닌가 하는 생각이 든다면 리눅스 환경은 배포에서 주로 쓰이지 실제 리눅스 데스크탑을 사용하는 사람은 극히 드물다는 사실을 기억하자. 리눅스 데스크탑은 리눅스 서버만큼이나 방대한 분야이며, 초보자들의 경우 익숙해지기 전까진 (소리가 안 나온다던가 하는) 기본적이고 자잘한 문제[44]들을 계속 마주할 수밖에 없다. 따라서 리눅스로 바꾸기 전에 리눅스를 사용함으로써 얻는 개발 환경과 리눅스에 적응하면서 소비하는 시간 중 어느 것이 자신의 생산성에 영향을 미칠지 한번쯤은 고민해 보도록 하자. 만약 특정한 개발 툴 등이 리눅스 전용이라면 상술한 WSL이나 Docker for Windows/Mac 등도 시도해 보자.

특정 운영체제에 종속적인 프로그램을 개발하려면(예: DirectX 게임 프로그램, iOS 앱 등) 해당 운영체제의 사용이 필수적이겠지만, Java, Python 등의 언어 실행 환경을 비롯하여 멀티 플랫폼을 지원하는 개발 도구도 많이 찾아볼 수 있다. 만약 운영체제에 종속적인 프로그램을 개발하게 된다면 기기를 구매하기 전에 먼저 비슷한 환경을 구축할 수 있는 에뮬레이터 가상환경 등등을 알아보자.

3.2.2. 모니터

입문자라면 모니터는 신경 쓸 필요 없다. 공부를 하는 데에는 화면에 코드 편집 창을 띄울 수 있고, 관련 문서를 띄울 수 있다면 충분하다. 그래도 모니터는 최소 2개 이상을 쓰는 것을 추천한다. 한 쪽에는 코드 편집 창을 다른 한 쪽에는 결과 창을 띄워 놓고 볼 수 있기 때문에 정말로 편하다. 굳이 하나의 모니터로 코드와 결과 창을 볼 필요는 없다. 인터넷 강의 등 교육을 들을 적에도 한쪽에는 강의를 틀어 놓고 다른 쪽에서는 코딩을 실습할 수 있기에 필수적이다.

기본적으로 개발용 모니터는 다음 사항을 추천한다: 크기가 크고 해상도가 높은 것, 다중 모니터를 사용. 하지만 양쪽 모니터가 모두 클 경우 자신의 목만 아플 경우가 생길 수도 있기에 케바케이기도 하다. 노트북과 22인치 서브 모니터로 개발하는 경우도 흔하며, 이조차도 목이 아프다며 더 작은 모니터를 쓰는 경우도 있다..

보통 프로그래밍 입문자의 모니터는 1920 * 1080 해상도의 FHD 모니터일 가능성이 큰데, 개발자는 텍스트를 볼 일이 많으므로 PPI가 높을수록 유리하다. 모니터 크기는 큰데 해상도가 낮으면 그만큼 텍스트는 더 흐릿해지므로 24인치급 QHD 모니터나 27인치급 4K 모니터가 좋다. 참고로 애플의 iMac 2019년형 모델의 경우 27인치에 5K 해상도를 박아 놓아서 픽셀 밀도가 218 PPI로 매우 높다. 자기가 주로 노트북을 이용해서 여러 곳을 옮겨다니며 코딩을 하는데 더 많은 모니터가 필요하다면, 13 ~ 17인치 사이의 포터블 모니터를 추가로 구매하는 것도 좋다. 보통 DisplayLink 기술을 이용한다. 별도의 DisplayLink 드라이버 설치가 필요하다.

듀얼 모니터를 설치하기에는 공간이 부족할 경우, 다수의 PC를 연결하여 분할 화면을 띄워주는 PBP(Picture By Picture) 기능이 지원되는 모니터를 구매하는 것도 좋다. 주로 21:9 와이드 모니터들이 이 기능을 탑재하고 있으며, 아무리 와이드하다고 해도 모니터 두 개를 놓는 것만큼 공간을 많이 차지하지는 않으므로 꽤 효율적인 방법이다. 다만 화면 비율이 깨지는 현상이 있는지는 제품마다 다르므로 사전에 주의가 필요하다.

그리고 가상 데스크탑 기능을 통해 모니터 하나로 여러 대를 쓰는 효과를 볼 수 있다.

3.2.3. 키보드

손에 피로를 심하게 주는 것을 피하면 된다. 쫀쫀한 키감이 있는 팬터그래프 키보드를 사용하면 얇은 키 스트로크 + 가위식 스위치의 반발력 덕분에 손가락의 피로가 상당히 줄어든다. vim이나 Emacs를 자주 사용하는 프로그래머의 경우, 해피 해킹 키보드를 구입해서 사용하기도 한다. 이 키보드는 일본 토프레 사의 정전용량 방식 스위치를 사용하는 제품인데 스위치 내부에는 스위치 눌림에 따라 정전용량을 변하게 하기 위한 고깔 모양의 스프링과 고급 재질 인조 러버돔이 들어 있다. 같은 스위치를 사용하는 리얼포스 키보드의 경우는 표준 윈도우 레이아웃을 따른다. 고급스러운 키감에 소음도 적은 편이라 사무실에서 사용하기 위한 용도로는 끝판왕에 가깝다. 아니면 멤브레인 키보드라 하더라도 키감이 아주 나쁘지만 않다면 상관없다. 주로 로지텍이 사무용 멤브레인, 팬터그래프 키보드들을 많이 만든다.

너무 오래돼서 키가 뻑뻑하거나 휴대성에 극한으로 치중해서 타건감을 완전히 내다버린 키보드는 손가락 부상을 야기한다. 기자나 작가 정도는 아니라고 해도 프로그래머 직군은 타 직종에 비해 키보드를 쓰는 비율이 높다.

기계식 키보드는 소음이 심해 같이 일하는 주변 동료들에게 피해를 주므로, 기계식을 쓸 거라면 저소음 모델[45]을 사용하는 것이 좋다. 대신 기계식 특유의 키 감은 어느 정도 희생되는 걸 감안해야 한다. 이런 종류로 유명했던 제품은 애플 확장2 키보드가 있었다. 알프스 스위치 내부에 댐퍼가 있었다.

최근 노트북 개발이 많아지면서 노트북 기본 멤브레인을 사용하는 경우도 많은데, 장시간 사용에도 피로한 경우가 거의 없기에 키보드를 별도로 구비하지 않는 경우도 많다. 노트북 거치대 또한 호불호가 갈리기에 필요한 경우에 한해 직접 구비하면 된다.

3.3. 분야에 따라 필요한 지식

3.4. 꾸준한 공부

일단 책을 보다가 모르면 이런 게 있다는 것만 알고 넘어가라. 나중에 일하다 보면 이게 왜 쓰인다는 걸 깨닫고 이해하게 된다. 언젠가 알게 될 시점이 온다.

그 중에는 프로그래밍 자체에 대한 흥미 및 이 분야의 트렌드를 지속적으로 구독하는 능력 및 꾸준한 공부 습관도 포함되어 있다. IT 분야는 발전 속도가 매우 빠른 분야이기 때문에 공부를 그만두면 도태될 수밖에 없다. 따라서 그만두는 순간까지 꾸준히 공부해야 한다. 뜬구름 같은 이야기일 수도 있지만, 프로그래머에게 필요한 가장 중요한 적성은 프로그래밍 그 자체에 대한 흥미라고 할 수 있다. 따라서 프로그래머가 일과 공부에 쏟는 시간은 엄청나며, 당연히 주말에도 쉴 수 없다.주말에 쉬고 싶다면 처음부터 프로그래머를 하면 안 된다. 웹으로 입문해서 회사에서 시킨다고 억지로 디자인도 하고, 그러다 산업 의뢰가 온다고 PLC를 파고, 로봇을 파다 보니 인공지능 의뢰가 온다고 인공지능을 파고 하는 것이 프로그래머의 기본적인 생존 패턴이다. 심지어는 HCI같은 학문까지 공부한다. 한 마디로 자기 분야라는 게 정해져있지 않으며, 필요하면 모든 것을 알아서 배워야 한다.

개발도구는 간편해지고 있는데 그런 툴 자체가 워낙 많이 쏟아지고 있어서 프로그래머는 그 수많은 툴 중에 뭘 쓸지 '선택'을 해야 한다. 라이브러리간 호환성이 어떤지, 개발은 계속 되고 있는지, 얼마나 많은 유저가 쓰고 있는지, 그리고 검증되었는지 등을 다 따져봐야 하게 된 것이다. 고민을 하는 동안에도 세계 어딘가에서는 새로운 툴이 만들어져 발표되고 있고 기존 툴이 대대적인 업그레이드를 해서 원래는 후보 탈락이었는데 다시 검토해야 하는 경우도 발생한다. 어떨 때는 1년 동안 고생해서 프로그램을 제작했더니 다른 회사에서 일주일만에 신기술을 도입한 더 좋은 프로그램을 출시해버리는 경우도 있다. 툴 선택이 잘못돼서 생산성이 떨어진 상태로 작업하는 게 어떤 참사를 불러오는지의 가장 극단적인 사례.

IT쪽 뉴스에 뭐가 뜨면 최소한 자기 분야는 죄다 챙겨봐야 한다. 덕분에 학원 출신이라도 이후 독학으로 대학출신을 능가하는 것도 가능하다. 또한 구글링에만 의존할 것이 아니라 잘 쓰여진 책을 가지고 공부하는 것이 중요하다. 인터넷에 떠다니는 정보들은 파편화된 것으로, 전체적인 그림은 알고 있지만 일부 지식을 모를 때 이를 메우기에는 도움이 되나, 처음부터 지식을 쌓아갈 때는 오히려 독이 된다. 최근에는 코딩 교육과 딥 러닝의 열풍으로 컴퓨터 분야 기술 서적의 번역 품질이 상당히 올라간 편이다.[46] 심지어는 IT 이야기가 나온다는 이유로 관련 영화까지 챙겨보는 사람들도 존재한다.

어차피 흥미가 있는 사람이라면 누가 시키지 않아도 직접 찾아서 새로운 기술과 관련 정보를 습득할 테고, 누가 강요하지 않아도 알아서 공부할 것이기 때문에 유리하다. 반면에 시험 같은 강제적인 동기가 없으면 공부를 하지 않는 케이스라면 학교를 졸업하고 난 후 자연스레 공부에 소홀해지고, 그렇게 되면 다른 사람들에 비해 실력이 뒤쳐지는 것이 수순이다.

이렇게 트렌드 파악 및 꾸준한 공부가 필요한 분야이기 때문에 프로그래머 집단은 동종업계 종사자들 사이에서 지식 공유가 활발하게 이루어지는 분야이기도 하다. 예를 들어, 위키위키는 프로그래밍에 쓰는 패턴들을 정리하기 위해서 처음 탄생했다. 또한 모르는 사람들이 모여서 상업적인 목적으로 만든 것보다 쓸만한 물건을 만들어 내는 오픈 소스 프로젝트는 활발한 지식 공유 없이는 유지될 수가 없다.

해외 코딩 문제은행 사이트에 꾸준히 들러서 문제를 푸는 것도 좋은 방법이다. 기초부터 시작하고 싶다면 HackerRank, 깊이 있는 문제들을 원한다면 LeetCode 또는 InterviewBit를 방문해 보자. 좋은 방법중 하나이다.

책을 산다면 대부분의 경우 가능한 최근에 출시된 책을 사야 한다. 혹여나 이전 버전으로 작성된 책을 살 경우 코드 이해가 되더라도 가독성 면에서 골치만 아파지는 쓰레기가 될 수 있다. 가능하면 출판 혹은 개정 2년 안의 책을 구매하는 것을 권장한다. 간혹 회사에서 레거시 요구해서 중고책을 찾는 사람도 있다.

3.5. 기술영어

전문가로 대접받으려면 영어로 된 기술언어 정도는 읽고 쓸 수 있어야 한다. 최초의 컴퓨터는 영국과 미국에서 만들었고 현대의 모든 IT 기술은 미국이 리드하고 있으며, 한국어로 된 프로그래밍 정보보다 영어로 된 정보가 압도적으로 많다. 논문은 물론이고 문서, 강의, 책, 질답, 사소한 팁도 영어권에 압도적으로 많다.

기술 영어는 영어회화 의미하는게 아니다. 무역사원들이 사용하는 비즈니스 영어가 존재하듯이 프로그래머들이 사용하는 기술자 영어가 존재하는데, 프로그래머들은 기술적 사항을 빠르게 전달하는 것을 중요시 여기기 때문에 기술 영어는 생활영어보다도 배우기 쉽다. 어휘 자체가 적고, 3형식을 넘어가는 문장은 거의 쓰이지 않으며, 문장의 의미가 명확하다.

일반인이 들었을 때 왈도체스러운 영어를 구사하게 되니까 거기서 만족하면 곤란하지만 어쨌든 같은 기술자끼리는 말이 통한다. 정 안통하면 코드로 대화할 수도 있다. Stack Overflow 사이트라면, 내 코드를 쭉 긁어다 붙이고 나서 "I expected True but False." 라고 하든지 "It should be True." 또는 "Not working." 이라고 하면 상대방이 알아서 코드를 읽고 의도를 파악해서 답변을 달아 줄 것이다. 물론 검색해서 답이 나오는 문제를 이런 식으로 질문하면 쫓겨나는 수가 있으므로 그건 주의할 것. if(you == mad) { this = 'Sparta!'; }

4. 현실

4.1. 연봉과 근무

타 직종도 비슷하겠지만, 연봉(시간당 급여)은 프로그래머의 실력을 나타내는 객관적인 지표가 된다. 인맥 등의 이유로 실력이 없는데 연봉이 높을 수는 있지만 실력이 좋은데 연봉이 낮은 케이스는 거의 없기 때문.[47] 굳이 코더와 프로그래머를 구분해야겠다면 연봉이 구분자가 될 것이다.

한국에서는 네카라쿠배라는 이름으로 IT 대기업을 통칭하기도 한다.

북미의 경우 스택 오버플로우에서 조사한 2016년 자료에 따르면 평균 $106,120로 연봉이 높은 직업(developer)에 속한다. 다른 나라들도 대부분 높은 편이며 한국도 $45,000로 연봉이 높은 축에는 들지 못해도 국내 사무직 평균보다는 높다. 물론 실력이 없으면 말짱 도루묵이다.

연봉은 보유한 기술에 따라 달라지기도 한다. 북미 기준 가장 높은 보수를 받는 기술로는 스파크와 스칼라가 선정되었으며 그 위로 카산드라, F#, Go, Clojure 등이 차례로 선정되었다. 업종에 따라서 구분해도, 상대적으로 접근이 쉬운 웹 프론트 개발자보다는 아이폰 개발자의 급여가 더 높은 것으로 나온다.[Disclaimer]

프로그래머별 연봉의 편차가 큰 편이다. 취업할 때부터 이 차이는 시작된다. 국내 대졸초임 기준으로 적게는 2200부터 시작하는 중소기업도 있지만 삼성전자나 금융권같이 성과급 포함 6000으로 시작하는 대기업도 있다. 아쉽게도 신입인 경우 유명 코딩 대회 입상 경력이 있거나 유명 오픈소스 커미터가 아닌 이상 기업의 연봉테이블에 따라 낮은 연봉으로 결정되는 경우가 대부분이다.

경력직의 경우 인사고과에 크게 의존하는 타 직종과는 달리 면접 시 간단한 시험을 보는 등 실력 측정이 상대적으로 용이하기 때문에 연봉을 높이기 위해 잦은 이직[49]을 하는 사람도 많은 편이며, 그만큼 연봉의 편차가 심해진다. 수년 전에 올라온 연봉관련글에 다들 의견이 제각각이다. 경력직으로 입사한 동료 개발자의 연봉을 알고 나서 퇴사를 결심했다는 이야기도 종종 들릴 정도.[50] 대기업이나 괜찮은 중견 기업은 추천으로도 많이 뽑기 때문에 실력은 기본이고 자신을 좋은 회사에 추천해줄 인맥 관리도 해두는 것이 좋다. 자세한 것은 프로그래머/인사고과에 있다.

프로그래머의 근무 형태는 일반적인 사무직과 비슷하다. 인 하우스로 근무하건 파견을 나가서 온 사이트로 근무하건 일단 출근은 사무실로 한다. 다른 직장과 다른 점은 현장에 나가거나 출근을 해야 업무 효율이 극대화되는 게 아니라서 재택 근무나 투잡 형식의 알바가 가능하다는 것이다. 직종 특성상 신기술 도입에 적극적이다 보니 영어만 통하면 몸은 한국인데 재택 근무로 해외에서 일하는 것도 가능하다. 회사에 별로 일이 없는데, 뭔가 매일 열심히 만들고 있는 사람이 있다면 회사 몰래 투잡을 하고 있을 가능성이 있다. SI나 소규모 앱 개발 등에서는 아예 정규직 형태가 아니라 프리랜서 형태로 근무하는 경우도 많다. 비전문가가 본다면 일하는 건지 노는 건지 구분하기 힘들다.

단, FA 분야처럼 직접 기계장비를 제어해야 하는 경우 공장으로 출근을 해야 하는 경우도 있다.

4.2. 인사고과

파일:상세 내용 아이콘.svg   자세한 내용은 프로그래머/인사고과 문서
번 문단을
부분을
참고하십시오.

5. 기타

고급 프로그래머도 사람이기 때문에 설계 미스를 내는 경우가 있다. 대표적인 경우가 Win32 애플리케이션 API. 왠지 NULL값을 파라메터에 자주 넘긴다. 사실 Win32 API가 NULL값을 파라메터로 많이 받는 이유는 이후의 호환성을 고려해서 예약해둔 인자(Reserved)가 많은 탓이 큰데, 어쩌다보니 이들이 대부분 쓰이지 않고 지금까지도 Reserved 상태로 남아있기 때문이므로 설계미스라고 할 수는 없다. 당시에는 아직 운영체제 경쟁도 유의미한 수준으로 있었고 기술도 급변하던 시절이었으므로 이런 것은 전혀 이상할 게 없다. 그리고 PHP라는 언어도 함수 이름에 일관성이 없어서 레퍼런스를 항상 참고해야 한다. 뭔가 프레임워크를 사용하는 방식이 어렵게 느껴지면 첫째는 본인 실력을 의심해야 하는 게 맞지만 둘째로는 그 프레임워크의 설계가 잘못되어 있을 가능성도 고려하자. 안 되던 일이 프레임워크를 바꿨더니 일사천리로 진행되는 경우도 간혹 있다. 대형 프레임워크일수록 이런 설계 결함이 발생할 확률이 높아지기 때문에 몇몇 프로그래머는 '마이크로 프레임워크' 쪽으로 전향하기도 한다.

2016 기준으로 미국 IT 업체 개발자 남성과 여성 비율(100기 준)은 애플이 80:20, 트위터는 90:10, 구글은 83:17, 페이스북은 85:15 수준이다.

개발이 완료되었지만 QA[51]에서 수많은 버그 리포트가 전달되면 수정을 위한 야근으로 인해 상당히 강한 압박감과 현자타임이 올 수 있다. 물론 주니어 단계에서나 느끼는 것이며 업무를 오래하면 QA에서 전달되는 버그 리포트를 감사하게 여기게 되며 보다 더 완벽한 코드를 짤 수 있게 된다. 가장 골때리는 타입은 '성능'에 대한 리포트인데 그깟 몇 초가 대수냐고 여기다가도 실제로 최적화하여 성능을 개선하면 매우 기쁘다. 그리고 만약 처자식들이 생기면 빠른 퇴근을 위해 QA에서 버그 리포트가 오지 않도록 완벽하게 짜는 자세로 바뀌게 된다. 사실 고객보다는 QA팀과 회사가 기뻐한다.

프로그래머를 골 때리게 하는 법 : 세미클론(;)하나를 그리스어 물음표(;)로 바꾸면 된다. [52]

프로그래머 중에서는 맘아이 같은 유해매체 필터링 소프트웨어를 무력화 하려고 공부를 하거나, 아니면 해킹, 변조 프로그램을 만지다가 심지어는 유즈맵을 만들다가 프로그래머의 길을 걷게 된 사람이 있다고 한다. # 노마드 코더 등이 좋은 예.

서양에서는 '프로그래머들 중엔 비만이 많다'는 편견이 있다. 심슨 가족에서 호머 심슨이 고도 비만이 되어서 킹사이즈 옷가게에 갔을때 점원이 가장 먼저 꺼낸 말이 "컴퓨터 프로그래머세요?"였다. # 실제로 프로그래머들은 대부분 의자에 앉아 있는 시간이 많으므로 대개 운동이 부족하다. 다만 운동이 부족하다고 꼭 비만인 것은 아니고 오히려 밖에 나가기보단 주로 실내에서 작업하고, 장시간 머리를 사용해 소비하는 열량이 높다 보니 무척 마른 사람이 될 수도 있다. 게임 개발자들은 돼지나 멸치 둘 중 하나라는 자조적인 평가도 가끔 들을 수 있다.

6. 유사 용어

7. 관련 문서


[1] 일부 프로그래머들은 자신의 능력을 이용해 악의적인 일을 벌이기도 하는데 안드로이드는 버전이 2.X대였을 시절에나 가능한 이야기로, 이후 버전이 올라가면서 스토어에 등록되지 않은 어플은 원격 설치가 불가능하게 패치되었고, 스토어에 등록을 하려고 하더라도 백그라운드에서 IP, SSID, BSSID를 전송하거나 GPS, 카메라를 가동할 수 있는 백도어 기능이 있는 앱은 스토어에 등록할 수 없어 더 이상은 어려운 이야기이다. 악의적 사용 예시로는 랜섬웨어를 비롯한 컴퓨터 바이러스들이 있다. [2] 컴퓨터에 대한 이해가 부족할수록, 개발 경험이 부족할 수록 프로젝트를 넓게 보고 주도하는 능력이 떨어질 수 밖에 없다. 이 경우 초급개발자라고 부르며, 경험이 늘고 지식이 깊어질 수록 프로젝트를 넓게 보고 주도할 수 있는 능력이 생기며 이 경우 고급개발자로 분류된다. 따라서 굳이 모욕할 의도가 없다면 초급 프로그래머를 코더라고 부르기 보다는 순화해서 부르는 것이 원만한 인간관계를 위해 좋다. [3] 고급/저급은 언어의 난이도나 질을 의미하는 것이 아니라, 얼마나 기계에 가까운 지를 나타낸다. 고급이 인간에 가깝다는 뜻이고, 저급이 기계에 가깝다는 뜻이다. 그래서 저급 언어를 다루는 쪽이 고급 인력으로 대접받는 경우가 왕왕 있다. [4] 이는 많이 알려진 바와는 다르게 'hacker'라는 용어가 MIT TMRC에서 탄생한 용어이며, '어떤 분야에 매우 전문 적인 사람' 또는 '한쪽 분야에 미친 찐따(nerd)'를 의미하는 MIT학생들만의 은어가 '컴퓨터를 깊게 깨우친 사람', '프로그래밍의 경지에 도달한 고수' 등의 의미로 쓰이기 시작했기 때문이다. 다만 어원과는 별개로 이 용어를 수입한 한국에서는 해커라고 하면 무조건 남을 공격해서 이득을 취하는 부류의 사람들을 가리키게 되었다. 해외에서는 두 의미가 공존하기 때문에 해석에 주의하자. [5] 타 분야와 달리 특정 언어 하나를 딱 집어서 지칭하는 이유는 2019년 기준 장치 드라이버 등의 저수준 제어를 위한 언어로는 C언어가 유일하기 때문이다. [6] 생명 주기는 스프링부트의 Bean에서도 등장한다. 메모리의 가비지 컬렉팅 면에서는 의미가 같지만 구조는 매우 다르다. 비동기 처리는 멀티스레딩과 멀티프로세싱을 이해하고 있으면 쉽다. [7] 대표적으로 닷넷 기반의 프레임워크들과 플러터가 있다. 플러터의 디자인 위젯들은 CSS의 구조와 매우 흡사하며 html, css, js 또한 공식적으로 지원하지만 많이 쓰이지는 않는다. 플러터의 경우 앱에서만 WASM을 지원했으나 2024년 5월부터는 웹에서도 WASM을 지원한다. 물론 JS 또한 WASM으로 구동시키는 것 또한 당연히 가능하다. 단지 WASM으로 컴파일하는데 JS를 쓰며 힘들게 코딩할 이유가 없을 뿐이다. [8] 스프링(전자정부), 스프링부트. [9] Laravel [10] ASP.NET에서 최근에는 Blazor로 전환 중. Microsoft와 관계된다면 이쪽을 쓰는 것이 Azure 등과 연계하는 데에 있어 좋다. [11] 노드 기반은 JS로 프론트엔드와 백엔드를 모두 관리할 수 있다는 장점이 있지만, 태생이 JS이기에 단점도 만만치 않다. 최근에는 민간 기업들, 그중에서도 개발 비용을 줄이는 것이 중요한 스타트업에서 주로 사용하는 경향이다. [12] Flask, Django [13] Ruby on Rails [14] 말이 하나 이상이지 실전에선 가능한 많은 DB를 다뤄야 한다. 솔루션을 하나만 가진 사람과 여러개를 가진 사람의 차이는 비교가 불가능하다. 따라서 SQL을 안다고 데이터베이스를 잘 안다고 생각하면 크나큰 오산이다. 데이터베이스는 기본 이론부터가 두께가 엄청나며, 실전에서 구현하는 쿼리 및 아키텍처 그리고 PostgreSQL과 같은 비슷한 언어들과 다양한 NoSQL까지 할 줄 알아야 그나마 데이터베이스를 다뤄보았구나 평가를 받는다. 다시 말하지만 이것이 신입 풀스택 개발자의 기본 전제 조건이다. 일부 분야에서는 이더켓과 같은 네트워크 통신 분야에 대한 이해도 필요하다. 어차피 풀스택이 되는 과정에서 누구나 겪는 길이긴 하지만. [15] React의 경우 React Native를 통해 모바일 어플리케이션도 작성하고 Electron을 통해 PC에서 돌아가는 응용프로그램도 작성이 가능하므로 언어 하나로 다양한 플랫폼을 지원하는 게 가능하다. 물론 Electron을 쓰는 건 권장되지 않는다. 윈폼을 비롯 대체재가 너무나도 많기 때문. [16] HTML과 CSS를 안 쓰고 JS의 프레임워크와 말도 안 되는 수의 라이브러리를 대체하니까 [17] 이러한 경향 및 풀스택을 비판하는 개발자들도 있지만 어차피 배우다보면 결과적으로 풀스택을 지향하게 되고, 풀스택만이 아닌 다양한 관점 및 다양한 기술들을 익힐 수밖에 없다. 단지 그 기술을 요구하는 시점이 상당히 빠르게 앞당겨졌을 뿐이다. 예전에는 시니어에 완벽한 풀스택을 요구했다면, 지금은 신입이나 주니어에게 완벽하진 않아도 어느 정도의 풀스택 경험을 요구하니까. 당연하다면 당연하다지만 이로 인해 구직자의 취업 경쟁은 엄청나게 심화되었고, 전공자도 몇 년을 고생하는 판국에 국비지원교육의 경우 취업사기나 다름없는 수준이 되었다. 하루 12시간 6개월을 공부해도 노베이스로 풀스택 경험을 쌓기란 불가능하니까 말이다. [18] 웹을 안 쓰는 회사에서 갑자기 작은 웹이 필요한 경우 내부적으로 JS인력을 찾아 해결하지 별도로 풀스택을 구인하는 경우는 거의 없다. 웹디자인 또한 마찬가지. [19] 웹 기술은 곧 통신이 연계되며, 21세기 모든 B2C 서비스는 통신이 필수적이다. 따라서 웹을 모른다는 것은 통신을 모른다는 말과도 같다. 정신나간 회사가 아닌 이상 그런 개발자를 채용해서는 소비자에게 정상적인 서비스를 제공할 수가 없다. 다시 말해 웹은 기본 덕목에 불과하고, 그것에 더해 전기 전자 혹은 인공지능 등의 본업을 하는 것이 개발자의 현실이다. [20] Kotlin이 표준 언어란 걸 듣고 Kotlin만 배우면 되는 게 아니냔 사람들도 있는데, Kotlin이 공식 언어로 채택된 게 2017년이란 소리는 바꿔 말하면 그 전까지는 전부 Java를 사용했다는 것과 같다. 즉 구글링을 해야 한다면 높은 확률로 Java로 작성된 코드의 비율이 더 많으니 기본적인 Java 코드를 볼 수 있는 능력이 필요하다. 프로그래밍 문서에 서술된 것처럼 프로그래머는 구글링에 꽤 많은 시간을 투자하게 된다. [21] 로우 레벨은 기본이고 sci-kit learn, tenserflow 및 keras, pytorch에 더해 대부분의 통계학과 인공지능 알고리즘에 대한 이해, 더 나아가서는 분석이나 개발 대상에 따라 사회학, 경제학, 법학 등의 지식을 공부하기도 한다. 인공지능은 일반적인 PC에서 굴리는 것이 당연히 아니니 웹에서의 클라우드 시스템 및 네트워크 프로그래밍, 경우에 따라서는 임베디드 지식도 요구한다. [22] 물론 6개월~1년 정도 배운 '코더'의 임금 수준은 낮은 편이며, 그들 상당수는 미래에도 높은 임금을 받지 못한다. [23] 그냥 복붙하면 당연히 에러난다. [24] 책상 위와 등 뒤에 달고 있는 것은 레드불. 용도는 야근. 농으로 야근 능력이 필수라 하기도 한다. 비상 걸리거나 마감 직전이라면야 당연히... [25] 물론 전문 분야 자체를 바꾸는 게 아니라면 대략 3종 내에서 결정되는 편이다. [26] 맥시스는 유명 개발사인데 심즈4에서 C++과 파이썬을 혼용했다. 사실 서버 문제는 언어와는 관계가 없긴 하다만, 기획자들은 그걸 모른다. [27] 대기업에서 ERP가 유행할 때 ABAP 프로그래머나 아이폰 발매 초기 C 프로그래머 등. [28] 단순한 양만을 따져봤을 때도 장난이 아닌데 거기에 적용된 개념을 이해하기 위해 읽어야 하는 것까지 합치면 방대하기 그지없다. 오래된 언어일수록 공부량이 방대한 것은 당연하긴 하다. [29] 예를 들어 10.times do puts "hello" end 라는 코드가 문법적으로 올바르다. 코드의 의미는 'hello를 10번 출력하라.' [30] 좋은 점들만 계속 얘기해서 함정에 빠질까봐 얘기하는 것이지만 이는 자기 전문 분야를 확실히 익히면서 추가적으로 공부하라는 거지 주구장창 언어들만 공부해서는 아무것도 안 된다. [31] 특히 닷넷 계열은 구인난이 심하기에 자바 배웠다 하면 일단 취직시키고 다음날에 공장으로 출근시키는 납치가 횡행하다. [32] 다만 현재로서는 뒤처진 기술이며, 제이쿼리를 사용하는 곳이 있다면 십중팔구 레거시 때문이다. [33] Java에서는 모든 함수가 클래스에 속해 있으므로 메서드라 칭한다. [34] 다만 쓸만한 IDE의 상당수는 전체 혹은 일부 유료인 경우가 있기에 무료인 커뮤니티 버전을 사용하거나 또는 프로 버전의 무료 트라이얼로 체험을 해보고 결정하는 것이 좋다. JetBrains 제품의 경우 대학생 이메일 등록을 하면 프로 버전을 무료로 이용할 수 있으니 적극적으로 이용해보는 것을 추천한다. [35] 학교에서 배워도 이해하기 어려운 개념인데 학원이나 인강, 책으로 습득하기는 불가능에 가깝다. 쉽게 생각하면 우리가 쓰는 모든 것은 객체로 만들어져 있으며, 객체를 만드는 객체를 만드는 객체를 만들어야 한다. [36] import static java.lang.System.out이라는 코드로 System 접두어는 줄일 수 있다. 그래봐야 out.println이다. 여기서 더는 못 줄인다. [37] 사실 함수로 빼면 되긴 한다. 'public void main(String msg)' 같은 형태로 선언해 내부에서 System.out.println(msg)를 호출하면 줄어들긴 한다. 대신 이러면 필요한 곳마다 선언해줘야 하는 게 문제다(...). [38] 클래스는 대소문자를 구분함, 클래스의 디렉토리 패스와 패키지 패스는 일치해야 함, 한 파일에는 한 개의 public 클래스만 존재할 수 있음, public으로 선언된 클래스 명과 파일 명은 일치해야 함 등 제약이 심하다. [39] 심한 말로 파이썬은 특성화 고등학교를 나온 학생들도 자유자재로 구사한다. 작정하고 공부하면 중학생도 할 수 있는 무언가를 가지고 취업 시장에서 성공하겠다는 것은 엑셀과 파워포인트만 가지고 취업하겠다와 다를 바 없는 소리다. [40] 교육계는 주로 파이썬과 C를 쓰며, 단순히 코딩 체험만 하는 경우 적절히 개량된 아두이노를 사용할 가능성이 높다. [41] 단 본인의 개발 업무가 하드웨어에 큰 영향을 받지 않는다고 해도 늘 컴퓨터를 끼고 사는 직업적 특성상 자신의 개인 컴퓨터에 일반인보다는 많은 관심을 기울이고 상당한 비용을 투자하는 사람이 많은 것은 사실이다. [42] 명령어 하나로 라이브러리와 개발 도구를 한꺼번에 설치할 수 있다. [43] 예를들어 curl, wget 등의 널리 쓰이는 명령어의 결과를 활용하는 스크립트를 작성할 경우, 간단한 shell 문법 자체는 macos와 리눅스가 서로 호환되지만 명령어 자체의 결과가 다른 경우에는 다른 결과가 나와 스크립트가 실패하는 경우가 많다. 이는 양쪽 모두 리눅스를 사용하더라도 busybox를 사용하느냐, 개별 실행파일을 사용하느냐에 따라 다르기도하다. 운영체제에 대해 이해가 충분하다면 macos는 훌륭한 개발도구가 될 수 있다.다만 현실에선 백엔드 개발자조차 예쁘다고 쓰는경우가 대부분.. (스벅 입장권) [44] 우분투 등의 초보자 친화적인 배포판을 사용한다면 당장 이러한 문제들은 면할 수 있다. [45] 저소음 적축 등. [46] 단적인 예시로 HTML을 두고 계층구조라고 알려주는 블로그가 상당히 많지만, 시각적으로 계층처럼 보일 뿐이지 로드할 때는 계층 구조가 아니다. (모질라 닷컴의 HTML 안내에서도 계층이라는 단어는 하나도 없다.) 계층 구조란 결국 클래스가 중첩되어있다는 의미이기에 절대다수는 웹에서 사용하는 논리가 아니다. 결국 제대로 된 디지털 리터러시 능력이 없다면 백날 독학해봐야 오히려 잘못 배울 위험성이 클 수도 있다. 다만 자바스크립트의 Document Object Model은 트리 구조로 이루어져 있긴 하다. [47] 이 업계는 이직과 스카웃이 빈번하다. [Disclaimer] 링크의 내용은 정확한 통계치가 아니라 설문조사이므로 심각하게 따지지 말고 재미로 보도록 하자. [49] 보통 개발자의 실력이나 포지션을 이전 직장의 연봉으로 평가(사기업이 일 못 하는 사람한테 돈을 많이 줄 리 없다)하기 때문에 이직 시 연봉은 기존 연봉 +@가 되는 경우가 많다. [50] 이 바닥에서 연봉 공개는 해고 사유가 될 수 있으므로 발설에 주의해야 한다. [51] 소프트웨어의 품질을 관리하는 조직 [52] 두 문자가 똑같이 생기긴 했지만, 실제로 그리스어 물음표는 컴파일러에서 처리하지 못하기 때문에 넣자마자 빨간 줄이 그어지며 컴파일러에서 잡아낸다. 실제로 아무런 문법적 오류도, 티 나는 수정 사항도 없이 프로그램과 개발자의 멘탈을 파멸로 몰고 갈 수 있는 방법은 따로 있는데, 그 방법은 아래 사진과 같다. 사진 상에는 보이지 않지만 소스코드의 중간에 #define true (rand() > 30)와 같은 전처리문을 끼워넣은 것으로 보인다. 파일:1665734132177.png [53] 외국에는 유사한 단어로 코더가 존재한다.