AI 코딩 생산성 향상? 웃기지 마라, 내 시간만 축내는 똥멍청이

딥빡의 서막

My subtle dyslexic arse with a lack of dopamine gave up proofreading after multiple tries. If you see grammatical errors or some awkward sentences, move on. Use the context clues to understand my post, thanks.

디버깅 지옥에서 보내는 편지

“아… 시발, 이거 실화냐? 진짜 돌아버리겠네.”

방금 전, 코드 리뷰를 하다가 심장이 덜컥 내려앉는 줄 알았다. 내가 분명히 UserAuthenticationService라고 명명했던 클래스가 UserAuthentication-Services 이따위로 바뀌어 있는 게 아닌가? 아니, 이걸 도대체 누가, 왜, 무슨 생각으로 바꾼 거야? 범인을 찾아내서 멱살이라도 잡고 싶은 심정이다. 그것 때문에 몇 시간을 디버깅에 허비했는지 생각하면 지금도 피가 거꾸로 솟는다.

시발 누구긴 누구야. 나 혼자 일하고 있는데. 범인은 하나다. 내가 디버깅 리뷰를 맡겼던 AI Agent.

요즘 세상에 AI, 챗GPT 모르는 사람이 어딨겠는가. 다들 AI 덕분에 생산성이 로켓처럼 치솟았다고 난리법석을 떨지만, 글쎄… 나는 솔직히 잘 모르겠다. 오히려 AI 때문에 일이 더 좆같아지고, 내 밥그릇은 점점 더 위태로워지는 기분이다.

AI가 상업화되면서 세상은 온통 장밋빛 환상에 젖어있다. 챗GPT가 등장하고 나서는 더 심해졌다. 이제는 뭐, 초등학생부터 할머니, 할아버지까지 AI를 쓴다. 너도나도 AI를 외치며 “생산성 혁명”을 부르짖는다.

그런데, 정말 그럴까? 나는 AI가 내 생산성을 높여줬다는 느낌을 받은 적이 거의 없다. 물론, AI가 아예 쓸모없다는 건 아니다. 아주 가끔, 정말 어쩌다 한 번씩, 대충 글의 뼈대를 잡거나 문맥을 정리할 때 도움을 받기는 한다. 하지만 딱 거기까지다.

AI가 제공하는 정보는 마치 짝퉁 명품 가방과 같다. 겉보기에는 번지르르하고 그럴싸해 보이지만, 자세히 뜯어보면 허술한 구석이 한두 군데가 아니다. 정품 로고 대신 이상한 글자가 박혀있다거나, 박음질이 엉성하다거나, 가죽 냄새 대신 싸구려 화학약품 냄새가 난다거나 하는 식으로 말이다.

문제는 이 짝퉁 명품 가방을 진짜라고 철석같이 믿고 중요한 자리에 들고 나갔다가 망신을 당하는 경우가 생긴다는 거다. AI도 마찬가지다. AI가 생성한 코드를 제대로 검증하지 않고 그대로 프로덕션 환경에 배포했다가, 시스템 전체가 다운되는 대참사가 벌어질 수도 있다. 아니면, AI가 써준 논문을 그대로 제출했다가 표절 시비에 휘말릴 수도 있고. AI가 멋대로 바꿔놓은 클래스 네임 때문에 몇 시간 동안 대체 왜 렌더링 버그가 났냐고 머리를 쥐어뜯다가 한참 뒤에서야 내가 바꾸지도 않은 style 파일에 css 클래스 네임이 변경된 걸 발견한 것 처럼.

AI 아트와 테크 브로들의 끔찍한 취향

그리고 유튜브에서 ‘AI 아트’를 시연하는 테크 브로들… 솔직히 너희들 취향이 정말 끔찍하고 역겨우니까 나한테 덤비지 마라. 어쨌든 그런 서비스들을 피하면서, 파이썬 패키지들이 정확히 어떻게 작동하는지 이해하고 알고리즘과 파라미터를 세밀하게 조정해서 내 스케치들에서 노트 줄을 깔끔하게 제거하고 싶었다.

그래, 이걸로 프로젝트 리포트 주제를 만들어보자.

