AI로 일한다는 것은.

https://news.hada.io/topic?id=21799

코드 작성은 절대 병목 지점이 아니었음 | GeekNews

일을 하는 건 병목이 아니다. 개발 작업도 보고서도 어렵지 않다. 어려운 건 사람간의 소통이다...

회사 일의 대부분은 대개 고객과의 소통, 상사와의 소통, 동료나 팀원들과의 소통이다. 일이 어려운 게 아니라 소통에서 보통 문제가 생긴다. 작업은 좀 못해도 되지만 커뮤니케이션에서 미스가 발생하면 일이 커진다.

문제 정의가 잘못되면 당연히 어떤 해결책도 듣지 않는 법이다.

실제로 AI코딩을 해보면서 느끼는 것이다. 좋아, 코딩은 빨라졌어. 근데 일은? 아이러니한 건 AI코딩이 매우 효과적이란 점이다. 그럼에도 확실히 일의 본질은 아니다. 그렇기 때문에 더욱 느낀다. AI의 문제는, 사람의 문제라는 것을.


코딩으로 돌아가보자.

원글이 지적하는 건 AI코딩를 피상적으로 접하는 이들이 마주하고 야기하는 가장 기초적인 문제다. 그리고 그건 비단 코딩만이 아니다. 한편으로 저런 일이 벌어지는 건 AI 이전에 일에 대한 이해의 부족과, 그로 인해 도구를 잘못 이해하는 데에서 나온다.

저 사람이 그랬다는 게 아니고. 오히려 저 글에선 일에 대한 본질을 잘 잡고 있어서 가져온거다.

개발을 하면서 중요한 건 코드를 짜는 게 아니라 그 개발의 목표가 무엇이고, 갖춰야 할 요건들이 뭐고, 그걸 위해 프로젝트를, 코드를 어떻게 관리해야 하고, 또 검증해야 하느냐다. 이는 대단히 복잡하고 고도의 작업이라 AI에게 통으로 떠넘길 수가 없다. 그리고 AI도입 사업이 실패하는 가장 기본적인 이유는, 이러한 일의 본질을 무시하고 AI가 다 해주기를 기대하기 때문이다.

AI는 컨텍스트를 넣어줘야 동작한다. 그마저도 100퍼센트 동작을 보장 못한다.

단도직입적으로 말하면, 저 상황에서 개발자가 해야할 일은 AI를 통한 코드 리뷰, 테스트케이스 작성이다. 그걸로 정말 중요하고 시간 많이 잡아먹는 코드의 이해와 검증절차를 크게 단축시킬 수 있다. 근데,

이렇게 말하면 '프로젝트 코드 통으로 넣고 평가해달라고 하면 되나'라고 생각할 것이다. 이게 언어의 어려운 점...

핵심은 코드를 만들고 검증하는 구조를 사람이 설계하고, 그것이 맞는지를 끊임없이 검증하는 것이다. 간단히 말하면 개발자로서의 자신을 버리고 경영자가 되는 것이다.

여기서 또 중요해 지는 게 소통이다. 이제 하다못해 AI하고까지 소통을 해야한다. 위 말대로, 그냥 통으로 넣고 돌리면 내 의도와 다른 코드, 다른 검증내용이 100% 들어간다. 그걸 끊임없이 감시하고 검증해야 하는 게 AI 작업이다.

그러면 뭐하러 AI를 쓰냐고?

옛날에 밀을 처음 수확했을 때는 밀가루를 어떻게 만들었을까? 절구에 빻았을 것이다. 그러던 사람에게, 누군가가 풍차로 자동으로 돌아가는 제분기를 만들면 된다고 했을 때 이렇게 생각하지 않았을까? '뭐하러 그 큰 것을 고생해서 만들어? 이게 더 간편한데?'

자동화라는 게 그런거다. 한 번 만들어두면 지속적이고 장기적으로, 대량으로 효능을 낼 수 있지만 그 한 번 만드는 건 대단히 힘들다. 그 원리는 현대사회 그 자체의 기본 룰이다.

AI로 관리되는 일의 파이프라인을 만드는 것은 이럴거면 뭐하러 AI를 써? 하게 만드는 어려운 일이다. 하지만 하면 할수록 점점 편해진다. 그리고 이건.

사장님들은 모두 하는 일이다. 사람 일 시키는 건 힘든 일이다. 일 잘하는 우리 회사 후임들도 쉽지 않은데 다른 곳들은 오죽할까. 10을 시키면 20을 해와도 일시키는 건 원래가 쉽지 않다. 하지만 한 번 프로세스를 잡아두면 그건 내가 세세하게 관리 안해도 오토로 돌아간다.

LLM도 마찬가지다. 히스토리가 쌓이면 내가 하는 업무에 대한 이해도도 높아지고, 나 역시 LLM에게 어떻게 지시해야 효율적으로 할 수 있을지 알 수 있다. 그리고 방법론이 갖춰지면 이리저리 묻고 검토하느라 시간 낭비할 일도 줄어든다.


