소프트웨어 개발의 AI 현황

프롬프팅, 컨텍스트 윈도, 압축, 그리고 AI와 함께 일하는 방법에 관한 단상.

AI에게 시키고 싶은 일이 있고, 그 일을 어떻게 해야 하는지 알 수도 있고 때로는 모를 수도 있다. 이때 세 가지 방법이 있다. 먼저 세세한 부분까지, 구체적인 사항을 하나하나 모두 설명하는 방법이다.

아니면 해야 할 일을 큰 틀에서만 말하고 AI가 알아서 이해하길 기대할 수도 있다.

그 중간을 택할 수도 있다. 나는 AI가 어려워할 만한 핵심 부분을 설명해 주는 이 방법을 주로 쓴다.

예시를 제공하는 방법도 있다. 일을 더 빠르게 진행할 수 있지만, 예시가 원하는 결과와 얼마나 비슷한지에 따라 효과가 달라진다.

어느 방법이든 시간이 든다. AI에게 요청하기 전에 시간을 들이는 방법도 있고, 결과를 받은 뒤 시간을 들이는 방법도 있다.

LLM은 학습 데이터에서 이미 접했을 법한 일반적인 패턴을 쉽게 구현한다. 사용자 인증 구현이 그런 예다. 반면 새롭게 구상했거나 처음 설명하는 문제는 당연히 어려워하므로 하나하나 안내해야 한다.

컨텍스트 윈도 문제도 있다. 3,000단어에 4페이지나 되는 촘촘하고 상세한 명세를 건네고 모든 내용을 따르길 기대할 수는 없다. 코드베이스가 커질수록 컨텍스트에 전체 내용을 담기는 더 어려워지고, 방대한 문서를 입력할 수 있다고 해서 반드시 그만한 가치가 있는 것도 아니다. 상세한 명세를 작성할 때만 문제가 되는 것은 아니다. AI가 패턴을 요약하고 대규모 데이터셋에서 결론을 도출하게 할 때도 마찬가지다. 예를 들어 주식의 과거 데이터셋처럼 방대한 수치 데이터를 분석하는 작업이 이에 해당한다.

결국 비용은 사용자가 부담한다. 프로젝트와 목표, 문제점을 자세히 설명하고, 무엇보다 만들고 싶은 결과물의 청사진을 작성하는 데 여전히 시간을 써야 한다.

AI 모델마다 전문성이 다른 문제도 있다. 작업에 맞는 모델을 골라야 한다.

더 큰 문제를 다루고 AI를 애플리케이션에 통합할수록 정보 압축이 필요해진다. 특정 문제를 해결하거나 결론을 내리고 의사결정을 하는 등의 작업을 위해, 유용한 정보를 전부는 아니더라도 최대한 많이 AI 에이전트에 담아야 한다. 이 분야에서 압축을 효과적으로 해내는 회사들이 등장하거나, 모델 개발사들이 이 문제를 완전히 해결할 것이라고 생각한다.

코드베이스가 커지면 테스트와 도구를 활용해 결과를 피드백하고, 접근 방식을 계속 개선해야 한다. 도구는 이런 용도로 특별히 만들 수도 있고 기존 도구를 활용할 수도 있다. 코드베이스의 신호 대 잡음비를 높이는 방법도 필요하다.

설명을 잘하거나 가르치는 데 타고난 사람은 AI와 쉽게 소통하고 더 나은 결과물을 얻는다고 느낀다.

결론은 여전히 시간을 써야 한다는 것이다. 구현에 들이던 시간은 사라졌다. 이제는 시스템을 미리 설계하고, 가정을 바꾸고, 개발 환경을 다듬는 데 시간을 쓴다. 하지만 구현이 정말 사라진 것은 아니다. 나는 아직도 코드를 쓰는 대신 말로 구현하고 있다고 느낀다.

^{source https://srikanth.ch/posts/the-ai-situation/}

HN에서는 AI 코딩의 속도보다 결과를 통제할 개발자의 판단력이 더 중요하다는 반응이 두드러졌다. 에이전트는 요청한 기능을 빠르게 구현하지만, 그 기능이 더할 복잡성을 따져 범위를 줄이거나 아예 만들지 않는 선택에는 약하다. 반면 구조와 규칙이 잘 잡힌 코드베이스에서 독립 기능을 추가하거나 익숙한 CRUD·SaaS 작업을 처리할 때는 충분히 유용하다는 경험도 나왔다.

성과를 가르는 기준은 작업의 크기와 검증 방식이다. 방대한 명세를 한꺼번에 맡기면 세부 요구와 테스트 범위를 놓치고, 중복 코드나 불필요한 구현을 남기기 쉽다. 명세를 작은 과제와 이정표로 쪼갠 뒤 단계마다 새 맥락에서 확인하는 방식이 대안으로 제시됐다. 수용 조건을 미리 정하고, 추가 코드량을 제한하며, 채택하거나 버린 접근과 프로젝트 규칙을 기록하는 방법도 복잡성을 억제하는 데 도움이 됐다.

생산성 수치를 해석할 때도 주의가 필요하다. 장시간 에이전트를 돌려 더 많은 작업을 끝냈다는 경험은 있었지만, 코드량이나 PR 개수만으로 진전을 판단해서는 안 된다는 반론이 뒤따랐다. 구현 시간이 줄어든 만큼 검토와 통합, 품질 관리에 일이 옮겨갈 수 있다. 승인과 내부 절차가 병목인 조직에서는 코딩 속도가 빨라져도 전체 납기가 크게 달라지지 않을 수 있다.

결국 개발자가 직접 구현 원리와 구조를 이해해야 테스트 통과 너머의 품질을 판별할 수 있다. 도입 여부만 따지기보다 에이전트에 맡길 작업의 경계, 사람이 지킬 아키텍처 기준, 성과를 확인할 수용 조건부터 정해야 한다. 민감한 코드와 지식재산을 어떤 환경에서 다룰지도 함께 점검해야 한다.