에이전트와 함께 프로그래밍하는 방법

• 이 글은 기존 프로그래밍 경험을 대화형 컴퓨터(LLM, 에이전트) 세계에 적응하는 과정을 다루는 두 번째 내용임
• 첫 번째 파트인 "LLM과 함께 프로그래밍하는 방법" 에서는 LLM을 기존 도구에 접목해 자동완성이나 검색 대체로 활용하는 방법을 설명함
• 이번에는 좀 더 어려우면서도 보람 있는, 에이전트 기반 프로그래밍의 실제적 경험과 통찰을 공유함

에이전트의 정의와 실제

• LLM(대형 언어 모델) 맥락에서 "에이전트"라는 용어를 정의하는 것이 의미 있음
• AI 업계의 유행어처럼 오랫동안 사용되어 왔으나, 실제로 쓸모 있는 구조로 자리잡은 것은 최근임
• 이 과정에서 많은 마케팅적 수사와 신비주의가 덧씌워져 왔음

• 엔지니어의 시각에서 보면 이제는 명확하고 단순하게 정의할 수 있음: 에이전트는 9줄짜리 코드, 즉 LLM 호출을 포함한 for 루프임
• 이 루프 안에서 LLM이 명령을 실행하고 그 결과를 직접 확인할 수 있으며, 인간의 개입 없이 반복적으로 동작함
• 단순하게 느껴질 수 있으나, 실제로 이렇게 구성하면 순수 LLM만 사용할 때보다 프로그래밍 능력이 비약적으로 향상됨

화이트보드 프로그래밍과 에이전트의 차이

• 화이트보드 앞에 서서 마커로 C 언어로 UTF-8 문자열의 유효성을 검사하는 함수를 작성한다고 가정해보면
  • (실제로 필자가 겪은 면접 상황이자 흔한 인터뷰 과제임)
  • 이 작업의 성패는 프로그래머로서의 경험, 그리고 외부 자료를 참고하지 못하는 한계를 얼버무릴 수 있는 능력에 달려 있음
  • UTF-8 인코딩 규칙을 기억해야 하고, C 문법이 다른 C계열 언어와 헷갈리지 않도록 주의해야 함(이름-타입, 타입-이름 순서 등)
  • 실제 일상에서는 컴파일러 피드백, 문서 검색, printfs 등 다양한 방법으로 코드를 검증하고 오류를 찾을 수 있음
• 에이전트 없이 LLM에게 코드를 작성시키는 것은 화이트보드에서 외부 도움 없이 코드를 짜는 것과 비슷함
  • 어렴풋한 기억을 끌어내고, 비효율적인 방식으로 문법을 맞추려 애쓰며, 엉뚱한 인터페이스를 상상하는 오류를 피해야 하는 작업임
  • LLM이 완전히 새로운 프로그램을 만들어내는 기술적 성과는 놀랍지만, GPU를 연결한 가상 화이트보드만으로는 실질적 프로그래밍 생산성이 크게 오르지 않음
• 하지만 LLM에게 가상 화이트보드 그 이상을 제공하면?
  • 예를 들어 컴파일러를 호출하고, 컴파일 에러를 확인한 뒤 스스로 수정할 수 있도록 하면?
  • grep, cat으로 기존 파일을 읽고, 여러 파일(유닛 테스트 포함)을 패치하고 반복적으로 테스트까지 할 수 있다면?
• 에이전트는 바로 이런 피드백 기반 LLM임.

에이전트 = 피드백 환경에서 동작하는 LLM

• 사람처럼 피드백 환경에서 잘 작동하는 LLM은 몇 가지 친숙한 도구만 있어도 실질적인 프로그래밍 능력을 발휘함
  • bash(cmd): 터미널 명령 실행 (find, cat, grep 등)
  • patch(hunks): 파일 패치, 코드 변경 적용
  • todo(tasks): 작업 목록 관리
  • web_nav(url), web_eval(script), web_logs(), web_screenshot() 등: 웹 탐색, 평가, 로그, 스크린샷 등
  • keyword_search(keywords): 키워드 검색
  • codereview(): 코드 리뷰
