병이 있으니 운동한다고 생각하게 되면, 내 잠재의식 속에 병이 자리 잡게 됩니다 아무리 몸에 좋은 운동을 하더라도 병이란 잠재의식이 방해꾼처럼 훼방을 놓아 운동 효과를 쓸모없게 만듭니다. 그러니 운동할 때는 어떤 운동이라도 좋아하는 걸 골라서 하세요. 마음은 놀이나 게임하듯 즐겁게 가지고요.
- 전홍준의 《보디 리셋》 중에서 -
* 병이 있으니 운동을 한다? 그러면 늦습니다. 싫어하는 운동을 억지로 한다? 그것도 옳지 않습니다. 운동은 일이나 노동이 아닙니다. 일과 노동은 고되고 피곤하지만 놀이는 지치지 않고 즐겁습니다. 시간 가는 줄 모르고, 돈을 써가면서 하는 것이 놀이입니다. 운동도 놀이처럼 하면 다가오던 병도 물러납니다.
축(軸)은 바퀴를 굴리는 중심입니다. 축이 부실하거나 틀어져 있으면 가다가 멈추거나 엉뚱한 방향으로 구릅니다. 5세 이전, 인생 첫 번째 축의 핵심은 '어휘'입니다. 누구에게서 어떤 말을 듣고 새기느냐에 따라 삶의 목표와 방향이 결정됩니다.
- 고도원 박덕은의 《당신이 행복하면 나도 행복하다》 중에서 -
* 축은 수레의 중심이면서 바퀴를 다스립니다. 축이 견고해야 수레가 힘을 쓸 수 있습니다. 인생의 축은 어린 시절 다져집니다. 특히 '어휘'는 그 모든 것에 앞서는 인생의 축입니다. 엄마 아빠의 어휘력과 독서습관에 따라 아이들의 어휘 실력은 천차만별입니다. 이때 형성된 축이 아이들의 평생을 좌우합니다. 굴곡지고 험난한 길을 고장 없이 잘 굴러갈 수 있습니다.
생성형 AI가 지루한 작업을 처리하고 오류를 찾는 데 능숙하더라도 프로그래머의 전문성과 직관은 항상 필요할 것이다.
데이터셋(Datasette)의 설립자사이먼 윌리슨은 “지금이 프로그래밍을 배우기에 더할 나위 없이 좋은 시기”라고 말했다. AI가 코딩을 대신 해줘서가 아니다. 사실 정반대다. 그는 “대규모 언어 모델은 학습 곡선을 평평하게 만들어 젊은 개발자가 더 쉽게 따라잡을 수 있게 해준다”라고 말했다. 코딩하는 방법을 잊어서는 안 되지만, 생성형 AI를 사용해 경력 수준에 관계없이 개발자 경험을 강화할 수 있다.
‘배움에 대한 의지’를 예찬 필자는 생성형 AI에 대한 윌리슨의 견해를 살피는 것을 즐긴다. 그는 이 주제를 사려 깊게 생각하는 개발자다. 오라일리(O'Reilly Media)의마이크 루키데스글도 큰 주제에서 핵심을 압축해 설명했기 때문에 읽어볼 만하다. 루키데스는 생성형 AI와 코딩에 대해 “정말 좋은 프롬프트를 작성하기란 생각보다 어렵다”라는 점을 상기시켜 준다. 그는 “프롬프트를 잘 작성하려면 프롬프트의 목적에 대한 전문 지식을 쌓아야 한다”라고 말했다. 다시 말해, 먼저 ‘좋은’ 프로그래머가 돼야 한다.
루키데스는 “AI를 '인간이 얻을 수 없는 전문 지식과 지혜의 보고’로 생각해버리면 이를 생산적으로 사용할 수 없게 된다”라고 조언했다. AWS 코드위스퍼러(CodeWhisperer)나 구글 코디(Codey)와 같은 도구를 효과적으로 사용하기 위해서는 기대하는 결과물을 코칭해야 한다. 그리고 AI에게 개발 문제를 해결하는 방법을 단계별로 알려주려면, 먼저 문제를 깊이 이해하고 AI가 응답하도록 이끌어내야 한다.
또한 개발자는 AI가 틀렸을 때이를 평가할 수 있어야 한다. 여기엔 일정 수준의 전문성이 필요하다. 윌리슨이 언급한 것처럼 코딩 어시스턴트가 프로젝트에서 더 활발히 일하고 도와줄 것으로 기대되는 상황이지만, 그렇다고 해서 개발자가 코드를 파악해야 할 필요성까지 없애주진 않을 것이다. 그렇게 되기를 바라는 이도 없을 것이다. 다시 윌리슨의 첫 번째 요점으로 돌아가 본다.
AI를 활용한 코딩 학습 특정 언어, 프레임워크, 데이터베이스 등을 처음 접하는 개발자라면 학습 곡선이 가파를 수 있다. 예를 들어 “세미콜론을 놓쳐서 기이한 오류 메시지가 표시되고, 그 오류를 다시 찾는 데 2시간이 걸리는 경우도 있다”라고 윌리슨은 말했다. 당연히 이러한 점 때문에 학생들은 자신이 프로그래밍을 배울 만큼 똑똑하지 않다고 생각해 배움을 포기할 수 있다.
바로 이 부분에서 AI 어시스턴트가 개입할 수 있다. 윌리슨은 “컴퓨터공학 학위가 없어도 컴퓨터가 지루한 일을 대신 해줄 수 있어야 한다”라고 전했다. 챗GPT 같은 LLM 기반 어시스턴트는 지루한 작업을 자동화할 수 있다. 깃허브(GitHub) 엔지니어자나 도건은 “사람들은 코드 생성에만 너무 집중한 나머지 LLM이 코드 분석에 유용하다는 사실을 완전히 잊고 있다”라고 강조했다. 모든 작업을 AI가 할 필요는 없다. 윌리슨의 주장에 따르면, 애플리케이션을 만들거나 망치지는 않으나 개발자의 자신감을 떨어뜨릴 수 있는, 개별적이고 지루한 작업을 자동화하는 데 AI를 활용할 수 있다. 코딩 어시스턴트가 지루한 작업을 처리할 수 있음에도 개발자가 프로그래밍의 모든 측면을 배우고 수행할 것을 요구받는 경우에 더 그렇다.
언제나 그렇듯 생성형 AI와 함께 소프트웨어 개발을 시작하는 가장 좋은 방법은, 바로 시작하는 것이다. 이해는 했지만 반복해서 작성할 필요는 없는 간단한 작업부터 자동화해 작게 시작하라. 이렇게 절약한 시간으로 더 까다로운 코딩 문제를 해결하는 방법을 배우는 데 집중할 수 있다. 전문성이 높아지면 이러한 작업도 자동화할 수 있게 될 것이다.
생성형 AI를 도입한 소프트웨어 개발 작업에 인간 프로그래머와는 근본적으로 다른 실수가 포함된다는 사실은 잘 알려져 있다. 그럼에도 대부분의 기업에서 AI 코딩 실수를 수정하는 계획은 단순히 숙련된 인간 프로그래머를 루프에 투입하는 것에 의존하고 있다.
숙련된 인간 프로그래머는 인간 프로그래머가 저지르는 실수와 지름길의 종류를 직관적으로 알고 있다. 하지만 소프트웨어가 소프트웨어를 만들 때 발생하는 실수의 종류를 찾아내는 훈련은 별도로 필요하다.
이러한 논의는 이르면 2026년부터 대부분의 개발자가 더 이상 코딩을 하지 않을 것으로 예상한다는 AWS CEO 매트 가먼의 발언으로 더욱 가속화되었다. 개발 도구 분야의 많은 업체는 AI 코딩 앱을 관리하기 위해 AI 앱을 사용하면 이 문제를 해결할 수 있다고 주장했다. 2번째 열차 사고의 신호탄이나 마찬가지다. 금융 대기업인 모건 스탠리조차도 AI를 사용해 AI를 관리하는 방법을 고민하고 있다.
현실적으로 안전하고 원격으로 실행 가능한 유일한 접근 방식은 생성형 AI 코딩 오류의 특성을 이해하도록 프로그래밍 관리자를 교육하는 것이다. 사실 AI 코딩 오류의 특성이 매우 다르다는 점을 고려할 때, 인간의 코딩 실수를 발견하는 데 익숙하지 않은 새로운 사람을 AI 코딩 관리자로 교육하는 것이 더 나을 수도 있다.
문제의 일부는 인간의 본성이다. 사람들은 차이를 확대하고 잘못 해석하는 경향이 있다. 관리자는 자신이 절대 하지 않을 실수를 사람이나 AI가 저지르는 것을 보면 그 실수가 코딩 문제에서 관리자보다 열등하다고 생각하는 경향이 있다.
하지만 자율 주행 차량에 비추어 가정해 보자. 통계적으로 자율주행차는 사람이 운전하는 자동차보다 훨씬 더 안전하다. 자동화된 시스템은 피로를 느끼지도 않고, 취하지도 않으며, 고의적으로 난폭해지지도 않는다.
하지만 자율주행차는 완벽하지 않다. 그리고 교통 체증으로 정차한 트럭을 전속력으로 들이받는 등의 실수를 저지르면 인간은 “나라면 저런 멍청한 짓은 절대 하지 않았을 텐데...인공지능을 믿을 수 없어”라고 반문하게 된다. (웨이모 주차 차량 참사는 꼭 봐야 할 동영상이다.)
하지만 자율주행차가 이상한 실수를 한다고 해서 인간 운전자보다 안전하지 않다는 의미는 아니다. 그러나 인간의 본성은 이러한 차이를 조정할 수 없다.
코딩 관리도 마찬가지다. 생성형 AI 코딩 모델은 매우 효율적일 수 있지만, 자칫 잘못하면 엉뚱한 방향으로 흘러갈 수 있다.
AI는 미친 외계인 프로그래머
SaaS 기업 쿼리팰(QueryPal) CEO인 데브 내그는 생성형 AI 코딩 작업을 해오면서 많은 기업 IT 경영진이 이 새로운 기술이 얼마나 다른지에 대해 준비가 되어 있지 않다고 느꼈다.
내그는 “마치 다른 행성에서 온 외계인처럼 이상한 실수를 많이 했다. 인간 개발자가 하지 않는 방식으로 코드가 잘못 작동한다. 마치 우리처럼 생각하지 않는 외계 지능처럼 이상한 방향으로 나아간다. AI는 병적으로 시스템을 조작할 방법을 찾아낼 것”이라고 말했다.
올해 ‘AI 보조 프로그래밍’을 포함해 여러 권의 AI 프로그래밍 책을 펴낸 톰 타울리에게 물어보자.
타울리는 “예를 들어 LLM에 코드 작성을 요청할 수 있으며, 때로는 원하는 작업을 수행하기 위해 프레임워크나 가상의 라이브러리 또는 모듈을 구성할 수도 있다”라고 말했다. (타울리는 LLM이 실제로는 새로운 프레임워크를 만드는 것이 아니라 그렇게 하는 척하는 것이라고 설명했다.)
타울리는 “(인간 프로그래머가) 미치지 않는 한, 가상의 라이브러리나 모듈을 만들어서 허공에서 만들어내지는 않을 것”이라고 지적했다.
이런 일이 발생하면 누구든 찾아보면 쉽게 발견할 수 있다. 타울리는 “직접 설치하려고 하면 아무것도 없다는 것을 알 수 있다. 이 경우 IDE와 컴파일러에서 오류가 발생한다"라고 설명했다.
실행 파일의 창의적인 제어를 포함해 애플리케이션 전체 코딩을 주기적으로 환각을 일으키는 시스템에 넘긴다는 생각은 끔찍한 접근 방식인 것 같다.
생성형 AI 코딩의 효율성을 활용하는 훨씬 더 좋은 방법은 프로그래머가 더 많은 작업을 수행할 수 있도록 돕는 도구로 사용하는 것이다. AWS의 가먼이 제안한 것처럼 인간을 배제하는 것은 자살 행위나 다름없다.
만약 생성형 AI 코딩 도구가 마음대로 돌아다니면서 백도어를 만들어 나중에 사람을 귀찮게 하지 않고도 수정할 수 있도록 한다면 공격자들도 사용할 수 있는 백도어를 만들면 어떨까?
기업은 앱, 특히 자체 개발한 앱의 기능을 테스트해 앱이 제대로 작동하는지 확인하는 데 매우 효과적인 경향이 있다. 앱 테스트가 실패하기 쉬운 부분은 앱이 수행해서는 안 되는 작업을 수행할 수 있는지 확인하는 경우이다. 이것이 바로 모의 침투 테스트 사고방식이다.
하지만 생성형 AI 코딩 현실에서는 이러한 펜 테스트 방식이 기본이 되어야 한다. 또한 생성형 AI의 실수라는 엉뚱한 세계에 대해 잘 교육받은 감독자가 이를 관리해야 한다.
기업 IT는 확실히 더 효율적인 코딩 미래를 기대하고 있다. 프로그래머는 앱이 무엇을 해야 하는지, 왜 해야 하는지에 더 집중하고 모든 줄을 힘들게 코딩하는 데 시간을 덜 할애하여 더 전략적인 역할을 맡을 것이다.
하지만 그러한 효율성과 전략적 이득은 막대한 대가를 치러야 한다. AI가 생성한 코드가 올바른 방향으로 나아가도록 하기 위해 더 뛰어나고 다르게 훈련된 인력을 고용해야 하기 때문이다.
