코더에서 소프트웨어 엔지니어까지

프로그래밍 직종이 1940년대부터 지금까지 어떻게 바뀌었는지 정리한다.

연대별 요약

매 10년마다 밑단이 도구로 내려가고 프로그래머는 한 층 위로 올라갔다. 기계어 → 어셈블리 → 고급 언어 → 라이브러리 → 프레임워크 → 클라우드 → AI. 대신 위에서 일이 내려왔다. 1970년대부터 분석가의 설계가, 1980년대부터 사용성이, 2000년대부터 테스트가, 2010년대부터 운영이 프로그래머 몫이 됐다.

코더가 하는 일은 줄어든 게 아니라 자리가 옮겨졌다. 기계 쪽 일은 도구에 넘기고, 사람 쪽 일을 받았다.

지금 소프트웨어 엔지니어는 1950년대 기준으로 분석가+프로그래머+오퍼레이터+테스터를 한 사람이 하는 직종이다. 패러다임 전환은 대략 10년 주기다.

용어

• 컴퓨터 과학: 계산과 정보를 다루는 학문. 기계보다 "무엇을 어떻게 계산할 수 있는가"가 핵심.
• 공학: 과학 지식을 써서, 제약(비용·시간·안전) 안에서 실제로 쓸 수 있는 것을 만드는 활동. 과학이 참/거짓을 묻는다면 공학은 잘 됨/안 됨을 묻는다.
• 소프트웨어 공학: 쓸 만한 소프트웨어를 제때, 감당 가능한 비용으로, 계속 고쳐가며 만드는 방법. 1968년 NATO 회의에서 소프트웨어 위기(납기 지연, 예산 초과, 버그)를 해결하려고 붙인 이름. 다루는 범위는 요구사항, 설계, 구현, 테스트, 유지보수, 형상 관리, 프로세스, 프로젝트 관리, 품질. 상당 부분이 사람과 조직에 대한 이야기다.
• 소프트웨어 엔지니어: 원래는 위 일을 책임지는 사람. 현실에서는 프로그래머·개발자의 격 높인 직함으로 쓰이며, 하는 일과 무관한 경우가 많다.

1940년대: 코더

ENIAC·EDSAC 시절, 코더는 남이 짠 순서도를 기계어로 옮기는 사람이었다.

역할 위계:

1. 분석가 / 수학자: 문제를 풀 방법을 순서도로 그림. 지적인 일로 여겨졌고 대부분 남성.
2. 코더: 순서도를 기계 명령어와 숫자로 번역. 사무직으로 여겨졌고 대부분 여성. ENIAC 첫 프로그래머 6명이 전원 여성이었다.
3. 키펀치 오퍼레이터: 코딩 용지를 보고 카드에 구멍을 뚫음. 검공(verifier) 절차가 있어 오류가 걸러졌다.
4. 컴퓨터 오퍼레이터: 카드를 기계에 넣고 실행.

실제 난이도

"번역"이라 불렀지만 사실상 설계였다.

• 메모리가 극도로 부족했다. EDSAC은 워드 512~1024개. 주소를 손으로 배정하고, 모자라면 알고리즘을 다시 짰다.
• 명령어가 빈약했다. 순서도 한 칸이 수십 줄 코드였다. 소수점이 없어 자릿수를 미리 계산했다.
• 반복문에서 배열을 순회하려면 실행 중에 명령어 안의 주소를 고쳐야 했다.
• 디버깅 수단이 없었다. 한 명령씩 돌리며 램프를 읽었다.
• 순서도가 불완전했다. 경계 조건, 오버플로, 초기화를 코더가 발견해 메웠다.

책임

결과가 틀리면 코더가 책임졌다. 키펀치는 검공, 오퍼레이터는 로그로 검증 가능했고, 분석가는 결과가 나올 때쯤 다른 프로젝트에 가 있었다. 순서도 오류로 밝혀져도 고치는 건 코더였다. 책임 있는 사람이 권한도 갖게 되면서 코더가 설계까지 떠안는 계기가 됐다.

교육

필요했지만 "필요 없다"고 여겨졌다. ENIAC 프로그래머 6명은 전원 수학 전공자였고, 매뉴얼이 없어 회로도와 배선도로 기계를 이해했다. 정규 교육 과정도 없이 현장에서 스스로 익혔다.

왜 격하됐나