내가 코드를 짤 때는 주로 작은 단위의 코드는 일단 LLM이 짜도록 시킨다. 작은 단위는 일반적으로 범용 기능이라 세세하게 설명 안해도 잘하기 때문이다. 하지만 미묘하게 내 요구사항에 맞지 읺을 때도 있고, 간결한 코드를 선호하는 나로서는 스타일이 안 맞을 때도 있다. 그럼 몇 차례 최적화를 하며 기능적으로 올바른지 검토를 시킨다. 그게 다 되면 테스트 케이스를 만들도록 시키고 docstring 도 만들 수 있다. 이렇게 확실하게 해 나가면 단위 코드의 오류를 걱정할 일은 크게 줄어들게 된다.

큰 범주에서의 전체 로직에 대해서는 가급적 내가 짠다. 보통 내가 하고자 하는 일에 특화된 코드라 LLM이 잘 못 짜기도 하고, 짜더라도 한 바닥에 코드를 다 몰아넣으니 검토도 어렵다. 메인 함수는 프로세스 단계를 순차적으로만 보여줘야 하며 세세한 로직은 다 하위로 들어가야한다. 그러지 않으면 내가 내 코드를 관리 못한다.

그리고 놀랍게도, 그렇게 틀을 잡아주고 던지면 LLM이 알아보고는 어느정도 거기에 맞춰서 코드를 짜 준다. 그러면 LLM이 짜주는 로직도 이해하기 쉽고 검토도 빠르다.

때때로 일이 막힐 때는 LLM에게 제안하게 한다. 코드를 짜도 되고 방법론을 정리해도 된다. 단번에는 당연히 안 된다. 몇 번씩 대화가 오가야한다.

사람들이 크게 착각하는 게 있다. 이제 바이브 코딩이 있으니까 프로그래밍 언어를 몰라도 프로그램을 개발할 수 있다고 생각한다. 아직 멀었다. AI의 코드는 사람이 검수해야 하고, 빠르게 검수하려면 프로그래밍 언어에 대단히 능숙해야 한다. 단번에 보고 가능한 리스크들을 채크하고, AI가 리뷰해준 사안도 어느 것이 필요한지, 어느 것이 불필요한지 단시간에 판단해야 한다. 그러려면 오히려 코딩을 더 잘해야 한다. 코드를 몰라도 프로그램을 만들 수만 있는 거지 고품질의 프로그램을 만들 수 있는 건 아니다.

장기적으로 봐도, AI가 만든 로직의 허점을 빠르게 눈치채고 자기 목적에 맞춰 교정하도록 지시할 수 있는 논리력, 사고력, 판단력이 필요하다. 조직의 리더는 실무에서는 당연히 실무자를 따라갈 수 없지만, 의사결정 능력만큼은 실무자를 압도해야 하는 것과 같다.

AI의 반란은 AI가 사람에게 악의를 가지고 해를 끼치며 일어나는 게 아니다. AI에 버그가 있는 데 사람이 못 잡아서 일어난다. 예를 들어, 인류의 모든 자동차가 자율주행차로 대체 되었다고 치자. 그런데 그 코드에 하나 결함이 있어, 특정 시점이 되면 엑셀이 제어가 안되는 버그가 있었다고 하자. 심지어 그 코드는 오픈소스의 밑바닥이 있어, 모든 AI 개발자들이 사용했지만 몇 단계를 거쳐 사용해 그게 있는지도 몰랐다고 하자. 그럼 AI의 반란 시작이다. 한 순간에 전세계에서 수백만 명이 죽을 거다. 일말의 악의도 없이.

그래서 저 사람이 코드 리뷰를 사람이 해야하고 보틀넥이라고 하는 것이다. 그런데 문제는, 현대 사회는 나날히 복잡해지며, 코드도 복잡해지고, 요구되는 개발 기간은 더 줄어들기만 한다. 어차피 사람의 인지도 그것을 따라잡지 못한다.

AI와 사람의 상호 검토, 그리고 밑바닥까지 탄탄한 코드, 그리고 그걸 체계화하여 지금보다 몇 배, 몇 십 배 빠르게 하는 수밖에 없다. 고로.

테스트와 검증은 자동화가 아니라 인간의 인지기능을 AI로 확장하는 수밖에 없다.

AI를 통해 1차 검증을 시켜 문제를 인간의 가시 범위로 좁혀야 한다. 그 과정에서 AI가 놓치는 게 있을 수 있으니 AI의 검토 체계를 정밀하게 짤 필요가 있다. 나중에는 AI에이전트간의 상호 감시와 규제같은 방식도 많이 나올 것이다. 지금도 AI가 만든 답변을 AI로 필터링하기도 한다.

그 속에서 인간은 몇 겹으로 AI의 동작이 위험한 길로 빠지지 않도록 방법들을 찾아야 한다. 데이터의 정제, 이상 케이스의 발굴, 상호 견제 구조 등등.

