최근 극심한 개발 슬럼프를 겪었다.
개발을 넘어서 사는 게 우울하게 느껴질 지경이었다. 여느 때의 내가 그랬듯 탄산음료 하나를 책상에 두고 컴퓨터 앞에 앉아 무언가 뚱땅뚱땅 만드는데, 도통 재미가 없었다.
나는 이때 내 인생이 무언가 잘못된 건가 싶었는데(물론 그것도 있을지도 모르지만), 지금 그때의 나를 분석해보면 그건 분명 개발 슬럼프였다.
왜 재미가 없지?????
그리고 이 ‘노잼’ 상태는 사실 이번 년 초, 정확히는 테크랩 입소 시절부터 시작된 것 같았다. 그때는 워낙 할 게 많고 바빠서 몰랐을 뿐.
왜 재미가 없는가?
이건 무조건 100% AI Agent 사용 때문이다. 내가 AI Agent를 본격적으로 사용하기 시작한 게 테크랩 입소 때부터다. 지금 생각해보면 좀 놀랍기도 한데? 그 전에는 거의 손코딩했다… (주위에서 AI Agent 써보라고 떠먹여줘도 거절함.)
테크랩 교육을 모두 끝마친 지금 내가 생각해볼 때, 그 교육과정의 제1의 목적은 분명 ‘게임 엔진에 대한 밑배경 지식 = 기초적이고 전통적인 아이디어 습득하기’이다. 코드 더미들은 단지 도구일 뿐이라는 것이다. 코드 자체보다는 왜 그런 아이디어들이 게임 엔진에서 사용되었는지, 하드웨어의 발전을 따라 왜 그런 변화가 일어났는지와 같은 ‘이유’가 더 중요했다. 분명 모든 교육생들이 동의할 것이다. 코치님들의 피드백도 매번 그런 방향으로 우리를 이끌어가려고 했으니까.
내가 하고픈 말은 해당 교육과정이 AI 사용을 명시적으로 권장하지는 않았더라도, ‘교육과정의 최우선 1순위 목적상, 그리고 4인 팀에 부여된 것치고는 꽤나 과도한 주간 할당량상’ 생성형 AI를 사용하게 된 건 자연스러운 수순이라는 것이다. (그 때문에 ‘구현은 했는데 왜 그렇게 했는지 설명을 못하는’ 사람들이 나오는 안타까운 부작용도 발생했다만…)
테크랩에 있었던 시절에는 눈치를 못 챘다. 사람들과 일정상의 이벤트들 덕에 늘 도파민거리가 넘쳐나기도 했고, 무엇보다 너무 바빴거든.
복학하고 나서 홀로 프로젝트를 하게 되어서야 깨닫게 된 것이다:
아, AI Agent 쓰니 개발 노잼이야!!!
내가 개발에서 즐거움을 느끼는 기전: ‘개발은 창작이다’
나는 창작을 참 좋아한다. 어린 시절 꿈이 일러스트레이터였을 정도.
지금도 그림 그리기는 물론이고, 글쓰기도 꽤 좋아한다.
내가 자아가 비대해서 방출하지 않고 살아가기 어려운 타입인가 생각한 적도 있다
개발도 이런 이유에서 재미를 느꼈었다.
- ‘내가 이런 걸 직접 만들 수 있네!’
- ‘와 내가 머릿속으로 구상한 걸 만들어냈어!!’
특히, 처음으로 그래픽스 프로그램을 만들었을 때 가장 큰 재미를 느꼈다.
나는 소스 코드를 작성했을 뿐인데 이렇게 시각적인 결과물이 나온다는 게 얼마나 기뻤는지ー
무려 순100% 손코딩이다.
이 첫 그래픽스 프로그램은 당시에 주변 교육생들에게 인터페이스 UI로 칭찬도 많이 받았었다. 높이에 따른 Vertex별 색상값 부여라든지 반투명 렌더를 위한 색상 합성이라든지 원 과제에서는 요구되지 않던 Axis라든지 Camera 혹은 Object Transform 전환 모드라든지. 지금은 딸깍 한 번으로 되겠지만 그때는 아니었다고…
…. 바로 이 지점이다. 더 이상 한 땀 한 땀 개발을 하는게 일반적이지 않고(누군가 일컫길 ‘손코딩은 일종의 비싼 취미 혹은 바보짓’), 그 때문에 ‘우와!‘라는 감탄사가 나오기 위한 퀄리티의 커트라인이 한없이 올라갔단 말이다.
게다가 난 주변 개발자 지인들이 혀를 내두를 정도로 소스 코드를 한 줄 한 줄 고심해서 짜는 편이었기 때문에(디렉토리, 파일, 구조체, 함수의 역할과 책임 분리와 같은 전체 설계는 물론 함수명, 변수명 하나하나조차) 프로그램 하나가 완성될 때면 늘 작품 하나를 완성시킨 듯이 뿌듯해했었다…
그래서… 솔직히 AI Agent가 등장해서 개발판을 이리저리 휘젓는 동안 내가 만드는 결과물의 가치가 낮아진 것 같아 너무 우울했고, 인정하고 싶지 않았다. Agent뿐만 아니라 채팅 서비스만 해도, 사기업에 내 피 같은 돈을 헌납하고 종속되는 느낌이라 기분이 심히 좋지 않았다. AI를 이용해 무언가를 만든다고 한들, 그건 ‘내가 만든 것이 아닌 것만 같은’ 이질감 때문에도 싫었다.
요약하자면 그렇다.
오직 나만이 창조하고 통제해야할 터인 창작에
사기업이 껴들어서 확률 놀이를 하는 게 싫어!
한 땀 한 땀 정성스레 만드는 창작물의 가치가 낮아지는 것도 싫어!!!
그림 그리기가 재밌는 이유는 ‘예쁜 그림을 생성해내서’가 아니라 ‘내가 이 예쁜 그림을 나의 의도가 담긴 터치들로 직접 그려내서’이다.
글쓰기가 재밌는 이유는 ‘글을 생성해내서’가 아니라 ‘내가 나의 생각을 직접 기술하며 성찰하고 기록하는데 보람을 느껴서’이다.
나에겐 개발도 마찬가지였다………
그래서 꽤 오랫동안 AI를 이용한 개발을 인정하지 않았던 것 같다.
결과물의 부정확함은 차치하고, AI를 이용한 개발은 ‘재미도, 보람도, 감동도 없으니까’.
시대에 뒤떨어진 내게 깨달음을 준 글
최근 내게 깨달음을 준 글이다.
그간 어렴풋이 느끼고 있던 것이 명료한 언어로 기술되어 있어, 나의 불안과 고통과 우울의 원인을 파악할 수 있었다.
나는 ‘기술의 발전에 따른 추상화 수준의 상승을 받아들이지 못한 옛 시대의 개발자’였던 것.
해당 글에서 가져온, 가장 핵심이 되는 이미지이다.
나는 운 좋게도 바로 가까이에 ‘어셈블리어’로 프로그래밍을 하는 친구가 있고 그간 그 친구한테서 이것저것 들어왔기에 이 글을 읽고 나름의 통찰을 빠르게 얻어낼 수 있었다.
가령, 이 친구가 가끔 우스갯소리로 아니 사실 진지하게 이런 말을 했었는데…
“컴파일러가 생성하는 코드는 너무 느리고 비효율적이야.
컴파일러는 바보다”
내 친구지만 요즘 시대에 참 흔치 않은 젊은이이다…
그런가 하면, 똑같은 작업을 얼마나 지루하게 반복해야하는지(레지스터에 의미 부여하기, 배치 바꿔주기 등…) 그리고 이렇게 힘들게 코드를 작성하지만 결국 하드웨어 종속적이기 때문에 재사용할 수 없다는 점도 언급하곤 했다.
그렇지만 그런 지겹고 험난한 과정을 통해 ‘도구의 기계적인 변환 결과’를 뛰어넘을 수 있는 것이다.
프로그래머들의 모든 업무라고 해도 과언이 아닌ー문제 풀이의 로직(Logic)부터 기계어까지의 변환 과정에서, 남들은 다 도구에게 대리 맡기는 한 단계를 이 친구는 자신의 머리를 통해 돌파구를 찾아내기 때문에 남들은 하지 못하는 극한의 최적화를 해내는 것이다.
작금의 세태에 대해 어렴풋이 무언가의 통찰을 끌어낼 수 있지 않을까 짐작할 수 있었던 것도, 사실 이 친구의 어렵고, 험난하고, 어찌보면 무모하다고까지 할 수 있는 개발 과정을 옆에서 지켜봐왔기에 가능했던 듯하다.
현실을 인지하고 인정했다. 그 다음은?
위 글에서는 ‘사람이 손을 떼지 말아야 할 것’으로 설계, 아키텍처, 코드의 형태(shape of the code), 컴포넌트와 함수의 배치와 분할을 언급한다. 설계와 아키텍처는 뭐 굳이 언급하지 않아도 모두가 알고있는 사실이겠고,코드의 형태(shape of the code) 에 대한 예시를 들어주신 것이 인상 깊었다.
요점은 ‘소스 코드 Level에서 추상화를 분명히 하고, 윤곽을 발췌해서 Top-down 형태로 보기’.
AI를 코딩에 활용할 때 극단적인 두 가지 길이 있다:
- AI가 작성한 코드를 AI가 작성한 테스트로 돌리고, 괜찮다고 믿는다. -> 이래도 되나?? 불안함…
- AI가 작성한 코드를 하나하나 이해하고 살펴본다. -> 시간 너무 오래 걸림!
글쓴이는 제3의 길을 제시한다.
Source Code의 전체적인 윤곽을 보는 것에 집중한다.
정확히 무슨 말인지 궁금하다면, 글의 ‘손을 떼는 것은 문법뿐이다’ 단락에 좋은 예시가 있으니 한번 보는 것을 추천한다. (결국은, 또 추상화이다.)
바뀐 인간의 역할
앞선 ‘프로그래밍에서 추상화 수준이 변화해온 과정’을 통해, 나는 우리의 임무를 이렇게 이해하였다:
‘인간의 역할이 고급 언어(Source Code)와 자연어 명세(Specification) 사이의 조율을 맡는 것으로 이행됨’
명확하게 기술하면
- 프로젝트의 목적을 수립하고, Requirements와 Constraint를 분석 및 판단
- 1의 결과를 바탕으로, 자연어 명세(Specification)를 수립 및 판단
- 2의 결과를 바탕으로, 코드의 윤곽을 중심으로하여 Source Code 해석 · 평가 및 판단
이 모든 과정에서 ‘어떤 것이 더 좋을까?’, ‘왜 하필 이 방법이어야 하는가?‘라는 인간의 판단이 필요하며, 이렇듯 소프트웨어의 품질은 여전히 인간의 지혜가 좌우한다.
때문에 Layer가 하나 더 얹어졌다한들, ‘개발하는 인간이 소프트웨어의 품질을 좌우함’이라는 본질은 변하지 않는다. 오히려 요구되는 능력은 그쪽으로 더 치우쳐졌다.
AI가 고급 언어 코드 더미를 무시무시한 정확도와 속도로 생성해내는 능력, 그것을 자연스럽게 도구로 삼아(과거 우리가 컴파일러를 당연하게 사용해온 것처럼 말이다) 문제 해결을 할 수 있는 사람이 결국 AI 시대의 인재이기 때문이다.
게다가 AI가 생성해내는 코드는 자연어 명세(specification)의 수준과 프로그래밍 언어 수준 차원에서 다룰 수 있는 논리 수준과의 Gap을 해결하지도 못한다. 의사 코드(Pseudo-code) 수준으로 명확하게 전달한다면 또 모를까. 아 이건 더 이상 자연어가 아니구나
그렇기 때문에 결국은 고급 언어 소스 코드를 까봐야한다. 그렇다.
두 단계의 완충 지대의 역할을 제대로 수행해내기 위해선, 소프트웨어 개발에서의 상대적 저수준 레벨ー고급 언어의 소스 코드를 들여다보고 판단할 수 있는 능력이 있어야한다.
결론
… 이렇게 시대에 따른 인간 역할 이행의 흐름을 인정하고 나니 AI Agent 사용에 대한 거부감도 조금은 덜해졌다. 컴파일러가 처음 나오던 시기 어셈블리어를 이용해 코드를 작성하던 사람들도 비슷한 느낌을 받았을까? (뭐, 그랬다한들 AI 등장보다는 훨 덜하겠지만)
아무튼 시대의 발전에 따른 추상화 수준의 상승은 업계에 발 들여서 밥 벌어먹고 살려면 ‘어쩔 수 없이’ 받아들여야 하는데 다행히도 고급 언어로 작성된 Source Code를 읽고 해석하고 평가할 수 있는 능력은 여전히 필요하며, 가치 있더라.
솔직히 사기업들이 고성능 AI를 독점하고 일반인들은 그것을 구독하여 매달 피같은 돈을 헌납해야하는 것이나(나는 이것을 늘 ‘원숭이 꽃신 우화’에 비유하곤 한다), ‘무지성 AI 사용’으로 사람들이 점점 생각을 안 하게 되는 현상 등 지적하고 싶은 것은 수도 없이 많지만…
결국 난 이 거대한 흐름 속의 한낱 힘없는 개인(업계 경력 0, 학사졸조차 못함)에 불과하기 때문에 받아들일 부분은 받아들이고 경계할 부분은 뇌에 힘주고 경계하고 살련다.
PS. 개인적인 견해
개인적으론, 어셈블리 코드와 고급 언어 코드 사이의 간극에 비해 고급 언어와 자연어 사이의 간극이 너무도 크기에 상대적으로 더 많은 부작용을 낳고 있다고 생각한다. (자연어가 고급 언어로 변환되는 것에 비하면 고급 언어에서 어셈블리 코드로의 변환은 거의 절차적 생성에 가깝다…)
언젠가 이런 간극을 해결하기 위한 모종의 완충 지대 레벨이 솔루션으로 등장하여 수많은 개발자(사실 비개발자가 더 많을듯)들을 ‘최대한 자연어만 이용해서 개발할 수 있게’ 도와주지 않을까싶다. (몇 년 뒤의 미래일까?)