2026년 개발 트렌드 3장면, 레거시 전환·아이스버그 통계·PR 측정의 함정

오늘은 세 가지 서로 다른 개발 생태계 소식을 살펴봅니다. 하나는 AI를 활용한 레거시 시스템 전환 사례, 다른 하나는 대규모 데이터 처리에서 통계 정보를 다루는 파일 포맷, 마지막은 코드 리뷰와 생산성을 측정하는 방식에 대한 문제 제기입니다. 세 이야기는 서로 직접 연결되지는 않지만, 모두 "개발 프로세스를 어떻게 더 낫게 만들 것인가"라는 공통 질문 아래 놓여 있습니다.

AI로 레거시 시스템을 바꾼 Bupa의 사례

핵심: Bupa는 앱을 Xamarin에서 네이티브 Swift·Kotlin으로 전환해 평점을 3.7에서 4.7로 끌어올렸습니다.

레거시 기술은 오랫동안 기업들이 해결해야 한다고 알면서도 좀처럼 손대지 못한 문제였습니다. 비용과 복잡성, 위험 부담 때문에 현대화는 기회가 아니라 관리해야 할 혼란으로 여겨지곤 했습니다. 하지만 고객 기대치가 높아지고 AI가 소프트웨어 개발의 경제성을 바꾸면서 이 계산법이 달라지고 있습니다.

Bupa의 건강보험 부문 CIO인 Asifa Sherazi는 수명이 다한 기술이 "조용히 쌓이다가 한꺼번에 닥치는" 위험이라고 설명했습니다. My Bupa 모바일 앱을 Xamarin에서 네이티브 Swift와 Kotlin으로 전환한 결과 앱 평점은 3.7에서 4.7로 올랐고, 사용자 체감 충돌률은 안드로이드에서 약 24%포인트, iOS에서 8%포인트 낮아졌습니다. Infosys의 Sanjeev Tripathi는 AI가 리버스 엔지니어링과 포워드 엔지니어링을 결합하는 방식으로 현대화 작업의 효율성을 바꾸고 있다고 설명했으며, Bupa의 경우 AI 이전 시대보다 약 60% 적은 시간에 전환을 마쳤습니다.

Sherazi는 이 변화로 조직이 던지는 질문 자체가 바뀌었다고 말했습니다. 예전에는 "우리 플랫폼이 이걸 지원할 수 있나"였다면, 이제는 "이게 고객에게 옳은 일인가"를 묻게 됐다는 것입니다. 이는 하나의 기업 사례이지만, 코드베이스를 다루는 방식이 곧 조직의 전략적 태도와 직결된다는 점을 보여줍니다. 코드와 데이터를 다루는 관점을 좀 더 기술적인 층위로 옮겨보면, 대규모 데이터 처리 엔진에서도 비슷한 고민이 존재합니다.

출처: MIT Tech Review | 원문 보기 ↗

매니페스트가 놓치는 통계, Puffin 파일 포맷이 채우는 자리

핵심: Puffin은 아이스버그(Iceberg) 매니페스트가 담지 못하는 고유값 추정치와 삭제 벡터를 저장하는 컨테이너 포맷입니다.

여기서 아이스버그란 대규모 데이터 처리에서 쓰이는 테이블 포맷을 뜻합니다. 20억 행짜리 팩트 테이블과 4만 행짜리 차원 테이블을 조인할 때, 쿼리 옵티마이저는 어느 쪽을 브로드캐스트하고 어느 쪽을 해시할지 결정해야 합니다. 옵티마이저는 매니페스트를 읽어 각 파일의 행 수, 최소·최대값, 널 개수는 찾아내지만 팩트 테이블 전체에서 고유한 고객 ID가 몇 개인지는 알 수 없습니다. 이 숫자가 없으면 옵티마이저는 추측할 수밖에 없고, 잘못된 추측은 브로드캐스트로 피할 수 있었던 테라바이트 단위 셔플을 유발합니다.

같은 엔진이 잠시 후 400만 행짜리 데이터 파일에서 300개 행을 삭제하면, 포맷 버전 2에서는 삭제된 행의 위치를 나열하는 포지션 삭제 파일을 별도로 씁니다. 이후 해당 데이터 파일을 읽을 때마다 삭제 파일을 열어 파케이(Parquet)를 디코딩하고 위치 집합을 만들어 필터링해야 하는데, 파일 1만 개에서 이 작업이 반복되면 삭제 처리가 쿼리 시간을 지배하게 됩니다. Puffin은 매직 넘버, 불투명한 블롭들의 시퀀스, 그리고 각 블롭이 무엇이고 어디에 있는지 설명하는 JSON 푸터로 구성된 단순한 컨테이너 포맷입니다. 현재 스펙은 두 가지 블롭 타입을 정의하는데, 하나는 고유값 추정을 위한 세타(Theta) 스케치, 다른 하나는 포맷 버전 3의 행 단위 삭제를 위한 삭제 벡터입니다.