• 아무도 해본 적이 없었다. von Neumann은 "수학 문제를 푸는 게 지적인 일이고, 기계 형식에 맞추는 건 사무 절차"라고 봤다. 실제로 해보지 않은 사람의 추정이었다.
• 누가 하느냐가 평가를 정했다. 여성이 하는 일은 사무직이라는 당시 인식이 그대로 붙었다.
• 비유가 잘못됐다. 번역은 원문이 완성돼 있을 때 성립하는데, 순서도는 완성된 원문이 아니었다.

"코딩은 AI가 하니까 사람은 기획만 하면 된다"는 말이 1947년 "코딩은 사무 절차"와 같은 구조다.

1950년대: 프로그래머

상용화

컴퓨터 자체가 상품이 됐다. 1951년 UNIVAC I이 돈 주고 살 수 있는 첫 컴퓨터였고, 미국 인구조사국이 첫 고객이었다. 은행, 보험사, 항공사가 급여 계산, 계좌 관리, 예약에 컴퓨터를 썼다. 컴퓨터 쓰는 사람이 수학자에서 회사원으로 바뀌었다.

코더에서 프로그래머로

수학자 아닌 사람들이 프로그래밍을 배우려다 실패하면서 "아무나 못 하는 일"이 드러났다. 1950년대 중반이면 프로그래머가 표준 직함이 됐고, 급여가 올랐다. 어셈블러와 FORTRAN이 나오면서 "기계어로 옮기는 일" 자체가 없어졌으니 코더라는 이름도 뜻을 잃었다. 이후 코더는 "생각 없이 코드만 치는 사람"이라는 낮춤말로 남았다.

업무를 아는 시스템 분석가와 기계를 아는 프로그래머로 나뉘었다. 분석가는 기계어를 몰라도 됐다. 둘의 격차는 "문제를 정의하느냐, 남이 정의한 걸 옮기느냐"였다.

여성의 퇴장

일부는 프로그래머가 됐다. Betty Holberton은 UNIVAC 개발에 참여해 최초의 정렬 프로그램과 COBOL 표준을 만들었다. 1960년대까지 프로그래머의 30~50%가 여성이었다는 추정도 있다.

집단으로는 밀려났다. 코딩이 전문직으로 격상되자 그 자리를 남성이 채웠고, 1960년대 프로그래머 적성검사는 "사람과 어울리기 싫어하는 성향"을 자질로 넣었다. 1980년대 가정용 컴퓨터가 남자아이 장난감으로 팔리며 격차가 굳어졌다. 미국 컴퓨터 과학 전공 여성 비율은 1984년 37%에서 2010년대 18%까지 떨어졌다.

언어

• FORTRAN (1957): IBM, 과학·공학 계산용. 최초로 널리 쓰인 고급 언어.
• LISP (1958): MIT, 인공지능 연구용.
• COBOL (1959): 미 국방부 주도, 업무용.

초기 프로그래머들은 컴파일러가 만든 코드를 불신했다. FORTRAN 팀이 최적화에 공을 들인 이유다.

운영체제

없었다. 프로그래머가 카드 읽기, 프린터 출력, 테이프 제어를 매 프로그램마다 짰다. 1956년 GM과 노스아메리칸 항공 프로그래머들이 IBM 704용 배치 모니터(GM-NAA I/O)를 만든 것이 최초의 운영체제로 꼽힌다. IBM은 하드웨어만 팔았고 소프트웨어는 사용자 모임 SHARE(1955)에서 나눴다.

1960년대: 응용과 시스템의 분화

• ALGOL 60 (1960): 블록 구조, 중첩 함수. C, Pascal, Java의 조상.
• BASIC (1964): 교육용.
• Simula 67 (1967): 클래스와 객체 최초.
• IBM OS/360 (1964~): 컴퓨터를 사면 운영체제가 딸려왔다. 응용 프로그래머는 입출력 코드를 짤 필요가 없어졌다. 시스템 프로그래머와 응용 프로그래머가 갈라졌다.
• 계층형 DB IBM IMS (1966). 데이터 구조를 미리 정해두고 포인터로 따라가는 방식. 새 질의를 하려면 프로그램을 다시 짜야 했다.

OS/360 개발의 어려움이 『맨먼스 미신』을 낳았고, 1968년 NATO 소프트웨어 공학 회의의 배경이 됐다. 같은 해 Dijkstra의 "goto 유해론"으로 구조적 프로그래밍이 자리잡기 시작했다.

고급 언어를 쓰되 필요하면 어셈블리로 내려갈 줄 알아야 했다. OS/360은 어셈블리로 짜였다.

1970년대: 유닉스와 C