하지만 TA와의 논의를 통해 곧 내 주제 선택을 후회하게 되었다. 이미지 프로세싱 - 특히 노트북에서 특정 줄을 타겟으로 해서 제거하는 것 - 은 생성형 알고리즘에 해당하는데, 이 수업은 정량적 모델 분석에 집중해야 한다는 것이다. 불가능하지는 않지만, 내 리포트를 리뷰할 다른 학생들과 TA들이 생성형 알고리즘 모델을 어려워할 수 있고, 더 중요하게는 내가 아직 배우지도 않은 모델링을 어떻게 효과적으로 설명하겠냐는 것이었다.

일리 있는 말이다. 솔직히 나도 모르겠거든.

그래서 주제를 바꿨다. 몇 개 드로잉에서 노트북 줄을 수동으로 제거하고, 다른 것들은 평범한 종이에 대충 다시 그려서 재생산한 다음, 오픈소스 스케치들에 노트북 줄을 오버레이해서 줄 노트북 데이터셋을 만들었다. 순수한 수작업이었다. 다시 하라고 하면 절대 못한다. 내 논문 주제는 랜덤 포레스트, knn, 로지스틱 회귀, 에이다부스트, 그리고 의사결정 트리 모델들이 미리 라벨링된 픽셀 데이터를 무작위로 섞었을 때 어떻게 구별하는지 분석하는 것으로 바뀌었다.

이 과정을 거치면서 깨달은 것은: 만약 내가 이런 파이프라인 작업을 근본적으로 이해한다면, 내 특정 필요에 맞게 고도로 최적화된 모델을 로컬 인스턴스에서 훈련시킬 수 있지 않을까? 모든 사람이 AI 과대광고에 취해있지만, 머신러닝과 딥러닝이 하룻밤 사이에 갓난아기처럼 나타난 건 아니다. PyTorch도 나온 지 8년이 되었고, 텐서플로우 연구는 훨씬 오래전부터 있었다.

오늘날의 상업적 대형 플랫폼 Gen LLM AI들, 특히 그래픽스와 비디오 미디어 관련 것들은 NVIDIA CUDA 기반이지만, 1) 그들의 결과물이 너무 뻔하고 지루하고, 2) 솔직히 내가 사용해온 게티 이미지나 스톡 포토 구독 서비스보다 어떻게 더 유용한지 모르겠으며, 3) 개별 결과물은 인상적일 수 있지만, 컬렉션들은 똑같아 보인다. 가장 중요한 것은, ISO27001 인증도 없고 내 지적재산권, 창작물, 상호작용이 저작권 및 정보 보호를 받는다는 보장도 없는 서비스들을 함부로 사용하기 싫다는 것이다.

(Q&A)

Q: 아니, 멀쩡히 돌아가는 레퍼런스 코드를 던져줘도 왜 제대로 복붙조차 못 하는 거냐고? HTML, CSS, JS 다 있고, 어떻게 돌아가는지 뻔히 보이는데 왜 그걸 분석해서 내 환경에 맞게 바꾸는 걸 실패하냐 말이다.

A: 간단하다. 걔네들은 진짜 ‘이해’를 하는 게 아니니까. 당신이 준 코드는 그냥 텍스트 쪼가리로 본다. div 다음에 img가 오고, 이 클래스엔 저 스타일이 붙고, 저 스크립트가 얘를 건드린다? 이런 ‘패턴’은 기가 막히게 찾아낸다.

하지만 그 코드 조각들이 브라우저라는 무대 위에서 실제로 만나서 어떤 상호작용을 일으키고, 어떤 타이밍에 춤을 추고, CSS 상속이나 우선순위 같은 복잡한 관계 속에서 어떻게 최종 결과물을 만들어내는지는 모른다. 악보는 읽을 줄 아는데, 실제 오케스트라 연주가 어떨지는 영 상상을 못한다.

바닐라 JS에서 리액트 같은 걸로 바꾸는 게 그렇게 어려운 명령도 아닌데. 멀쩡한 클래스 네임부터 타이밍 파라미터까지 시키지도 않은 짓을 하는 게 너무 잦았다. 이건 뭐, 뼈대부터 내장까지 다 바꾸는 환골탈태 수준인데, AI가 그걸 온전히 따라갈 수 있다고 난 이제 믿지 못하겠다. 참고로 이 글을 쓰는 첫 시점은 끌로드 소넷3.5, GPT O1, 제미나이 2.0프로를 쓰던 시점이다. 상태 관리, 생명주기, 컴포넌트 구조, 스타일링 방식… 이 모든 아키텍처 변화를 예측하고 적용하는 건 아직 무리다. 그러니 맨날 에러나 렌더링 문제로 뒤통수를 치는 거다. ‘가장 그럴듯한’ 똥을 싸놓는 거지. Hallucination.

