Empathy in Software Engineering Education: Evidence, Practices, and Opportunities

이 논문은 2001 년부터 2025 년까지의 43 건의 연구를 체계적으로 분석하여 소프트웨어 공학 교육에서 공감 능력이 윤리적 성찰과 설계 중심의 실천으로 진화하고 있으며, 이를 교육 과정에 체계적으로 통합함으로써 미래 소프트웨어 전문가의 협업, 윤리성, 그리고 책임 있는 혁신 역량을 강화할 수 있음을 시사합니다.

핵심

이 논문은 **"소프트웨어 공학 교육에 '공감 (Empathy)'을 어떻게 가르치고 있는지"**에 대한 거대한 조사 보고서입니다.

쉽게 말해, **"코딩만 잘하는 개발자가 아니라, 사람을 이해하는 개발자를 어떻게 키울 것인가?"**에 대한 답을 찾기 위해 2001 년부터 2025 년까지 발표된 43 개의 연구를 분석한 것입니다.

이 복잡한 내용을 일상적인 언어와 비유로 설명해 드릴게요.

---

🍎 핵심 비유: "요리사 vs. 셰프"

이 논문의 핵심은 **일반 공학 (General Engineering)**과 **소프트웨어 공학 (Software Engineering)**이 '공감'을 바라보는 눈이 조금 다르다는 점입니다.

1. 일반 공학 (건축, 기계, 화학 등): "인간적인 요리사"

   • 이 분야에서는 공학을 배울 때 **"인간을 어떻게 배려할까?"**라는 도덕적, 철학적 질문을 던집니다.
   • 마치 요리를 할 때 "이 음식이 노약자에게 얼마나 따뜻한가?", "사회에 어떤 영향을 줄까?"라고 고민하는 것과 같습니다.
   • 목표: 기술자로서 올바른 인격과 사회적 책임을 갖춘 **'선한 인간'**을 만드는 것입니다.

2. 소프트웨어 공학: "사용자 중심의 셰프"

   • 소프트웨어 공학에서는 공감을 구체적인 도구와 방법으로 바꿉니다.
   • 단순히 "착하게 생각하자"가 아니라, **"사용자 페르소나 (가상 인물) 를 만들고, 공감 지도 (Empathy Map) 를 그려서, 장애인이 앱을 어떻게 사용하는지 시뮬레이션하자"**는 식입니다.
   • 목표: 기술적인 결과물 (앱, 프로그램) 에 사람의 마음을 담는 **'실무 능력'**을 키우는 것입니다.

---

🔍 이 연구가 발견한 3 가지 큰 이야기

1. 공감은 '부수적인 능력'이 아니라 '핵심 기술'이 되고 있다

과거에는 개발자 교육에서 코딩, 알고리즘 같은 '딱딱한 기술 (Hard Skills)'만 중요하게 여겼습니다. 공감은 '부드러운 기술 (Soft Skill)'이라서 뒷전으로 밀려났죠.
하지만 이제는 **"사람을 이해하지 못하면 좋은 소프트웨어를 만들 수 없다"**는 인식이 생겼습니다. 마치 자동차를 설계할 때 운전자와 보행자의 안전을 고려하지 않으면 차를 만들 수 없는 것처럼, 소프트웨어도 사용자 마음을 읽지 못하면 쓸모없어집니다.

2. 어떻게 가르치고 있을까? (실전 예시)

연구에 따르면, 학교에서는 다음과 같은 방법으로 공감을 가르칩니다.

• 시뮬레이션: 학생들이 시각 장애인이 되어 스마트폰을 사용해 보게 하거나, 휠체어를 타고 건물에 들어가는 체험을 시킵니다. (직접 겪어보아야 아픔을 안다는 뜻)
• 스토리텔링: "이 앱을 쓰는 할머니는 어떤 고민이 있을까?"라는 가상의 이야기를 만들어보고, 그 할머니의 입장에서 코드를 짭니다.
• 봉사 활동: 실제 지역 사회의 문제를 해결하는 프로젝트를 하며, 기술이 어떻게 사람들의 삶을 바꿀 수 있는지 체득하게 합니다.

3. 하지만 아직 넘어야 할 산이 많다 (난관들)

모든 것이 완벽하지는 않습니다. 연구자들은 다음과 같은 문제점을 지적했습니다.

