The Role of LLMs in Collaborative Software Design

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

• 배경: 대규모 언어 모델 (LLM) 은 개인적인 코딩 작업 (Solo Development) 에 있어서는 많은 연구가 이루어졌으나, 소프트웨어 공학의 핵심 활동인 협업적 그룹 작업 (Collaborative Group Work), 특히 소프트웨어 설계 (Software Design) 단계에서 LLM 이 어떻게 영향을 미치는지에 대한 연구는 부족합니다.
• 문제: 소프트웨어 설계는 요구사항을 현실화하고 품질 속성 (확장성, 보안 등) 간의 트레이드오프를 결정하는 복잡한 과정으로, 인간 중심의 협업 활동입니다. LLM 이 이러한 설계 과정에서 어떻게 활용되는지, 그리고 그것이 팀의 협업 패턴과 설계 결과에 어떤 영향을 미치는지에 대한 실증적 연구가 부재했습니다.
• 연구 질문 (RQs):
  1. 설계자가 LLM 에 접근할 때 어떤 협업 패턴이 나타나는가?
  2. 설계자는 LLM 을 어떤 목적으로 어떻게 사용하는가?
  3. 설계자는 LLM 의 응답을 어떻게 해석하고 행동에 반영하는가?
  4. 설계자들은 소프트웨어 설계에 LLM 을 사용하는 것에 대해 어떻게 인식하는가?

2. 연구 방법론 (Methodology)

• 연구 설계: 탐색적 실험실 연구 (Exploratory Laboratory Study).
• 참가자: 소프트웨어 설계 경험이 있는 전문가 36 명 (18 개의 쌍, Pair). 경력은 1 년에서 20 년 이상까지 다양하며, 기술직 (엔지니어, 아키텍트) 과 비기술직 (UX, PM) 이 혼재되어 있음.
• 작업 과제: 단일 대학 캠퍼스 내 자전거 주차를 돕는 모바일 애플리케이션 설계.
  • 입력: 제품 요구사항 문서 (PRD) 와 6 가지 핵심 기능 제공.
  • 제약: 90 분 이내, 원격 (Zoom) 협업, 자체적인 설계 도구 사용 허용.
  • LLM 환경: ChatGPT API 를 기반으로 한 커스텀 챗 툴 제공. 각 파트너는 독립적으로 LLM 을 호출할 수 있었으며, 상호작용 로그가 기록됨.
• 데이터 수집:
  • Zoom 회의 녹화 (설계 세션 및 인터뷰).
  • LLM 프롬프트 및 응답 로그.
  • 최종 설계 문서.
  • 사후 인터뷰 (Exit Interview).
• 분석 방법:
  • 질적 분석: 귀납적/연역적 코딩 (Abductive Coding) 을 통해 대화 로그, 녹화 영상, 인터뷰를 분석.
  • 주요 분석 대상: 협업 패턴, LLM 의 역할 부여, 응답 해석 및 검증 과정, 참가자의 인식.

3. 주요 기여 및 발견 (Key Contributions & Results)

3.1 협업 패턴 (Collaboration Patterns - RQ1)

LLM 사용 시 두 가지 주요 패턴이 관찰됨:

1. 공유 인스턴스 사용 (Shared Instance): 한 쌍이 하나의 LLM 세션을 공유하며 한 사람이 프롬프트 입력 (Driver), 다른 사람이 검토하는 '페어 프로그래밍' 방식. 이는 공유 이해 (Shared Understanding) 형성에 유리함.
2. 별도 인스턴스 사용 (Separate Instances): 각자가 별도의 LLM 세션을 사용.
   • 동시 작업 시: 서로 다른 프롬프트를 입력하거나 동일한 프롬프트로 다른 응답을 비교하여 아이디어를 확장하기도 함.
   • 단독 작업 시: 하위 작업 분담 시 발생. 이 경우 맥락 드리프트 (Context Drift) 가 발생하여 설계 방향이 불일치할 수 있음.

3.2 LLM 의 역할 (Roles of LLM - RQ2)

참가자들은 LLM 을 다음과 같은 4 가지 역할 중 하나로 정의하여 사용함:

