오픈소스 프로젝트 메인테이너 3인은 AI 확산으로 코드 작성이 쉬워진 반면 검토와 방향 판단의 부담이 커졌다고 밝혔습니다. CIO 코리아는 2026년 10월 12일 발키(Valkey)와 이스티오(Istio) 등 프로젝트를 이끄는 이들을 인터뷰해 기여와 검토, 커뮤니티의 변화를 전했습니다. 발키 메인테이너 매들린 올슨(Madelyn Olson)은 자체 분석에서 지난해 말부터 올해 초까지 발키에 들어온 커밋 수가 약 2배, 제출 코드 줄 수가 약 5배로 늘었다고 말했습니다. 그는 이 변화가 AI 에이전트의 문제 해결 능력이 좋아진 시기와 맞물렸다고 설명했습니다.

발키 메인테이너 제이콥 머피(Jacob Murphy)는 과거에는 코드 작성에 드는 시간과 노력이 충분히 고민하지 않은 기여를 걸러냈지만, 이제는 AI가 1,000줄도 한 번에 만들 수 있어 첫 비판적 검토가 메인테이너의 몫이 되곤 한다고 말했습니다. 코드 생성은 크게 쉬워졌지만 리뷰는 조금만 쉬워졌으며, 기여가 올바른 방향인지 확인하려면 여전히 집중과 깊은 판단이 필요하다는 설명입니다. 올슨은 모든 풀 리퀘스트(PR·코드 변경 제안)를 검토하지 못하는 점은 아쉽지만, 더 많은 사람이 참여하려는 사실은 반갑다고 밝혔습니다.

린 선(Lin Sun)은 코드뿐 아니라 검토 의견에 대한 답변까지 AI가 작성한 뒤 그대로 붙여 넣는 사례를 경험했다고 말했습니다. 일부 신규·비정기 기여자가 코드를 이해하거나 검증하지 않은 변경안을 제출해 메인테이너의 부담을 키우고, 일부 리뷰어는 봇과 수정 요청을 주고받는 상황에 불만을 나타냈습니다. 이에 선이 참여하는 일부 프로젝트는 리눅스 재단의 AI 사용 지침을 바탕으로 기여 원칙을 마련했습니다. AI를 사용해도 기여자가 결과물을 확신하고 직접 작성했음을 밝혀야 한다는 내용입니다. 선은 신규 참여자에게 회의 참석을 요청해 함께 일하고 소통할 사람이 있는지 확인하기도 합니다. 자신도 AI 코딩 도구로 문법과 절차를 찾는 시간을 줄이되, 결과물을 직접 확인하고 이해한 뒤 공개한다고 말했습니다.

메인테이너들은 AI를 코드 검토에도 활용합니다. 머피는 리뷰를 메모리 누수나 비정상 종료 같은 오류 확인, 코드 일관성과 중복 점검, 변경안이 전체 설계와 목적에 맞는지 판단하는 세 층위로 나눴습니다. 여러 AI 에이전트가 사람의 검토 전에 코드를 살피고 의견을 남기면 기여자가 일부 문제를 먼저 고칠 수 있습니다. 검토자는 기존 기능과의 중복이나 프로젝트 방향을 확인하고, 에이전트에 풀 리퀘스트를 읽힌 뒤 질문을 주고받으며 구현 맥락을 파악하기도 합니다.

올슨은 AI가 만든 코드에 중복 함수가 없는지 확인하고 더 단순한 해결책을 살피며 테스트를 작성한다고 말했습니다. 테스트가 의도한 동작을 검증하는지, 구현이 원하는 대로 작동하는지도 직접 확인합니다. 지속적 통합(CI)에서 테스트가 실패하면 AI 에이전트에 문제 재현을 맡기고, 재현되면 로컬 환경에서 원인을 살펴 수정할 기반을 마련합니다. AI 도구로 보안 문제를 미리 찾는 일도 도움이 된다고 올슨은 밝혔습니다. 다만 변경 코드가 프로젝트 목표에 맞고 안정성과 성능을 유지하는지, 새 보안 취약점을 만들지 않는지는 메인테이너가 계속 확인해야 한다고 강조했습니다.

