코덱스 Co², AI 시대 페어 프로그래밍 방식 제안

다시 가져온 "의자"

예전에는 두 프로그래머가 같은 문제를 함께 해결하고 싶을 때, 의자를 같은 화면 앞으로 옮기면 됐다.

한 사람은 키보드 조작을 맡고, 다른 한 사람은 사고 과정을 살핀다. 의견이 갈리면 멈춰 서서 토론한다. 화면 위의 코드는 두 사람이 함께 만들어낸 성과물이고, 문제의 맥락 또한 이 문답 속에서 점차 정렬되어 간다.

이런 협업 방식을 "페어 프로그래밍(pair programming)"이라고 부른다.

지금은 AI가 어느새 우리 화면 반대편에 앉은 새 파트너가 되었다.

우리는 AI에게 요구 사항을 설명하고, 코드를 읽게 하고, 문제를 분석하게 하며, 수정을 시도하게 한다. 여러 차례의 대화를 거치면서 그 세션 안에는 전체 작업의 배경이 점차 쌓인다. 왜 이 기능을 만들어야 하는지, 어떤 방안이 이미 부정되었는지, 어떤 제약을 반드시 지켜야 하는지 등이 그것이다.

그런데 이후에 다른 동료가 참여하고 싶어 하거나 당신의 작업을 인계받으려 할 때, 일은 비효율적으로 변하기 시작한다.

우리는 대화 스크린샷을 보내고, 코드를 복사해 보내고, 동료의 의견을 다시 AI에게 전달해야 한다. 상대가 한마디 더 묻고 싶어 하면, 우리가 질문을 넣고 답변을 다시 가져올 때까지 기다려야 한다.

AI는 이미 점점 더 많은 실행 작업에 참여할 수 있게 되었지만, 사람과 사람 사이의 협업은 여전히 이런 왕복 전달에 발목이 잡힐 수 있다.

개인의 생산성은 확대되었지만, 팀이 파악하는 정보는 그에 못지않게 원활하게 한데 모이지 못할 수 있다.

이제는 우리가 그 "의자"를 다시 가져와야 할 때다.

Codex Co²가 해결하려는 것은 무엇인가?

같은 세션을 기반으로 한 협업이 바로 내가 Codex Co²로 해결하려는 문제다.

Codex Co²의 정식 명칭은 Codex Conversation Collaboration(Codex 세션 협업)이다. 이름은 다소 길지만 하려는 일은 아주 단순하다. 여러 사람이 같은 Codex 세션에 참여해 함께 작업을 진전시키는 것이다.

공유자는 계속 공식 Codex Desktop에서 작업할 수 있으며, Co²에서 기존 세션 하나를 선택해 초대장을 생성하여 협업자에게 보내기만 하면 된다. 협업자는 브라우저로 초대장을 열어 참여를 신청하고, 승인을 받으면 공유된 컨텍스트를 읽고, 같은 Agent에게 요구 사항을 보충하고, 그 응답을 따라갈 수 있다.

협업자는 Co²를 설치할 필요도 없고, Codex에 별도로 로그인할 필요도 없다. 발송되는 모든 메시지는 공유자가 현재 사용하는 세션의 도구, 권한, 할당량을 그대로 따른다.

협업자 초대하기

구체적인 사례를 하나 살펴보자.

사용자가 다음과 같이 피드백했다고 가정하자. "작업은 이미 처리가 완료되었는데, 페이지의 상태가 계속 바뀌지 않아 새로고침한 뒤에야 복구되었다."

운영 담당자는 FeedbackID를 받은 뒤 먼저 Codex에서 관련 사용자 로그를 분석하여 초기 결론을 얻을 수 있다. 조작 요청은 이미 성공했고, 문제는 페이지 상태 업데이트 단계에 있을 가능성이 있다는 것이다.

이어서 운영 담당자는 Co²를 통해 이 세션을 개발팀에 공유할 수 있다.

개발자가 참여한 뒤에는 기존 분석을 따라 계속 질문할 수 있다. 서버 측에서 상태 변경 알림을 보냈는가? 클라이언트가 수신했는가? 예외가 발생하기 전에 연결 끊김과 재연결을 겪었는가?

로그와 관련 코드를 결합하자 문제는 점차 좁혀진다. 클라이언트가 네트워크 재연결 이후 실시간 구독을 복구하지 못했고, 그 때문에 이후의 상태 변경이 페이지에 도달하지 못했다. 그리고 수동 새로고침은 데이터를 다시 가져오므로 표시가 다시 정상으로 돌아온 것이다.

이 지점에서야 모호했던 하나의 사용자 피드백이 설명 가능하고 검증 가능한 기술적 근본 원인을 갖게 된다.

또 다른 협업자 초대하기

하지만 근본 원인을 찾았다고 해서 문제 해결의 마지막 단계에 도달한 것은 아니다.