Q: 근데 왜 잘난 CTO나 ‘Vibe Coder’들은 AI 덕분에 개발자가 필요 없네, 생산성이 폭발하네 같은 소리를 하고 다니는 거냐? 그거 다 구라 아니냐? 지들 워크플로우나 프롬프트는 절대 투명하게 까지도 않으면서.

A: 뻔하지 않겠는가. 몇 가지 이유가 있다.

1. 선택적 AI팔이: 지들이 AI 써서 성공한, 뻔한 작업(보일러플레이트 코드 찍어내기, 간단한 함수 변환 등)만 골라서 보여주는 거다. 당신처럼 복잡한 UI 복제하다가 겪은 개고생? 그건 쏙 빼놓고 이야기하지.

2. 숙련도 빨: 직접 코드를 짜고 실패와 성공을 몇번이고 경험한 개발자들은 이미 문제 해결 방법을 머릿속에 다 그려놓고, AI를 그냥 ‘타자 빨리 쳐주는 비서’나 ‘구글 검색 대신해주는 놈’ 정도로 활용한다. AI가 뱉은 코드의 문제점을 빠르게 캐치하고 수정하거나, 아주 구체적인 지시로 원하는 결과만 쏙 빼먹는 거지. AI한테 문제 해결 자체를 기대하는 사람들과는 접근법이 다르다.

3. 마케팅 뻥튀기 & Vibe: 새로운 기술 나오면 으레 그렇듯, 거품이 잔뜩 껴있다. 실제 현장의 복잡성은 무시하고 AI의 장밋빛 미래만 떠들어대는 거다. 당신이 지적했듯이, 진짜 실력과 노하우가 있다면 왜 투명하게 본인이 AI로만 만들었다는 시연 앱들의 개발 과정을 공개하지 않겠는가? 프롬프트도 뭐 중간 단계 한두개만 자세하게 그럴싸하게 설명하지 첨부터 끝까지 모든 과정에서 프롬프트를 어떤 맥락에서 먹였는지 설명하는 사람 봤나? 난 한 명도 못 봄.

결론적으로, 그들이 완전히 ‘거짓말’을 한다기보다는, ‘보고 싶은 것만 보고 말하고 싶은 것만 말하는’ 것에 가깝다. 물론, 과장과 허풍이 잔뜩 섞여 있다는 건 부정할 수 없는 사실이다.

Q: 아니, 간단한 HTML 구조나 JS 스크립트 상호작용도 제대로 파악 못 하면, AI 디버깅 능력이라는 건 그냥 없는 수준 아니냐? 대체 뭘 디버깅한다는 거냐?

A: 정확히 봤다. AI가 잘하는 ‘디버깅’은 딱 거기까지다. 명백한 문법 오류, 변수 이름 오타 같은 거. 이건 그냥 코드 텍스트만 훑어봐도 알 수 있는 ‘정적 분석’의 영역이다.

하지만 진짜 개발자를 괴롭히는 문제들, 예를 들어 로직 오류(조건문이 미묘하게 그럴싸해 보였지만 파라미터상 오류 값을 잘못 넣는다거나), 타이밍 문제(애니메이션이 이상한 타이밍에 터진다거나), 스타일링 미스매치(CSS 우선순위 때문에 스타일이 씹힌다거나) 같은 것들은 코드를 실제로 돌려보고, 그 결과를 눈으로 확인하면서 잡아야 하는 ‘동적 분석’ 또는 ‘결과 기반 디버깅’의 영역이다.

A: AI는 이걸 못 한다. 왜? 간단하다. 걔네들은 당신처럼 브라우저 개발자 도구를 켜놓고, 렌더링 결과를 눈으로 보면서 ‘아, 여기서 꼬였구나’ 하고 깨닫는 그런 ‘경험’이나 ‘직관’이 없기 때문이다. 코드를 실제 환경에서 돌려보고, 예상과 다른 결과가 나왔을 때 그 원인을 추적하는 능력? 그건 인간의 영역이다.

