★ ‘10년이 가도 변치 않을 업의 지혜, 그 후 2년’(최현우) _ 3쪽
연두색 바탕에 나열된 블록들 위로 ‘코볼의 구조’라는 고딕 폰트를 사용한 흰색 글자가 선명하게 빛나고 있었습니다. 2024년 6월 21일 금요일. 이 책의 출간 1년 7개월을 기념한 행사 〈래빗톡 : 개발자 원칙 완전체〉 현장에는 ‘AI 코파일럿이 내 프로그래머라는 직업을 삼켜버릴 것 같다’는 위기감에 휩싸인 청중 70명의 눈이 잊혀진 언어의 구조에 초점을 맞추고 있었습니다. 발표자가 다음 페이지를 넘기자 코볼 코드가 등장했습니다. “Hello Cobol World“를 출력하는 단정한 코드 뭉치. 데이터 처리 목적으로 만들어진 양산형 개발자의 언어! 단순한 문법으로 사랑받으며 사실상 기업용 애플리케이션의 표준 언어로 자리잡았던 코볼이 프로젝트의 빔으로 소환되었습니다. 이어서 화자는 화두를 던졌습니다.
“AI 시대, 어떤 개발자가 될 것인가?”
공저자이자, 존경받는 (나만의 생각으로는) ‘구도자형 개발자’인 박성철 본부장은 ‘이런 개발자가 되고 싶었던 건 아니었는데 말이죠...’를 강연하며 개발 초년부터 지금까지 이어진 ‘진짜 프로그래머’ 논쟁을 ‘어떤 개발자가 될 것인가’라는 명제에 이어붙였습니다. 끝없이 변화하고 혁신이 반복되는 업계에서 실존적 존재로서 적응하며 살아 남는 문제로 말이죠.
아홉 저자가 모두 모인 행사장에 질문이 끊임없이 이어졌습니다. 저자 사이에 의견도 갈렸습니다. 서로 마이크를 번갈으며 반론에 반론을 더했습니다. 질문은, “AI가 개발자를 대체하지 않겠는가?”, “AI 시대에 우리는 어떻게 해야 하는가?”, “AI를 업무에 어디까지 이용하나?” 같은 AI 일변도였습니다.
2022년 11월 이 책은 예약 판매에 들어갔습니다. 우연의 일치로 같은 기간 챗GPT 3.5가 공개되었습니다. AI 광풍이 개발 현장에 찾아왔습니다. 이 책의 엮은이로서 궁금해졌습니다. 그간 저자들에게는 무슨 일이 벌어졌을까? 과연 ‘10년이 가도 변치 않을 업의 지혜’를 담은 이 책의 내용이 AI 시대에도 유효한가? 그리고 개발자는 어떻게 살아가야 하는가?
행사 당일 강대명 저자는 이렇게 말했습니다.
“더 깊고 자세히, 더 많이 공부하라.”
‘프로그래머가 무엇인지’에 대한 정의는 아직 내려지지 않았지만, 그럼에도 프로그래머는 오늘을 살아가야 합니다. 길이 안 보일 때는 그저 할 수 있는 일을 할 뿐입니다. 그런 하루하루가 모이면 훗날 누군가가 길이라 부를 것입니다. 그러니 섣부른 답을 찾으려 책장을 펼치지는 말기 바랍니다. 이 책은 애초에 정답을 품지 않았습니다. 먼저 걸어간 선배의 발자취만 담았을 뿐입니다.
★ ‘덕업일치를 넘어서’(박성철) _7쪽
개발자에게 소위 덕업일치의 삶은 덜 고통스럽고 남보다 수월하거나 유리한 삶이라는 시선이 있습니다. 프로그래머라는 직업이 생소하고 정립되지 않았던 시절, 용기를 내어 어릴 때 접한 프로그래밍을 직업으로 삼고 살아보기로 결심했습니다. 그 결심에 도움이 되었던 생각을 원칙으로 삼고 미래가 불투명한 프로그래머라는 직업을 탐색했습니다.
직업인으로서 프로그래머는 단지 프로그래밍할 줄 아는 사람이라는 의미와 매우 다른 모습이었고 전문가로서 프로그래머는 더 먼 여정이 필요했습니다. 이 글은 이왕 선택한 직업이 의미 있고 인정받는 직업이었으면 하는 마음으로 길을 떠났던 여러 사람 중 한 사람의 중간 보고서입니다.
제가 경력을 시작할 때와 달리 개발자는 인기 많은 직업이 되었고 친숙해졌습니다. 하지만 아직도 전문가로서 인정받지는 못하고 있습니다. 남은 이 길을 같이 떠나 보기를 권하고 싶은 마음에 성급하게 글을 정리해보았습니다.
★ ‘출간 후 2년, 그다음 이야기’ (공용준)_146쪽
생성형 AI가 만든 코드들이 완벽하게 돌아가진 않지만 적어도 내 설계가 어떠한지 곧바로 확인할 수 있게 되어서 ‘구현부터 하지 말고, 제발 설계부터 하자!’는 원칙을 훨씬 더 강화해서 적용해도 될 환경이 마련되었습니다.
그간 제품 개발 전이나 신규 항목을 리뷰할 때 RFDC* 세션을 만들어서 진행했습니다. 처음 개발자들 반응은 “우리가 왜 이런 문서를 써? 항목은 뭐 이리 많아!”였는데, 막상 도입하고 나니 설계에 대한 개선 사항을 토론하는 문화가 생겨 제품 개선에 많은 도움이 되었다고 하더라고요. 그동안 제가 주창한 ‘소프트웨어엔 설계가 없다(그래서 문제다)’에 대한 공감도 얻을 수 있었습니다. 제품 설계와 사전 리뷰가 이렇게 유익합니다. 여러분도 적극 도입하기 바랍니다.
★ ‘달리는 기차의 바퀴를 갈아 끼우기’(장동수) _291쪽
지금까지 개발 문화의 3가지 행동 강령과 글쓰기의 중요성을 말씀드렸습니다. 행동 강령을 아무리 지켜나가려고 해도 글쓰기 능력, 코딩하는 능력이 없으면 그럴 수 없습니다. 글을 마무리하면서 《유시민의 글쓰기 특강》에 나오는 ‘글쓰기’를 ‘코딩’으로 바꿔서 읽어보겠습니다.
“코딩을 잘 하려면 많이 읽어야 합니다. 코드를 많이 읽어도 코딩을 잘 못할 수는 있습니다. 그러나 많이 코드를 많이 읽지 않고도 코딩을 잘하는 것은 불가능합니다. 코딩을 많이 할수록 더 잘하게 됩니다. 축구나 수영이나 글쓰기가 그런 것처럼 코드도 근육이 있어야 쓸 수 있습니다. 코딩 근육을 만드는 유일한 방법을 코딩을 하는 겁니다.”
여기에 예외는 없습니다.
그래서 ‘원칙’입니다.
