잡스는 세계 최초로 개인용 컴퓨터, 즉 PC를 만든 선구자로 추앙되지만, 사실 애플 I과 애플 II는 하드웨어와 소프트웨어 모두 애플의 공동창업자 워즈니악이 만들었다. 잡스가 애플 II를 잽싸게 잘 팔았던 덕도 있지만, 애플 II가 공전의 히트를 칠 수 있었던 것은 희대의 천재 워즈니악이 정말 애플 II를 잘 만들었다는 데 있다. 애플 II는 애플이 후속 제품을 발매한 이후에도 후속작 매출을 능가하며 약 10년 동안 애플을 먹여살렸을 정도다. PC의 선구자라면 잡스가 아니라 워즈니악을 첫 번째로 꼽아야 하는 것이 아닐까?!
[그림] Apple II (출처 : 위키)
그런데 우리가 최초라고 믿고 싶은 애플 I은 세계 최초의 개인용 PC가 아니다. 그보다 3년 일찍 1974년에 앨테어 8800(Altair 8800)이 출시되었는데, 앨테어 8800이 최초의 개인용 컴퓨터다.
국민학교를 나온 사람이라면 아마 중고등학생 시절 최초의 컴퓨터가 에니악이라고 교과서에서 배웠을 것인데, 구글의 모회사 이름인 ABC와 같은 이름의 컴퓨터가 최초라고 이미 1973년 10월 19일 미국 법원이 판결을 내려주었다. ABC는 무려 1942년 탄생했다. 에니악은 1946년에야 완성되었다. 개인용 컴퓨터 시대는 최초의 컴퓨터로부터 무려 32년이나 후에 시작되었다.
내가 대학에서 처음 들은 프로그래밍 언어 수업은 포트란이다. 1학년 1학기를 마치고 2학기가 되니 포트란 수업은 온데 간데 없고 C 언어 수업이 즐비했다. 군대에 갔다오니 JINI라는 프로그램이 프로그램 잡지에서 좀 회자되다가 Java라는 언어를 학교 수업에서 만날 수 있었다. C와 자바의 과도기에 스몰토크를 이용해 객체지향을 조금 익혔다(스몰토크는 객체지향 언어의 효시로 여겨지는데 대중적으로 성공했다고 볼 수는 없다. 영향력 만큼은 만점!). 그 당시에 프로그램 과제를 제출하는 방법은 두 가지였다. 하나는 텔렛으로 접속해 vi로 프로그램을 짜고 돌려본 후 제출하기, 또는 플로피 디스크로 제출하기.
[그림] 스몰토크 프로그래밍(출처 : https://docs.huihoo.com/smalltalk/Smalltalk-Overview.html)
회사에 입사하니 극한 서버 환경이 아니면 vi를 쓸 일이 많지 않았다. MS 비주얼 스튜디오를 쓰거나, 울트라 에디터 같은 편의 기능을 제공하는 IED/에디터를 썼다. 그뿐만 아니라, 플로피 디스크도 잘 쓰지 않았다. 컴퓨터 한 대에 쓰기 가능 기능을 두고 소스를 관리했다. 이 기간 USB 스토리지도 좀 사용했다. 그러다가 SVN을 도입했는데 신세계! 아마 Linus Torvalds가 git(깃)을 개발하지 않았다면 아직도 SVN을 이 글을 읽는 여러분도 쓰고 있을지 모른다!
나는 그때까지만 해도 너무 어렸던 탓에? 혹은 무지했던 탓에 앞으로의 변화의 방향을 잘 몰랐다. 어쩌면 변화가 없길 바랐던지도 모른다. 특히 내가 주력을 삼았던 윈도우 디바이스 드라이버 영역은 새로운 운영체제가 출시될 때마다 대응해야 하는 버전 수가 늘어나기 때문에 무엇보다 새로운 운영체제 출시 소식이 너무 무서웠다. NT로 대변되는 서버 계열과 개인용 윈도우 계열이 번갈아 출시되고, 특히나 그 둘을 통합하며 과거와의 호환성을 저버린 윈도우 7은 정말 악몽이었다. 인간 코딩으로 주어진 시간 안에 그 많은 윈도우 버전에 알맞는 디바이스 드라이버를 만드는 일은 쉽지 않다. 무엇보다 디바이스 드라이버는 다른 디바이스 드라이버와 충돌이 잦다. 특히 안티 바이러스 프로그램들과 천적이다.
그때 챗GPT나 깃허브 코파일럿이 있었다면 나는 이렇게 질문했을 것이다.
“너는 MS 윈도우 디바이스 드라이버 전문가야. 이 네트워크 드라이버는 윈도우 2000용이야. 윈도우 7에 설치하고 싶어. 두 운영체제에서 네트워크 드라이버를 설치할 INI 파일을 만들어줘. 그러고 나서 내가 다음 단계라고 말하면 디바이스 드라이버에서 운영체제별 최적화해야 하는 곳 코드를 알려주고, 각각의 코드를 제시해줘”라고…
그런데 그때는 그러지 못했다. MSDN을 뒤지고, 가뭄에 콩나듯 출판되는 관련 서적을 기다려 구매해 탐독했다. 그리고 맨땅에 헤딩을 한다. 아마 그 시절 개발자는 나만 헤딩에 능한 것이 아니었을 것이다. 그래도 나는 좀 나은 편이다. 워즈니악이 애플 II에 키보드라는 멋진 휴먼 인터페이스를 붙여준 덕분에 타이핑하여 코딩할 수 있었으니까! 참고로 앨테어 8800은 전면 패널에 있는 스위치를 조작해 코드를 입력했다(이것은 비트필드를 조작하는 순수 절정의 레벨 제로 코딩 기법).
[그림] 앨테어 8800(출처 : https://americanhistory.si.edu/collections/nmah_334396)
1977년 스위치에서 키보드로 코드를 입력 방식이 바뀌고 나서 멋진 에디터가 많이 나왔지만 시대를 극명하게 그을 만한 변화는 아니었다. 시간이 지나 오늘날 음성 인식으로 코딩을 하지는 못했지만, 이제 적어도 구어체로 코딩을 할 수 있게 되었다. 이는 기계와 아주 친숙한 기계어와 기계와 덜 친숙한 기계어로 코딩하던 시대와 분명히 선을 그어주어야 하는 혁명, 그래! 인간 코딩 시대의 절벽, 노 코드로 가는 변곡점! 2차 코딩 혁명이 틀림없다. 아마도!
“노코드 시대는 멀지 않았어요. 제 생각에는 5년이면 옵니다”
약 4년 전 쯤에 OOO사 M 대표님이 미팅 도중에 하신 말씀이다. 사실 노코드 시대에 대한 예언은 한둘이 아니고, 미래에 대한 예측의 정확도는 운발이라고 생각하지만, 그래도 방향성은 있어야 운발도 작용한다. 기계어 코딩, 추상화가 많이된 친 인간적인 기계어 코딩, 자연어로 코딩, 그리고 노코딩.
아마도 자연어로 코딩은 로우(low) 코딩일 수도 혹은 로우 코딩으로 이어지는 하이퍼루프일 수도 있다.
2023년 초 나는 챗GPT에 빠져 있었다. 무료로, 잘 안 되어 유료로도 써봤다. 바둑 게임 만들어줘. 오목 게임 만들어줘. 이런 거 한 방에 원하는 바대로 제공해주지 않더라. 지금은 개발자 생활을 떠나 IT 책을 기획하고 원고를 개발해 출간하는 편집자로 산다(그리고 가끔 자동화에 필요한 프로그램을 만들어 쓴다). IT 편집자의 특성상 아는 IT인이 거의 저자이거나 저자급이기 때문에 만나서 대화를 나누다 보면 배우는 바가 풍성하다.
“에잇 챗GPT 별거 없네요. 아직을 쓸 만하지 않아요”라는 말에 “그건 질문이 잘못되어 그래요. 질문을 잘하면 실력이 나쁘지 않은 후임과 일하는 기분 정도는 듭니다.” 그당시에는 선뜻 납득하지 못했는데, 질문 방법을 바꾸고 이런저런 테스트를 해보니 정말로 우리 아이가, 아니 우리 챗GPT가 달라졌다.
노코드가 인간 코딩 시대의 절벽이라고 할 때, 우리는 로우 코딩 또는 자연어 코딩 시대까지 다달았다. 언제가 될 지는 알 수 없지만 방향성은 있다. 코딩이 더 쉬워지도록 발전하기 때문에 이 주장은 사실이라고 주장하고 싶다.
이러한 코딩 혁명의 시대에 어떻게 개발자가 개발자로 살아남을 수 있을까? 1년 반 정도 챗GPT와 깃허브 코파일럿을 사용한 경험을 토대로 딱 세 가지로 정리해보자면…
첫 번째로, 개념의 이해는 코딩 문법보다 중요하다. 이는 이미 서울대 등에서 차용하는 학습 방법이다. 그렇지만 언어마다 용어나 개념이 판이하게 다르므로 역시나 과거와 같이 적어도 모던 객체지향 언어 한 가지에 익숙하긴 해야겠다. 그러면 다른 언어로 된 코드를 프롬프트와 함께 코딩하고 해독하고 수정할 수도 있게 된다. 즉 한 가지 언어를 제대로 배워라, 이때 개념을 잘 숙지해둬라. 이 말씀!
두 번째로 아키텍처 능력을 갖춰라. “쿠팡을 만들어줘”라고 주문한다고 해서 프롬프트가 뚝딱하는 사이에 쿠팡을 만들어주지 않는다. 프론트엔드와 백엔드 명세를 아주 잘 만들어야 하고, 기능마다 모듈화하여 잘게 쪼갠 후에야 부분 부분 원하는 코드를 얻을 수 있다. 그래서 명세를 만드는 능력(아키텍처)이 중요하다. 그런데 서비스마다 적당한 아키텍처가 다르니까 책 반 경험 반으로 익혀야 하는 능력이다. 어쩌면 8할이 경험일지도!!!
세 번째로는 프롬프트 기술을 익혀라. “에잇 챗GPT 쓰는 데 뭔 기술이 있어? 그냥 질문하면 되지”라고 생각하면 오산! 프롬프트는 구글링과는 다르다. 뭐든지 할 수 있지만 뭣도 못할 수 있는 인격체. 어떻게 그 인격체를 구슬릴지 궁리를 해야 한다. 그 궁리의 퀄리티는 질문의 기술에 있다.
다시 한번 말하지만 이렇게 3가지 기술이 중요한 이유는 지금 개발자는 노 코드 변곡점에 서 있기 때문이다(사실을 말하자면 첫 번째와 두 번째 능력은 현 시점 이전에도 항상 중요했다).
그렇다면 “노코드로 가는 변곡점에서 개발자에게 달라진 점이 뭘까?” 여러분은 이 질문에 뭐라 답하겠는가? 나는 생산성이라고 말하고 싶다. 과거에는 PC 앞에만 앉아 있다고 코딩이 되는 게 아니라고 빈번히 말했지만, 자연어 코딩 시대에는 안 통한다. 일주일에 코드 몇 줄을 짜서 몇 가지 기능을 만들고, 몇 가지 버그를 처리했는지를 이제는 정말로 잣대로 가져다 댈 수 있다. 생산성을 낼 수 있는 개발자, 이것이 개발자가 노코드 시대에 살아남는 궁극의 잣대가 될 것이라 나는 예측해본다.
그렇다면 이런 시대에 필요한 것 뭐?
개발자의
개발자에 의한
개발자를 위한
프롬프트와 함께 일하는 개발자를 위한 기술!
마침 그 기술을 전격적으로 그리고 본격적으로 담은 《AI 페어 프로그래밍》이 출간되었다.
이것이 개발자 생존 키트가 되길 빈다.
<- 자세히 보기
