기술 부채 (Technical Debt, TD)는 개발자가 품질 개선 작업보다 단기적인 인도(delivery)를 우선시할 때 발생하는 장기적인 비용을 의미합니다. 아키텍처 기술 부채 (Architectural Technical Debt, ATD)는 아키텍처 결정(예: 기술 선택, 패턴 또는 분해)이 미래의 유지보수성 및 진화 가능성보다 단기적인 진척을 우선시할 때 발생합니다. ATD는 시스템의 핵심 구조에 영향을 미치고 아키텍처 의존성을 통해 전파되기 때문에, 국소적인 코드 수준의 부채보다 해결하는 데 더 많은 비용이 들고 파괴적일 때가 많습니다. ATD에 대한 연구는 널리 이루어져 왔지만, 부채 상환의 중요한 측면 중 하나인 '누가 상환을 수행하는가'에 대해서는 아직 충분히 탐구되지 않았습니다. 기존 연구들은 ATD의 상환 책임과 수정 시간 (time-to-fix) 사이의 관계에 대해 제한적인 실증적 근거만을 제공합니다. 본 연구에서는 부채를 유발한 사람이 직접 부채를 상환하는 '자기 수정형 (self-fixed) ATD'를 실증적으로 연구하고, 이를 대규모 Apache 오픈 소스 프로젝트 내의 '비-자기 수정형 (non-self-fixed) ATD'와 대조합니다. 우리는 Jira 산출물을 버전 관리 이력(version-control history)과 추적하여 ATD의 생명 주기를 재구성함으로써, 도입 및 상환 시점을 식별하고 개발자 역할을 할당했습니다. 우리는 자기 수정형 ATD의 보급률, 자기 수정형 항목과 비-자기 수정형 항목 간의 수정 시간 차이, 그리고 코드 변경 및 협업 지표와 관련된 요인들이 상환 속도와 어떻게 연관되는지에 대한 세 가지 연구 질문을 다룹니다. 기술 통계, 비모수 검정 (non-parametric tests), 생존 분석 (survival analysis)을 사용하여, 우리는 자기 수정형 ATD와 비-자기 수정형 ATD가 서로 다른 상환 역학을 보이며, ATD의 영향을 받는 파일에서 변경 사항이 공유되는 방식에도 차이가 있음을 보여줍니다. 특히, 비-자기 수정형 ATD는 변경 사항이 많은 개발자에게 분산되어 있을 때 해결되지 않은 채 더 오래 남아 있을 가능성이 높습니다. 이러한 결과는 유지보수자가 고위험 ATD 항목을 식별하고, 가능한 경우 도입자의 참여를 높이며 상환 과정에서 설계 근거 (design rationale)를 문서화함으로써 인수인계 비용을 줄일 수 있는 실행 가능한 지침을 제공합니다.