• "코딩이 먼저야!": 학교 커리큘럼이 너무 빡빡해서, 공감 수업을 넣을 시간이 부족합니다. "기술 실력이 모든 것을 해결해 줄 거야"라는 생각이 아직 강합니다.
• "측정하기 힘들어": 코딩 실력은 점수로 쉽게 잴 수 있지만, "공감이 얼마나 커졌는지"를 점수로 매기는 것은 매우 어렵습니다.
• "학생들의 거부감": "나는 코딩하러 온 건데, 왜 감정적인 이야기를 해야 하지?"라고 생각하는 학생들도 많습니다.

---

💡 결론: 왜 이 연구가 중요한가?

이 논문은 **"공감은 이제 선택이 아니라 필수"**라고 말합니다.

앞으로의 소프트웨어 교육은 단순히 **"어떻게 코드를 짜는가 (How to code)"**를 가르치는 것을 넘어, **"누구를 위해, 왜 이 코드를 짜는가 (Who and Why)"**를 함께 가르쳐야 합니다.

마무리 비유:
과거의 소프트웨어 교육이 **'레시피 (코드) 만 외우는 요리사'**를 키웠다면, 이제는 **'손님의 입맛과 감정을 읽는 셰프'**를 키우는 시대로 변하고 있습니다. 이 연구는 그 변화를 위한 지도 (Roadmap) 를 제시한 것입니다.

이제 개발자들은 단순히 기계적인 존재가 아니라, 기술로 세상을 따뜻하게 만드는 인간으로 거듭나야 합니다.

기술 요약

논문 개요

본 연구는 소프트웨어 공학 (SE) 교육에서 '공감 (Empathy)'이 어떻게 개념화, 교육, 평가되어 왔는지를 체계적으로 검토한 문헌 분석 (Systematic Review) 입니다. 저자들은 공학 교육 전반과 소프트웨어 공학 교육 내에서의 공감 교육 현황을 비교 분석하여, 공학 교육의 윤리적 성찰과 소프트웨어 공학의 구조화된 설계 실천 사이의 차이와 통합 가능성을 제시합니다.

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

• 기술적 역량의 한계: 소프트웨어 공학은 기술적 능력뿐만 아니라 협업, 의사소통, 윤리적 의사결정을 지원하는 대인관계 능력 (Soft Skills) 을 요구합니다.
• 공감의 중요성: 공감은 사용자 요구사항 도출, 팀워크, 윤리적 설계, 포용성 향상에 필수적이지만, 현재 SE 교육 과정에서는 기술적 숙련도가 우선시되어 공감 교육이 파편화되거나 소홀히 다루어지고 있습니다.
• 연구 격차: 다른 공학 분야나 의료/인문학 분야에서는 공감 교육이 체계적으로 연구되고 있으나, 소프트웨어 공학 교육 내에서의 통합적 접근과 체계적 분석은 부족합니다.
• 핵심 연구 질문 (RQ):
  1. 공학 및 소프트웨어 공학 교육에서 공감은 어떻게 통합되고 있는가?
  2. 공감을 증진시키기 위해 어떤 교수법이 사용되고 있는가?
  3. 공감 적용의 보고된 이점은 무엇인가?
  4. 공감 교육의 적용 시 어떤 도전 과제가 존재하는가?

2. 연구 방법론 (Methodology)

• 연구 유형: 소프트웨어 공학 연구의 체계적 문헌 검토 (Systematic Literature Review, SLR) 가이드라인을 따름.
• 데이터 수집: Google Scholar, IEEE Xplore, ACM Digital Library 등 6 개의 주요 데이터베이스에서 2001 년부터 2025 년까지 발행된 논문을 검색.
• 검색어: "empathy", "engineering education", "software engineering" 등 관련 키워드 조합.
• 선정 기준:
  • 포함 기준 (IC): 공학 프로그램 학습 과정에서 공감 개념의 적용, 촉진, 평가, 이점 또는 한계를 명시적으로 다룬 연구.
  • 제외 기준 (EC): 공학 교육 맥락이 아님, 초록/짧은 논문 (5 페이지 미만), 접근 불가, 비영어권, 중복 연구 등.
• 분석 대상: 초기 374 건의 검색 결과 중 최종 43 건의 주요 연구가 선정됨.
• 분석 기법:
  • 기술적 분석 (Descriptive Analysis): 연도별, 학문별 연구 트렌드 및 분포 분석.
  • 주제 분석 (Thematic Synthesis): 공감의 정의, 교수법, 이점, 도전 과제 등을 코딩하여 주제별로 종합.

