사내애 copilot 전파를 위해 작성한 가이드 문서입니다. 코파일럿을 1년 정도 사용하면서 느꼈던 점, 더 나은 copilot 사용을 위해 도입해볼 포인트를 정리한 내용입니다. 기초 가이드는 여기서 확인 가능합니다.

1. 개요

• 적용 기간 : 2023.04 ~ 현재
• 적용 프로젝트 : 데이터 분석 플랫폼 프론트엔드, 소셜 데이팅 앱 백엔드, 소셜 데이팅 앱의 admin 백엔드, 가상 성형 견적 앱 백엔드
• 주요 사용 기능 : copliot 자동 완성, copilot chat
• 개선 측정 지표
  1. 동일 기간 대비 개인 사이드 프로젝트의 개발 속도와 비교
  2. 프로젝트 내 copilot의 코드로 작성된 비율
• 개선 사항
  1. 동일 기간 대비 개인 사이드 프로젝트의 개발 속도와 비교 시 약 55% 속도 향상
  2. 소셜 데이팅 앱 백엔드의 경우 copliot으로 작성한 코드 비율 약 65%
• 핵심 포인트
  • copilot의 유효 코드 작성을 높이려면 일관된 코드 작성 규칙 필요
  • copilot을 통해 생산성을 높일 수 있는 지점은 개발이 초기가 아닌 개발 진행 중인 중반 단계
  • copilot 사내 도입 시 수치로 생산성 향상을 관리할 수 있는 지점 및 측정 매트릭스 필요

2. 코파일럿 사용 방법

1. Suggestions matching public code 비활성화

코파일럿의 추천 코드 우선 순위는 코드가 작성되고 있는 프로젝트 > 공용으로 학습한 코드 > 개인 레포지토리를 우선으로 가집니다.

그에 따라 해당 옵션이 활성화되어 있을 경우 프로젝트 초기 단계에서 유효한 코드를 추천 받기 어렵습니다.

2. 의미를 추론할 수 있는 샘플 코드 작성

ex) userOption에 Yn 컬럼이 의미하는 바를 함수로 표현

@Getter
public class UserOption {
    private Long userId;
    private String noticeConversationYn;
    private String noticeNewMatchesYn;
    private String noticePromotionsYn;
    private String noticeMessagesYn;
    private String termsThirdPartyYn;
		
		//...

    private String convertYnByBoolean(boolean value) {
        return value ? Y_VALUE_BY_YN_COLUMN : N_VALUE_BY_YN_COLUMN;
    }
}

코파일럿의 비효율성과 사용감 저해는 주로 프로젝트 초기에 발생합니다. 이는 코파일럿이 추천 동작을 위해 참고할 코드의 양이 절대적으로 적고, 대부분의 코파일럿 사용 가이드에서 Suggestions matching public code 옵션을 활성화하는 방향을 추천하기 때문에 도메인에 적합한 코드가 추천되는 것이 아니라 공용에서 유사하게 사용한 코드를 추천하게 됩니다.

이러한 문제를 해결하기 위해 실제 해당 코드를 사용하지 않더라도 의미를 추론할 수 있는 코드를 작성해야 코파일럿이 유효한 코드를 응답할 가능성을 높일 수 있습니다.

위의 예시는 코파일럿이 Yn이라는 컬럼이 무엇을 의미하는지 추론할 수 있도록 작성한 convertYnByBoolean 함수를 학습하도록 유도합니다.

Y는 true를, N은 false를 의미함을 코파일럿이 추론할 수 있도록 코드를 작성합니다.

3. 코드 컨벤션을 통한 정확도 높은 추론 유도

개인적으로 코파일럿을 사용하면서 추천 코드의 유효율을 높이는 가장 중요한 방법이라고 생각합니다.

저는 주로 코파일럿의 자동완성 기능을 사용했습니다.

copilot 자동 완성의 경우, 기존에 잘 사용하던 Spring JPA와 사용 방식이 아주 유사했습니다. spring JPA가 사용한 함수의 이름에 따라 어떤 데이터를 쿼리해올지 결정하는 것처럼 코파일럿의 자동완성은 제가 작성한 함수명에 따라 작성할 코드를 추천해줍니다. 한 가지 차이점이라면 spring JPA의 경우 인터페이스이기 때문에 내부 동작을 사용자가 정의할 수 없지만 코파일럿은 추천한 코드를 상세하게 살펴볼 수 있다는 점이었습니다.

ex) spring JPA

