안녕하세요, 박민재입니다. 요즘 AI의 발달과 함께, 기술 그 자체보다 프로그래밍과 관련된 철학적인 이야기를 나누는 일이 많아진 것 같습니다. 이 글에도 개인적인 견해가 듬뿍 담겨 있으니, 누구의 말이 맞고 틀리다는 이야기는 하지 않겠습니다. 지난 글에서는 우리가 AI 에이전트를 어떻게 활용하고 있는가에 대해 많은 이야기를 나눴는데요. 결국 사람과 사람 사이의 문제를 해결하는 소프트 스킬이 점점 더 중요해졌다는 이야기를 했습니다. 이제 개발은 기본적으로 AI가 해주고 있으니까요.
그렇다면 이제 개발자는 날카롭게 생각할 필요가 없는 걸까요? 아키텍처 설계부터 코드 작성, 프레임워크 사용법까지 AI가 다 알고 있으니까요. 글쎄요, 저는 그렇지 않다고 생각합니다. 얼마 전 친구들과 술자리에서 이런 이야기를 나눴습니다. "AI가 다 할 수 있다면, 우리 부모님에게 내 일을 맡겨도 AI로 문제를 해결할 수 있으니 괜찮지 않겠냐"고요. 그렇다면 우리 부모님과 저는 어떤 차이가 있을까요?
극단적인 예시이긴 하지만, 부모님께서 제가 회사에서 운영하는, 하루에 1,000억 건의 데이터가 유입되어 연산 후 내보내는 애플리케이션을 운영하신다고 가정해 보겠습니다. 서버가 무엇인지 모르시는 상태에서 "이 서버를 안정적으로 운영하게 해줘"라고 질문을 던지실 것입니다. 컴퓨터공학을 전공하지 않은 수준에서 몇 차례 질문이 오가고, "이렇게 하면 될 것 같은데 진행할까요?"라는 답변을 받으면, 일단 모르겠으니 진행해 달라고 모든 것을 LLM에게 맡기실 것입니다. 그렇게 LLM이 알 수 없는 컨텍스트에서 문제가 발생하고, 무엇이 문제인지 파악하지 못한 채 계속 LLM에게 해결을 요청하다 보면, 아무도 관리할 수 없는 코드와 맥락이 무한히 발산하여 결국 LLM조차 해결할 수 없는 상황이 만들어질 것입니다. 또한 도메인 지식, 이 프로젝트가 운영되는 이유, 사용자에게 제공되어야 하는 데이터와 지켜져야 할 SLO 같은 정보도 없기 때문에, 애초에 요구사항을 제대로 정의하기조차 어렵습니다. 사실 이렇게 장황하게 설명하지 않아도, 어떤 일이 벌어질지는 개발자분들이 잘 아실 것입니다.
그렇다면 제가 AI에게 질문을 던지는 경우를 가정해 보겠습니다. 저라면 먼저 이 애플리케이션이 왜 운영되고 있는지, 어디에서 어떤 데이터를 받아 처리한 뒤 어디로 보내는지, 데이터 연산의 특성과 그로 인해 어떤 컴포넌트에 부담이 생길 가능성이 높은지를 판단하고, SLO를 충족할 수 있는지를 AI를 통해 정리할 것입니다. 그런 다음 정리된 요구사항을 바탕으로 병목이 될 가능성이 높은 컴포넌트에 문제가 없는지 메트릭을 수집하도록 할 것입니다. 애플리케이션 개선이 가능한 부분에서는 셔플, CPU 시간, 분산 처리 관점에서 최적의 후보군을 선정하고, 네트워크·스토리지 비용을 절감할 수 있는지, 데이터 압축과 CPU 시간의 트레이드오프를 고려해 최적의 옵션을 설정할 것입니다. 그리고 AI가 어떤 작업을 수행하는지 옆에서 함께 검토하며 무분별하게 발산하지 않도록 방향을 잡을 것입니다. 앞선 경우와는 다르죠. 우리는 경험과 지식을 통해 무엇이 필요한지, 어떤 방향으로 가서는 안 되는지를 알고 있습니다.
LLM은 생성형 모델입니다. 가드레일이 없다면 가장 정답에 가까울 확률이 높은 방향으로 무한정 발산한다는 의미이기도 합니다. 새로운 컨텍스트가 우후죽순 생겨나다 보면 나중에는 AI조차 따라가지 못하는 상황이 발생합니다. 이를 방지하기 위해, AI가 새로운 컨텍스트를 생성할 때마다 확인을 받도록 하거나, ADR을 작성하게 해 이후 세션에서 참고하도록 하거나, 애매한 질문에는 되물어보도록 플러그인을 활용하는 방법을 쓸 수 있습니다.
최근 체감상 LLM에 과도하게 의존하다가 장애가 발생하는 사례가 업계에서 자주 나타나고 있습니다. LLM이 작성한 코드를 제대로 이해하지 못한 채 운영 환경에 배포했다가, 문제가 생겼을 때 원인을 파악하지 못해 장애가 장기화되는 일들이 주변에서 심심찮게 발생하고 있습니다. 물론 "그 에러도 AI가 찾으면 되지 않냐"는 말이 틀린 것은 아닙니다. 그러나 왜 그 코드가 작성되었는지, 어떤 과정에서 들어가게 되었는지 파악하지 못한다면 정확한 질문을 던지지 못하고, 다운타임은 더욱 길어질 것입니다. 요즘 생산성을 높이기 위해 여러 세션을 동시에 띄우는 경우가 많은데, 저는 최대 2개 이하로 유지하면서 각 세션이 어떤 작업을 수행하는지 직접 읽어 내려고 합니다. 그래야 코드의 의도를 파악하고 내 것으로 체화할 수 있으며, 문제가 생겼을 때 바로 잡아줄 수도 있으니까요.
갑자기 알파고 이야기가 나오는 이유는, 10년 전 이세돌과 알파고의 대국 이후 바둑계의 변화를 살펴볼 필요가 있기 때문입니다. 알파고 이후 바둑계는 인공지능과 경쟁하는 것을 포기하고, 인공지능의 수를 배우는 방향으로 전환했습니다. 기존에는 정석이라 여겨지던 플레이들이 있었지만, 인공지능은 그 관례를 깨고 새로운 방식으로 승리하는 법을 사람들에게 보여주었습니다. 최근 바둑 해설에서는 승리 확률을 실시간으로 계산해 주고, 어떤 수를 두어야 유리한지를 관중에게 설명합니다. 흥미로운 점은, 최근 바둑 기사들의 실력 차이가 인공지능의 수를 얼마나 정교하게 자신의 것으로 체화하느냐에 따라 크게 갈린다고 합니다.
SW 업계도 마찬가지일 것입니다. 우리는 오히려 인공지능의 수를 공부해야 할지 모릅니다. 테스트 코드 작성이나 동작에 영향을 미치지 않는 단순한 코드 변경, AI에게 자동화를 맡길 수 있는 영역은 위임하되, 아키텍처 측면에서 내가 미처 하지 못했던 생각들을 옆에서 배우고 체화해 더 좋은 질문을 던질 수 있는 역량을 키우는 것이 필요합니다. AI를 어느 부분에서 활용해 생산성을 높일 것인가도 매우 중요합니다. 결국 우리는 가치를 만들어야 하니까요. 하지만 남들이 해결하지 못하는 문제를 풀어내는 영역으로 나아가려면, 그에 맞는 더 좋은 질문을 던지는 능력을 갖춰야 합니다. 그래서 저는 LLM에게 일을 맡긴 뒤 결과만 확인하는 것이 아니라, 어떤 방식으로 문제를 해결해 나가는지 그 과정을 지켜보며 배우고, 저 자신을 더 정교하게 다듬어 가려 합니다.
결국 AI에게 일을 맡기더라도, 발산과 수렴, 사고의 학습, 맡겼을 때 생산성이 올라가는 것과 그렇지 않은 것, 그 경계를 명확히 구분하는 것이 중요하다고 생각합니다. 그러기 위해서는 사람의 끊임없는 사유가 뒷받침되어야 하겠죠. 예전에는 개발자의 통찰을 선배의 경험이나 개발자 블로그를 통해 배웠다면, 이제는 AI와의 문답을 통해서도 새로운 생각을 확장할 수 있게 되었습니다. 아직 AI 활용에 있어 '클린 코드'처럼 업계의 기준이 될 만한 무언가가 나오지 않은 것을 보면, 우리에게는 아직 논의할 것들이 많이 남아 있구나 싶습니다. 긴 글 읽어 주셔서 감사합니다.