▲

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

 (crawshaw.io)
15P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 이 글은 기존 프로그래밍 경험을 대화형 컴퓨터(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 역시 그동안 주장했던 통합성과는 달리, 완전히 뜯어고쳐야 할 때가 옴
    • 업계에서도 이 변화를 인식하고 있지만, 에이전트 중심 접근은 이제 막 시작 단계
    • 앞으로도 큰 변화가 예고되어 있으며,
      호기심과 겸손함만이 이 변화를 잘 통과하는 방법임
    • 오히려 지금은 기술 관련 인터넷 포럼을 멀리하고,
      이런 토론과 요약도 에이전트에게 맡기는 것이 나을 수 있음
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 주로 내 도구를 위해서만 코딩하기 때문에, 내 코드가 아닌 다른 누군가 또는 어떤 무언가가 코드를 대신 작성한 다음 그걸 읽고, 이해하고, 고치는 것에 큰 메리트를 잘 모르겠다는 생각을 함, 물론 API 문서에서 내가 원하는 부분을 LLM에게 찾아달라고 하면 상당히 유용하고 시간 절약임, 그래서 LLM의 미래 성능이 좋아질지 여부와 무관하게 나는 그냥 남의 코드를 읽는 것 자체가 별로임

    • 나에게는 LLM이 도움이 되는 케이스가 있음, 예를 들면 공식화된 코드에서는 매크로나 코드 생성기가 필요 없어지는 효과가 있음, 다만 느리고 매크로처럼 한번에 전체 갱신하긴 어렵지만, 약간씩 다르게 반복되는 구조의 코드에는 오히려 매크로보다 LLM이 유용함, 또 익숙하지만 코드까지는 외우지 않은 API 쓸 때 구글 검색하고 문서 뒤질 필요 없이 바로바로 작업 가능, 타입 언어를 쓰기 때문에 LLM이 헛소리하면 타입체커나 테스트에서 걸러낼 수 있어서 큰 걱정 없음, 그리고 10개 이상의 파일에 걸쳐 변경이 필요할 때 마크다운으로 변경 계획을 세워주는 게 정말 큰 시간 절약임, 마지막으로 피로할 때 스타일이나 네이밍 규칙을 그냥 넘기기 쉬운데 LLM은 프로젝트의 기존 스타일을 잘 유지해줘서 좋음
    • 요즘 이런 방식으로 일하는 게 점점 좋아짐, 우선 전체 코딩 디자인을 계획한 후, LLM에게 구체적 단계들을 설명해 주고, 내가 코드 읽고 이해하고, 고치고, 다음 단계를 계획하는 동안 LLM이 다음 섹션 코드를 미리 작업하게 만듦, 말하자면 나와 LLM이 병렬로 각자 작업하는 흐름임, 이건 마치 레스토랑의 쉐프가 주문이 들어오면 그 즉시 전체 요리 작업 단계를 구상하고, 스테이크를 굽는 동안 기다리지 않고 다른 준비도 병행하는 상황과 같음, LLM은 오븐이나 푸드 프로세서 같은 조리 도구에 가까움, 예를 들어 치즈 갈기를 손으로 할 수도 있지만 푸드 프로세서에 넣어두면 몇 분 절약 가능, 전문 요리사는 각종 도구를 활용해 멀티태스킹으로 효율을 올리는데, 앞으로 코딩도 한 줄씩 단계별 작업이 아니라 멀티태스킹 구조로 바뀔 수도 있다고 생각
    • 내가 다른 무언가에 내 코드 작성 책임을 미루고 결국 그걸 다시 읽고, 이해하고, 또 직접 고치는 것에 무슨 이점이 있냐는 의문에 대해선, '마찰'이라는 표현을 씀, 많은 사람들이 새 일을 시작하는 걸 어려워하고(작가의 블락처럼), 이미 다른 누군가가 만들어둔 솔루션을 받으면 그걸 내 방식대로 바꾸고 모듈화하는 게 진입 장벽을 크게 낮춰줌, 나와 동료들 중 프로젝트를 0에서 세팅할 때 툴체인 구성과 부트스트랩에 큰 부담을 느끼는 사람이 많음, LLM은 충분한 컨텍스트와 자원이 있으면 전체 코드베이스를 빠르게 스캔해서 "이미 이 코드 내에 audit 메커니즘이 두 군데 있으니 공통부를 추출하자" 같은 걸 발견해줄 수도 있음, 내가 스스로 놓치던 부분까지 자동으로 잡아줄 수 있음
    • 내가 다루는 한 코드베이스에선 여러 파일을 반복적으로 조금씩 바꿔야 하는 과업이 많음, 이런 일은 창의성이나 도전보단 그저 여러 파일 열고 수정하는 반복노동임, 이전까진 3~4시간 걸렸지만 AI 에이전트에게 작업을 설명해주면 99% 알아서 처리해주고, 소요 시간이 3~4분밖에 되지 않음
    • 어떤 사람들은 도구 없인 아무 것도 못하는 타입임, 이런 사람들이 얼리어답터이자 파워유저가 되어 새로운 발견을 전파함, GitHub의 가치는 평범한 개발자가 PR, 리뷰, 그린스퀘어, todo 리스트 등에서 생산적인 듯 보일 수 있는 환경 제공이었음, LLM 또한 평범한 개발자가 별 중요하지 않은 도구와 에이전트들을 돌리면서 생산적인 모습을 연출할 수 있게 해주기 때문에 매니저들이 좋아함

  • 저자는 코드 리뷰가 부실하고 거의 제대로 동작하지 않는다고 한 부분에 완전히 동의함, 에이전트가 코드를 작성하는 시대에는 실제 병목은 작성이 아니라 코드 읽기임, 사람들이 리뷰를 대충하거나 각자 취향을 드러내는 수단 정도로만 사용하면, 에이전트는 심각한 보안이나 성능 문제를 쉽게 집어넣을 수 있음, 솔직히 진짜 문제는 코드를 읽는 것만으론 안 보이고, 직접 디버깅하거나 가정들을 검증하는 수작업이 필요함

    • 에이전트/AI 코드는 '부실 리뷰' 문제를 어떤 식으로 해결하는지 분명하지 않다는 의문임, 사람들은 코드 리뷰 자체를 하기 싫어하고 지루해함, 나는 재미있는 부분인 '코드 작성'을 AI에게 넘겨버리고 대신 끝없는 코드 읽기&검수를 받아야 하는 상황이 올까봐 걱정임
    • 현재 시장에서 가장 부족한 부분은 LLM이 만들어낸 코드, diff, 전체 코드베이스를 어떻게 효율적으로 읽고, 제대로 리뷰하고, 이해하느냐의 문제임, 프로젝트 내에 사람 자체가 소수 뿐이라면 남아있는 사람들이 코드를 실제로 읽기는 하는지, 아니면 그냥 넘겨버리는지 걱정임
    • 에이전트의 핵심은 테스트 커버리지가 충분하다면, AI가 코드를 작성하고 안전/성능 피드백까지 얻을 수 있다는 점임, 그리고 그 AI가 테스트 작성도 도와줌

  • 드디어 LLM에 대한 현실적인 분석을 한 글을 봤다는 소감임, "에이전트"라는 용어가 사실상 재귀적으로 LLM을 부르는 for 루프에 이름 붙인 것이라 좀 답답하지만, 작명 센스가 원래 업계 평균도 낮으니 그냥 받아들임

    • '에이전트'의 정의에서 글쓴이와 같지 않다는 의견임, 진짜로는 LLM이 (반복적으로) 도구와 리소스를 호출하며 루프 도는 구조임, 미묘한 차이지만 어디까지가 주체인지를 정하는 문제임
    • "에이전트란 도구가 루프에 있는 것"이라는 표현이 마음에 들었음, Simon이 이렇게 말했다고 기억함
    • OP의 에이전트 정의에 약간 이견이 있음, 단순히 LLM이 루프 도는 게 아니라, LLM의 행위가 다른 논리적 컴포넌트에 의해 제약되거나 유도되는 게 진짜 특징임, 이 중 일부는 결정적이고 다른 일부는 ML 기반(LMM 포함)임, 즉 LLM이 어떤 방식으로든 설계된 시스템에서 계획을 강제로 짜게 하거나, 코드 편집 이후 테스트 빌드 및 실행을 트리거하는 등의 방법을 통해 추가 유용성을 얻을 수 있음, "에이전트는 스스로 입력 받아 움직인다"라는 설명이 틀리진 않지만, 실은 여러 구성요소가 수시로 LLM의 행동을 감독 및 인도하는 의도가 더 본질적임
    • "Agent"라는 네이밍 자체는 사람들이 직관적으로 잘 이해하기 때문에 괜찮다고 보지만, 혹시 다른 대안 후보로는 LoopGPT 같은 건 어떨지 생각함

  • "우리는 컨테이너가 프로그래밍에서 쓸모 있고 필요하다는 점에 동의함" 이 부분과 관련해 Docker를 만든 Solomon Hykes가 왜 최근 Container Use라는 프로젝트를 오픈소스로 공개했는지 설명함, 에이전트가 병렬로 안전하게 실행이 가능하도록 하기 위함, Sketch 등 일부 플랫폼은 격리된 로컬 개발환경을 내장하고 있지만 다른 코딩 에이전트들은 그렇지 않아서, 추가 정보로 YouTube 영상도 추천함

  • 에이전틱 루프, 기계 안의 두뇌, 사실상 규칙 엔진의 대체물로 보임, 아직 고유한 단점도 있지만 여러 대가들이 본질을 잘 짚어냈다고 생각함, '에이전트 도구를 연결해서, 사용자의 요청으로 프롬프트 해주고, 그냥 돌리며 반복 실행, 그리고 프롬프트 자체도 상황에 따라 동적으로 변함', 이런 식으로 인간적 인터랙션이나 문제해결 방식을 굳이 흉내내지 않아도 오케스트레이션/다단계, 모호한 태스크 대체나 자동화에 충분히 유용함, 예전엔 모호성을 직접 코드로 구현해야 했는데 이제 사라질 수도 있음, 실운영 환경에선 dry run 없이 실행시키는 것에 대한 우려도 있지만 도구, 서비스 자체가 진화하리라 생각함, 100개가 넘는 유사 서비스들이 일관된 인터페이스로 외부 세계(e.g. SMS, 메일, 날씨, 소셜 등)와 연결되면 지금보다 훨씬 더 강력한 어시스턴트 또는 그 이상이 나올 것으로 기대함

    • 캘린더, 날씨 등 여러 서비스에 에이전트를 연결해 게임 인터페이스를 만든 흥미로운 토이 프로젝트가 있음, 링크
    • 모든 사용 도구에 대해 추상화가 통일되면 기존의 어시스턴트보다 훨씬 뛰어나질 수 있지만, 그만큼 어마어마한 장애, 오류 가능성도 감수해야 하는 현실임, 신뢰성 엔지니어링, 품질보증, 권한 관리, 보안, 개인정보 보호 같은 이슈가 갈수록 더 중요해질 전망임, 애플이 Siri의 한계를 뛰어넘는 최신 음성 어시스턴트를 내놓지 않는 이유도 바로 이 리스크 관리 때문일 수도 있다고 추측함

  • 코드 읽기가 항상 작성만큼 중요했지만 이제 점점 더 중요해지는 현실임, 내 악몽임, 코드 작성은 때로 즐거움이 있는데, 코드 읽기는 언제나 노동임

    • 그래도 '고치는 재미'가 계속 남아있거나 오히려 늘어날 수 있음

  • 에이전트를 쓰는 사람이 실제로 "프로그래밍" 즉, 문제 해결 방식 고민과 코드로 표현하는 즐거움 자체를 좋아하는 사람이 얼마나 될지 궁금함, 요즘 많은 에이전트 작업을 보면 그 과정 자체가 사라지고 오히려 자연어로 요구사항만 설명한 다음 LLM이 버그를 만들지 않기만 바라게 되는 구조임

    • 나는 코딩 자체를 즐기는 타입이고, LLM이 내가 재미있을 법한 파서를 한 번에 만들어내면 오히려 허탈함도 들었음, 그래도 시간 잡아먹는 파서 작성 대신 더 큰 목표에 집중할 수 있게 됨, 원하는 타입/함수 시그니처만 짜두고 LLM이 세부 구현을 채워주면 바로 다음 단계 진행이 가능해진 점이 인상적임, 예전에는 "고치면 좋겠지만 너무 귀찮음" 수준의 전체 수정도 큰 부담이었는데, 이제는 코드 다듬기, 테스트 생성, README 싱크, 리팩토링 아이디어까지 다 LLM이 도와줘서 오히려 프로젝트 완성도와 야망이 높아짐, 마음가짐만 잘 바꾸면 소프트웨어를 즐기는 빌더들에겐 천국이라고 볼 수 있음
    • 역으로 나는 코드 작성이 수천 번 반복되었던 문제에 대해서는 별로 내 손으로 구현하고 싶지 않음, 그럴 땐 딕셔너리를 쓰지 해시테이블을 새로 만들진 않음, 만약 "이 언어 컴파일러를 만들어줘"라고 하거나 "DFS로 풀어봐"라고 해서 완벽하게 결과가 온다면 오히려 프로그래밍 재미가 줄어들지 않을 것임, 자연어로 컴퓨팅 프로세스를 기술하는 건 복잡한 수준에선 부정확하거나 모순을 초래하기 쉬운 한계는 있음, 그래도 어느 쪽이든 LLM을 아무 생각 없이 사용하는 건 누구도 권장하지 않고 있고, 결국 결과에 대한 책임은 내가 가져가야 함
    • 자연어가 프로그래밍에 적합하지 않다는 근거로 EWD667 문서를 참고함, 실제로 LLM은 stackoverflow 스타일 질문-답변엔 쓸모 있는데, 앞으로 SO의 데이터가 줄어들면 그조차 한계가 생길 수 있다고 봄
    • 나로서는 동의하지 않음, LLM이 하는 일은 대부분 반복적이고 지루한 구현 작업이 많음, 나는 여전히 프로젝트 아키텍처, LLM에게도 어려운 창의적/난이도 높은 부분 직접 설계 등 재미있는 부분은 놓치지 않음, 앞으로 1년 뒤엔 또 다른 상황일 수 있지만 당분간은 진짜 고민하는 부분에만 집중할 수 있어서 만족임
    • 글쓴이 본인임, 나는 프로그래밍도, 그리고 에이전트도 좋아함

  • 코딩할 때 AI를 즐겨 사용하는 분야가 몇 가지 있음 (정말로 내가 쓴 내용임!):

    • CSS: 아무 웹사이트에서든 CSS 작업이 싫었는데, AI는 복잡한 CSS 트릭까지 전부 기억하고 있어서 작업 시간이 단축됨, 예를 들어 복잡한 워드프레스에서 특정 div 중앙 정렬하는 것도 몇 번 시행착오 끝에 금방 가능
    • 단위 테스트: AI가 내장 코드 데이터가 오래되지 않았을 때엔 테스트 생성도 재미있는 경험임
    • 커밋 요약: 첫 초안까지는 충분히 쓸만함
    • 아주 작은 1학년 수준의 과제도 빠르게 처리 가능
    • 흥미롭게도 내 입장에서는 AI가 CSS를 별로 잘 못 쓰는 듯해서 무용하게 느낀 적이 있음, 하지만 좋아하지 않는 작업을 대신해 준다는 점에 충분히 공감함, 내 경우엔 티켓 설명서 작성이 그 예시인데, AI가 나보다 훨씬 잘 처리해줌
    • 오해였다면 미안하지만 혹시 최근 CSS 트렌드에 익숙하지 않다면 요즘 CSS는 예전보다 훨씬 덜 복잡하고 관리가 쉬워졌으니, 몇 시간 투자해 최신 CSS를 알아보는 것도 추천함, 그럼에도 나 역시 스타일링에 AI를 많이 씀

  • "자산"과 "부채"에 대한 부분이 흥미로웠지만 동의하진 않음, 많은 프로그램은 소수 사용자만을 위해 시작됐다가 어느새 대형 프로젝트가 된 경우도 흔함, 과거에는 일회성으로 대충 작성한 과학용 코드가 어느 순간 본의 아니게 오랜 기간/넓은 범위로 확장되는 사례를 너무 자주 경험함, 그래서 내 코드는 훨씬 길게 쓰이고 더 넓은 범위까지 염두에 두면서 심지어 내 자신과 다른 사람에 대한 배려로 작성함, 동료가 만든 개인용 사이드 프로젝트를 매니저가 부서 프로젝트로 승격시킨 경험이 있다면 이 문제 공감할 것임

    • 그래도 "대안이 뭘까?"란 의문이 남음, 사람들은 무엇이 널리 채택될지 예측을 잘 못함, 오히려 공들인 프로젝트가 아무 데도 안 쓰이는 쪽이 흔하고, 허술하지만 빠르게 만든 프로젝트가 성공하는 쪽에 진화 압력이 걸려 있는 현실임, 이 부분은 "worse is better" 고전 글을 들 수 있음 (링크)

  • LLM을 코드 작성/설계가 아니라 코드 리뷰에 쓰는 게 진정한 킬러 특성이 될 수 있다고 봄, 지금 code review 자체가 많은 부분에서 깨져 있고, 앞으로는 보안, 정의되지 않은 행동, 기능오용, 컴파일러 경보 이슈의 이중 확인 등에서 LLM 활용도가 커질 것이라 기대함, 개인적으로는 LLM을 검색엔진 스타일로 오류 진단이나 디버깅에 주로 쓰는데, 정답률이 50%쯤 되고 이는 충분히 만족스러움

    • ChatGPT는 이미 충분히 웹에서 많이 논의된 문제라면 디버깅에 상당히 훌륭함, stack overflow의 지식을 요약, 통합해주기 때문에 개별 사례를 찾아보는 시간 절약이 큼, 다만 LLM의 답변이 허구(환각)이 섞여서 다소 노이즈가 남아있고, 코드 전체를 리뷰한다면 오류 유형이나 문제가 되는 함수/호출을 잘 찾아낼 수 있지만, 반대로 오탐지도 많을 수밖에 없음, 실제로 LLM을 코드 자동 리뷰에 적절히 활용하는지 궁금함
    • "이 코드를 리뷰해달라"는 요청을 반복해서 하다 보면 chatbot이 X를 Y로 바꿨다가, 조금 뒤에는 다시 Y를 X로 바꾸기도 하는 현상이 발생함, 코드 리뷰에는 어느 정도 효과가 있지만, 결과를 보고 어떤 건 수용, 어떤 건 거부할지 직접 판단해야 함, 충분히 분별력이 있는 사람에게는 정말로 생산성 높게 후보 변경사항을 제시해주는 역할임
    • 왜 이런 주제가 더 크게 논의되지 않는지 궁금함, 내 주변 개발자들은 기술에 대한 관심 정도가 다양함, 주로 경력이 짧을수록 더 적극적으로 사용하고, 시니어일수록 관심이 적음, 코드 리뷰/검증에 AI 쓰는 얘기는 거의 듣지 못했으며, 아마도 커밋 시점에 자동으로 해주는 기능이 필요하지 않을까 생각함
    • code review/design보다 code review 특화 LLM은 이미 Github Copilot에서 리뷰어 모드로 제공 중임, 아직 최고 수준은 아니지만 루프에 두고 쓰기엔 충분히 쓸만한 퀄리티임
    • 동의함, 우리는 sourcery.ai에서 이런 것 작업 중임
답변달기