Refactoring for Novices in Java: An Eye Tracking Study on the Extract vs. Inline Methods

이 연구는 32 명의 Java 초보자를 대상으로 한 아이 트래킹 실험을 통해, 추출 리팩토링이 복잡한 작업에서는 이해도와 성능을 향상시키지만 단순한 작업에서는 오히려 탐색 빈도와 소요 시간을 증가시켜 초보자에게는 과도한 모듈화가 비효율적일 수 있음을 밝혔습니다.

핵심

이 논문은 **"코드를 읽을 때, 함수를 따로 떼어내는 것 (Extract Method) 이 정말로 초보자에게 도움이 될까?"**라는 질문에 답하기 위해 진행된 흥미로운 연구입니다.

연구팀은 32 명의 Java 초보 개발자를 대상으로 실험을 했으며, 그들의 **눈동자 움직임 (아이 트래킹)**을 추적해서 코드를 읽는 과정에서 뇌가 얼마나 힘들게 노력하는지 측정했습니다.

이 복잡한 연구를 일상적인 비유로 쉽게 설명해 드릴게요.

---

🍳 요리책 비유: "레시피" vs "한 번에 다 하기"

코드를 요리한다고 상상해 보세요.

1. 인라인 (Inline Method): 모든 재료를 한 냄비에서 한 번에 섞고 끓이는 방식입니다.

   • 장점: 재료가 한눈에 들어옵니다. "소금 넣기, 후추 넣기, 끓이기"가 한 줄에 다 적혀 있어요.
   • 단점: 요리가 길어지면 한눈에 들어오지 않아서 혼란스러울 수 있습니다.

2. 추출 (Extract Method): "소금 넣기"나 "끓이기" 같은 과정을 따로 작은 레시피 카드 (함수) 로 만들어서, 메인 레시피에는 "소금 넣기"라고만 적는 방식입니다.

   • 장점: 메인 레시피가 깔끔해 보이고, "이건 소금 넣는 과정이야"라고 이름만 봐도 내용을 유추할 수 있습니다.
   • 단점: 요리할 때 메인 레시피를 보다가 "아, 소금 넣는 건 어딨지?" 하고 레시피 카드를 찾아서 다시 돌아와야 합니다.

🔍 연구의 핵심 발견: "초보자는 이름만 보고 넘어가지 못한다!"

연구팀은 이 두 방식이 초보자들의 눈동자 움직임에 어떤 영향을 미치는지 봤습니다. 결과는 놀라웠습니다.

1. 복잡한 요리 (예: 팩토리얼 계산, 리스트에서 최고 점수 찾기)

• 상황: 요리 과정이 복잡하고 재료가 많을 때입니다.
• 결과: **함수를 따로 떼어낸 방식 (추출)**이 훨씬 좋았습니다.
• 이유: 복잡한 과정을 "소금 넣기"라는 이름의 작은 레시피로 분리해 주니, 초보자들이 전체 흐름을 이해하기 쉬웠습니다. 눈이 왔다 갔다 하는 횟수 (재귀적 움직임) 가 줄어들고, 문제를 푸는 속도도 빨라졌습니다.
• 비유: 복잡한 레시피를 작은 단계로 나누어주니, 요리사가 당황하지 않고 차분하게 따라 할 수 있었습니다.

2. 간단한 요리 (예: 정사각형 넓이 구하기, 짝수인지 확인하기)

• 상황: "변수 × 변수"처럼 한 두 줄로 끝나는 아주 간단한 계산입니다.
• 결과: 함수를 따로 떼어낸 방식이 오히려 해가 되었습니다!
• 이유: 아주 간단한 일을 위해 따로 레시피 카드를 만들어서 찾아다니게 하니, 초보자들은 오히려 더 지쳤습니다.
  • 눈동자 데이터에 따르면, 초보자들은 "이 함수가 뭘 하는지 이름으로 알겠는데, 진짜 맞는지 확인하려고" 다시 함수 몸체 (본문) 로 눈을 돌려야 했습니다.
  • 통계: 간단한 작업에서 함수를 추출했을 때, 해결 시간이 166% 증가했고, 눈이 뒤로 돌아간 횟수 (재귀) 가 200% 증가했습니다.
• 비유: "물 한 잔 마시기"라는 아주 간단한 일을 위해, "물 마시는 법"이라는 별도의 두꺼운 설명서를 만들어서 찾아보게 한 꼴입니다. 오히려 더 귀찮아지고 시간이 더 걸린 것입니다.

🧠 왜 이런 일이 일어날까요? (눈동자가 말해주는 것)