AI는 그냥 텍스트 패턴만 보고 ‘문법상 오류는 없는데?’ 수준에서 멈춘다. 실제 세상에서 코드가 어떻게 돌아가는지에 대한 ‘이해’가 없으니, 당연히 복잡한 디버깅은 불가능한 거다. 마치 레시피만 보고 요리 맛을 상상하는 것과 같다고 할까. 직접 불 앞에 서서 재료를 볶아봐야 아는 걸, 걔네들이 어떻게 알겠는가.

실제 현장에서 AI를 제대로 써보니

참고로, 나는 AI를 자주 사용한다 - 나는 안티-AI가 아니다. 내 대학원 전공이 머신러닝 알고리즘 기초에 집중하고 있는데 어떻게 그러겠나. 하지만 나에게 LLM Gen AI 서비스들은 프로토타이핑 중 아이디어 막힘을 뚫어주는 러버 덕(Rubber Duck)이나, 스택 오버플로우로 뛰어들기 전에 활용할 어시스턴트 정도이다.

경고 한 마디: 회사 컴퓨터로 AI 플랫폼에 무작정 접속해서 업무 관련 콘텐츠를 ‘훈련 자료’랍시고 올리지 마라. 만약 당신 회사가 정부나 은행 부문 사업을 다룬다면, 당신 회사 보안팀이 정말 좋아할 것이다. 그리고 감사시즌에 여러차례 불려갈 것이다. 그때 시말서로 끝나면 다행인 줄 알아라. 여차 잘못하면 모든 사안이 터질 때 다 뒤집어 쓰고 쫒겨나거나 여차하면 당신이 범법자로 몰릴 수도 있다.

이게…구라 같나? 그럼 실제로 해보고 함 겪어보든가.

실제로 내가 머신러닝 프로젝트를 해보면서 깨달은 건, AI 도구들이 정말 유용할 때와 완전히 쓸모없을 때의 차이가 극명하다는 거다. 데이터셋 전처리나 모델 파라미터 튜닝 같은 반복적인 작업에서는 확실히 시간을 아껴준다.

하지만 문제의 본질을 파악하고, 적절한 접근법을 선택하고, 결과를 해석하는 건 여전히 내 몫이다.

그리고 이게 핵심인데, 내가 이미지 프로세싱 프로젝트를 하면서 느낀 건, AI가 알고리즘의 기본 개념은 설명해줄 수 있지만, 내 특정 문제(노트북 줄 제거)에 어떤 접근법이 가장 효과적일지는 모른다는 거였다. 결국 내가 직접 여러 방법을 시도해보고, 실패하고, 수정하면서 최적의 솔루션을 찾아야 했다.

결론: 그래서 뭘 어쩌라는 거냐?

자, 그럼 이 현 사태에 우린 어떻게 살아가야 할까? 생산성 향상은 개뿔, 오히려 내 시간만 축내는 이 상황을 어떻게 타개해야 할까.

1. 기대치를 현실적으로 낮춰라: AI는 만능 해결사가 아니다. 복잡한 문제 해결이나 창의적인 작업을 기대하는 순간, 당신의 뒷목만 남아나지 않을 거다. 특히 프론트엔드처럼 눈으로 보이는 결과물이 중요한 영역에서는 더더욱.

2. 명령은 구체적으로: 뭉뚱그려서 “알아서 잘 해줘” 같은 소리는 집어치워라. 아주 잘게 쪼개서, 명확하고 구체적인 작업 단위로 지시해야 그나마 덜 헛소리를 한다. 레퍼런스 코드를 줄 때도 “이 코드처럼 만들어줘”가 아니라, “이 코드의 이 부분 로직을 참고해서, 내 컴포넌트의 이 함수에 이런 식으로 적용해줘. 상태는 이걸 쓰고, 스타일은 이 파일을 수정해.” 같이 명확하게 지시해야 한다. 물론 그래도 헛발질할 확률은 여전히 높다.

