▲

에이전트 기반 AI는 왜 좋은 페어 프로그래머가 아닌가

 (justin.searls.co)
12P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • LLM 에이전트는 인간보다 훨씬 빠르게 코드를 작성하기 때문에 페어 프로그래밍 경험이 오히려 저하될 수 있음
  • 너무 빠른 자동화로 인해 사용자가 따라가지 못하고, 작업 맥락을 놓치는 문제가 빈번하게 발생함
  • 이러한 현상은 경험 많은 개발자와의 페어링에서 느꼈던 소외감과 유사하며, 결국 품질 관리와 소통이 약화되는 결과로 이어짐
  • 해결책으로는 비동기적 코드 리뷰 위주 협업과, AI와의 페어링 속도를 줄여 품질 관리와 소통 중심의 워크플로우로 전환하는 방식을 제안
  • AI 에이전트도 인간과 유사하게 “멈추고 대화하며, 자신감보다 의심과 검증에 집중”하는 설계가 필요함

LLM 에이전트와 페어 프로그래밍의 문제점

  • AI 에이전트(예: Copilot Agent)는 인간의 사고 속도보다 훨씬 빠르게 코드를 작성함
  • 이로 인해 사용자는 따라가기도 전에 코드가 쏟아지며, 맥락을 놓치고 작업 몰입도가 저하되는 현상이 발생함
  • 문제 상황에서 에이전트가 도움을 요청하면 이미 사용자는 상황 파악이 안 된 채로 “뒷수습” 역할을 맡게 되고, 결과적으로 잘못된 방향으로 진행된 코드를 정리하는 부담이 커짐
  • 결국 품질 관리, 소통, 올바른 방향성 유지가 어려워짐
  • 최고의 AI 에이전트와 페어를 하는 경험은 과거 탁월한 인간 프로그래머와의 페어링에서 느꼈던 부정적 기억을 떠올리게 함
    • 페어 파트너가 과도한 속도로 소리 없이 키보드를 두드림으로써, 코드를 따라잡을 수 없게 만듦
    • 정신적 에너지를 모두 소진시킨 후 점차 작업에서 멀어지게 됨
    • 페어가 막히는 순간 도움을 요청하지만 상황 파악이 어려운 당황스러운 경험이 발생함
    • 작업 진행 과정에서 목표와 다른 방향의 구현물이 생성되고, 마감기한 내 수정해야 하는 부담이 전가됨

The path forward: 실질적 해결책

  • 1. 비동기적 협업

    • 인간과의 페어 프로그래밍에서 한 명이 주도적으로 진행할 때처럼, AI가 코드를 독립적으로 작성하고 Pull Request로 리뷰하는 형태가 더 효과적임
    • GitHub Coding Agent 등 비동기 워크플로우를 활용해, 사용자가 리뷰와 품질 관리에 집중할 수 있음

  • 2. 속도를 낮춘 “턴 기반” 페어링

    • AI의 “Agent Mode” 대신, Edit/Ask Mode와 같은 한 번에 한 단계씩 진행하는 방식을 사용
    • Ping-pong 페어링(한 쪽이 제안, 한 쪽이 승인)처럼, AI가 제안한 변경을 사용자가 직접 수락/검토하며 속도를 조절
    • 문제 해결/디버깅에만 AI를 쓰지 않고, 일관된 워크플로우로 활용하는 것이 바람직함

에이전트 페어링을 더 인간적으로 만드는 아이디어

  • 사용자가 코드 출력 속도(라인/분, 단어/분) 를 직접 조절 가능하게 설정
  • 에이전트를 임시 중지해, 사용자가 질문하거나 방향성에 반박할 수 있는 기능
  • 기존 챗봇 UI를 넘어, 작업 진행 상황과 연동된 UI 프리미티브(예: 현재 세션을 특정 GitHub 이슈에 고정, 내장 To-do 리스트 등) 제공
  • 에이전트가 더 자주 멈추고 대화하도록 설계: “왜 이걸 하는지” 확인, 조언 요청, 방향성 점검 등 인간과의 협업 분위기 조성
  • 고급 음성 채팅 지원을 도입해, 사용자가 눈은 코드에 두고 음성으로 AI와 소통할 수 있도록 함
  • 이러한 기능이 적용된다면, 현재의 빠르고 일방적인 에이전트 페어링 대신, 진정한 인간-에이전트 공동 협력 경험이 가능해질 것