세 메인테이너는 오픈소스 커뮤니티가 코드 작성법 외의 경험을 제공한다고 말했습니다. 올슨은 AI가 설계에서 어떤 요소를 우선하고 포기했는지, 소프트웨어가 왜 그런 방식으로 만들어졌는지를 이해하는 데 아직 어려움이 있다고 설명했습니다. 그는 커뮤니티에서 엔지니어가 개발 관리자와 제품 관리자 관점으로 사용자의 경험을 고민할 수 있다고 덧붙였습니다. 머피는 사용자 경험과 개발 목적, 시스템이 고장 나는 조건을 익히고, 쏟아지는 연구와 기술 정보 중 프로젝트에 도입할 것과 제외할 것을 판단하는 경험을 꼽았습니다.

선은 신뢰를 얻고 영향력을 키우며 다른 사람에게 동기를 주는 능력은 AI와 대화하는 것과 다르다고 말했습니다. 커뮤니티에서는 새로운 분야의 전문성을 쌓고 역량을 알릴 수 있지만, 기술 쟁점과 업체 이해관계, 정치가 얽힌 상황에서 합의를 이끄는 일은 어렵다고 설명했습니다. 올슨은 2019년 무렵 레디스 프로젝트에서 고친 버그를 몇 년 뒤 사용자가 기억하고 감사 인사를 건넨 경험을 보람으로 들었습니다.

선은 토큰 비용 부담 때문에 직접 호스팅하는 오픈 모델에 관심을 갖는 사람이 늘고 코딩 에이전트가 기여 진입 장벽을 낮출 것이라 전망했습니다. 다만 프로젝트의 성공에는 지지하고 함께 발전시키는 커뮤니티가 필요하다고 강조했습니다. 그는 코드를 만드는 비용이 저렴해져도 사람들이 그 코드를 사용하는 것은 아니라고 말했습니다. 기사는 오픈소스에서 나타난 변화가 기업 개발 조직에도 설계 이유를 설명하고 동료와 합의하며 사용자 문제를 해결하는 역량을 어떻게 키울지 묻는다고 전했습니다.

오픈소스 프로젝트 메인테이너 3인은 AI 확산으로 코드 작성이 쉬워진 반면 검토와 방향 판단의 부담이 커졌다고 밝혔습니다. CIO 코리아는 2026년 10월 12일 발키(Valkey)와 이스티오(Istio) 등 프로젝트를 이끄는 이들을 인터뷰해 기여와 검토, 커뮤니티의 변화를 전했습니다. 발키 메인테이너 매들린 올슨(Madelyn Olson)은 자체 분석에서 지난해 말부터 올해 초까지 발키에 들어온 커밋 수가 약 2배, 제출 코드 줄 수가 약 5배로 늘었다고 말했습니다. 그는 이 변화가 AI 에이전트의 문제 해결 능력이 좋아진 시기와 맞물렸다고 설명했습니다.

발키 메인테이너 제이콥 머피(Jacob Murphy)는 과거에는 코드 작성에 드는 시간과 노력이 충분히 고민하지 않은 기여를 걸러냈지만, 이제는 AI가 1,000줄도 한 번에 만들 수 있어 첫 비판적 검토가 메인테이너의 몫이 되곤 한다고 말했습니다. 코드 생성은 크게 쉬워졌지만 리뷰는 조금만 쉬워졌으며, 기여가 올바른 방향인지 확인하려면 여전히 집중과 깊은 판단이 필요하다는 설명입니다. 올슨은 모든 풀 리퀘스트(PR·코드 변경 제안)를 검토하지 못하는 점은 아쉽지만, 더 많은 사람이 참여하려는 사실은 반갑다고 밝혔습니다.

