AI 기반/지원 코딩의 가능성에 들뜬 사이 우리가 진짜 문제를 외면하고 있는 건 아닌지 묻는다. LLM의 한계, 끝없는 재발명, 교육·투자 부족, 품질 저하와 기능주의 집착을 짚으며 에이전트가 잘못된 문제를 더 빨리 악화시킬 수 있음을 논한다.
나는 AI가 보조하는 코딩과 AI가 주도하는 코딩에 대해 자주 생각한다. 첫 번째는 인간이 어느 정도 AI의 도움을 받아 코드를 쓰는 경우다. 우리는 이미 일상적으로 보고 있다. 두 번째는 인간이 코딩 자체를 여러 AI 에이전트에게 맡기는 경우다. 사람이 생성된 코드를 들여다보지도 않고, 그저 블랙박스로 취급하며 바깥에서 결과만, 즉 무엇을 “하는지”만 바라본다면, 이를 보통 바이브 코딩(vibe coding)이라고 부른다.
특히 코딩의 운전대를 AI 에이전트가 잡는 두 번째 상황에서는, 오늘날 이 에이전트들이 만들어 내는 해법의 수준이 꽤 인상적이다.
물론, 때로는 이들이 심각한 주의력 결핍을 가진 4살짜리 영재처럼 굴기도 한다. 자꾸 딴짓을 하며 방금 하려던 일과 지켜야 할 제약을 잊어버린다. 그래서 계속 상기시켜 줘야 한다. “아니, 그게 아니라니까. 네가 해야 할 건 그게 아니고 이거야.” 그러면 에이전트는 사과하고, 주변을 전혀 인식하지 못한 채 만들어 낸 난장을 수습하려 애쓰다가… 다시 산만해진다.
또 때로는, 다른 부분은 멀쩡한데 특정 한 지점에만 명백히 잘못된 조각을 끼워 넣어서, 어찌 그 부분에서만 그렇게 한참을 벗어날 수 있는지 고개를 절레절레 흔들게 만든다.
그럼에도 전반적으로 보면, 오늘날의 에이전트들이 이미 상당히 야심찬 과제를 제법 잘 수행한다는 점은 분명 인상적이고, 현재의 여러 불안정성도 시간이 지나며 점차 완화될 것이라 기대할 수 있다.
하지만 그럼에도, 어딘가 맞지 않는다는, 가능성에 들뜬 나머지 정말 이게 말이 되는지, 제대로 된 문제를 다루고 있는지 묻는 일을 멈춰 버린 건 아닌지 하는, 찝찝한 느낌이 남는다. 여기서 말하는 건 AI 기반 코딩이 IT의 실제 문제를 해결해 주지 않는다는 사실이 아니다. 그 점과 AI 기반 코딩의 몇 가지 결과에 대해서는 이전 블로그 시리즈에서 충분히 길게 썼다. 그 시리즈에서 다룬 내용도 내 생각에는 모두 중요하지만, 여기서 하려는 말은 그와는 조금 다르다.
이번에는 그 모든 고려사항을 옆으로 밀어놓고 그냥 이렇게 말해 보자. “좋아, 일단 해보자.” 그래도 어딘가 여전히 어긋나 있다는 느낌이 든다. 정확히 뭐라고 집어 말할 수 있을지는 확신이 없지만, 곱씹다 보니 몇 가지 지점이 떠오른다.
몇 걸음 물러나(요즘 내 체감으로는 거의 아무도 이렇게 하지 않지만) 바라보면, 전혀 다른 질문들이 보인다. 핵심적으로 LLM은 확률에 기반해 동작한다. 입력을 받으면, 학습 과정에서 본 것을 바탕으로 다음에 올 법한, 가장 가능성 높은 토큰을 낸다. 학습 데이터에 비추어 가장 말이 되는 토큰을 고르는 것이다.
이들이 전통적인 다층 퍼셉트론이나 LSTM 같은 고전 RNN보다 훨씬 더 영리하게 응답하는 이유는, 어텐션 메커니즘이 입력(그리고 지금까지 생성한 출력)의 다양한 부분에 선택적으로 더 많이, 혹은 덜 주목하도록 도와주기 때문이다. 이는 인간의 처리 방식과 비슷하다. 텍스트 입력을 받으면 모든 단어에 같은 주의를 기울이지 않는다. 답변을 만들어 내는 동안, 입력의 서로 다른 부분이 출력의 서로 다른 부분에 각기 다르게 중요해진다.
그럼에도 답변은 결국 학습 중에 본 것에 기반한다. 요즘 에이전트들처럼 도구 호출을 붙인다 해도, 근본적으로는 여전히 학습에서 본 것에 의존한다. 이 사실을 곱씹으면 하나의 딜레마에 부딪힌다.
에이전트는 학습 중에 본 것을 바탕으로 코드를 만든다. 전통적인 의미에서 창의적일 수는 없다. 필요한 정보가 학습 데이터에 없으면, 그들의 작동 원리는 보통 “환각(hallucination)”이라 부르는, 학습 데이터가 있는 영역들 사이를 보간하는 식으로 움직인다. 그렇다면 에이전트가 대부분의 경우 쓸 만한 코드를 만들어 낸다는 건, 학습 중에 유사한 것을 봤다는 뜻이다.
학습 데이터 안에 완성된 해법이 통째로 있을 필요는 없다. 대신 그 해법의 조각들과, 그 조각들을 재조합하는 방법을 봤을 수 있다. 그리고 그러한 조각과 재조합 방식을 신뢰도 있게 재현하려면, 한두 번이 아니라 아주 많이, 수없이 봤어야 한다.
예를 들어 보자. 어떤 이들은 에이전트형 AI가 처음부터 러스트(Rust) 코드로 만들려고 하면 완전히 막혀 버렸다고 했다. 그래서 우회로를 썼다. 먼저 파이썬으로 만들게 하고, 그게 제대로 돌아가면 러스트로 번역하게 한 것이다.
문제는 모델이 학습 중에 러스트 코드를 충분히 보지 못했다는 데 있었다. 그래서 러스트 코드를 처음부터 생성하는 데 어려움을 겪었다. 반면, 파이썬 코드는 학습 과정에서 엄청나게 많이 봤기 때문에, 제대로 된 파이썬 코드를 만들기가 훨씬 쉬웠다. 또한 파이썬 코드를 러스트로 번역하는 방법에 대해서도 학습 말뭉치에 충분한 데이터가 있었다. 그래서 파이썬으로 돌아 우회하는 방법은 통했지만, 정면 돌파는 실패했던 것이다.
이 지점에서 질문이 생긴다. LLM이 생성의 근거로 삼는 코드가 그토록 자주 LLM의 학습 데이터에 들어 있다면, 왜 그것들이 애초에 더 높은 수준의 빌딩 블록, 이를테면 라이브러리, 프레임워크, 또는 표준 소프트웨어로 제공되지 않는가?
우리는 소프트웨어 개발에서 바퀴를 재발명하느라 너무 바빠, 정작 우리의 처지를 개선하는 일을 잊어버린 건 아닐까?
LLM로 뒷받침된 AI 에이전트가 작동하는 코드를 쉽게 만들어 낼 수 있다면, 그건 우리가 더 나은 고수준 추상화를 만들기보다 같은 일을 반복해서 하고 있다는 방증일 수도 있다. 그러면 이런 질문으로 이어진다.
우리는 영원히 바퀴를 재발명하도록 숙명지어진 걸까?
이 글 앞부분에서도 썼듯, 정확히 집어 말하기는 어렵지만 어딘가 어색하다. 우리는 LLM을 이용해 이미 수백만 번 만들어 본 것과 같은 코드를 또다시 생성하면서, 정작 이 문제를 더 잘 다루는 방법을 생각하지 않고 있는 건 아닐까? 흠…
또 한편으로는, 위 질문을 다룰 때 조심해야 한다. 예컨대 링크드인이라는, 스스로를 혁신의 최전선에 있다고 마케팅하는 사람들이 모여 있는 곳을 가 보면, AI 에이전트로 몇 시간 “바이브 코딩” 해서 전에는 몇 주 걸렸을 일을 해냈다고 떠들어댄다. 이때 누가 떠들고 무엇을 했는지 잘 들여다볼 필요가 있다.
거의 언제나, 그들은 전업으로 코딩하지 않는 사람들이다. 과거에 코딩을 했거나, 지금도 재미로 조금 할 수는 있다. 하지만 20년 넘게 안정적으로 운영되어야 하고 지속해서 변경해야 하는 프로덕션 코드를 쓰는 사람은 거의 없다. “iOS 앱을 방금 만들었다. 스위프트는 전혀 몰랐는데, 몇 시간 만에 작동하는 앱을 만들었다. 예전 같으면 몇 달 걸렸을 일이다. 바이브 코딩이 미래다!” 같은 식이다.
잠깐만 곱씹어 보면, 이런 이들 대부분은 보통 _바퀴를 재발명_한다. 이미 수천, 아니 수백만 번 구현된 것을 또 구현하는 것이다. 그들의 유일한 문제는, 해당 언어나 생태계를 몰랐다는 데 있다.
다시 말해, 그들은 스스로 하면 훨씬 더 오래 걸렸을 재미용 애플리케이션을 만들어 냈다. 하지만 그게 오래 걸렸을 이유는 코딩 자체가 오래 걸려서가 아니라, 지식과 전문성의 부족 때문이었다. 1
이미 수백만 번 해 본 일을, 필요한 지식과 전문성이 부족한 사람이 하려 할 때, AI 에이전트는 당연히 속도를 크게 높여 준다. 그래도 그건 결국 바퀴를 재발명하는 일이다.
사족: 자칭 “허슬러” 중 일부는, 소프트웨어 개발에 대해 아무것도 모른 채, 개발자에게 돈을 지불할 의지도 여력도 없이, AI 에이전트로 “획기적인” 소프트웨어를 만들어 “금방 부자가 되겠다”고 한다. 하지만 이 접근이 제품-시장 적합성을 검증하는 초기 프로토타입 단계를 넘어 실제로도 통할지는 아직 증명되지 않았다.
오해하지 말자. 사람들이 아이디어를 소프트웨어로 바꾸는 데 있어서, 소프트웨어 개발·프로그래밍 언어·생태계 등을 배우고 첫 줄의 코드를 쓰기까지 기다릴 필요가 없다는 점은 훌륭하다. 혹은 개발자에게 비용을 지불해야 하는, 때로는 엄두도 못 낼 만큼 비싼 장벽을 넘지 않아도 된다는 점도 그렇다. 그러나 이것은 보안이 확보되고, 운영 환경에서 신뢰성 있게 돌아가며, 장기간 유지보수와 진화를 감당해야 하는 _프로덕션 코드_를 작성하는 일과는 전혀 다르다.
두 번째로 마음을 콕콕 찌르는 지점이 있다. 프로덕션 코드를 쓰는 일은 (바이브) 코딩으로 프로토타입을 만드는 것과 완전히 다른 게임이다. 제대로 하려면, 프로그래밍 언어와 그 생태계, 좋은 소프트웨어 설계·개발의 가이드라인과 금기, 소프트웨어를 프로덕션급으로 만드는 데 필요한 갖가지 볼트와 너트, 그리고 그 밖의 많은 것을 깊이 알아야 한다. 여기서는 코드가 무엇을 하느냐뿐 아니라 어떻게 하느냐도 중요하고, 디테일이 거대한 차이를 만들며, 제대로 하려면 많은 지식과 경험이 필요하다.
흥미롭게도, 숙련된 개발자들이 AI 에이전트가 얼마나 자신들을 더 빠르게 해줬는지 흥분해서 떠드는 건 거의 듣기 어렵다. 그들 중 적잖은 이들이 에이전트나 적어도 AI 보조 도구를 쓰지만, 상상초월의 생산성 향상을 말하기보다는, 지루한 부분을 넘겨 주고 재미있고 어려운 부분에 집중할 수 있다고 말한다. 그들은 속도나 생산성보다 편의성에 대해 말한다. 링크드인의 “허슬러”들과의 차이는 그들이 _자기 장인정신을 안다_는 것이다.
그런 사람들이 더 큰 편의성과, 더 재미있게 일하기 위해 AI 에이전트를 쓰는 건 좋다고 본다. 일에서 즐거움을 느끼는 것은 과소평가된 동기 부여 요인이다. 하지만 핵심은, 숙련된 개발자들에게 AI는 많은 이들이 우리에게 믿게 만들려는 것만큼의 “혁명”은 아니라는 점이다. 멋지고, 더 편하고, 더 즐겁게 해 주지만(이건 좋은 일이다) “혁명적”인 부분은 빠져 있다.
하지만 대부분의 소프트웨어 엔지니어는 방금 말한 그들과 같지 않다고 말할 수도 있다. 그렇지 않았다면, 보안도 취약하고, 운영에서 신뢰성 있게 돌지도 않으며, 유지보수와 진화도 제대로 안 되고, 프로덕션급 코드의 다른 속성도 빠진, 대충 휘갈긴 형편없는 코드가 그렇게 많이 운영에 배포될 리 없지 않냐는 것이다. 이런 코드가 다수라고 말할 수 있다. 폴 그레이엄이 최근 X에서 이렇게 썼다:
“AI 코딩이 그렇게 잘 먹히는 이유는, LLM 이전에도 중간값 수준 앱의 소스코드는 이미 잡탕(slop)이었기 때문이다.”
그렇다면, 평균적인 프로덕션 코드의 기준선을 거기에 두는 편이 더 합리적이지 않을까?
그 기준선을 택한다면, 앞서 말한 숙련된 개발자들의 속도가 그다지 빨라지지 않는다 해도, 덜 숙련된 개발자들의 속도는 빨라지지 않을까? 적어도 우리가 방금 기준선으로 설정한 그 정도의 하급 품질 코드를, AI 에이전트를 써서 더 싸게 만들 수 있지 않을까?
의사결정자들이 내부든 외부든 개발자들이 만들어 주는 코드가 대체로 형편없고, 그 형편없는 코드를 쓰는 데도 느닷없이 오래 걸린다고 느낀다면, AI 벤더의 약속에 귀가 솔깃해져, 소프트웨어 개발을 AI 에이전트에게 넘기고 싶어 하는 건 이해할 만하다.
그리고 맞다. 형편없는 코드는 판친다. 대부분의 엔터프라이즈 소프트웨어 코드는 잘해 봐야 “그럭저럭 돌아가는” 수준이다. 종종 그조차 못하다. 하지만 최소한 내게는, 코딩을 AI 에이전트에게 넘기는 게 이 문제를 다루는 올바른 방식이라기보다, 잘못된 문제를 푸는 느낌으로 다가온다.
내가 보기에는, 문제는 평균적인 개발자 교육의 부족에서 시작한다. 오랜 세월 IT, 특히 소프트웨어 개발은 안정적인 일자리, 안전한 선택지로 여겨졌다. 그래서 많은 이들이 원래 하던 일이 잘 풀리지 않자 소프트웨어 개발로 돌아섰다. “본업으로는 먹고 살기 힘드니, 개발자가 되어야겠다. 그게 얼마나 어렵겠어?”
왠지 모르게, 소프트웨어 개발자가 되는 건 쉽다는 착각도 있었다(그리고 아직도 있다). “그게 얼마나 어렵겠어?” 하지만 몇 개의 널판지를 톱질해 손가락을 자르지 않고 상자를 만들어 봤다고 해서 훌륭한 목수가 되는 건 아니듯, 코드를 조금 배웠다고 해서 훌륭한 소프트웨어 개발자가 되는 건 아니다.
그럼에도 소프트웨어 개발을 배우는 일이 쉽다는 생각이 퍼졌고, 소프트웨어 개발자에 대한 끝없는 수요를 맞추기 위해, 몇 달 만에 누구든 훌륭한 개발자로 만들어 주겠다는 재교육 과정이 우후죽순 생겨났다. 그 결과(그리고 지금도) 많은 IT 종사자들이 IT 경력을 시작할 때, 좋은 소프트웨어를 만들고 운영하고 유지할 기본적인 소프트웨어 공학 역량을 갖추지 못한 채 출발하게 되었다.
평균적인 IT 부서에 가서 사람들에게 전공을 물어보라. “컴퓨터공학을 전공했다”고 답하는 이는 극히 드물 것이다. 내가 물어보면, 철학까지 포함해 정말 다양한 답이 돌아온다. 철학 공부가 사람과 세상 일반에 대해 많은 걸 배우게 해 줄 수는 있겠지만, 프로덕션급 소프트웨어를 쓰는 법을 가르쳐 주지는 않는다.
사람이 컴퓨터공학을 공부했다고 하더라도, 프로덕션급 소프트웨어를 쓰는 법을 배웠는지는 미지수다. 하지만 적어도 관련된 기초를 배웠기 때문에, 프로덕션급 소프트웨어를 쓰는 법을 이해하기가 훨씬 쉬워진다.
이 모든 것은, 개발자가 커리어를 시작할 때의 평균적인 교육 수준과, 프로덕션급 소프트웨어를 쓰는 데 필요한 수준 사이에 거대한 간극이 있음을 의미한다. 그래서 우리는, 역량을 계속 날카롭게 유지하기 위한 지속적인 훈련의 문제로 이어지게 된다.
IT는 결코 멈추지 않는 영역이다. 단명하는 유행을 제외하더라도, IT는 꾸준히 움직인다. 10~15년 전에 익힌 기술이 이제는 오히려 해가 될 수도 있다. 우리는 계속 적응해야 한다. 즉, 기업 입장에서는 임직원의 역량을 정기적으로 훈련해 날카롭게 유지하는 것이 중요하다.
그런 다음, 평균적인 기업이 사람을 훈련시키고 역량을 유지하는 데 얼마나 투자하는지 둘러보면, 다소 실망스러운 현실을 마주한다. 간신히 일을 해낼 정도 — 때로는 그마저도 못 미치는 수준이다.
사람을 훈련시키는 데는 돈이 들고, 단기 수익을 만들지 않는다. 사람들이 교육을 듣지 않고 일하면 즉각적인 산출물을 만든다. 효율 중심 환경에서는 이를 기대 수익의 척도로 삼는다. 그 결과, 소프트웨어 개발자를 포함한 직원들은 크게 과소교육되고, 업무를 간신히 해낼 정도의 상태에 머문다.
대개 그들은 프로덕션급 소프트웨어를 쓰는 법을 모르는 채 일을 시작한다. 그리고 직장에 있는 동안에도 그걸 배우지 못한다. 설령 어느 시점에는 알았더라도, IT가 계속 변하는 동안 따라잡을 시간과 교육을 제공받지 못해 그 역량을 잃어버린다.
그 모든 결과—그리고 가능한 한 빨리 기능을 찍어 내라는 압박—가 바로 이것이다. 어디에나 형편없는 코드.
소프트웨어 개발자들이 평균적으로 너무 교육이 부족해, 견고하고 프로덕션급 코드를 합리적인 속도로 만들지 못한다는 이유로 소프트웨어 개발을 AI 에이전트에게 넘기는 일은, 내게는 “우리는 잘못된 문제를 풀고 있다”는 찝찝함을 남긴다. 내게 이 모든 일은 마치 이렇게 들린다.
형편없는 코드를 만들어 내는 시스템을 완벽히 다듬었다. 이제, 기계를 써서 형편없는 코드를 더 빨리 만들자.
만약 AI 에이전트로 훨씬 더 나은 코드를 만들 수 있다면 이야기는 다르다. 하지만 에이전트와 LLM은 그들이 학습 중에 본 것에 묶여 있다 — 바로 우리가 고통받고 있는 그 형편없는 코드, 개발 속도를 늦추고 운영 신뢰성을 해치는 각종 문제의 근원인 코드 말이다.
이제 왜 기업들이 늘 소프트웨어 개발의 속도를 높이고 싶어 하는지라는 질문으로 들어갈 수도 있겠다. 하지만 그 질문은 이미 여러 글에서 다뤘으므로, 여기서는 간단히만 짚겠다. 자세한 내용은, 예컨대 “Simplify!” 시리즈를 보라. 거기서 우발적 복잡성이 어떻게 폭증하고, 이를 어떻게 다룰 수 있는지 여러 동인을 논한다. 결국 이런 불균형하게 커지는 우발적 복잡성이, 소프트웨어 개발을 더 빠르게, 더 짧은 시간에 더 많은 기능을 요구하는 지속적 수요를 부추긴다.
요구되는 기능의 대부분은 어떤 가치도 만들지 못한다. 즉, 낭비다(자세한 내용은 “Forget efficiency” 글을 보라). 그런데도, 원하는 비즈니스 임팩트가 나타나지 않으면, “요구 기능들이 가치를 못 만들기 때문일지도 모른다”는 질문 대신, 자기강화적 사이클이 촉발된다. 간단히 말해 “더 많은 기능이 필요해!”에서 “우리가 한 일이 원하는 임팩트를 못 내고 있어”로, 다시 “더 많은 기능이 필요해!”로 되돌아간다.
효율 중심 기업(거의 모든 기업)이 암묵적으로 깔고 있는 가정은, 요청된 기능이라면 정의상 모두 가치를 만든다는 것이다(따라서 임팩트/매출을 만든다). 그러니 이 관점에서는 임팩트의 부족은 구현된 기능의 “양”이 충분치 않다는 뜻일 뿐이다.
동시에, 이 엄청난 양의 무가치한 기능이 코드베이스를 막아 버린다. 코드가 무엇을 하는지 점점 더 이해하기 어렵게 만든다. 새로운 기능은 기존의 무가치한(그리고 소수의 유용한) 기능들을 피해 가며 만들어져야 하고, 그만큼 개발이 느려진다. 결과적으로 악순환이 생긴다. 더 많은 기능을 더 짧은 시간에 요구하고, 대개는 쓸모없는 각 기능이 다음 기능 구현을 한층 어렵게 만든다.
하지만 이제 에이전트형 AI가 있다. 훨씬 빠른 속도로 소프트웨어를 만들어 내는 AI 에이전트! 이제 비즈니스 부서가 원하는 만큼 기능을 만들 수 있다. 이제 모든 게 잘 풀릴 것이다!
솔직히 말하자면: 나는 회의적이다. 악순환은 더 빨리 돌 뿐이다. 달리 말하면 이렇다.
우리는 대부분의 시간에 쓸모없는 기능을 만든다. 이제, 기계를 써서 쓸모없는 기능을 더 빨리 만들자.
또 하나의 찝찝함. 우리는 또다시 잘못된 문제를 풀고 있는 건 아닐까.
마지막으로 하나의 아이러니를 짚고 싶다. 소프트웨어 개발에 AI 에이전트를 많이 쓰는 사람들과 이야기해 보면, 요구사항과 아키텍처 설계·문서화의 품질이, AI 에이전트가 만들어 내는 코드의 품질에 엄청난 차이를 만든다고 한다. 그래서 요구사항을 더 정교하게 기술하고, 좋은 아키텍처 설계에 더 많은 노력을 들여야 한다고 말한다.
여기서 나는 뭐라고 답해야 할지 모르겠다. 정말 모르겠다.
지난 30~40년 동안, 빠르고 신뢰할 수 있는 소프트웨어 개발을 가로막는 가장 큰 장애물 중 하나가 엉망인 요구사항과 엉망인 아키텍처 설계였다. 그 문제를 지적하면, 개선하자는 제안은 늘(지금도) 이렇게 묵살됐다. “그럴 시간이 없어. 기능을 내야 해. 뭘 그리 호들갑이야! 그렇게 어렵지 않잖아.”
그런데 요구사항이나 아키텍처 설계·문서화가 엉망이면 제대로 된 결과를 만들기 어려운 AI 에이전트 얘기가 나오자, 그걸 고치려고 시간을 들이는 게 갑자기 “베스트 프랙티스”가 되는가? 다년간 인간 개발자들이 같은 문제로 고통받으며 똑같은 요구를 했을 때는 늘 거절하던 일을?
인간 개발자들도 수십 년 동안 엉망인 요구사항과 설계·문서화 때문에 똑같이 고생했다. 그런데 아무도 신경 쓰지 않았다. 대신 “개발이 너무 오래 걸린다”는 불평만 있었다.
역시나 균형이 어딘가 어긋났다는 느낌을 더한다.
처음에 썼듯, 오늘날 우리가 AI로 소프트웨어 개발에서 할 수 있는 일이 매우 인상적이더라도, 여전히 어딘가 맞지 않는다는 찝찝함이 남아 있다.
그리고 이 모든 문제의 해법이 “소프트웨어 개발에 에이전트형 AI를 쓰자”라고?
이제 내게 왜 그런 찝찝함이 있는지 조금은 이해가 될지도 모르겠다.
내겐, 에이전트 기반 소프트웨어 개발이(다시 2) 앞서 말한 중요한 문제들을 해결하지 않기 위한 편리한 핑계로 쓰이는 듯 보인다.
대신, 소프트웨어 개발은 더 빨라져야 한다 — 즉, 실제로 그게 우리의 문제인지 고민도 없이 더 짧은 시간에 더 많은 기능을 내야 한다 — 는 인식된(인지된) 문제를 해결하는 데 쓰인다.
그래서 나는 우리가(또다시) 잘못된 문제를 풀고 있다고 생각한다.
LLM은 놀라운 기술이고, AI 기반 소프트웨어 개발 솔루션이 해내는 일도 인상적이다. 하지만 이걸 무분별하게 여기저기에 적용하면, 나는 그저 현 상태를 공고히 하고, IT 전반, 특히 소프트웨어 개발에서 우리가 겪는 문제들을 증폭시킬 뿐이라고 본다.
개인적으로는, 이런 놀라운 기술을 더 영리하게 쓸 수 있으면 좋겠다. 앞서 언급한 문제들을 먼저 해결하고, 그 다음에 에이전트형 AI를 적용한다고 상상해 보라. 그게 진짜 인상적일 것이다…
수작업으로 하면 언어와 생태계를 정말 잘 아는 경우에도 AI 에이전트를 쓸 때보다 훨씬 오래 걸린다면, 이는 당신이 바퀴를 재발명하고 있다는 신호로 볼 수 있다. (같은 문제가 이미 수차례 해결되었음에도) 필요한 추상화가 없어서 어쩔 수 없이 그러는 것일 수도 있고, (이유야 어찌됐든) 자발적으로 그러는 것일 수도 있다. ↩︎
지난 수십 년 동안 소프트웨어 개발의 모든 긴급한 문제를 해결해 주겠다는 “은탄환(silver bullet)”을 수없이 봐 왔다. 하지만 우리 모두—적어도 배웠어야—알다시피, 그 어느 것도 그런 약속을 지키지 못했다. ↩︎
