RFICE 프로젝트 외주 협업 회고: 베트남 개발자와의 협업 경험

작성 목적

RFICE 프로젝트에서 베트남 외주 인력과의 코드 협업 경험을 바탕으로, 주요 내용, 발생 이슈, 그리고 개인적인 소감을 정리했습니다.

본 회고는 향후 외주 개발자 운영에 있어 더 나은 개발 방향을 모색하는 데 기여하고자 합니다.

프로젝트 환경

운용 형태

기존 국내 프로젝트와 동일하게 Redmine과 Slack을 주요 협업 툴로 활용하여 개발을 진행했습니다.

팀 구성

프론트엔드 개발 인원:

국내 개발자: 5인
외주 개발자: 7인
- PM: 1인
- TL: 1인
- 개발자: 5인
- 커뮤니케이터(CC): 1인

총 12인의 프론트엔드 팀

역할 분담

국내 개발자:

서비스의 핵심 코드 작성
가이드 제공
코드 리뷰 및 승인

외주 개발자:

TOBE 버전 타겟의 추가 작업
특정 서비스 담당 (예: 회의-기능)
국내 개발자의 가이드에 따른 개발

코드 가이드 프로세스

기능별 국내 담당 개발자 지정
  ↓
외주 개발자 작업
  ↓
PR 제출
  ↓
국내 개발자 리뷰
  ↓
승인 하에 머지

각 기능별로 국내 담당 개발자가 지정되어 있으며, 국내 개발자의 승인 하에 해당 코드가 머지됩니다.

커뮤니케이션 방식

온라인 중심:

RemoteMeeting: 화상 회의
Slack: 실시간 소통 및 업무 공유
Redmine: 일감 관리 및 진척도 추적

추가 기획 및 미팅:

사내 인원 (PM, 기획, BE)과 협의
Slack 및 화상회의 통한 실시간 가이드

발생한 문제점 회고

아래 문제점들은 외주 개발자와의 협업을 진행하며 느낀 지극히 개인적인 의견이며, 외주 인력 운영 시 겪었던 어려움들을 주제별로 정리했습니다.

1. 채용 과정의 문제: 적합한 인재 여부 확인 필요

문제의 핵심

현 서비스 개발에 적합한 인재인지를 정확하게 판단하기 위해서는 사전 채용 과정에서 면접, 테스트, 포트폴리오를 통한 정밀한 검증이 필수적입니다.

1.1. 이력서와 다른 실제 역량

문제 상황:

이력서에 기재된 내용과 현저히 다른 개발자의 미달 역량 확인
중개 업체를 통한 경력 부풀리기
허위 이력서 기재 사례 발견

실제 사례:

이력서: "React 3년 경력, Redux 전문가"
실제: Hooks 모름, Redux Toolkit 사용 불가

1.2. 사전 테스트의 불공정성

테스트 내용:

React를 활용한 TODO 리스트 작성

발견된 문제:

응시자 간 코드 공유
GitHub 등에서 유사 코드 복사하여 테스트 완료
실제 코딩 능력과 테스트 결과 불일치

결과:

테스트: 완벽한 TODO 앱 제출
실제 업무: 간단한 컴포넌트도 작성 못함

개선 방안

제안 1: 라이브 코딩 테스트

- 화상으로 실시간 코딩
- 간단한 문제 30분 내 해결
- 복사-붙여넣기 불가능
- 사고 과정 관찰 가능

제안 2: 코드 리뷰 테스트

- 버그가 있는 코드 제공
- 문제점 찾기 및 개선안 제시
- 실제 업무 능력 평가

제안 3: 프로빙 인터뷰

- 제출한 코드에 대한 질문
- "이 부분은 왜 이렇게 작성했나요?"
- 진짜 본인이 작성했는지 확인

2. 베이스 코드 이해 부족으로 인한 코드 품질 저하

적응 시간의 차이

국내 개발자:

자국어 사용
오프라인 소통
지속적인 실시간 소통
비교적 빠른 적응

외주 개발자:

온라인 툴 의존
코드를 통한 간접 소통
커뮤니케이션에 상당한 시간 소모 (약 20~30분)
심지어 코드 두 줄 작성에 3시간 소요되는 경우도 발생