• C (1972): 운영체제를 짤 수 있는 고급 언어. 어셈블리를 밀어냈다.
• 유닉스와 C 표준 라이브러리: 하드웨어를 몰라도 되는 첫 환경. 기계가 바뀌어도 코드를 옮길 수 있게 됐다.
• 관계형 DB: Codd 논문(1970), IBM System R, Oracle(1979). IBM 내부에서도 "너무 느리다"는 반응이었다. 널리 쓰인 건 DB2(1983), SQL ANSI 표준(1986) 이후다.
• Smalltalk (1972~80): 제록스 PARC. 객체지향과 GUI 환경. 프레임워크의 직접 조상.
• 마이크로프로세서 임베디드: 메인프레임은 OS가 있었지만 8비트 보드에는 없어서, 프로그래머가 운영체제를 직접 만들었다. Robert Martin이 Teradyne에서 8085용 실시간 OS를 만든 것이 그 예다(『클린 아키텍처』 부록 A).

프레임워크는 아직 없었다. 프레임워크는 "뼈대가 내 코드를 호출하는" 구조라 객체지향의 상속과 다형성이 필요했다. 1970년대 프로그래머는 라이브러리를 부르는 사람이었다.

1980년대: PC와 객체

개인용 컴퓨터

• 1977: Apple II, Commodore PET, TRS-80. 사서 바로 쓰는 첫 개인용 컴퓨터.
• 1979: VisiCalc. 회사가 컴퓨터를 사야 할 이유를 만든 첫 소프트웨어.
• 1981: IBM PC. 호환기종이 쏟아지며 표준이 됐다.
• 1982: Commodore 64. 가정 보급의 주역.
• 1984: Macintosh. 1990: Windows 3.0.

메인프레임은 회사에서만 만질 수 있었는데 PC는 집에서 독학이 가능했다. 1980년대에 10대 때 BASIC으로 시작한 세대가 1990년대 업계 주력이 됐고, 컴퓨터 과학 학위 없는 프로그래머가 흔해졌다.

PC통신

미국은 1978년 CBBS, 1979년 CompuServe부터. 한국은 1986년 천리안, 1988년 케텔(하이텔)부터 시작해 1990년대 하이텔·천리안·나우누리·유니텔이 전성기였다. BBS와 동호회가 프로그래밍 독학의 통로였고, 셰어웨어와 소스 코드가 여기서 오갔다. 오픈소스 문화의 전신이다.

세 가지 전환

• 누가 쓰는가: 회사에서 개인으로. GUI, 사용성, 문서화가 처음으로 중요해졌다.
• 어떻게 짜는가: 절차에서 객체로. Smalltalk-80 공개, C++(1985). MacApp(1985)이 첫 GUI 프레임워크다.
• 누가 만드는가: 회사 직원에서 독립 개발자로. 소프트웨어를 따로 사는 시장이 생겼다. 마이크로소프트, 로터스, 어도비.

객체지향으로 짜다 보니 "잘 짜는 법"이 문제가 됐고, 그 답이 1990년대 디자인 패턴(1994)과 XP(1996)다. Kent Beck, Ward Cunningham, Ron Jeffries가 전부 1980년대 Smalltalk 경험에서 출발했다.

1990년대: 웹과 자바

• HTML과 브라우저 (1991~93): 문서 공유 도구였던 웹이 소프트웨어 배포 채널이 됐다. 설치 없이 URL로 프로그램을 쓰는 시대.
• Java (1995): "한 번 짜면 어디서나 실행". 가비지 컬렉션으로 메모리 관리를 개발자 손에서 뺐다. C++의 대안으로 기업 시스템 표준이 됐다.
• PHP (1995), Python·Ruby 확산: 스크립트 언어로 진입 장벽이 낮아졌다. JavaScript도 1995년에 나왔고 홈페이지 제작의 일부로 널리 쓰였지만, 롤오버와 폼 검사 정도였다. 브라우저마다 달라 진지한 로직은 서버에서 처리했고, 프로그래밍 언어보다 HTML의 부속으로 여겨졌다.
• Windows 95 (1995): 미국 가정 PC 보급률이 30%를 넘고 2000년에 50%를 넘었다.
• Linux (1991)와 오픈소스: 운영체제, 웹 서버(Apache), DB(MySQL)를 공짜로 쓸 수 있게 됐다. 1998년 "오픈소스"라는 이름이 생겼다.
• 디자인 패턴 (1994), XP (1996), 애자일 선언 (2001): 객체지향으로 "잘 짜는 법"과 "잘 일하는 법"이 체계화됐다. 다만 이건 소수의 일이었다. C++와 Java는 주류였지만 대부분의 코드는 절차적이었다. 클래스는 함수를 담는 통이었고, "C++로 짠 C"라는 말이 이때 나왔다. 책임 주도 설계와 디자인 패턴 책이 나온 이유 자체가 그 문제를 봤기 때문이다. UML과 RUP가 객체 설계를 대중화하려 했지만 다이어그램 그리기가 목적이 되면서 어긋났고, 그 반발이 XP의 "설계는 코드에서"다.

