Devin의 RSA-260 작업 보고, AI에게 맡기지 않은 일은 무엇이었을까요

핵심 요약 (TL;DR)

9월 9일 Cognition의 Eric Lu는 Devin을 활용해 RSA-260 인수분해 작업을 진행한 구현 보고를 공개했습니다.[4] 인수분해 사실 자체는 9월 3일 이미 알려졌으므로, 새 소식은 숫자가 풀렸다는 선언보다 그 일을 어떻게 수행했는지에 있습니다.[7] 바이브코더가 주목할 대목도 같습니다. 작성자는 자신의 역할을 우선순위 설정, 벤치마크 수립, 작업이 잘못된 방향으로 갈 때의 판단이라고 설명합니다.[4]

이번 성과를 ‘AI가 암호를 깼다’고만 읽으면 왜 곤란할까요?

RSA-260은 이름에서 짐작할 수 있는 작은 테스트 문자열이 아니라, 큰 정수를 인수분해하는 공개 도전 문제입니다. 그렇다고 이 결과를 모든 인터넷 서비스의 암호가 무너졌다는 뜻으로 읽어서는 안 됩니다. Cognition 보고는 현재 널리 쓰이는 RSA-2048이 이 작업으로 의미 있게 영향을 받은 것으로 보이지 않는다고 선을 긋습니다.[4] 수학자 John D. Cook의 별도 설명도 도전 문제의 크기와 권장 키 크기를 구분합니다.[7]

연구 결과의 인상적인 제목만 보고 인증 라이브러리를 바꾸거나 자체 암호화를 만들면, 뉴스보다 내 변경이 더 큰 위험이 될 수 있습니다. 이 글은 암호 시스템의 안전을 보증하는 안내가 아니라, 특정 성과에서 실제로 확인된 범위를 좁혀 읽자는 제안입니다.

코드를 많이 맡길수록 사람은 무엇을 더 명확히 해야 할까요?

보고는 Devin이 측정, 클러스터 운영, 최적화를 수행했다고 설명합니다. 다만 이는 제작사 연구자의 작업 보고이며, 같은 결과를 외부에서 재현한 생산성 비교는 아닙니다.[4] 비용 절감 배수나 전문가 대체 기간을 모든 프로젝트의 기대치로 가져오지 않는 편이 정확합니다.

대신 작업을 맡기는 구조는 참고할 수 있습니다. AI에게 ‘최대한 빠르게 개선해 주세요’라고 말하면 무엇을 빠르게 해야 하는지부터 흔들립니다. 문의 접수 앱이라면 첫 화면 표시, 저장 완료, 관리자 검색 중 지금 해결할 구간을 하나 고르세요. 같은 입력과 같은 환경에서 변경 전후를 비교하고, 속도만 좋아진 대신 데이터가 빠지지는 않는지 함께 봐야 합니다.

벤치마크는 거창한 점수표여야 하나요?

첫 프로젝트에는 짧은 재현 절차면 충분합니다. 샘플 문의를 입력하고 저장한 뒤, 새로고침해 같은 내용이 남는지 확인하는 과정을 고정해 보세요. AI가 코드를 바꿀 때마다 그 순서를 다시 실행하면, 최소한 이전에 되던 흐름이 사라지지는 않았는지 판단할 수 있습니다.

여기서 시간 측정은 필요할 때만 추가하면 됩니다. 측정 조건을 바꾸면서 결과 숫자만 비교하면 개선인지 환경 차이인지 알 수 없습니다. 입력 데이터와 실행 위치를 함께 남기고, 실패한 시도도 지우지 마세요. 실험 기록은 성공을 자랑하는 자료가 아니라 다음 변경을 멈출 근거가 됩니다.

또한 ‘방향이 틀렸다’고 판단할 조건을 미리 적어 두는 편이 좋습니다. 저장 속도를 줄이려다가 접근 권한을 느슨하게 만드는 제안, 작은 수정 때문에 전면 교체를 요구하는 제안은 별도 검토로 돌릴 수 있습니다. 에이전트에게 많은 코드를 맡겨도 제품의 우선순위까지 자동으로 정해지는 것은 아닙니다.

FAQ: 이 사례는 비개발자도 같은 연구를 할 수 있다는 뜻인가요?

아닙니다. 작성자의 수학적 관심과 연구팀의 환경이 포함된 사례입니다.[4] 재현 가능한 것은 성과 규모가 아니라 목표·측정·중단 기준을 나누는 작업 습관입니다.

FAQ: 지금 쓰는 서비스의 암호를 바로 바꿔야 하나요?

이 보고 하나로 판단하지 마세요. 사용 중인 제품의 공식 보안 권고와 지원 상태를 확인하고, 중요한 변경은 보안 전문가 검토를 거치는 편이 좋습니다.

관찰 시점: 2026-09-11 KST

Sources

[4] https://cognition.com/blog/factoring-rsa-260
[7] https://www.johndcook.com/blog/2026/09/03/new-rsa-number-factored