목적과 이해의 충돌

외주 개발자의 우선순위:

Redmine 일감 데드라인 준수
  >> 코드 이해

결과:

담당 인원이 코드 안정기에 접어들기 전
코드 이해도가 낮은 상태에서 작업 진행
코드 품질 저하

실제 사례:

// 요구사항: 사용자 목록 필터링 기능 추가
 
// 베이스 코드 패턴 (이해해야 할 것)
const users = useSelector(state => state.users);
const filteredUsers = useMemo(
  () => users.filter(filterFunction),
  [users, filterFunction]
);
 
// 외주 개발자 코드 (이해 없이 작성)
let result = [];
for (let i = 0; i < users.length; i++) {
  if (users[i].active === true) {
    result.push(users[i]);
  }
}
// 기존 패턴 무시, Redux 스토어 직접 수정 시도 등

악순환

시간 압박
  ↓
충분한 이해 없이 코드 작성
  ↓
코드 품질 저하
  ↓
리뷰에서 수정 요청
  ↓
더 많은 시간 소요
  ↓
더 큰 시간 압박

3. 코드 주인의식 부재

코드 리뷰의 어려움

코드 리뷰 프로세스:

리뷰어는 기본 베이스 코드 및 히스토리 이해를 바탕으로 진행
개발 방법론 및 코드 방향이 부적절할 경우 피드백 제공
개선 유도

그러나 실제로는:

오번역 문제
개발자의 역량 부족
국내 담당 개발자 존재로 인한 안일함

가장 큰 문제: 주인의식 부재

관찰된 패턴:

문제 인식
  ↓
"이건 국내 개발자가 고쳐주겠지"
  ↓
깊이 고려하지 않고 코드 작성
  ↓
품질 낮은 코드 제출

구체적 사례:

// 명백히 잘못된 코드
function handleClick() {
  // TODO: 나중에 고치기
  globalVariable = 123;  // 전역 변수 직접 수정
  localStorage.setItem('temp', data);  // 임시 저장
}
 
// PR 코멘트: "이거 나중에 리팩토링 해주세요"
// 실제: 영원히 안 고쳐짐

문제의 본질:

주어진 코드 환경에서 문맥에 따른 적절한 코드 작성을 추론 가능함에도
Redmine 일감 해결을 위한 단순 코드 기입에 그침
적절한 해결 방안에 대해 깊이 고려하지 않음

코드 리뷰 생태계에 미치는 악영향

국내 담당 개발자의 고충:

베이스 코드 오염
- 불필요한 코드 증가
- 기술 부채 누적
작업 공유 간 이해를 위한 시간 및 노력 소모
- “이 코드는 왜 이렇게 작성됐지?”
- 문맥 파악에 추가 시간
개발자 역량 의심
- “이 사람이 정말 개발할 수 있나?”
- 신뢰 하락
상당한 스트레스
- 리뷰어로서의 책임감
- 계속되는 품질 문제

결과:

개발자 간 개인적인 갈등
협업의 어려움
팀 분위기 악화

4. 결국 국내 개발자에게 돌아오는 일감

책임의 귀결

문제 발생 시 책임 소재:

BE/기획/디자인과의 소통 문제
  → 국내 개발자 참조

개발 어려움
  → 국내 개발자의 실시간 가이드

외주 작업자 퇴사/일감 포기
  → 국내 개발자가 인수

최악의 시나리오

RFICE 알림 기능 사례:

1차 버전 외주 개발자 완료
  ↓
추가 작업 외주 할당
  ↓
버전 업데이트마다 QA 실패
  ↓
지속적인 코드 불안정
  ↓
PM의 국내 개발자 작업 요청
  ↓
결국 처음부터 다시 작성

시간 계산:

외주 개발: 2개월
QA 실패 및 수정: 1개월
국내 개발자 재작업: 2주

총 시간: 3개월 이상
만약 처음부터 국내 개발자: 3주

낭비된 시간: 2개월 이상

추가 업무 부담

국내 개발자의 실제 업무:

본인 담당 개발
  +
외주 코드 리뷰 (시간 많이 소요)
  +
외주 개발자 가이드
  +
소통 문제 중재
  +