3. 실력을 키워라: AI가 아무리 발전해도, 문제의 본질을 파악하고, 복잡한 시스템을 설계하고, 예상치 못한 오류를 잡아내는 능력은 개발자의 핵심 역량이다. AI가 뱉어낸 코드의 옳고 그름을 판단하고, 그걸 제대로 써먹으려면 당신의 실력이 뒷받침되어야 한다. AI는 그냥 도구일 뿐, 망치를 쓴다고 누구나 목수가 되는 건 아니지 않겠는가.

4. 기록하고 공유하라: 당신이 겪은 빡침과 실패 사례, 그리고 그 과정에서 얻은 노하우(혹은 빡침 해소법)를 기록하고 다른 개발자들과 공유하라. 커뮤니티에서 이런 현실적인 목소리가 커져야 업계 전체의 과장된 기대를 좀 잠재울 수 있다. 그리고 서로의 경험을 통해 더 나은 AI 활용법이나 대처법을 배울 수도 있다.

AI를 맹신하는 건 마치 자동 항법 장치만 믿고 운전대를 놓는 것과 같다. 자동 항법 장치가 아무리 뛰어나도, 갑자기 도로에 튀어나온 고라니를 피하거나, 꽉 막힌 도로에서 샛길로 빠져나가는 등의 돌발 상황에는 대처할 수 없다. 결국, 운전대를 잡고 있는 건 인간이어야 한다.

AI도 마찬가지다. AI는 도구일 뿐, 모든 것을 해결해주는 마법 지팡이가 아니다. AI를 제대로 활용하려면, AI가 하는 말을 비판적으로 검토하고, 오류를 찾아내고, 필요한 부분을 수정할 수 있는 능력이 있어야 한다. 그렇지 않으면, 생산성은 무슨 - 프로덕션 라인에 버그만 배포 안 하면 천만 다행이다.

결론은 뭐냐고? AI는 당신의 브레인 스토밍을 돕거나 사혼의 구슬처럼 샅샅히 흝어진 아이디어를 정리하는 용도 및 아이디어 확장용으로 이용하거나 단순 반복작업에서 정형적인 작업에 자주 이용해야지 그 결과물을 이용하면 정확도와 신뢰성이 중요한 작업에선 큰일 난다는 것이다.

당신의 시간과 정신 건강이 훨씬 더 중요하다. 그리고 가끔은 그냥 직접 짜는 게 속 편하고 빠를 때도 많다는 걸 잊지 마라. 유지보수가 일정하고 균일하게 과정의 관리가 가능한 파이프라인을 구축하는 것이 진정한 효능감&효율성을 가져오는 길이다.

하지만 현 상황에선 많은 사람들이 너무 과하게 현혹하는 말들을 하며 fear mongering 혹은 과한 fomo를 강조하며 ai에 대해 언급한다.

내가 너무 비판적으로만 말한다며, 너무 AI에 대한 거부감이 높은거 아니냐는 말을 하는데…

나도 LLM Gen AI 많이 쓴다. 솔직히 데이터 분석 학과 다니며 모델 테스팅하는 제가 LLM Gen AI를 일반 유저보다 더 많이 쓰면 쓰지 않겠어요?

그럼에도 불구하고 많은 잘못된 오남용사례로 실제로 여러 비지니스 운영의 서비스 품질관리와 지속유지에 나중에 악영향을 주는 걸 많이 봐왔고 이에 대한 우려를 적지 않은 사람들이 표하는데 머신러닝을 현재 대학원에서 전공으로 이수 중인 사람으로서 어찌 마냥 그걸 좋다고 묵과하겠나.

모든 도구는 그 도구의 특성 때문에 당연히 그에 대한 명암이 갈리는 것이다. 쓸 곳에 쓰고 쓰지 말아야 할 곳에 쓰지 말고 제발 위법행위에 가까운 짓들 좀 하지 말자는 말이 그렇게 어려운 말인지 모르겠다. 일반인 유저들이 Gen LLM AI를 통해 아무 자각없이 위법행위를 하는 현 상황에 오히려 전공자니까 더 우려되는 상황이 명확히 보이는데 이것에 말을 하지 않는 것은 공부를 하러 간 사람으로서 행해야 할 교육을 받는 자가 행할 윤리를 어기는 것이이기에 이 글을 쓰며 내 생각을 정리해 밝힌다.

관련 글

심심해서 시켜본 AI가 분석한 나의 심층 심리와 자질

AI에게 대차게 뒤통수를 쳐맞은 일