결론

  • 현재 시점에서 AI 에이전트 기반 페어 프로그래밍의 한계와 가능성을 동시에 목격하고 있음
  • AI 에이전트 페어 프로그래밍은 속도만 빠른 것보다, 인간과의 협업처럼 소통·품질·검증 중심으로 설계할 때 더 큰 효과를 거둘 수 있음
  • “천천히, 대화하며, 검증하고, 상황을 공유하는” 방식이 AI 페어링의 질을 높임
▲
panarch 2일전  [-]
  1. 비동기적 협업
    인간과의 페어 프로그래밍에서 한 명이 주도적으로 진행할 때처럼, AI가 코드를 독립적으로 작성하고 Pull Request로 리뷰하는 형태가 더 효과적임

Codex를 며칠간 사용하고 있는데 에이전트 형태보다는 여기에 공감합니다. 여러 프로젝트 작업을 동시에 돌릴 수 있게 되면서, 정말 주니어 개발자 여럿과 함께 일하는 경험을 하고 있습니다.
비동기적으로 AI를 사용할 수 있게 되니 여러 프로젝트, 그리고 한 프로젝트에서도 여러 작업을 동시에 시킬 수 있게 되면서 생산성이 산술적으로 3-10배 이상 나오는게 정말로 체감이 됩니다.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 내가 AI를 이런 방식으로 사용하다가 금방 그만둔 이유를 정확히 설명한 글이라는 느낌. 내가 뭔가를 만들고 싶을 때 이미 대충 <i>방법</i>을 정하고 있지만, AI가 실제로 하는 방식이 내가 원하는 것과 자주 다르기 때문. 그런데 AI가 2,000줄의 코드를 한 번에 생성하면 오히려 일이 더 많아지는 현상. "우선 이 모든 주석을 지워줘, 간단한 코드에 불필요한 설명이 두 배야. X를 이렇게 추상화하지 말고, 나는 이걸 원해..." 처럼 지시해야 하고, 피드백을 주면 또 갑자기 2,000줄이 700줄로 확 달라져서 따라가기가 너무 힘든 문제. 코드베이스가 내가 잘 모르는, 방식도 제각각인 스크립트 투성이가 되는 것도 싫음. 내 스타일과 생각이 비슷한 AI가 필요하지만, 그게 너무 어려운 점. AI와 함께 일하는 건 경험이 없는 누군가와 첫날 함께 일하는 것과 비슷한 느낌. 개인적으로는 도구의 자심감 문제라기보다는 디자인 과정을 더 드러나게 했다는 생각. 이상적으로는 "이런 접근을 생각 중이고, 이런 함수나 클래스, 상태를 이런 방식으로 관리할 예정"이라는 설계서를 먼저 보고, 괜찮으면 그 다음에 구현으로 넘어가는 절차가 필요.

    • 인간 엔지니어와 마찬가지로, 먼저 플래닝 세션이 정말 중요하다는 점을 강조. 코드 작성 전에 먼저 토론하고 흥정하듯 세부사항 정리. 나는 일부러 첫 질문을 최대한 두루뭉술하게 던져서 오히려 예상 못 한 추천이 나오나 살펴보고, 점점 구체적으로 들어가는 방식으로 진행. 충분히 만족하면 LLM이 initialprompt.txt와 TODO.md라는 두 개 문서를 만들도록 요청. initialprompt.txt에는 프로젝트 요약과 TODO.md를 읽으라는 지시, 그리고 각 단계가 완료될 때 체크하라는 명령이 포함됨. 이런 방식 덕분에 LLM이 전체적인 목표와 세부 작업을 모두 파악하고, 나중에 컨텍스트 제한 때문에 대화가 끊겨 다시 시작할 때 빠르게 업무를 리마인드해줄 수 있음.

    • 내 경험을 똑같이 요약해줬다는 느낌. AI가 작성한 코드에 대해 아예 결과물만 중요하고 해당 분야에 대해 배경지식이 거의 없을 때만 성공적으로 끝냈던 경험. 내가 어떤 결과가 ‘좋은 것’인지에 대해 강한 의견이 있을 때는 결국 좌절하고 프로젝트를 포기하기 일쑤. roo code의 architect 기능으로 먼저 접근 방식을 정리한 뒤, code mode로 실제 코드를 구현할 때는 기쁨과 좌절이 반반이었음. 중요한 교훈은 항상 새 작업을 시작할 것, 장기 대화 이어가지 말 것. 나는 원래 문제를 잘게 나누고 결과 확인을 하는 스타일인데, LLM에는 문제 공간 전체를 한 번에 던져서 실패한 경향. 나만의 방법을 찾기 위해 여러 번 시도해 봤고, 오늘도 30분 만에 앱 기능을 추가함. 직접 구현하면 정말 며칠 걸릴 일이었음. 그리고 실제로 30분만 일지에 기록한 이유는 내가 원하는 것을 확실히 알고 있었고, 과정에는 관심이 없었기 때문. 이런 경험 덕분에 언젠가 다른 사람이 써야 할 코드를 AI에게 맡기는 것은 모든 이유 때문에 불가능하다는 결론.

    • 결국 너무 지치고, 결과도 불만족스러운 경험뿐. 이런 고민을 가진 사람에게 한 말임. 나 역시 에이전트 코딩에 만족한 경험은 코드 품질에 신경 안 쓰는 단기 스크립트나 진짜 어디에서도 영향 없는 잎사귀 함수일 때뿐.

    • Anthropic의 Claude Code 활용 가이드에서 권장하는 워크플로가 추천할 만함. 요점은 “일단 먼저 코드를 읽게 한 뒤, 변화 계획을 세우도록 하고, 마지막에 실행하게 하라”는 것. AI가 코드를 한 줄도 작성하기 전에 계획서를 보고 수정할 수 있음. 에이전트를 쓸 때 내가 원하는 방식과 다르게 움직인다면, 예를 들어 설계도 없이 바로 코딩을 한다면, 그냥 "다르게 해줘"라고 요구하면 됨.

    • 2,000줄짜리 코드를 한 번에 생성한다는 얘기, 혹시 SNES에 Skyrim 전체를 시키는 프롬프트 입력하는 건 아닐지. 점심 먹고 와서 실행해보니 PS1 스타일로 근접 공격만 있는 Fallout을 만들어줬다고 화내는 상황 연상.

  • HN의 첫 페이지에 글이 올라가면 항상 댓글을 보고 내가 얼마나 멍청한지, 사람들이 내 체면을 끌어내리는 공격성 발언을 할까 두려워짐. 그런데 어떤 때는 내가 제목을 정말 잘 잡으면, 아무도 내 글은 안 보고 각자 자기 얘기만 하다가, 나는 그런 비난을 피해감.

    • 유쾌하면서도 현실적인 이야기라고 생각. 다른 글에서도 비슷한 패턴을 자주 보게 됨. 어쨌든 이런 토론 자체가 좋아서 재미를 느낌.

    • 글이 좋았음. 일종의 “AI와 페어 프로그래밍을 즐기는 방법” 같은 느낌. 유익했기 때문에 감사함.

  • LLM 에이전트를 처음 썼을 때, 나는 양방향 소통, 진짜 협력적 페어 프로그래밍을 기대함. 하지만 실제로는 전적으로 자기만의 방식대로 모든 걸 해결하려는 파트너를 만남. 내가 조금 고치려고 했더니 AI가 쓴 코드 컨텍스트가 깨져서 오히려 더 불편한 경험. 내가 원하는 건 내가 조금, AI가 조금, 서로 교대로 작업하는 진짜 협동 작업.

    • 최근에 다시 시도해봤는지 질문. 내 경험은 다르다는 얘기. 나는 AI가 생성한 코드를 수정한 뒤 파일을 다시 읽으라고 시킴. 그러면 보통 “파일에 변경사항이 있네요”식으로 반응. AI가 코드 변경하면 내가 테스트 돌려보고 피드백 주면 반복적으로 개선. Zed와 Claude Sonnet에서 이런 방식이 잘 통함.

    • 내가 대체로 쓰는 방식은 일단 AI의 제안을 받고, 리팩터링하거나 필요하면 다시 프롬프트로 지시. 이런 접근이 수락률(accept rate)을 인위적으로 높이는 효과가 있는데, 사실 이 통계로 AI 회사들이 "AI가 아주 좋은 코드를 작성한다"는 주장의 근거로 삼을 수 있음. 실제로는 “에휴, 그냥 내가 직접 고쳐야지” 하는 마음으로 넘어간 순간도 많음.

    • 나는 주로 “먼저 논의만 하자. 코드 수정은 하지 마라”라고 붙이면 원하는 식으로 대화가 가능. 충분히 왔다 갔다 얘기한 후 마지막에 “적용해”라고 지시.

    • 원하는 협업 형태를 원한다면 구체적으로 LLM에게 요청하라고 조언. 모든 대화마다 꺼내 쓸 수 있는 프롬프트 문서 몇 개 준비해두면 좋음.

    • 최근에는 맥락 유지가 크게 어렵지 않아 코드 수정에도 문제가 없음. 나는 Ask 모드(명령이 아니라 질의/응답 위주)로만 쓰고, Claude Code에서는 Opus, Cursor에서는 o3 max를 활용. 에이전트 모드는 일부러 피하는데, 원글처럼 시간이 지날수록 내가 얻는 이득이 적기 때문. 탭 완성은 드물게 쓰고, 제안 코드의 80~90%는 내가 수정해서 직접 타이핑. 덕분에 170wpm 속도로 계속 칠 수 있음. Opus와 o3 max의 출력 속도가 제한적이라 읽는 것도 버겁지 않고, 처음엔 너무 빨라서 힘들었지만 금방 적응. 내 개인 평은, 만약 GitHub Copilot이 LLM 체험의 전부라면 그건 모텔 수준 경험에 불과하다는 것.

  • 페어 프로그래밍도 모든 상황에 적합한 건 아님. 오히려 많은 경우 적합하지 않을 수 있음. 다른 데서 언급했지만, LLM의 자동 완성 제안 때문에 집중해서 코딩하는 흐름이 끊겨서, 중간마다 멈춰서 읽고 검토하고 수락/거절해야 해서 프로그래밍 플로우가 완전히 깨지는 문제. 내 워크플로우에 AI 자동완성 끼워 넣으려다 정말 힘들었음.

    • 나도 같은 생각. 해결책은 AI 없는 전용 IDE와 Cursor/VS Code를 둘 다 쓰면서 서로 번갈아 사용하는 것. 진정한 몰입/딥워크는 챗봇과 대화하면서는 불가능.

    • 최근에 새 노트북을 사고 IDE를 새로 설치했는데, 몇 시간 코딩하는 동안 뭔가 ‘이상하다’고 느낌. 알고 보니 GitHub Copilot 로그인을 깜빡해서 AI 없이 일하고 있었던 것. 코드 자동완성 기다릴 필요 없이 훨씬 더 적극적으로 코드를 작성하고 있다는 느낌. Cursor는 특히 사용 흐름을 계속 방해해서 ‘다음 커서 위치까지 예측’ 이런 기능도 정말 불필요함. 앞으로는 Copilot은 꺼두고, boilerplate나 반복 작업에는 aider 같은 에이전트 스타일 도구만 쓸 계획.

    • AI 자동완성이나 코드 제안 기능은 특히 타입 강한 언어를 쓰면 최악. 대부분 80%는 맞지만 IDE 자동완성은 거의 100% 정확. AI 에이전트 방식은 더 좋은 게 1) 계속 생각 흐름을 방해하지 않고, 2) 직접 컴파일, 테스트를 돌려서 틀린 걸 수정한 뒤 제대로 된 코드를 돌려주기 때문.

    • 나는 오히려 자동완성을 너무 좋아함. Go 언어 써야 해서 boilerplate가 워낙 많은데, 라이브러리 추가 같은 걸로는 해결 안 되는 문제라서 그냥 직접 타이핑이 더 빠를 때 많음. 귀찮은 코드 작성하기엔 AI 보다는 손이 빠르기에, 자동완성은 진짜 도움이 됨. 한 줄 제안은 순식간에 읽어내고, 긴 제안도 내가 쓰려던 내용과 비슷하면 그냥 넘어갈 수 있음. 반복되다 보면 AI가 뭘 예측할지 감이 잡힘. 엄청난 생산성 향상은 아니지만, 로그 메시지나 for 루프 등 귀찮은 건 확실히 빨라짐. 내가 읽는 속도가 직접 타이핑보다 훨씬 빠른 경우에만 도움이라는 생각.

    • 페어 프로그래밍이 항상 맞는 건 아니지만, 대다수 상황에서는 유용하게 쓸 수 있다는 견해. 잘 안 맞는 때는 보통 한 명 또는 두 명 모두 이 과정에 적극적으로 임하지 않거나, 한쪽이 “이런 건 안 된다”며 거부하거나, 페어 프로그래밍 원칙을 너무 엄격하게 지키려 할 때임.

  • 입장이 조금 복잡함. 최소 한 달간 회사에서 여러 LLM 툴을 모두 적극적으로 써보면서 최대한 효과적으로 활용하는 법을 배우는 중임. 코드 라인 수 기준으로는 확실히 생산성이 높아짐. 하지만 전체적으로 더 생산적이라고는 못 하겠음. 완료된 각 작업마다 설명 안 되는 이상한 동작을 하거나, 때로는 관련 없는 부분까지 손대서 오히려 되돌려야 할 때가 많음. AI가 자동 생성한 테스트는 처음엔 그럴듯하지만, 커버리지 등 다른 지표로 보면 부족한 점이 명확. 원하는 결과에 도달하려면 오히려 여러 단계를 거꾸로 되돌아가야 하는 느낌. 이득이나 학습 그런 것도 아닌 완전히 후퇴하는 듯한 경험. 예전에 한 번은 5만 줄의 불필요한 import 코드가 원래 수정 범위가 아닌 모듈에 몰래 추가된 적도 있었음. 또 어떤 땐 규칙을 명확히 설정해줬는데, 전체 객체지향 구조를 망가뜨리고 if/else만 잔뜩 써서 구현하는 사건도. 문제는 상황 따라 결과가 너무 달라서, 심지어 같은 작업이라도 어떤 땐 완벽하지만 어떤 땐 전체를 박살냄. 작업을 어떻게 시켜야 할지, 어떤 식으로 안내해야 할지 여러 방법을 써봤지만, 비슷한 작업이라도 행동이 너무 달라서 항상 변경 사항을 검수해야 하는 고통. 코드가 거의 맞더라도 특정 부분만 고쳐달라 하면 오히려 전체 작업이 산으로 감. 내 경험상 소규모 툴 작성 수준에서는 효과적이지만, 중~대형 코드베이스에선 일관된 결과를 기대하기 어려움.

  • LLM 에이전트는 말이 너무 많고 항상 자기 방식이 맞다고 생각하는 느낌. 간결하지 못하고, 한 줄이면 끝날 일도 엄청 길게 설명함. 사소한 변경에도 주석을 장문으로 달아버림. 나를 가르치려 들고, 지나치게 과하게 나오는 스타일.

    • 사람들이 싫어하는 일부 행동("너무 긴 출력, 과도한 주석 등")은 LLM이 다른 면에서 효율을 높이려고 설계된 부작용일 수 있음. 긴 출력은 게으르지 않은 코드, 성능 벤치마크 점수가 높은 경향과 연결. 주석 남발도 로컬 컨텍스트를 강화해 다음 코드 품질 향상, 에러 감소와 관련.

    • 어제 sonnet 4를 써봤는데, 단 한 개의 설정값을 바꾸려는 작업에 15분을 써서 계속 테스트하고 리팩터만 반복. 결국 쓸데없이 40개의 파일을 변경. 없는 디버거를 자꾸 실행하려 하고, 인증 필요한 웹페이지를 계속 열려고도 함. 정말 완벽과는 거리가 멀다는 걸 느낌.

  • 내 경험상 문제는 빠르기보다는 오히려 너무 느리다는 것. 속도가 미묘하게 애매해서 더 나쁨. 더 빨랐다면 코드를 실시간으로 따라가며 작업할 수 있었을 것. 더 느리면 그 시간에 다른 일 하다가 오면 되는데, 현실은 50초~수분 단위로 작업이 끝나서 다른 일에 집중 못 함. 오히려 더 작은 단위로 빠르게 반복하는 게 좋다고 생각. 궁극적으로는 인간 리뷰 수준의 자율성, 예를 들면 머지 리퀘스트(PR) 검토하듯이 독립적인 작업이 더 나음. 지금의 루프(작업 주고, 1~3분 대기, 결과 보고, 피드백 주고 반복)는 개인적으로 최악의 케이스.

    • 이 얘기가 오트밀의 “느린 인터넷 vs 아예 없는 인터넷” 만화 생각나게 함.

    • 집중 흩어지면 데스크에 30L 어항을 두라는 조언. 멍때리기엔 최고라는 재치 있는 팁.

  • 개발자로서 나는 AI를 거의 안 쓰고, 가끔 비프로젝트 질문용으로 채팅 챗봇을 쓸 뿐임. 혹시 클라이언트 프로젝트에도 AI를 쓰는지, 아니면 사적인(pet) 프로젝트에만 쓰는지 궁금. 클라이언트 용도라면 코드가 AI에 전달된다는 사실을 계약서에 포함시키고 있는지 묻고 싶음. 대부분의 클라이언트는 NDA 형태로 외부공개 금지 계약을 하는데, 어떤 클라이언트는 AI 사용도 금지 조항을 뒀던 적 있음. AI 코딩 도구를 예외로 인정하는 클라이언트를 만난 적 있는지 궁금.

    • 나는 거의 사내에서만 사용, 그것도 회사의 명확한 AI 사용 지침이 있어서임. 실제로 체감상 별로 시간을 아껴주지 않아서 내 개인 작업엔 돈 주고 쓸 일 없음. 개인 프로젝트에서는 결과보다는 직접 만드는 재미가 더 중요해서, 프롬프트 작업보단 직접 만드는 게 즐거움.

    • 클라이언트 쪽에서 AI 사용을 적극적으로 주문하는 경우도 있음. 더 좋은 품질, 더 빠른 개발을 기대(결국 비용 절감 목적)이지만, 현실은 그 기대와 다를 때가 많음(그래도 그건 별개의 얘기).

    • OpenAI/Anthropic에게는 웹 검색창에 그냥 붙여 넣을 수 있을 정도로 공개 가능한 코드만 공유.

    • 나는 공유하지 않음. 내부 프로젝트 포함이며 외부에 코드 공유는 비용을 받고서만 가능. 개인 정보 처리도 하다 보니 미국 기업에 코드가 노출된다면 법적 리스크가 너무 큼.

  • 드디어 누군가가 딱 집어서 얘기한 부분. AI가 설계에 대해 과도한 자신감, 상세 구현은 협의 없이 임의로 진행하는 스타일. 모킹 API도 구조를 지키지 않게 만드는 경우가 많아 재작업이 필수. LLM의 행동이 좀 더 협업, 디테일이 부족하면 즉시 물어보는 스타일이었으면 함. 최초 프롬프트에 모든 정보를 줄 수 없고, 추가 프롬프트는 처음 설계의 맥락과 사고 흐름을 깨트림. 내가 잘못 쓰고 있는 건지, 더 나은 방법을 알고 싶음. LLM이 피드백을 점진적으로 받고 반영하는 방향으로 개선되었으면 좋겠음. 문맥 추가/업데이트 자체가 어려운 문제인 건지도 궁금하지만, 계속 학습하고 싶다는 의지.

    • 요즘 대부분 테크 스택에서 “설계/계획” 세션을 지원해서, 먼저 이걸 써보면 개선 효과가 있을 것. 내가 잘 활용하는 워크플로는, 큰 모델이든 작은 모델이든 “@file, @docs, @examples 기준으로 @path에 _ 작업을 @module_requirements.md 참조해 진행하고 싶음 – 실제 구현 전에 필요한 내용을 모두 논의하자”는 대화부터 시작. 앞뒤로 왔다 갔다 논의해서 모두 합의되면 .md 파일 등으로 저장해 두거나, 바로 “이제 진행해줘”로 넘길 수 있음. .rules나 .md 파일, IDE 스니펫 등으로 워크플로를 등록해두면 새 작업마다 반복적으로 활용 가능. 최신 LLM은 훨씬 많은 문맥을 필요로 하니, 코드베이스별로(프로젝트마다) 다른 흐름을 시도해봐야 결과도 다르다는 걸 명심해야.

    • 정보가 많아질수록 AI가 헷갈려하는 느낌도 있음. 아마 극복할 방안이 있을 듯. 아주 작은 정보 조각만 뽑아내는 데는 능하지만, 업계 전체가 챗봇 모델에만 집중하는 분위기는 아쉬움. 만약 우리가 키보드나 마우스, GUI, 터치 스크린을 계속 만들지 않았다면 어땠을지 상상해봄.

  • AI를 도우미로 쓰는 협업형 스타일이야말로 AI의 올바른 활용 방식이고, “AI가 코드 직접 작성”에 집중하는 유행은 오히려 소프트웨어 업계가 잘못된 방향으로 흘러가는 예시라고 봄. 나는 AI에게 코드 작성을 절대 맡기지 않음. 내가 짠 코드를 비평하게 만들거나, 대규모 코드 구조 설계 전략 수립에만 활용. 마치 전략 컨설턴트로 쓰는 건데, LLM의 맥락을 잘 구성하면 아주 뛰어난 가이드를 얻을 수 있음. 주체는 항상 내가 되어 이해하고 실천, AI에게는 어디까지나 조언자 이상의 책임을 부여하지 않는 원칙. AI는 “바보 천재(idiot savant)”로 생각하고 신중하게 대해야 함.

답변달기