비상시 외주 작업 인수
  =
업무 과부하

자주 드는 생각:

“차라리 내가 할 걸…”

총평 및 개선 방안

현실적인 어려움

외주 개발자들과의 소통 및 코드 가이드에 상당한 시간과 노력이 소모되었습니다.

발생한 문제들:

상호 간의 불신
지속적인 스트레스
협업의 어려움
예상치 못한 추가 업무

그럼에도 불구하고

외주 개발자 활용이 필요한 이유:

인력 부족 해소
빠른 개발 속도
비용 효율성 (이론상)

개선 방안 제안

1. 채용 단계 개선

강화된 검증 프로세스:

1단계: 포트폴리오 심사
  ↓
2단계: 라이브 코딩 테스트
  ↓
3단계: 코드 리뷰 테스트
  ↓
4단계: 프로빙 인터뷰
  ↓
5단계: 시범 프로젝트 (1주일)

2. 온보딩 프로세스 강화

체계적인 교육:

Week 1: 프로젝트 구조 이해
  - 전체 아키텍처
  - 주요 모듈
  - 코딩 컨벤션

Week 2: 베이스 코드 학습
  - 공통 유틸 함수
  - 주요 패턴
  - 자주 사용하는 컴포넌트

Week 3: 간단한 태스크 할당
  - UI 수정
  - 간단한 기능 추가
  - 코드 리뷰 경험

Week 4: 실제 개발 시작

3. 코드 품질 관리

명확한 가이드라인:

## 필수 사항
- [ ] 기존 패턴 따르기
- [ ] 테스트 코드 작성
- [ ] 주석으로 복잡한 로직 설명
- [ ] 타입 정의 (TypeScript)
- [ ] 에러 핸들링
 
## 금지 사항
- [ ] 전역 변수 수정
- [ ] 죽은 코드 남기기
- [ ] TODO 주석으로 끝내기
- [ ] 하드코딩

4. 커뮤니케이션 개선

정기적인 동기화:

매일 오전: 15분 스탠드업
  - 어제 한 일
  - 오늘 할 일
  - 막힌 부분

매주 금요일: 1시간 회고
  - 이번 주 성과
  - 어려웠던 점
  - 개선 방안

5. 책임과 권한의 명확화

역할 정의:

국내 개발자:
  - 핵심 기능 개발
  - 아키텍처 설계
  - 최종 코드 리뷰

외주 TL:
  - 팀원 코드 1차 리뷰
  - 업무 배분
  - 품질 관리

외주 개발자:
  - 할당된 기능 개발
  - 자체 테스트
  - 문서화

기대 효과

이러한 개선을 통해:

✅ 채용 단계에서 적합한 인재 선별
✅ 체계적인 온보딩으로 적응 기간 단축
✅ 명확한 가이드라인으로 코드 품질 향상
✅ 원활한 커뮤니케이션으로 오해 감소
✅ 명확한 역할로 책임 소재 분명

마치며

솔직한 심정

이번 외주 협업은 예상보다 훨씬 어려웠습니다.

느낀 감정들:

답답함
스트레스
불신
피로

하지만 동시에:

배움
성장
문제 해결 능력 향상

미래를 위한 제안

이번 회고를 기반으로 국내 개발자들 간에 외주 개발자 운용 가이드라인 및 책임에 대해 논의하는 자리가 마련되기를 희망합니다.

논의할 주제들:

채용 프로세스 개선
온보딩 표준화
코드 리뷰 기준
커뮤니케이션 프로토콜
책임과 권한 정의

긍정적인 측면도

모든 것이 부정적이지만은 않았습니다:

일부 우수한 외주 개발자도 있었음
문화적 차이를 이해하는 계기
글로벌 협업 경험
프로세스 개선의 필요성 인식

결론

외주 개발자 활용은 필요하지만 쉽지 않은 선택입니다.

성공적인 외주 협업을 위해서는:

체계적인 프로세스
명확한 가이드라인
지속적인 소통
상호 존중과 이해

이 모든 것이 갖춰져야 합니다.

이번 경험이 더 나은 외주 협업 문화를 만드는 데 도움이 되기를 바랍니다.

4sizn blog

Explorer