• 신호등 (Beacon) 의 오해: 전문가들은 함수 이름만 봐도 "아, 이거 소금 넣는 구나"라고 바로 이해하고 넘어갑니다 (신호등 효과). 하지만 초보자들은 이름만 믿지 못합니다. "이름이 '소금 넣기'인데, 진짜 소금을 넣는 건가? 아니면 다른 걸까?"라고 의심하며 다시 본문으로 눈을 돌려 확인합니다.
• 눈의 피로: 이 확인 과정 때문에 초보자들의 눈은 코드를 위아래로 왔다 갔다 (Regressions) 하게 되고, 이는 뇌에 큰 피로 (Visual Effort) 를 줍니다.

💡 이 연구가 우리에게 주는 교훈

1. 초보자에게는 "적당한 복잡성"이 중요합니다.

   • 코드가 너무 복잡하면 함수를 나누어주는 것이 좋지만, 너무 단순한 코드까지 나누면 오히려 초보자를 혼란스럽게 합니다.
   • 교육자나 선배 개발자들은 "무조건 깔끔하게 함수를 나누자"라고 가르치기보다, **"이 작업이 정말로 복잡해서 분리할 필요가 있을까?"**를 먼저 고민해야 합니다.

2. 눈동자 추적 (Eye Tracking) 의 중요성.

   • 기존에는 "코드 길이나 복잡도" 같은 숫자만 보고 판단했지만, 이 연구는 사람의 눈이 어떻게 움직이는지를 봐야 진짜 이해도를 알 수 있음을 보여줍니다.

3. 결론:

   • 복잡한 작업: 함수를 나누어주세요 (추출).
   • 아주 간단한 작업: 그냥 한 줄에 다 써주세요 (인라인).
   • 초보자의 눈과 뇌는 생각보다 더 많은 에너지를 써서 코드를 따라갑니다.

이 연구는 **"무조건 좋은 것 (모듈화) 이 모든 상황에 좋은 것은 아니다"**라는 사실을, 초보자들의 눈동자를 통해 증명해낸 매우 의미 있는 결과입니다.

기술 요약

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

• 배경: 개발자들은 코드의 가독성, 이해도, 재사용성을 높이기 위해 리팩토링 (Refactoring) 을 자주 수행합니다. 그중에서도 Extract Method(코드 조각을 별도의 메서드로 분리) 와 Inline Method(메서드 호출을 본체로 대체) 는 가장 흔하게 사용되는 기법입니다.
• 문제: 기존 연구들은 정적 코드 지표 (Static Metrics) 를 사용하여 두 기법의 차이를 분석했으나, 명확한 차이를 찾지 못했습니다. 그러나 코드 이해도와 탐색에 영향을 미치는 인간적 요소 (Human Factor), 특히 개발자의 시각적 노력 (Visual Effort) 과 인지적 부하는 동적으로 측정되지 않았습니다.
• 가설: 의미 있는 메서드 이름 (Beacon) 이 코드의 목적을 직관적으로 알려주어 이해를 돕는다는 기존 이론과 달리, 초보 개발자 (Novices) 의 경우 메서드 추출이 오히려 시각적 탐색 비용을 증가시켜 이해를 방해할 수 있다는 가설을 검증하고자 합니다.

2. 연구 방법론 (Methodology)

이 연구는 동적 접근법 (Dynamic Approach) 으로, 개발자가 코드와 상호작용할 때의 안구 추적 (Eye Tracking) 데이터를 기반으로 합니다.

• 실험 대상:
  • 주 실험: 자바 초보 개발자 32 명 (대학생).
  • 설문 조사: 추가적인 자바 초보 개발자 58 명.
• 실험 설계:
  • 과제: 8 가지 간단한 프로그래밍 과제 (예: 팩토리얼 계산, 정수 합계, 제곱의 면적 계산 등).
  • 처리 (Treatments): 각 과제는 두 가지 버전으로 제공됨.
    1. Inline Method: 로직이 main 메서드 내에 인라인됨.
    2. Extract Method: 로직이 의미 있는 이름의 별도 메서드로 분리됨.
  • 방식: 라틴 사각형 (Latin Square) 설계를 사용하여 학습 효과를 통제. 각 참가자는 4 개는 인라인 버전, 4 개는 추출 버전의 과제를 수행.
• 측정 지표:
  • 성능 지표: 작업 완료 시간, 정답 도출 시도 횟수.
  • 시각적 노력 지표 (Eye Tracking Metrics):
    • 고정 시간 (Fixation Duration): 특정 지점을 응시하는 시간 (인지 처리 노력).
    • 고정 횟수 (Fixation Count): 응시한 지점의 총 수.
    • 회귀 횟수 (Regressions Count): 뒤로 돌아가 다시 읽는 눈동자 움직임 (이해도 부족 또는 흐름 방해).
  • 정성적 데이터: 실험 후 인터뷰 및 설문을 통한 선호도, 어려움, 동기 분석.

