본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 03. 23:27

에이전트와의 페어 프로그래밍 (Pair Programming)

요약

AI 에이전트와 협업할 때 발생하는 기술적 퇴화 리스크를 방지하기 위한 페어 프로그래밍 전략을 제안합니다. 에이전트를 드라이버로, 인간을 네비게이터로 설정하여 인지적 주도권을 유지하는 것이 핵심입니다.

핵심 포인트

  • 에이전트의 빠른 속도로 인한 기술 퇴화(skill atrophy) 주의
  • 에이전트를 드라이버로, 인간을 네비게이터로 역할 설정
  • 단순 코드 수용이 아닌 시스템 전체의 방향성 검토 필요
  • 인지적 작업을 유지하여 코드에 대한 이해도 확보

페어 프로그래밍 (Pair programming)은 본래의 의미에서 두 사람 사이의 관행이었습니다. 한 명은 드라이버 (driver) 역할을, 다른 한 명은 네비게이터 (navigator) 역할을 맡아 동시에 동일한 문제에 참여하는 방식입니다. 드라이버는 타이핑을 하고, 네비게이터는 지켜보며 질문을 던지고, 실수를 잡아내며, 다음에 올 내용을 생각합니다. 이들은 역할을 교대합니다. 이 훈련의 핵심은 어느 누구도 이탈해서는 안 된다는 것이었습니다. 참여하지 않는 것은 이 방식의 목적을 무너뜨리기 때문입니다.

이 관행은 사람들이 보통 예상하는 것보다 에이전트 (agent)와 함께 일할 때 더 잘 적용되며, 이러한 적용 과정은 실제로 무엇이 걸려 있는지를 드러내 줍니다.

리스크 (The risk)

더 강력한 페어 파트너와 함께 일하는 것은 항상 특정한 리스크를 수반해 왔습니다. 바로 당신이 생각을 멈추게 된다는 점입니다. 상대방은 더 빠르고, 더 자신감이 있으며, 정답을 알고 있을 가능성이 더 높습니다. 저항이 가장 적은 경로는 그들이 말하는 것을 그대로 타이핑하고 자신만의 의견 형성을 멈추는 것입니다. 그 결과는 단기적인 생산성 향상이지만, 장기적인 기술 퇴화 (skill atrophy)로 이어집니다. 당신은 작업을 완료합니다. 하지만 아무것도 배우지 못한 채 작업을 완료하게 되며, 다음에 혼자서 유사한 문제에 직면했을 때 스스로 해결할 수 없다는 사실을 깨닫게 됩니다.

이것은 이미 주니어와 시니어의 페어링 (pairing)에서 알려진 역학 관계였습니다. 에이전트와 함께할 때는 이 비대칭성이 더욱 날카로워집니다. 에이전트는 당신이 함께 일해본 그 어떤 페어 파트너보다 빠릅니다. 또한 확신을 피하지 않는 시스템이라는 특성 덕분에 더 자신감이 넘칩니다. 에이전트는 당신이 묻는 거의 모든 질문에 완전한 답변을 내놓을 것입니다. 따라서 에이전트가 말하는 것을 타이핑하고 넘어가려는 유혹은 그만큼 더 강력해집니다.

리스크는 에이전트가 나쁜 코드를 생성하는 것이 아닙니다. 리스크는 당신이 코드를 이해하지 못한 채 좋은 코드를 수용하게 되는 것이며, 이것이 기본값이 되어 1년 뒤에는 내부 구조를 설명할 수 없는 결과물을 배포하게 되는 것입니다.

페어 프로그래밍 관행은 부분적으로 바로 이러한 역학 관계에 맞서기 위한 방어 기제였습니다. 이 방어 기제는 (에이전트에게도) 그대로 적용됩니다.

드라이버와 네비게이터 (Driver and navigator)

인간 페어의 경우, 드라이버는 타이핑을 하고 네비게이터는 지켜봅니다. 이 역할은 의도적인 것입니다. 네비게이터의 임무는 질문을 던지고, 전체적인 그림을 유지하며, 드라이버가 너무 가까이 있어서 보지 못하는 실수를 잡아내는 것입니다.

에이전트와 함께하는 세션에서 에이전트는 드라이버 (driver)입니다. 코드를 생성하는 주체는 에이전트입니다. 당신은 네비게이터 (navigator)입니다. 이것이 올바른 프레이밍 (framing)인 이유는 인지적 작업 (cognitive work)을 적절한 위치에 배치하기 때문입니다. 즉, 네비게이터는 유휴 상태로 있는 것이 아닙니다. 네비게이터는 방향이 맞는지, 변경 사항이 시스템에 적합한지, 테스트가 실제로 대상 항목을 제대로 테스트하고 있는지에 대해 고민하는 사람입니다.

실패하는 방식은 네비게이터 없는 드라이버가 되는 것입니다. 당신은 에이전트가 앉아야 할 자리에 앉아, 당신이 말하는 대로 타이핑하라고 명령합니다. 이는 당신이 이미 할 줄 아는 일에 대해 스스로 병목 현상 (bottleneck)을 일으키는 반면, 에이전트는 잠재력보다 덜 흥미로운 결과물을 내놓게 만듭니다. 더 나쁜 점은, 네비게이터 자리에 아무도 남지 않게 된다는 것입니다. 자동차는 달리고 있지만 아무도 도로를 주시하지 않는 상태가 됩니다.

더 나은 방식은 에이전트가 운전하게 하는 것입니다. 에이전트가 제안하고, 생성하고, 스케치하게 두는 동안 당신은 네비게이터의 책임을 유지하십시오. 우리는 어디로 가고 있는가? 이 회전이 타당한가? 우리는 여전히 처음에 시작했던 문제를 해결하고 있는가? 에이전트는 이러한 질문을 던지지 않을 것입니다. 이 질문들은 당신의 몫입니다.