내가 LLM에게 코드를 짜달라고 하고, 그걸 보완 수정하고, 그걸 AI검토를 맡기고, 그 중에서 취약점들 중 내 프로젝트에서 필요한 것들을 선택해 수정하고, AI에게 테스트 케이스들을 작성하게 하고, 내가 누락된 부분들을 지적하는 일련의 과정이 모두 AI와 인간이 협업하는 방법이고, 인간이 AI를 통해 인지와 능력을 확장하는 방법이며, 사람이 사람에게 일을 시키는 것과도 동일한 메커니즘이고, AI와 인간이 서로 오류를 저지를 수 있는 부분을 상호 감시하는 방법이다.

그걸 위해서는 한 시간에도 수십 번 채팅을 치곤 한다.

반대로 보면, 인간간의 상호작용은 그만큼도 안 된다. 한 시간마다 말 거는 상사가 있다면, 개발자는 귀싸대기를 때리고 싶어질 것이다. 하지만 그렇다면 당연히 사람보다 AI가 Align이 잘 되고 사람보다 AI가 믿을만 해질 수도 있다.

여기서 또 중요한 착안점이 생긴다.

조직의 리더도, 말 한마디로 일을 시키면 당연히 의도대로 되지 않는다는 걸 인지해야 한다. 당연히 밑의 사람은 지시대로 하지 않는다. 의지의 문제 이전에 문제다. 팀장이 아는, 그 일을 해야하는 컨텍스트를 입력받은 적이 없는데 그 의도대로 할 수 있을 리가 없다. 끊임없이 프롬프트를 쳐야 한다. 그런데 사람은 그러면 화낸다.

그럼 나도 화내나? 어림없다. 그럼 그 사람은 이제 의지를 가지고 일을 안해주기 시작한다.

사람들은 주로 윗사람을 설득하는 데 공을 많이 들이지만 반대다. 일을 정하는 건 리더고 하는 건 팔로워다. 그럼 리더가 팔로워에게 설명을 해야한다. 팀장이 팀원들에게 주간보고를 하는 게 원래는 맞는 거다.

물론 현실이 그렇게 안 돌아가는 건 사실이지만, 그만큼 팀장은 팀원들에게 자신의 계획을 잘 설명해야 하고, 팀원이 받아들일 수 있게 팀원의 감정을 조율하는 법도 알아야 한다. 그게 힘들면?

다소 효율이 떨어지더라도 팀원에게 위임해야한다. 위임과 지시 사이의 균형점을 찾는 게 팀장의역량이자 생존스킬이다.

여기서 반대로, 사람이 AI를 다루는 방법도 나온다. 모든 걸 관리할 수는 없다. 위임해야한다. 중요한 관리 포인트들은 치밀하게 짚어내며 나머지 부분들은 위임해야한다. AI코드와 분석작업의 어디까지 믿을 수 있는지, 리스크가 있는 부분이 어디인지 이해하고, 최소의 관리 포인트로 충분할 만큼 오류를 잡아내고 위험 요소를 제거할 수 있는지 파악해야한다.

사실 AI코드의 영향력은, 그렇게 프로젝트들이 잘 관리되어 왔다면 미미한게 맞다. 프로그래머들은 바보가 아니다. 그들은 자신이 게을러지기 위해 필사적으로 고민하고, 그것이 해결되면 또 고민거리를 찾아나서는 사람들이다. 지금까지 AI이전에도 코드 재사용을 위해 온갖 기술들이 개발되었고, 그걸 적절히만 써도 매번 작성할 코드은 현저히 줄어든다. 반대로, 그 방법들로도 줄일 수 없는 코드들은 AI도 못 짠다.

그래서 실제로 AI로 업무개선이 되는 영역은 내 체감으로는 양적으로보다 질적인 개선이 많았다. (물론 내 경우 한정해서는 양적으로도 개선이 어마어마하게 된건 사실이다. 개발 말고 데이터 생성...) 빠르고 반복적인 코드 리뷰, 도큐먼트 작성, 코드의 표준성 개선 등등...

그러니까 AI가 짠 코드가 50%니 일정을 반으로 줄이거나 인력을 줄이는 의사결정을 한다면, 그 리더는 개발 업무가 어떻게 이루어지는지 모르는 거다. 그 조직을 맡으면 안될 사람인거다. 일에는 다양하고 복잡한 맥락들과 거기에 따르는 일들이 있고, AI로 업무를 개선하려면 그 디테일들을 알고 하나하나 해결할 필요가 있다.

효율 개선은 툴 하나로 되지 않는다. 그건 시스템 자체가 개선되어야한다. 주먹구구식 개발 프로젝트로 땜빵하는 환경에서 성급한 AI에 대한 과신은 품질만 현격히 떨어질 뿐이다. 오히려 AI는 시스템을 개선하기 위해 쓰여야하고 그 방법들은 이제 찾아나갈 단계다. 그것을 염두해두지 않으면 AI는 구독료만 소모하는 비싼 장난감일 뿐이다.