3. 주요 기여 (Key Contributions)

1. 안구 추적을 활용한 통제 실험: 자바 초보 개발자를 대상으로 Extract Method 와 Inline Method 의 영향을 객관적인 시각 데이터로 분석한 최초의 연구 중 하나.
2. 정성적/정량적 데이터의 삼각측량 (Triangulation): 실험 성능 데이터, 안구 추적 데이터, 인터뷰 및 설문 조사를 결합하여 개발자의 실제 행동과 인식 (Perception) 간의 괴리를 규명.
3. 새로운 통합 이론 제안: 작업 특성, 코드 표현, 인지 메커니즘, 이해 결과 간의 상호작용을 설명하는 통합 이론 모델을 제시.
4. 재현 패키지 공개: 실험 자료 및 분석 스크립트를 공개하여 연구의 투명성과 재현성 확보.

4. 주요 결과 (Results)

연구 결과는 과제의 복잡성에 따라 Extract Method와 Inline Method의 효과가 극명하게 나뉘었습니다.

• 복잡한 작업 (예: 팩토리얼 계산, 리스트에서 최댓값 찾기):
  • Extract Method 가 우세: 메서드 추출이 수행 시간을 최대 78.8% 단축하고, 회귀 횟수를 84.6% 감소시켰습니다.
  • 이유: 의미 있는 메서드 이름이 'Beacon' 역할을 하여 상향식 (Bottom-up) 분석 대신 하향식 (Top-down) 추론을 가능하게 하여 인지 부하를 줄였습니다.
• 단순한 작업 (예: 제곱의 면적 계산, 짝수 판별):
  • Inline Method 가 우세: 메서드 추출이 수행 시간을 최대 166.9% 증가시키고, 회귀 횟수를 200% 증가시켰습니다.
  • 이유: 로직이 단순할 때 별도의 메서드로 분리하는 것은 불필요한 컨텍스트 스위칭 (Context Switching) 을 유발합니다. 초보자들은 메서드 이름만 믿지 못하고 호출부와 본체를 오가며 (Visual Regressions) 코드를 다시 확인하는 경향이 있어 시각적 노력이 급증했습니다.
• 인식과 행동의 괴리 (Perception vs. Performance):
  • 대부분의 초보자는 가독성과 재사용성을 이유로 추출된 메서드 버전을 선호했습니다.
  • 그러나 실제 성능 데이터는 단순 작업에서 인라인 버전이 더 효율적임을 보여주었습니다. 이는 초보자가 인지적 효율성 (실제 수행) 과 주관적 가독성 (느낌) 을 혼동하고 있음을 시사합니다.
• Beacon 의 한계: 의미 있는 메서드 이름이 항상 초보자의 이해를 돕지는 않습니다. 초보자는 경험 부족으로 메서드 이름을 신뢰하지 않고 본체를 직접 확인하려는 경향이 있어, 오히려 시각적 흐름을 방해했습니다.

5. 의의 및 시사점 (Significance)

• 교육적 시사점: 자바 초보자를 가르치는 교육자들은 미리 (Premature) 한 모듈화 (Extract Method) 에 주의해야 합니다. 단순한 로직에서는 인라인 방식이 오히려 학습 흐름을 방해할 수 있으므로, 작업의 복잡도에 따라 리팩토링 기법을 선택적으로 적용해야 함을 강조합니다.
• 연구적 시사점: 정적 코드 지표만으로는 포착할 수 없는 동적 인지 과정을 안구 추적을 통해 규명할 수 있음을 증명했습니다. 특히 '시각적 회귀 (Visual Regressions)'와 같은 지표가 리팩토링의 실제 영향을 파악하는 데 핵심적임을 보여줍니다.
• 실무적 시사점: 개발 도구 (IDE) 나 교육 자료는 초보자가 리팩토링을 적용할 때 발생할 수 있는 탐색 비용 (Navigation Cost) 을 고려하여 컨텍스트에 맞는 권장 사항을 제공해야 합니다.

결론적으로, 이 연구는 "리팩토링이 무조건 좋다"는 통념을 반박하며, 작업의 복잡성 (Task Complexity) 과 개발자의 숙련도 (Expertise) 가 리팩토링 기법의 선택과 그 효과에 결정적인 역할을 함을 실증적으로 증명했습니다.