3. 주요 기여 (Key Contributions)

1. 매핑 연구 (Mapping Study): 공학 및 소프트웨어 공학 교육 전반에 걸친 43 건의 연구를 종합하여 공감의 사용, 교육, 평가 방식을 체계화함.
2. 비교 분석 (Comparative Analysis): 일반 공학 교육이 공감을 '윤리적 성찰 역량'으로 규정하는 반면, 소프트웨어 공학은 이를 '구조화되고 측정 가능한 설계 실천'으로 전환시킨다는 점을 규명함.
3. 교육적 기준 마련 (Educational Baseline): 소프트웨어 공학 교육에 공감을 체계적으로 통합하기 위한 증거 기반의 교수법과 실천 가이드를 제시함.

4. 주요 연구 결과 (Results)

가. 공감의 개념화 및 통합 방식 (RQ1)

• 일반 공학 (General Engineering): 공감을 사회적 책임과 연결된 윤리적, 성찰적 역량으로 강조. 철학적 논의, 윤리 토론, 전문성 형성을 통해 통합.
• 소프트웨어 공학 (Software Engineering): 공감을 사용자 중심 설계 (User-Centered Design) 와 직접 연결된 측정 가능한 실천으로 정의. 공감 지도 (Empathy Maps), 페르소나, 이해관계자 인터뷰 등 구체적인 설계 도구로 활용.

나. 교수법 (RQ2)

• 공통점: 반성적 학습 (Reflection), 디자인 씽킹, 서비스 러닝 (Service Learning), 체험 학습.
• 차이점:
  • 일반 공학: 인문학적 접근, 윤리 토론, 지역사회 참여 프로젝트 중심.
  • 소프트웨어 공학: 요구사항 공학, 접근성 (Accessibility) 재설계, 장애 시뮬레이션, 팀 기반 프로그래밍 내 공감 평가 등 기술 개발 주기와 결합된 구조화된 활동 강조.

다. 이점 (RQ3)

• 학습 및 전문성 향상: 문제 해결 능력의 확장 (사회적 맥락 고려), 팀워크 및 의사소통 능력 증진.
• 윤리적 인식: 편향 (Bias) 인식 및 완화, 포용적 설계, 사회적 책임감 고취.
• 동기 부여: 기술 학습과 사회적 의미의 연결을 통한 학생 참여도 향상.
• 소프트웨어 특화 이점: 실제 사용자 요구에 부합하는 포용적이고 접근 가능한 소프트웨어 설계 능력 함양.

라. 도전 과제 (RQ4)

• 우선순위 부족: 기술적 역량에 비해 공감이 부차적으로 취급됨.
• 측정의 어려움: 공감의 정량적 평가 도구 부재 및 공감과 유사 개념 (동정, 도덕적 추론) 과의 구분 난해.
• 학생의 저항: 기술적 편안함에서 벗어나 감정적/인간적 학습에 대한 거부감.
• 커리큘럼 제약: 과중한 과목 부담, 짧은 수업 시간으로 인한 심층적 학습의 어려움.
• 문화적 장벽: 공학 중심의 문화와 인문/사회과학 간의 소통 부재.

5. 의의 및 결론 (Significance & Conclusion)

• 패러다임의 전환: 공감은 더 이상 단순한 '부수적 소프트 스킬'이 아닌, 소프트웨어 공학 교육에서 측정 가능하고 평가 가능한 교육적 구성 요소 (Pedagogical Construct) 로 진화하고 있음.
• 실천적 시사점:
  • 공감 교육을 단발성 활동이 아닌, 설계 및 개발 과정 전반에 걸쳐 지속적이고 평가 가능한 요소로 커리큘럼에 통합해야 함.
  • 반성적 평가와 산출물 (Artifact) 기반 평가를 결합하여 공감 발달을 가시화해야 함.
• 미래 연구 방향: 공감 기반 개입이 소프트웨어 품질, 편향 완화, 팀 역학에 미치는 영향을 장기적으로 추적하는 연구와, 교수자 및 기관 차원의 지원 체계 구축이 필요함.

결론적으로, 본 논문은 소프트웨어 공학 교육이 기술적 엄밀함과 인간 중심의 윤리적 성찰을 결합하여, 더 책임 있고 포용적인 소프트웨어를 개발할 수 있는 전문가를 양성하기 위해 공감 교육을 체계화해야 할 시점임을 강력히 주장합니다.