public interface MemberRepository extends JpaRepository<Member,Long> {
	
	List<Member> findByUsernameAndAgeGreaterThan(String username, int age);	
}

ex) copilot

다만, 이 과정에서 spring JPA처럼 코드를 추론할 수 있도록 함수에 대한 용어 정의가 필요했습니다. 예를 들어 ‘함수의 동사가 find라면 찾아온 return 오브젝트가 없을 경우 null을 반환한다, get이라면 찾아온 return 오브젝트가 없을 경우 exception을 발생 시킨다’와 같이 용어를 한정하고 한정한 용어의 사용처를 명확하게 약속해서 사용해야 했습니다.

이 과정이 소셜 데이팅 앱 Giddy의 백엔드 개발에서 유효하게 동작했는데, Giddy의 백엔드는 주로 제가 개발하고 PL님은 추가적인 이슈들에 대한 지원을 하는 방향이었기 때문에 온전히 제가 사용하던 코드 컨벤션에 따라 개발할 수 있었습니다. (아직 회사에는 명확한 코드 컨벤션이 정의되어 있지 않았기 때문에 저의 컨벤션을 일관적으로 사용할 수 있었습니다)

위처럼 사내 혹은 개발팀 단위 간에 컨벤션을 명확하게 지정할 수 있어야 합니다. 컨벤션이 지켜지지 않는다면 코파일럿은 유효하지 못한 코드를 추천할 가능성이 높아집니다.

4. 코파일럿의 효율성이 증가하는 구간은 개발 중반

앞서 다뤘던 2번 의미를 추론할 수 있는 샘플 코드 작성과 연결되는 부분입니다. 프로젝트 개발 초반에는 코파일럿이 학습할 레퍼런스와 유효한 코드가 부족하기 때문에 대부분의 샘플 코드 혹은 기본적인 비즈니스 로직은 개발자가 직접 작성하게 됩니다.

개발자가 작성하는 코드의 양 증가는 코파일럿이 학습할 수 있는 레퍼런스의 증가로 이어지고, 이는 코파일럿의 생산성이 향상되는 결과를 가져옵니다.

다만 아래의 그래프와 이야기는 제 개인 경험을 통해 추론한 내용입니다. 절대적인 지표를 가지고 측정하거나 잘 만들어진 매트릭스를 기반으로 분석한 데이터가 아니라는 점 미리 명시합니다.

(x축은 개발 진행도, y축은 생산성을 의미 합니다. 매트릭스를 사용하지 않았기 때문에 y축의 값은 임의로 추가한 값입니다)

초기의 샘플 코드 작성이 끝나게 되면 코파일럿을 통한 생산성은 급격하게 증가합니다. 이후 기본 기능 개발이 완료되면 코파일럿의 사용도는 보다 감소합니다. 이후부턴 코파일럿에 의해 추천 받은 코드들이 문제를 일으키는 것은 없는지 개발자가 검수하거나 검증하는 단계를 거칩니다. 이 케이스에서 발생하는 이슈들 또한 코파일럿을 통해 대응할 수 있기 때문에 생산성 자체는 떨어지지만 0에 수렴하지는 않습니다.

그렇기 때문에 코파일럿의 도입 시점에 대해 명확하게 고민할 필요가 있습니다. 특히, 상용화된 제품을 지속적으로 유지 보수하지 않고 계속 새로운 프로젝트를 개발해야 하는 SI 환경에서 코파일럿은 초반 프로젝트 세팅에는 크게 영향을 주기 어렵습니다.

5. 테스트 코드 도입

어떠한 코드든 100% 신뢰할 수 있는 코드는 없습니다. 하물며 코파일럿이 제공한 코드는 실제 비즈니스 로직을 이해하고 있는 개발자에게서 나온 코드가 아니기 때문에 더더욱 신뢰하기 힘듭니다. 그렇기 때문에 개발 과정에서 테스트 중심으로 개발을 해야 합니다.

코파일럿이 작성한 코드를 검증해야 합니다. 다양한 케이스에서 코파일럿의 코드가 의도한 결과를 도출하는지 계속 테스트 케이스를 작성하고 테스트 코드를 통해 검증해야 합니다.

가상 성형 앱 개발 중반부에 선배님을 통해 테스트 코드를 작성하는 방법을 대략 학습했고, 이후 코파일럿을 통해 개발한 코드들은 최대한 의도한 결과를 응답하는지 확인하는 과정을 진행하려고 했습니다.