프로그래머가 웹 개발자로 불리기 시작했다. 화면(HTML), 로직(서버), 데이터(DB)를 한 사람이 다루는 경우가 많아 "풀스택"의 전신이 됐다. 닷컴 버블(1995~2000)로 수요가 폭증해 학위 없는 독학 개발자가 대거 유입됐다.

2000년대: 애자일과 오픈소스

• 애자일 선언 (2001): 문서와 계획보다 동작하는 소프트웨어와 협업. 분석가·프로그래머·테스터 분리 모델을 버리자는 주장이었다. 실리콘밸리 스타트업과 일부 선도 기업이 도입했고, 대부분 기업은 여전히 폭포수와 CMMI였다.
• TDD, 리팩터링, 지속적 통합: 테스트가 개발자 일이 되기 시작했다.
• 프레임워크 시대: Spring (2003), Ruby on Rails (2004), Django (2005). 웹 애플리케이션의 뼈대를 프레임워크가 제공하고, 개발자는 업무 로직만 채웠다. 한국은 2000년대 초반 Struts나 JSP에 직접 JDBC가 많았지만, 2005~2008년 한국 스프링 사용자 모임과 토비 이일민의 강의로 스프링+iBatis가 SI 현장의 사실상 표준이 됐다. 2009년 전자정부 표준프레임워크가 스프링을 택한 건 이미 퍼진 것을 공식화한 것이고, 이후 2010년대 한국은 스프링+MyBatis가 거의 독점했다.
• Ajax (2005), jQuery (2006): 구글 맵과 Gmail이 새로고침 없이 동작하는 걸 보여주며 JavaScript가 진지한 언어가 됐다. jQuery가 브라우저 차이를 숨기면서 한국 SI도 본격적으로 썼다. 그 전 한국은 IE와 ActiveX가 표준이었다.
• Git (2005), GitHub (2008): 코드 공유가 기본이 됐다. 오픈소스 기여가 경력이 됐다.
• iPhone (2007), App Store (2008): 개인 개발자가 전 세계에 소프트웨어를 팔 수 있게 됐다.
• AWS (2006): 서버를 사지 않고 빌려 쓰는 시대. 운영이 코드로 넘어오는 시작점.

"개발자"가 표준 호칭이 됐다.

2010년대: 클라우드와 모바일

• DevOps: 개발과 운영의 통합. 배포, 모니터링, 인프라가 개발자 일이 됐다. "인프라를 코드로"(Terraform 2014).
• Docker (2013), Kubernetes (2014): 실행 환경까지 개발자가 정의했다.
• 마이크로서비스: 큰 시스템을 작은 서비스로 쪼개고, 팀이 서비스를 소유했다. 팀이 곧 작은 회사처럼 됐다.
• 모바일: iOS·Android 개발이 별도 전문 분야가 됐다.
• JavaScript의 확장: Node.js (2009), React (2013). 브라우저 언어가 서버와 앱까지 갔다.
• 스택오버플로 (2008), 부트캠프 확산: 검색과 단기 교육으로 진입하는 사람이 늘었다.
• FAANG 급여 경쟁: "소프트웨어 엔지니어" 직함이 세계적으로 표준화됐고, 격 높은 직업으로 자리잡았다.
• 애자일이 이름으로는 주류가 됐다. 스크럼, 스프린트, 스탠드업을 안 쓰는 회사가 드물어졌다. 실천은 소수였다. 2주 스프린트 안에서 폭포수를 돌리는 형태가 흔했고, Ron Jeffries가 2018년 "개발자는 애자일을 버려라"고 쓴 이유다. 한국은 SI와 대기업이 계약 기반 폭포수를 유지했고, 서비스 회사 위주로 2010년대 후반에 퍼졌다.

한 사람이 코드, 테스트, 배포, 운영, 모니터링을 다 하는 것이 기본이 됐다. 1950년대 기준으로 네 직종을 한 사람이 하게 됐다.