개발자는 계속해서 Agent에게 수정 방안을 정리하게 할 수 있다. 재연결 후 구독 복구를 보완하고, 연결 복구 시 상태를 한 번 교정하며, 동시에 영향을 받는 시나리오, 변경 범위, 검증 비용, 그리고 임시 처리 방식을 정리한 뒤, 제품 담당자를 이 세션에 초대할 수 있다.

제품 담당자가 보게 되는 것은 사용자가 처음 겪은 어려움, 운영 담당자가 로그에서 얻은 단서, 개발자가 근본 원인을 규명하는 과정, 그리고 서로 다른 처리 방식의 비용과 위험을 포괄한다.

이러한 정보를 바탕으로 제품 담당자는 즉시 수정이 필요한지, 버전을 어떻게 배치할지, 그리고 수정이 배포되기 전에 사용자에게 어떻게 응대할지를 결정할 수 있다.

운영 담당자가 현장을 가져오고, 개발자가 근본 원인까지 추적하고, 제품 담당자가 어떻게 진행할지를 결정한다.

서로 다른 역할의 판단이 같은 세션 안에서 점차 이어진다. 앞사람이 남긴 분석은 뒷사람이 계속 질문하는 출발점이 되어, 결국 하나의 사용자 피드백을 근거 있는 처리 결정으로 밀어붙인다.

흩어진 정보 모으기

Co²가 가져오는 이 작아 보이는 변화는 소프트웨어 개발에서 오래 존재해 온 하나의 사실과 정확히 맞닿아 있다. 하나의 문제를 이해하는 데 필요한 정보는 흔히 서로 다른 사람의 손에 흩어져 있다는 것이다.

제품 담당 동료는 언뜻 이상해 보이는 어떤 규칙 뒤에 어떤 비즈니스 현실이 있는지 알고 있고, 테스트 담당 동료는 간헐적으로 발생하는 문제를 재현하려면 어떤 단계를 거쳐야 하는지 알고 있으며, 시스템에 익숙한 엔지니어는 겉보기에 무해한 변경 하나가 어떤 역사적 제약을 건드릴 수 있는지 안다.

이런 판단은 "기능을 만들어 주세요"라는 한마디만으로는 설명하기 어렵다.

AI가 처리할 수 있는 정보가 아무리 많아도, 가장 관련성 높은 사실을 AI 앞으로 가져다주는 사람은 필요하다. 따라서 우리가 AI를 어떻게 더 잘 활용할지를 논의할 때 더 고려할 만한 것은 바로 실제로 문제를 잘 아는 사람들이 현재의 작업에 더 쉽게 참여할 수 있게 하는 방법이다.

Co²가 제공하고자 시도하는 것이 바로 그러한 진입점이다.

나는 이것이 페어 개발에 쓰여 또 다른 엔지니어가 방안 논의에 직접 참여하고, 원격 장애 대응에 쓰여 현장을 아는 사람이 재현 조건을 보충하며, 요구 사항 명확화에 쓰여 비즈니스 판단이 제때 구현 과정에 들어올 수 있기를 바란다.

더 많은 가능성

물론 Co²는 현재 여전히 초기 단계의 독립 실험 프로젝트다.

프로젝트 코드는 이미 Github에 오픈소스로 공개되었고, macOS와 Windows 설치 패키지를 제공하며, Homebrew로 설치해 실행하거나 브라우저에서 바로 실행할 수도 있다.

사용 시에는 다음과 같은 제한점을 이해할 필요가 있다.

공유 세션은 원래의 실행 환경과 할당량을 그대로 따르며, 협업자의 모든 메시지는 실제로는 공유자의 신분으로 발송되는 것이므로 사용 시 권한 제어와 할당량 관리에 주의해야 한다.

공인망 공유는 중계를 거치며 일반 TLS를 사용하고 종단 간 암호화는 없으므로, 신뢰할 수 있는 협업자만 초대하거나 "사내망에서만 접근 가능" 스위치를 켜는 것을 잊지 말아야 한다;

Co²를 종료하면 공유된 초대 링크는 접근 불가능하게 되는데, Co²는 설계상 현재의 협업을 위한 것이지 장기적인 진입점으로 쓰이는 것이 아니기 때문이다.

여러분도 동료와 함께 Codex를 사용하고 있다면, 한번 시험해 보고 겪은 경험상의 문제를 Issue를 통해 나에게 피드백하여 함께 Co²의 공동 창작에 참여해 주길 바란다.

맺음말

바라건대, 앞으로 우리가 AI로 업무 효율을 높이는 동시에, 곁에 있는 동료에게도 계속 자리를 하나 남겨줄 수 있기를.

요구를 이해하는 사람, 코드에 익숙한 사람, 문제를 발견한 사람이 각자 가진 부분을 가져와 공동의 협업을 완성하게 하는 것, 그것이 팀이 존재하는 의미일 것이다.

예전 화면 앞에 있던 그 의자는, 조금 더 가까이 당겨 올 만하다.

Github 주소: github.com/SpaceCoder-…

星际码仔

47

글

205k

조회

660

팔로워