Investigating Technical Debt Types, Issues, and Solutions in Serverless Computing

1. 연구 배경 및 문제 정의 (Problem)

• 서버리스 컴퓨팅의 부상: AWS Lambda, Azure Functions 등 서버 관리가 클라우드 제공업체에 위임되는 서버리스 아키텍처가 확장성과 비용 효율성으로 인해 급격히 확산되고 있습니다.
• 기술 부채 (Technical Debt, TD) 의 존재: 서버리스 환경은 빠른 개발을 유도하지만, rushed architectural decisions(급한 아키텍처 결정), 서비스 지식 부족, 자동화 미비, 보안 관행 소홀 등으로 인해 기술 부채가 쉽게 누적됩니다.
• 연구의 공백: 기존 연구는 서버리스의 장단점이나 일반적인 어려움에 집중했거나, 소수의 전문가 인터뷰를 통해 코드/테스트/아키텍처 부채만 제한적으로 다뤘습니다. 실제 개발자들이 겪는 구체적인 기술 부채의 유형, 문제점, 그리고 해결 방안이 어떻게 나타나는지에 대한 실증적 데이터가 부족했습니다.
• 목표: Stack Overflow(SO) 와 같은 대규모 커뮤니티 지식 베이스를 활용하여 서버리스 환경에서의 기술 부채가 어떻게 manifest(발현) 되는지, 어떤 유형이 있는지, 그리고 어떻게 해결되는지를 체계적으로 분석하는 것입니다.

2. 연구 방법론 (Methodology)

이 연구는 2014 년 (서버리스 개념 도입) 부터 2025 년 3 월까지의 Stack Overflow 데이터를 기반으로 진행되었습니다.

• 데이터 수집:
  • serverless, aws-lambda, azure-functions, google-cloud-functions 등 15 개의 관련 태그를 사용하여 총 78,867 개의 질문을 추출했습니다.