'왜'라고 묻기

네비게이터의 가장 가치 있는 습관은 '왜'라고 묻는 것입니다. 왜 이 라이브러리를 사용하는가? 왜 이 함수가 이 파일에 있는가? 왜 테스트가 저것이 아니라 이것을 확인하는가? 이러한 질문들은 적대적인 것이 아닙니다. 이는 네비게이터가 방향 감각을 유지하는 방법입니다.

에이전트와 함께할 때

가장 중요한 단 하나의 습관이자, 가장 자주 생략되는 것: 바로 수락하기 전에 디프 (diff)를 읽는 것입니다.

당연한 소리처럼 들릴 것입니다. 하지만 실제로 에이전트와 협업하는 리듬 속에서는 이를 생략하기가 매우 쉽습니다. 에이전트가 변경 사항을 생성합니다. 당신은 그것을 훑어봅니다. 괜찮아 보입니다. 당신은 수락합니다. 다음 프롬프트가 이미 머릿속에 떠오릅니다. 디프 (diff)는 이제 코드베이스에 반영되었고, 당신은 그것이 실제로 무엇을 했는지 제대로 이해하지 못했습니다.

이런 상호작용을 하루에 열 번으로 곱하면, 당신은 결과물의 상당 부분을 읽지도 않은 채 배포하고 있는 셈입니다. 이러한 퇴보는 처음에는 소리 없이 찾아옵니다. 여기서 발생하는 버그들은 당신이 진단할 수 없는 버그들입니다. 왜냐하면 코드가 어떻게 작동해야 하는지에 대한 모델 (model)이 당신의 머릿속에 없기 때문입니다.

해결책은 지루한 것입니다. 디프 (diff)를 읽으세요. 매번 말입니다. 에이전트를 신뢰할 때조차도요. 에이전트를 신뢰할 때일수록 더욱 그래야 합니다. 만약 디프 (diff)가 읽기에 너무 크다면, 읽지 않은 채 큰 것을 수락할 것이 아니라 더 작은 디프 (diff)를 요청하는 것이 올바른 행동입니다.

읽는 행위는 단순한 검증이 아닙니다. 그것은 세션 중에 멘탈 모델 (mental model)을 구축하는 과정입니다. 이를 생략하는 것은 학습을 포기하는 것과 같습니다. 학습이야말로 이 과정의 핵심 목적입니다.

당신이 결코 포기할 수 없는 역할

에이전트가 당신을 대신해 해줄 수 없는 단 하나의 작업이 있는데, 그것은 바로 원래의 의도 (intent)를 유지하는 것입니다.

당신은 해결해야 할 문제를 가지고 세션을 시작했습니다. 세 번의 대화가 오가고 나면, 대화는 곁길로 샙니다. 에이전트는 리팩터링 (refactor)을 제안하고, 관련된 개선 사항을 제안하며, 인접한 버그를 식별합니다. 각각의 제안은 개별적으로 보면 합리적입니다. 하지만 이들이 모여 당신을 원래 경로에서 10도 정도 벗어나게 만듭니다. 결국 당신이 완성한 PR (Pull Request)은 처음에 시작했던 문제와는 다른 문제를 해결하고 있으며, 원래의 문제는 여전히 남아 있게 됩니다.

네비게이터 (navigator)의 마지막 임무는 목적지를 시야에 계속 두는 것입니다. 에이전트는 국지적인 지형을 최적화할 것입니다. 당신은 지도를 들고 있어야 합니다. 만약 제안들이 목표에서 멀어지고 있다면, 당신은 그것들을 다시 되돌려 놓아야 합니다. 만약 탈선이 원래 작업보다 더 흥미롭다면, 그것을 표류가 아닌 의도적인 결정으로 만들어야 합니다.

이것은 위임하지 않는 역할입니다. 에이전트가 당신의 업무 중 무엇을 대신 처리해 주더라도, 의도를 유지하는 것(holding-of-intent)만큼은 남아 있어야 합니다. 양측 모두 목표를 기억하지 못하는 페어 프로그래밍 (Pair Programming) 세션은 진전 없는 움직임만을 만들어낼 뿐입니다.

날카로움을 유지하기 (Staying sharp)

이러한 관행들은 하나의 단순한 원칙으로 귀결됩니다. 바로 계속 몰입하는 것입니다. 차이점 (diff)을 읽으십시오. 이유를 물으십시오. 목표를 붙드십시오. 이해하지 못하는 작업을 수용하고 있다는 사실을 깨닫는다면 즉시 멈추십시오.

이것들은 인간의 페어 프로그래밍 (Pair Programming)을 가치 있게 만들었던 것과 동일한 관행들입니다. 그것들은 결코 올바른 내용을 타이핑하는 것에 관한 것이 아니었습니다. 그것은 두 개의 정신이 동일한 문제에 집중하며, 어느 쪽도 요령을 피우지 못하게 하는 규율 (discipline)에 관한 것이었습니다. 에이전트와 함께할 때, 당신은 두 정신 중 하나이며, 나머지 하나는 결코 지치지 않을 것입니다. 위험 요소는 당신이 지칠 수 있으며, 자신도 모르게 요령을 피우기 시작할 수 있다는 점입니다.

이에 대한 대비책은 바로 관행입니다. 페어 프로그래밍 (Pair Programming)은 언제나 하나의 규율 (discipline)이었습니다. 옆자리에 에이전트가 앉아 있을 때, 그것은 당신의 역량을 유지해 주는 유일한 규율입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0