이것도 미국 서비스 회사 기준이다. 한국은 배포와 서버를 운영팀·인프라팀이 맡았고, 개발자는 빌드 결과물을 넘기면 끝이었다. 서버는 IDC 물리 서버나 VM이었고, 클라우드 전환은 2010년대 후반 네이버·카카오·쿠팡 같은 서비스 회사부터였다. Docker는 2017~18년, Kubernetes는 2019~2020년 이후에야 서비스 회사에서 쓰기 시작했고, SI와 금융은 2020년대에도 온프레미스가 많았다. "DevOps"라는 이름은 있었지만 개발자가 운영을 겸하는 게 아니라 운영팀을 개명한 경우가 흔했다.

2020년대 전반: 원격과 AI 보조

• 팬데믹 (2020): 원격 근무가 기본이 됐다. 협업이 문서와 비동기 소통 중심으로 옮겨갔다.
• GitHub Copilot (2021), ChatGPT (2022): AI가 코드를 제안했지만, 쓰고 판단하는 건 사람이었다. 자동완성과 검색을 대체하는 보조 도구였다. 초기에는 보안을 이유로 막은 회사가 많았지만, 제안 품질이 좋아지면서 보일러플레이트 타이핑이 점점 줄었다. 다만 판단과 구조는 여전히 사람 몫이었다.
• 2023~2025: 빅테크 감원과 채용 축소. 닷컴 버블 이후 처음으로 수요가 꺾였다.

개발자는 여전히 직접 코딩했다. AI는 타이핑을 줄여줬을 뿐 일의 구조는 2010년대와 같았다.

2026~: AI 에이전트

• 코딩 에이전트: 명세를 주면 파일을 읽고, 코드를 짜고, 테스트를 돌리고, 고치는 것까지 AI가 한다. 코드 작성 자체가 사람 손을 떠나기 시작했다.
• 개발자의 일이 "코드 쓰기"에서 "무엇을 만들지 정하고, AI가 만든 것을 검증하기"로 옮겨가는 중이다.
• 1947년 "코딩은 사무 절차"와 같은 말이 다시 나온다. "코딩은 AI가 하니까 사람은 기획만 하면 된다." 그때처럼 실제로 해보면 다를 가능성이 높다. 명세를 실행 가능할 만큼 정확히 쓰는 것이 결국 프로그래밍이라는 것을 1970년대에 이미 배웠다.

분석가의 행방

코더가 "어떻게"를 전부 가져오는 동안, 분석가는 "어떻게"를 잃고 "무엇을"만 남았다.

• 1940년대 수학자: 문제와 풀이를 다 알고 순서도를 코더에게 넘김.
• 1950~60년대 시스템 분석가: 업무를 아는 사람. 기계어는 몰라도 됐고 프로그래머보다 위였다.
• 1970~80년대: 순서도가 실행 가능할 만큼 정확하려면 코드와 같다는 게 드러나 설계가 프로그래머에게 넘어감. 분석가는 요구사항 정리로 줄어듦.
• 1990년대: 기술 설계는 아키텍트, 요구사항은 비즈니스 분석가, 일정과 사람은 프로젝트 매니저로 갈라짐.
• 2000년대 애자일: 분석가 없이 고객이 개발자와 직접 대화하자는 주장. XP의 현장 고객, 스크럼의 프로덕트 오너.
• 2010년대: 서비스 회사에서 분석가의 일이 셋으로 쪼개짐. 무엇을 만들지는 프로덕트 매니저, 숫자로 판단하기는 데이터 분석가, 사용자 파악은 UX 리서처. 어떻게 만들지만 개발자에게 갔다. SI에는 분석가가 옛 의미로 남아 있다.

없어진 건 "업무를 알고 순서도를 그려 개발자에게 넘기는 단일 직종"이지, 일 자체는 이름을 바꿔 남아 있다. 한국 서비스 회사의 기획자는 미국 PM보다 옛 분석가에 가깝다. 화면 정의서와 기능 명세를 상세히 쓰고 개발자가 구현하는 구조라, SI의 분석가-개발자 관계가 기획자-개발자로 이어진 셈이다.

2026년 이후 AI가 "어떻게"를 가져가면 개발자는 "무엇을"로 올라가야 하는데, 그 자리에 이미 PM과 기획자가 있다. 개발자가 기획자가 되느냐, 기획자가 개발자가 되느냐, 새 직종이 생기느냐가 갈리는 중이다.