이 기사를 쓴 개발자는 Dremio 소속으로 해당 쿼리 엔진이 Puffin 통계를 소비한다고 밝혔지만, 내용 자체는 벤더에 종속되지 않는다고 설명했습니다. 이처럼 오픈소스 데이터 포맷의 세부 구조를 파고드는 글이 있는가 하면, 같은 개발 생태계에서는 코드 자체를 어떻게 검토하고 측정할지에 대한 근본적인 논쟁도 벌어지고 있습니다.

출처: dev.to | 원문 보기 ↗

PR을 측정하면 정말 생산성이 오를까: "티타임" 비유

핵심: DX 조사에 따르면 500개 이상 조직에서 PR이 오래 열려 있을수록 개발자당 출하량이 줄었습니다.

글쓴이는 풀 리퀘스트(PR)에 비판적인 입장을 오래 밝혀온 인물로, 하루에도 여러 번 메인라인에 코드를 병합하는 지속적 통합(CI) 방식을 지지합니다. PR로도 기술적으로는 CI가 가능하지만 실제로는 드물다는 것이 그의 주장이며, Martin Fowler가 지적했듯 사전 통합 리뷰는 잘 수행되더라도 통합 과정에 지연을 유발하고 통합 빈도를 낮추게 만든다고 인용했습니다.

최근 DX가 발표한 조사는 500개 이상 조직을 대상으로 PR이 열려 있던 시간과 개발자별 출하량 사이의 관계를 비교했습니다. PR이 오래 열려 있을수록 개발자당 출하량은 줄었고, 이 효과는 팀이 많이 출하할수록 더 강해졌으며, 출하량이 가장 적은 팀들 사이에서는 이 관계가 거의 사라졌습니다. 글쓴이는 데이터와 분석 자체는 타당해 보이지만 프레이밍이 정반대라고 지적하며, 고객에게 전달되는 가치를 측정하는 DORA 지표 같은 리드타임(LTTC) 대신 왜 PR 자체를 측정하는지 의문을 제기했습니다.

그는 이를 마라톤 비유로 설명합니다. 일부 러너가 카페인과 탄수화물을 챙기듯 준비하다가 중간에 차를 마시러 멈춘다면, 누구도 이 멈춘 시간을 기록에 넣지 않을 텐데, 만약 "차를 서빙받는 속도"만 측정한다면 엘리트 러너일수록 서빙 속도에 민감하다는 인상적인 통계가 나올 수 있다는 것입니다. 하지만 실제로는 차를 마시러 멈추는 행위 자체가 완주 시간을 늦추는 원인이라는 게 그의 논지입니다.

출처: dev.to | 원문 보기 ↗

이슈	핵심 수치/사실	영역
Bupa 앱 현대화	평점 3.7→4.7, 안드로이드 충돌률 24%p 감소	레거시 전환
Puffin 포맷	Theta 스케치·삭제 벡터 2종 블롭 지원	데이터 인프라
PR 측정	500개+ 조직서 PR 체류시간↑ → 출하량↓	개발 프로세스

이게 나에게 의미하는 것

레거시 시스템을 관리하는 개발자라면, Bupa 사례처럼 AI 보조 리버스·포워드 엔지니어링을 결합하는 방식이 전환 기간을 줄이는 하나의 참고 모델이 될 수 있습니다. 대규모 데이터 파이프라인을 설계하는 엔지니어라면, 옵티마이저가 고유값이나 삭제 정보를 어떻게 참조하는지 이해하는 것이 쿼리 성능 튜닝의 출발점이 됩니다. 팀 생산성 지표를 도입하려는 리더라면, PR 체류시간 같은 프로세스 지표를 볼 때 그것이 실제 고객 가치 전달(리드타임 등)과 어떤 관계인지부터 따져볼 필요가 있습니다.

정리: 오늘의 시사점

Bupa 사례는 AI가 레거시 전환의 시간과 비용을 줄이는 실제 수치(60% 시간 단축, 평점 1포인트 상승)를 보여줬습니다. Puffin 포맷은 매니페스트만으로 부족한 테이블 단위 통계를 별도 블롭으로 분리해 저장하는 설계 원칙을 담고 있습니다. DX의 PR 조사는 데이터 자체는 견고하지만, 무엇을 측정할지에 대한 프레임 선택이 결론의 유용성을 좌우한다는 점을 보여줍니다. 세 사례 모두 "무엇을 어떻게 측정하고 개선할 것인가"라는 질문에서 출발한다는 공통점이 있습니다.