다만, 테스트 코드의 작성 역량 부족으로 이 부분은 실제로 적용을 많이 해보지 못했습니다. 다만 앞으로의 코파일럿 사용 목표는 copilot chat을 통한 테스트 케이스 및 실제 동작할 테스트 코드를 작성하는 법을 다음 프로젝트에 도입해서 사용해볼 예정입니다.

3. 다음 할 일

이 부분은 사내에 코파일럿 도입에 대한 효과 및 그에 따라 제가 진행할 다음 스텝을 명시한 내용입니다. 사내에 코파일럿 도입을 하기 위한 제 목표를 다룬 내용이니 코파일럿을 어떻게 잘 쓸 것인가가 궁금했던 분들은 넘어가시면 됩니다.

코파일럿 도입으로 무엇을 향상시킬 수 있는가를 묻는다면 바로 생산성 입니다.

기업에서 도입하는 모든 프로세스는 숫자라는 근거를 필요로 합니다. 그리고 이러한 숫자를 만들 수 있는 건 가설을 세우고 검증하는 과정을 통해 도입 여부를 결정하게 됩니다.

코파일럿 도입을 통해 생산성 향상이라는 주안점을 둔다면 코파일럿 도입을 통해 저는 숫자를 만드는 일에 집중할 예정입니다.

이 과정에서 선행되어야할 것은 다음과 같습니다.

1. 생산성이란 무엇인가
   1. 코파일럿 파트의 목표는 생산성 향상입니다. 그렇다면 향상시켜야할 생산성이 무엇인지 정의해야 합니다.
2. 생산성은 어떻게 측정할 것인가
   1. 목표가 정의되었다면 목표를 측정할 수 있어야 합니다. 정의한 생산성 이라는 목표를 숫자로 바꿔 표현할 수 있도록 측정 방식과 기준을 정해야 합니다.
3. 생산성을 측정할 대상이 있는가
   1. 생산성 을 측정할 수 있는 테스트 그룹이 있어야 합니다. 테스트 그룹은 전체 사내 직원이 될 수 없습니다. 이들은 너무나 광범위한 개별적인 업무 목표를 가지고 있고, 그에 따라 정의한 생산성을 측정할 수 없습니다.
   2. 테스트 그룹은 가장 작고, 그룹이 실무 레벨에서 동일한 업무 목표를 가지고 있어야 합니다. 가령 가상 성형 견적 앱 프로젝트 팀은 가상 성형 견적 앱 프로젝트를 일정 기한 내 개발을 완수하는 동일한 업무 목표를 가지고 있습니다.
   3. 그에 따른 고려 대상은 신규 프로젝트 개발 그룹, 혹은 현재 코파일럿을 1년째 도입해 운영하고 있는 타팀의 프로젝트가 있습니다.

이렇게 선행할 항목들이 준비되었다면 반복적으로 진행할 업무는 다음과 같습니다.

1. 생산성 향상을 위한 가설 세우기
   1. 코파일럿을 사용하며 생산성을 향상 시킬 수 있는 가설을 세웁니다.
   2. 가설은 생산성 향상이라는 목표에 부합하는 숫자를 근거로 가지고 있어야 합니다.
   3. 현재 제가 제시한 코파일럿 사용 방법의 문제는 숫자를 가지지 못한 사용 방법입니다. 여기에 숫자를 더하는 과정을 거쳐야 합니다.
2. 가설 검증
   1. 테스트 그룹을 통해 가설을 검증합니다. 검증은 매트릭스로 측정 가능한 기간동안 시행합니다.
   2. 가설 검증이 끝났다면 결과에 따라 다음 목표를 분기합니다.
   3. 검증 결과가 유효하다면 해당 가설을 전사에 적용합니다.
   4. 검증 결과가 유효하지 않다면 해당 가설의 문제점을 파악 후 보완해 재검증을 합니다.
   5. 재검증의 결과가 유효하지 않다면 새로운 가설을 준비합니다.

저는 이 과정을 통해 전사의 생산성 향상을 목표로 움직일 예정입니다.

다만, 이 과정에서 저연차인 저의 역량이 많이 부족할 수 있습니다. 이 부분에 있어서 고연차 선배님들, 임원분들의 적극적인 지원과 협업을 필요로 하고 또한 부득이하게 이 부분에 대해 지원을 부탁 드립니다.

현재까지 준비한 내용은 여기까지며 피드백 및 향후 방향성에 의해 언제든지 내용이 변경될 수 있다는 점 미리 양해 부탁드립니다.

감사합니다.