• bash 도구를 활용해 코드베이스를 효율적으로 탐색하며, git add/commit 등 버전 관리까지 자동화함
• 이러한 도구 없이 단순 코드 생성만 하는 LLM과 달리, 에이전트는 다음과 같은 차별화된 이점을 가짐
  • API 사용 정확성이 크게 향상됨 (문서 검색 및 직접 context에 반영)
  • 컴파일러 피드백으로 문법 오류 및 인터페이스 착오 감소
  • 의존성/버전 관리 능력 강화 (특정 버전 특성 파악 가능)
  • 테스트 실패를 통한 오류 탐지 및 테스트 코드 작성 습관 강화
  • 컨텍스트 윈도우 한계를 넘어서는 코드베이스 처리 (필요한 부분만 선택적으로 읽음)
  • 실행 결과를 직접 실험: 코드를 실행, 브라우저 페이지 스크린샷 피드백, CSS 자동 조정, 서버 로그로 오류 추적 및 테스트 추가
• 단점도 존재함
  • 한 문장 요청으로 수만 개의 중간 토큰(도구 호출, 웹검색, 테스트 반복 등) 발생, 작업 시간이 수 분 이상 소요
  • API 호출 비용도 발생하지만, 하드웨어 발전으로 점차 사라질 전망
• 궁극적으로 중간 노동을 CPU/GPU가 대신 수행, 개발자의 시간을 아껴주며, 쓰고 싶었던 프로그램을 더 많이 완성할 수 있음
• 실제로 프로젝트에 에이전트를 도입해 작은 작업을 시켜보고 결과를 확인하는 것이 쉬움

예: Github App 인증 개발

• 에이전트를 활용해 sketch.dev의 Github App 인증 플로우를 구현한 실제 사례임
  • 3~4번의 피드백만으로 전체 인증 흐름을 빠르게 완성함
  • 오류나 요구 조건 발견 시 간단한 문장으로 설명해주면 바로 코드와 동작을 개선함
  • 반복적이고 지루한 API 연동 작업, 빌드 시스템/패키지 관리/라이브러리 세팅 등 실무의 "잡무"를 최소화하여 생산성 모멘텀 유지에 큰 도움을 줌
• 초기 요구사항으로 "사용자별 토큰 저장 없이 앱의 글로벌 인증 정보만 사용"을 넣었고, 에이전트가 이를 반영해 구현함
  • 하지만 그 결과 심각한 보안 취약점이 발생 (누구나 모든 레포를 볼 수 있게 됨)
  • 문제 설명을 한 문장으로 피드백하니, 바로 사용자별 권한 체크를 도입해 수정된 커밋을 생성함