• 데이터 분류 (Classification):
  • 수동 분류: 2 명의 annotator(연구자 및 박사과정 학생) 가 Dagstuhl 정의를 기준으로 825 개의 질문 (TD 관련 406 개, 비관련 419 개) 을 라벨링하여 훈련 데이터를 구성했습니다. (Cohen's Kappa: 0.83)
  • 자동 분류: 수집된 전체 데이터에 대해 5 가지 머신러닝 모델 (Logistic Regression, Random Forest, SVM, Naive-Bayes, BERT) 을 학습시켰습니다. BERT 모델이 F1-score 0.86 으로 가장 높은 성능을 보였으며, 이를 통해 전체 질문을 TD 관련/비관련로 분류했습니다.
• 데이터 분석:
  • 분류된 29,212 개의 TD 관련 질문 중 통계적으로 유의미한 샘플 (380 개, 95% 신뢰수준) 을 선정하여 심층 분석을 수행했습니다.
  • Li et al. (2015) 의 TD 분류 체계 (10 가지 유형) 를 기반으로 코딩 (Open Coding) 을 수행하여 하위 유형 (Subtypes) 을 도출하고, 서버리스 특유의 문제를 식별했습니다.

3. 주요 연구 결과 (Key Results)

RQ1: 서버리스 질문 중 기술 부채의 비율은?

• 추출된 78,867 개의 서버리스 질문 중 37% (29,212 개) 가 기술 부채 (TD) 와 관련이 있는 것으로 분류되었습니다.
• 개발자들은 "tech debt", "suboptimal" 등의 용어를 명시적으로 사용하여 부채 문제를 논의하고 있음이 확인되었습니다.

RQ2: 서버리스에서의 기술 부채 유형은 무엇인가?

• 주요 유형 (Top 3):
  1. 코드 부채 (Code Debt, 33.9%): 가장 빈번하게 논의됨. (DB CRUD, 함수 I/O, 외부 API 호출 등)
  2. 디자인 부채 (Design Debt, 12.9%): 함수 타임아웃, 디자인 패턴 부재 등.
  3. 버전 관리 부채 (Versioning Debt, 12.4%): 런타임 업그레이드 (예: Node 12 → 16) 관련 문제.
• 최소 유형: 인프라스트럭처 부채 (Infrastructure Debt) 가 가장 적게 논의됨. 요구사항 부채는 발견되지 않음.
• 서버리스 특유의 6 가지 주요 이슈 (Serverless-Specific Issues):
  1. 확장성 (Scaling): 자동 확장 시 의존 서비스의 병목 현상.
  2. 콜드 스타트 (Cold Start): 함수 초기화 지연으로 인한 성능 저하.
  3. 로그 접근 (Add/Access Logs): 일회성 (Ephemeral) 환경에서의 로그 수집 및 디버깅 어려움.
  4. 비용 최적화 (Minimizing Cost): 사용량 기반 과금 모델에서의 비용 통제 부재.
  5. 비밀 정보 관리 (Secrets Management): 상태 비저장 (Stateless) 환경에서의 API 키/자격 증명 관리 복잡성.
  6. 로컬 테스트 (Testing Locally): 클라우드 서비스와 긴밀하게 결합된 함수의 로컬 환경 시뮬레이션 어려움.

RQ3: 기술 부채는 어떻게 해결되는가?

• 해결책 유무: TD 관련 질문 중 21% 는 답변이 없었으며, 40% 는 '승인된 답변 (Accepted Answer)'이 없었습니다.
• **문서화 부채 (Documentation Debt)**가 답변이 없는 비율 (53.3%) 이 가장 높았으며, **빌드 부채 (Build Debt)**는 승인된 답변이 없는 비율 (75%) 이 가장 높았습니다.
• 제공된 해결책 유형: 코드 수정 (Code modifications), 대안 제시, 개념 설명, 디버깅 가이드, 공식 문서 참조, 도구 제안 등 다양하게 제시됨.

4. 주요 기여 (Key Contributions)

1. 서버리스 도메인의 기술 부채 유형 및 하위 유형 카탈로그: 10 가지 주요 유형과 49 가지 하위 유형을 체계적으로 분류하여 제공했습니다.
2. 서버리스 특유의 기술 부채 문제 식별: 기존 연구와 차별화된 6 가지 서버리스 고유의 문제 (콜드 스타트, 로컬 테스트 등) 를 실증적으로 입증했습니다.
3. 해결책 카탈로그: 개발자들이 제안하는 다양한 해결 전략을 분류하고, 어떤 유형의 부채가 해결되지 않고 방치되는지 분석했습니다.
4. 재현성 있는 패키지 (Replication Package): 데이터, 분류 모델, 분석 코드 등을 공개하여 후속 연구를 지원합니다.

5. 의의 및 시사점 (Significance)

• 연구자 및 도구 개발자: 서버리스 환경에서 기술 부채를 탐지하고 관리하기 위한 자동화 도구 개발에 필요한 요구사항과 기준을 제시합니다. 특히 '코드 부채'가 가장 흔하지만 '문서화'와 '빌드' 관련 부채는 해결이 어렵다는 점을 고려한 도구 개발이 필요함을 시사합니다.
• 실무자 (개발자): 서버리스 아키텍처 도입 시 발생할 수 있는 잠재적 위험 요소 (특히 보안, 비용, 테스트) 를 사전에 인지하고, Stack Overflow 의 사례를 참고하여 부채를 최소화하는 전략을 수립할 수 있습니다.
• 정책 및 가이드라인: 기술 부채가 시스템의 장기적인 품질과 성능에 미치는 영향을 이해하고, 조직 차원의 관리 전략을 수립하는 데 기여합니다.

6. 결론

이 연구는 Stack Overflow 의 방대한 데이터를 통해 서버리스 컴퓨팅 환경에서 기술 부채가 37% 의 높은 비율로 존재하며, 코드, 디자인, 버전 관리가 주된 문제임을 밝혔습니다. 또한, 서버리스 고유의 아키텍처적 특성 (콜드 스타트, 상태 비저장 등) 으로 인해 발생하는 독특한 부채 유형들을 구체적으로 규명했습니다. 이는 서버리스 기술의 성숙도를 높이고, 보다 견고한 시스템 구축을 위한 중요한 실증적 근거를 제공합니다.