1. 사용 안 함 (No Role): 2 쌍. LLM 의 신뢰성 부족, 비용 대비 효과 불명확, 자체 역량에 대한 자신감으로 인해 사용 거부.
2. 정보원 (Information Source): 5 쌍. 지식 격차 해소 (예: Google Maps API, DB 종류) 를 위해 검색 엔진처럼 사용. 설계는 인간이 주도.
3. 생성자 (Generator): 8 쌍. 설계 산출물 (데이터 모델, API 정의 등) 의 초안 (Starting Point) 을 생성하도록 요청. 생성된 내용을 인간이 수정, 정제하여 사용.
4. 생산자 (Producer): 3 쌍. LLM 이 전체 설계 문서를 생성하도록 지시. 인간은 프롬프트를 통해 방향을 설정하고 결과를 검토하는 역할만 수행.

3.3 응답 해석 및 행동 (Interpretation & Action - RQ3)

• 검증 및 비판적 검토: 설계자들은 LLM 의 응답을 맹신하지 않고 PRD, 기존 설계, 외부 도구 (PlantUML 등) 와 비교하여 검증함.
• 반성적 통찰: LLM 응답을 통해 설계의 누락된 부분이나 새로운 요구사항을 발견하고 설계 방향을 수정함.
• 반복적 개선 (Iteration): 오류 수정, 컨텍스트 추가, 제약 조건 명시 등을 통해 LLM 과의 대화 (Prompt-Review-Revise) 를 반복하여 출력을 정제함.
• 초기 고정 (Early Anchoring) 의 위험: LLM 이 생성한 첫 번째 응답에 매몰되어 대안 탐색이 제한되는 현상이 관찰됨.

3.4 설계자의 인식 (Perceptions - RQ4)

• 신뢰 문제: 할루시네이션 (Hallucination) 에 대한 우려로 인해 인간이 반드시 검증해야 함.
• 자신감 증가: LLM 을 통해 '현실성 확인 (Sanity Check)'을 받거나 '미지의 영역'을 파악함으로써 설계에 대한 자신감이 높아짐.
• 인간 파트너십의 가치: LLM 만으로는 잘못된 가정을 할 수 있으므로, 인간 파트너와의 협력이 필수적임.
• 적합성: LLM 은 '스파이크 작업 (Spike works)', '고수준 설계', '초기 설계'에는 유용하나, 세부적이고 복잡한 구현 단계에서는 인간이 직접 하는 것이 효율적일 수 있음.

4. 연구의 의의 및 시사점 (Significance & Implications)

• 도구 설계에 대한 시사점:
  • 포크 (Fork) 및 머지 (Merge) 기능: 병렬적인 설계 탐색을 위해 LLM 인스턴스를 분기 (Fork) 하고, 이후 결과를 비교하여 통합 (Merge) 할 수 있는 기능 필요.
  • 맥락 드리프트 방지: 팀원 간 LLM 컨텍스트 불일치를 감지하고 조율할 수 있는 기능 제공.
  • 인지 편향 완화: '초기 고정 (Anchoring)'이나 '설계 고착 (Fixation)'을 방지하기 위해 대안 제시 기능을 강화.
• 이론적 기여:
  • LLM 이 설계 과정에서 '경계 객체 (Boundary Object)'로 작용하여 팀원 간 이해를 조정하고 협상을 돕는다는 점 규명.
  • 설계의 중심은 여전히 인간 전문가이며, LLM 은 보조 도구로 활용되어 인간이 출력을 비판적으로 검토하고 적응시키는 과정이 핵심임을 확인.
• 한계점:
  • 실험실 환경 (녹지 설계) 에서 수행되어 실제 산업 환경의 복잡성과는 차이가 있을 수 있음.
  • LLM 모델의 빠른 발전으로 인해 향후 연구에서 재검토 필요.

결론

이 연구는 LLM 이 소프트웨어 설계 협업에 도입될 때, 공유 vs. 별도 인스턴스 사용이라는 새로운 협업 패턴을 만들고, 정보원부터 생산자까지 다양한 역할로 활용됨을 밝혔습니다. 핵심은 설계자가 LLM 의 출력을 맹목적으로 받아들이지 않고, 비판적으로 검토하고 인간 중심의 의사결정을 유지한다는 점입니다. 향후 도구는 이러한 인간 - LLM 협업의 효율성을 높이면서도 인간의 통제권을 보장하는 방향으로 발전해야 합니다.