린 선(Lin Sun)은 코드뿐 아니라 검토 의견에 대한 답변까지 AI가 작성한 뒤 그대로 붙여 넣는 사례를 경험했다고 말했습니다. 일부 신규·비정기 기여자가 코드를 이해하거나 검증하지 않은 변경안을 제출해 메인테이너의 부담을 키우고, 일부 리뷰어는 봇과 수정 요청을 주고받는 상황에 불만을 나타냈습니다. 이에 선이 참여하는 일부 프로젝트는 리눅스 재단의 AI 사용 지침을 바탕으로 기여 원칙을 마련했습니다. AI를 사용해도 기여자가 결과물을 확신하고 직접 작성했음을 밝혀야 한다는 내용입니다. 선은 신규 참여자에게 회의 참석을 요청해 함께 일하고 소통할 사람이 있는지 확인하기도 합니다. 자신도 AI 코딩 도구로 문법과 절차를 찾는 시간을 줄이되, 결과물을 직접 확인하고 이해한 뒤 공개한다고 말했습니다.

메인테이너들은 AI를 코드 검토에도 활용합니다. 머피는 리뷰를 메모리 누수나 비정상 종료 같은 오류 확인, 코드 일관성과 중복 점검, 변경안이 전체 설계와 목적에 맞는지 판단하는 세 층위로 나눴습니다. 여러 AI 에이전트가 사람의 검토 전에 코드를 살피고 의견을 남기면 기여자가 일부 문제를 먼저 고칠 수 있습니다. 검토자는 기존 기능과의 중복이나 프로젝트 방향을 확인하고, 에이전트에 풀 리퀘스트를 읽힌 뒤 질문을 주고받으며 구현 맥락을 파악하기도 합니다.

올슨은 AI가 만든 코드에 중복 함수가 없는지 확인하고 더 단순한 해결책을 살피며 테스트를 작성한다고 말했습니다. 테스트가 의도한 동작을 검증하는지, 구현이 원하는 대로 작동하는지도 직접 확인합니다. 지속적 통합(CI)에서 테스트가 실패하면 AI 에이전트에 문제 재현을 맡기고, 재현되면 로컬 환경에서 원인을 살펴 수정할 기반을 마련합니다. AI 도구로 보안 문제를 미리 찾는 일도 도움이 된다고 올슨은 밝혔습니다. 다만 변경 코드가 프로젝트 목표에 맞고 안정성과 성능을 유지하는지, 새 보안 취약점을 만들지 않는지는 메인테이너가 계속 확인해야 한다고 강조했습니다.

세 메인테이너는 오픈소스 커뮤니티가 코드 작성법 외의 경험을 제공한다고 말했습니다. 올슨은 AI가 설계에서 어떤 요소를 우선하고 포기했는지, 소프트웨어가 왜 그런 방식으로 만들어졌는지를 이해하는 데 아직 어려움이 있다고 설명했습니다. 그는 커뮤니티에서 엔지니어가 개발 관리자와 제품 관리자 관점으로 사용자의 경험을 고민할 수 있다고 덧붙였습니다. 머피는 사용자 경험과 개발 목적, 시스템이 고장 나는 조건을 익히고, 쏟아지는 연구와 기술 정보 중 프로젝트에 도입할 것과 제외할 것을 판단하는 경험을 꼽았습니다.

선은 신뢰를 얻고 영향력을 키우며 다른 사람에게 동기를 주는 능력은 AI와 대화하는 것과 다르다고 말했습니다. 커뮤니티에서는 새로운 분야의 전문성을 쌓고 역량을 알릴 수 있지만, 기술 쟁점과 업체 이해관계, 정치가 얽힌 상황에서 합의를 이끄는 일은 어렵다고 설명했습니다. 올슨은 2019년 무렵 레디스 프로젝트에서 고친 버그를 몇 년 뒤 사용자가 기억하고 감사 인사를 건넨 경험을 보람으로 들었습니다.

선은 토큰 비용 부담 때문에 직접 호스팅하는 오픈 모델에 관심을 갖는 사람이 늘고 코딩 에이전트가 기여 진입 장벽을 낮출 것이라 전망했습니다. 다만 프로젝트의 성공에는 지지하고 함께 발전시키는 커뮤니티가 필요하다고 강조했습니다. 그는 코드를 만드는 비용이 저렴해져도 사람들이 그 코드를 사용하는 것은 아니라고 말했습니다. 기사는 오픈소스에서 나타난 변화가 기업 개발 조직에도 설계 이유를 설명하고 동료와 합의하며 사용자 문제를 해결하는 역량을 어떻게 키울지 묻는다고 전했습니다.