• 그 다음 성능 문제가 드러남
  • 아래와 같은 구조로 모든 유저-레포 조합에 대해 API 호출이 발생하여 확장성에 문제가 있었음 for install := range allAppInstallations { for r := range install.Repositories() { if r.IsCollaborator(user) { // add to available repositories } } }
  • 이 문제의 근본 원인이 "사용자별 토큰을 저장하지 않는다"는 나의 요구조건임을 깨달음
  • 요구사항을 변경(사용자별 토큰 저장 허용)하니, 에이전트가 효율적인 API 호출 방식으로 다시 설계함
• 실제로 이 과정을 글로 설명하는 데 쓴 단어 수가, Sketch에서 인증 코드를 얻기 위해 입력한 총 단어 수보다 많았음
• 한마디로, 에이전트는 오늘날 개발자를 대체할 수 있는 수준은 아니지만, 전통적으로 며칠 걸릴 반복적 작업을 하루 만에 처리하게 도와줌
• 개발자가 "아이 방 청소를 하면서"도 일을 진행할 수 있을 정도로 자동화가 이뤄짐

예: JSON 기반 SQL 규칙 적용

• 에이전트가 자주 처리하는 작업 중 하나로, Tailscale에서 배운 특이한 SQL 스타일을 적용해야 했음
  • 모든 테이블에 실제 컬럼은 하나(JSON 데이터), 나머지 컬럼은 JSON에서 파생된 generated column으로 처리
  • 예시 테이블 구조: CREATE TABLE IF NOT EXISTS Cookie ( Cookie TEXT NOT NULL AS (Data->>'cookie') STORED UNIQUE, -- PK UserID INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID), Created INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED, LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0), Data JSONB NOT NULL );
  • 이런 방식은 일종의 poor man’s ORM 역할을 하며, 스키마 확장이 쉬워지고, SQL 제약조건이 JSON 데이터 품질 검증에 도움이 됨
  • 단점은 행당 저장 데이터가 늘어나고, 모든 INSERT/UPDATE가 JSON 단위로 이뤄져야 함
• 하지만 에이전트는 이 스타일을 항상 일관되게 따르지 못했음
  • 새로운 테이블을 만들 때는 대체로 잘 따르다가, 예외가 있으면 혼동하거나 임의로 스타일을 바꿔버리는 경우가 있었음
• 간단한 해결책: SQL 스키마 파일 상단에 3문장 설명 추가
  • "각 테이블은 하나의 실제 Data JSON 컬럼만 가지고, 나머지 컬럼은 모두 여기서 파생된다"는 키워드 문장 추가
  • 이 규칙을 따르지 않는 테이블에는 별도 주석으로 예외임을 명시
  • 이후 에이전트의 동작이 눈에 띄게 개선됨
• 흥미로운 점은, 이런 설명과 주석을 실제 인간 엔지니어들은 대체로 무시하거나 효용을 낮게 평가하지만,
  • LLM 기반 에이전트는 주석과 설명을 코드 작성에 적극적으로 반영함
  • 설명만 잘 달아줘도 코드 생성 품질이 확연히 좋아짐

“자산”과 “부채” 코드 모델

• LLM 기반 코드 생성 도구에 대한 흔한 비판 중 하나는 코드 생성 자체는 전체 소프트웨어 비용에서 극히 일부에 불과하다는 것임
  • 실제로는 기존 코드의 의존성, 얽힘, 복잡한 인터페이스를 관리하는 데 대부분의 시간이 소요됨
  • 규모가 큰, 오래된, 다수 사용자가 있는 제품은 유지보수 비용이 압도적으로 큼
  • 이런 환경에서 LLM에게 "버블 정렬을 Fortran으로 짜줘"라고 요청하는 건 장난감 혹은 불편한 방해물로 느껴질 수 있음
  • 금융의 "자산/부채" 개념과 비교하는 논의도 있으나, 이 역시 완벽하게 들어맞지는 않음
• 그러나 모든 소프트웨어 엔지니어링이 이런 대규모, 장기 프로젝트에만 해당하는 것은 아님
  • 대부분의 프로그램은 소수 사용자 또는 단명 프로젝트임
  • 대규모 유지보수 경험만을 전체 산업의 본질로 확대 해석하면 안 됨
• 에이전트의 가치는 코드 생성에만 국한되지 않음
  • 에이전트는 여러 도구와 LLM을 결합해 코드 읽기, 파일 편집, 코드 삭제/수정 등 변화 자체를 자동화함
  • 코드를 추가하는 것만큼 코드 삭제/리팩터링도 자연스럽게 수행함
• 결국 엔지니어의 목표는 변화(change)
  • 변화 과정에서 운전자가 변경을 이해해야 하는 추가 작업은 있으나, 에이전트는 중간 규모 프로젝트까지도 점진적 변화를 만들어낼 역량을 보여주고 있음
  • 현재 충분하지 않더라도, 에이전트는 올바른 방향으로 빠르게 발전 중임
• 추가로, 복잡한 언어나 빌드 시스템이 프로젝트의 진입 장벽 역할을 한다는 의견도 있음
  • 쉽게 코드를 작성할 수 있는 도구(LMM, 타입 세이프티, 가비지 컬렉션, 패키지 매니지먼트, 에이전트 등)가 진입 장벽을 낮추면 품질 저하 우려가 있다는 주장
  • 만약 변화 속도를 늦추거나 통제를 목표로 한다면, 에이전트와 같은 자동화 도구는 맞지 않음

왜 지금 에이전트인가?

• 트랜스포머 같은 복잡한 AI 원리와 달리, LLM에 피드백 루프를 넣는 것은 직관적으로 명확한 접근임
  • 개발자 도구를 고민하는 입장에서는 자연스러운 발전 방향으로 느껴짐
  • 실제로 1년 전 sketch.dev의 첫 버전도 LLM에 go 도구만 연결한 수준이었지만, 지금 사용하는 에이전트와는 실용성에서 큰 차이가 있음
  • ML 분야에서도 강화학습(피드백 기반 학습) 이 50년 이상 기본 원칙임
• 에이전트의 실질적 등장은 LLM의 진화와 직결됨
  • 2023년 LLM은 도구 호출 능력이 부족해 에이전트 역할이 제한적이었음
  • 2025년 LLM은 도구 호출 및 반복 작업에 최적화되어 있어, 실질적인 에이전트 활용이 가능해짐
  • Frontier(최신 상용) 모델은 오픈모델에 비해 도구 활용력에서 크게 앞서 있음
  • 향후 6개월 내 오픈모델도 따라잡을 것으로 기대됨
  • 유용한 반복적 도구 호출이 가능한 것이 최신 LLM의 가장 큰 변화임

앞으로의 방향: 컨테이너와 병렬 실행

• LLM 에이전트 분야는 아직 대부분의 엔지니어가 실제로 도입하지 않은 초기·빠른 변화의 단계임
• 현 시점에서 에이전트는 주로 IDE나 로컬 저장소에서 작동하도록 활용됨
  • VSCode 포크나 커맨드라인 도구 설치로 쉽게 시작할 수 있음
  • 하지만 두 가지 중요한 한계가 있음
    • 첫째, 안전장치 부족: 실컴퓨터에 저장된 실운영 인증정보 등 민감 정보 노출 위험
      • 에이전트가 배포 스크립트 등 의도치 않은 명령 실행 시 치명적 보안 사고 발생 가능
      • 명령 실행마다 수동 확인을 요구하지만, 실수로 민감정보 노출 가능성은 여전함
    • 둘째, 병렬 실행 및 자동화 한계: 각 개발자가 자기 환경에서 에이전트를 하나씩만 실행해야 하므로
      • 에이전트 1회 동작마다 수 분씩 걸려 여러 작업을 동시에 진행하기 어렵고 비효율적임
• 이러한 한계를 sketch.dev에서는 컨테이너 환경으로 해결 시도 중
  • 각 작업별로 격리된 개발 컨테이너를 만들고 소스코드를 복제해 git 커밋 등만 외부로 추출
  • 여러 에이전트를 동시에 실행할 수 있으며, 다른 에이전트들도 이 방식을 탐색 중임
• 실제 사례: Github 인증 작업과 동시에 폼 UI 개선을 별도의 에이전트 세션으로 처리
  • 별도의 이슈 트래커 등록 없이, 스크린샷과 짧은 요청 한 줄로 폼 디자인 개선 피드백 처리
  • 30초 투자로도 일정 수준 이상의 결과를 얻는 경험 제공
• 지난 6개월간 UX 실험 결과:
  • 에이전트 기반 개발에 있어 컨테이너(격리 실행 환경)가 가장 실용적이라는 결론에 도달

IDE는 무엇이 되는가?

• 에이전트 기반 개발 환경에서 IDE(통합 개발 환경)의 역할이 무엇이 될지는 여전히 열려 있는 질문임
  • 에이전트에게 지시문을 입력해 작업을 시작하고, 컨테이너 환경에서 실행하며, 변경사항을 diff로 확인하고 브랜치/PR로 푸시하는 것이 실제 워크플로우가 될 수 있음
• 실제로는, 에이전트가 생성한 대부분의 커밋에 일정 수준의 사람 손질(클린업)이 필요함
  • 처음에는 거의 모든 커밋이 수동 수정 필요, 하지만 프롬프트 작성 숙련도가 올라가면 점점 수정량이 줄어듦
  • 수정 내용은 주석 편집, 변수명 변경 같은 간단한 것부터, 더 복잡한 리팩터링까지 다양함
  • 컨테이너 환경에서 이런 수정을 어떻게 효율적으로 할지가 핵심
• sketch.dev 등에서 실험 중인 워크플로우
  • diff 뷰를 직접 수정 가능한 인터페이스 제공
    • Sketch의 diff 화면 오른쪽에 코드를 직접 수정하면 해당 커밋에 반영되어 바로 푸시됨
    • 작은 한 줄 수정에 매우 효율적임
  • 컨테이너에 SSH 접근을 제공하여
    • 쉘로 직접 진입하거나, 웹 터미널로 코드를 조작
    • vscode:// URL로 열어 전통 IDE에서 작업 가능
  • 코드리뷰 스타일 코멘트를 diff 상에서 직접 남겨 에이전트에 피드백으로 전달
    • 코드리뷰 경험을 살려, 필요한 설명/요구사항을 최소한의 입력만으로 전달
• 총평
  • 컨테이너 환경은 코드 생성-수정-검증-리뷰가 통합적으로 이뤄지게 하여,
    단순한 코드 작성을 넘어 진정한 에이전트 기반 개발을 가능하게 해줌
  • 과거에는 컨테이너에서 개발하고 싶지 않았지만,
    에이전트가 만든 diff를 컨테이너에서 정리/수정하는 경험은 매우 흥미롭고 생산적임

맺음말

• LLM 기반 기술을 배우고 실험하는 과정은 겸손함을 배우는 시간이었음
  • 과거 멀티코어, SSD 도입, 네트워크 확장 등 프로그래밍 본질이 변할 때마다 즐거움을 느꼈지만,
    LLM, 특히 에이전트는 코딩의 "과정 자체"를 완전히 새롭게 만들고 있음
  • 알고리듬, 언어, 라이브러리 선택에 영향을 주던 변화와는 달리,
    에이전트는 작업 방식 그 자체의 모든 전제를 근본적으로 재검토하게 만듦
  • 때론 "프로그래밍을 전혀 모르는 상태에서 처음부터 다시 배우는 게 더 나을 것 같다"는 생각이 들 정도로 변화가 큼
  • 그리고 이 변화는 지금도 계속 진행 중임
• 지금 우리가 경험하는 방식은 6개월 전과도 완전히 다르고, 아직 안정화되지도 않음
  • 팀 협업, 리뷰 등 개발문화의 표준도 곧 크게 바뀔 것으로 보임
  • 예를 들어, 형식적으로만 이뤄지던 코드리뷰는 더 이상 실질적인 문제를 해결하지 못하고 있음
    • 코드리뷰 프로세스 자체를 새롭게 발명해야 할 시점
  • IDE 역시 그동안 주장했던 통합성과는 달리, 완전히 뜯어고쳐야 할 때가 옴
  • 업계에서도 이 변화를 인식하고 있지만, 에이전트 중심 접근은 이제 막 시작 단계
  • 앞으로도 큰 변화가 예고되어 있으며,
    호기심과 겸손함만이 이 변화를 잘 통과하는 방법임
  • 오히려 지금은 기술 관련 인터넷 포럼을 멀리하고,
    이런 토론과 요약도 에이전트에게 맡기는 것이 나을 수 있음