「코드 보완(Code Completion)은 사용하고 있지만, 그 외의 상황에서 어떻게 사용해야 할지 모르겠다」, 「상류 공정이나 조사 업무에는 별로 활용하지 못하고 있다」라고 느끼고 계시지 않습니까? 사실 GitHub Copilot은 구현뿐만 아니라 설계서 작성, 테스트 관점 도출, 장애 조사 방향 설정 등, SE가 실제로 시간을 많이 할애하는 공정에서 진가를 발휘합니다. 이 기사에서는 실제로 던지는 프롬프트(Prompt) 형태를 포함하여, 내일부터 바로 사용할 수 있는 구체적인 테크닉을 소개합니다.

• 기존 코드로부터 기능 설계서나 시퀀스 다이어그램(Sequence Diagram)의 초안을 만드는 방법을 알 수 있음
• 테스트 사양서(정상계·이상계·경계값)를 관점별로 도출하게 하는 프롬프트 형식을 알 수 있음
• 장애 조사나 로그 분석에서 Copilot을 어떻게 사용해야 빠르게 원인을 파악할 수 있는지 알 수 있음
• 개수 시 영향 범위 조사나 레거시 코드(Legacy Code) 해독에 활용하는 실천적인 절차를 이해할 수 있음

결론부터 말하자면, SE의 일상 업무에서 Copilot이 정말 효과를 발휘하는 것은 코드를 쓰게 하는 장면보다, 기존의 코드나 자료를 읽히고 인간 대신 언어화·정리하게 하는 장면입니다. 설계서 작성, 테스트 관점 도출, 장애 조사 방향 설정은 모두 「읽고 정리하는」 작업이며, 이는 Copilot이 가장 잘하는 영역과 겹칩니다.

구현을 통째로 맡기는 방식은 사실 아직 발전 단계에 있습니다. 설계서를 인풋(Input)으로 하여 Copilot에게 구현까지 맡긴 사례에서는 완벽한 결과물을 얻기 어려우며, Copilot이 구현하게 한 뒤 틀린 부분을 인간이 수정해야 합니다. 체감상 80% 정도의 정답 코드를 생성한다는 보고가 있습니다. 즉, 「쓰게 하는」 장면에서는 아직 인간의 체크가 전제되어야 합니다.

반면, 기존 코드를 읽히고 설계서나 테스트 관점을 「도출하는」 장면은 이야기가 다릅니다. GitHub Copilot은 현재 열려 있는 소스 코드, 특히 선택 범위를 컨텍스트(Context)로 이용할 수 있으며, 사양서가 아닌 자신들이 작성한 기존 코드를 참조하여 그것을 입력값으로 삼아 어떠한 생성을 수행할 수도 있습니다. 저는 개인적으로 처음부터 쓰게 하는 것보다 「이미 있는 것을 읽혀서 정리하게 하는」 사용법이 재작업(Retake)이 적고 실무에서 신뢰할 수 있다고 느낍니다.

여기서부터는 실제로 던지는 프롬프트의 형태도 곁들이며, 공정별로 소개하겠습니다.

대상 함수·클래스를 열어둔 상태(또는 #file:으로 지정한 상태)에서 다음과 같이 던집니다.

#file:OrderService.java

이 클래스의 처리 내용을 다음 항목에 맞춰 기능 설계서 형식으로 정리해 주세요.

개요 (이 클래스가 무엇을 하는 것인지)

입력 파라미터와 타입, 의미

처리 흐름 (불렛 포인트로 절차화)

출력·반환값

예외 발생 시의 동작

GitHub Copilot을 활용하여 기존 프로그램의 코드로부터 프로그램 설계서를 생성하는 검증 작업은 실제로 보고되고 있으며, 저도 비슷한 형태로 시도해 보았습니다. 처리 흐름을 불렛 포인트로 정리하는 정밀도는 생각보다 높았고, 처음부터 쓰는 것보다 리뷰하는 것이 압도적으로 빠르다고 느꼈습니다. 다만 전문 용어나 사내 고유 명칭까지는 파악하지 못하므로, 용어만은 직접 교체한다는 전제로 사용하는 것이 요령입니다.

문장 형태의 설계서뿐만 아니라, 그림으로 만들고 싶을 때는 Mermaid 문법을 지정하면 다루기 쉬워집니다.

#file:OrderController.java #file:PaymentService.java

이 클래스들 간의 호출 관계를 Mermaid의 sequence diagram 형식으로 출력해 주세요.

이상계(결제 실패 시)의 분기도 포함해 주세요.

출력된 Mermaid 코드는 그대로 GitHub의 Markdown이나 Qiita에 붙여넣으면 그림으로 표시되므로, 설계서용 이미지를 별도로 만드는 수고를 덜 수 있습니다. 저는 리뷰 회의 설명 자료를 만들 때 이 방법으로 초안을 준비한 뒤 수정하는 흐름으로 바꾼 이후, 자료 작성 시간이 체감상 절반 이하로 줄었습니다.

테스트 코드를 직접 쓰게 하기 전에, 먼저 관점 표를 만들게 하는 것이 포인트입니다.

#file:validateOrder.py

이 함수에 대한 테스트 관점을 다음 표 형식으로 도출해 주세요.

| No | 관점 구분 (정상계/이상계/경계값) | 입력 조건 | 기대 결과 |

GitHub Copilot을 사용하여 테스트 코드 (Test Code)를 자동 생성하려면, 먼저 테스트 대상 코드를 작성하고 테스트 코드에 대한 주석을 작성하여 Copilot에게 테스트 코드 생성을 요청하면, 주석을 바탕으로 적절한 테스트 코드를 제안해 줍니다. 이 흐름을 그대로 테스트 사양서 작성에 응용하여, 곧바로 코드로 옮기지 않고 먼저 "관점 표"를 만들게 하면 테스트 케이스의 누락을 리뷰하기가 쉬워집니다. 특히 경계값 (Boundary Value) 도출은 매우 뛰어나기 때문에, 저는 이 부분만큼은 매번 Copilot에게 한 번씩 체크하도록 하고 있습니다.

테스트 관점을 도출하는 것은 강력하지만, 업무 로직 특유의 "암묵적인 규칙" (예: 특정 고객 등급만 예외적으로 허용하는 등)은 사양서나 코드에 명시되어 있지 않으면 포착할 수 없습니다. 도메인 지식 (Domain Knowledge)이 필요한 관점은 반드시 사람 측에서도 별도로 도출해야 합니다.

실제 개발 현장에서도 GitHub Copilot의 Agent 모드를 사용하여 I/F 사양서를 자동 생성하는 시도가 보고되고 있습니다. API 정의나 컨트롤러 (Controller) 코드를 컨텍스트 (Context)로 전달하고, "요청(Request)·응답(Response) 항목 목록, 필수/선택, 타입, 자릿수를 표 형식으로 정리해 줘"라고 요청하면, 항목 도출 수준에서는 상당히 실용적인 출력을 얻을 수 있습니다. 제가 테스트해 본 범위에서는 자릿수까지는 추측에 의존하는 경향이 있으므로, 그 부분만 원래의 DB 정의와 대조하여 확인하는 운용 방식을 취하고 있습니다.

장애 대응 시에는 먼저 로그와 에러 메시지를 그대로 붙여넣어 물어보는 것이 가장 빠릅니다.

다음은 에러 로그입니다. 발생 가능한 원인을 가능성이 높은 순서대로 3가지 들고,

각각 확인해야 할 코드 위치나 설정을 알려주세요.

[여기에 스택 트레이스(Stack Trace)를 붙여넣으세요]

코드베이스 (Codebase)를 열어둔 상태에서 질문하면, 해당 클래스나 메서드까지 깊이 있게 파고들어 후보를 제시해 주는 경우가 많아 "어디부터 의심해야 할지" 감을 잡는 속도가 빨라집니다. 저는 이 방식을 사용한 이후로 원인 조사에서의 첫 1시간을 통째로 절약할 수 있었던 경험이 여러 번 있었습니다.

grep으로 호출부를 수동으로 쫓기 전에 Copilot에게 먼저 물어보는 방법입니다.

#codebase

UserRepository의 findByEmail 메서드를 변경하려고 합니다.

이 메서드를 호출하고 있는 곳을 목록화하고,

각 호출처에서 반환값(Return Value)이 null인 경우의 처리를 정리해 주세요.

'#codebase'를 사용할 때 에이전트 코드 검색을 활성화하면 코드베이스 검색이 강화됩니다. 대규모 리포지토리 (Repository)일수록 수동 전체 검색으로는 놓치기 쉬우므로, 먼저 Copilot에게 목록화를 시킨 뒤 중요한 부분만 직접 눈으로 확인하는 2단계 전략이 안전합니다.

주석도 문서도 없는 오래된 코드를 인계받았을 때일수록 Copilot의 독해력이 빛을 발합니다.

#file:LegacyBatchProcess.java

이 배치 처리를 신입 엔지니어에게 설명한다는 가정하에,

처리 목적, 주요 분기 조건, 주의해야 할 부작용 (Side Effect)을 쉬운 용어로 설명해 주세요.

한꺼번에 전체를 이해하려고 하지 말고, 먼저 "무엇을 하고 있는지"를 언어화시킨 다음 세부 사항을 쫓는 순서로 진행하면, 스스로 한 줄씩 읽는 것보다 더 빠르게 전체상을 파악할 수 있습니다.

요구사항 정의나 히어링 (Hearing) 직후에 메모를 그대로 붙여넣어 정리하게 하는 것도 유효합니다.

다음은 고객 히어링 메모입니다. 요구사항을 "기능 요구사항", "비기능 요구사항", "미확정 사항"으로 분류하고,

각각 불렛 포인트로 정리해 주세요.

[여기에 메모를 붙여넣으세요]

미확정 사항을 따로 분리해 내게 함으로써, 다음 히어링에서 확인해야 할 항목이 자연스럽게 리스트업되는 것이 편리한 포인트입니다.

리뷰 담당자가 되었을 때는 먼저 관점 정리를 Copilot에게 도와달라고 합니다.

#file:PaymentController.java

이 코드를 리뷰할 때 체크해야 할 관점을,

보안(Security), 성능(Performance), 가독성(Readability), 예외 처리(Exception Handling)의 4가지 카테고리로 나누어 리스트업해 주세요.

지적 자체를 Copilot에게 맡기는 것이 아니라 "봐야 할 관점"을 먼저 정리하게 함으로써, 리뷰의 누락을 줄이면서도 최종 판단은 스스로 내릴 수 있는 체제를 유지할 수 있습니다.

반대 방향, 즉 설계서로부터 코드를 생성하는 경우에도 사용할 수 있습니다. 클래스와 시퀀스 (Sequence) 설계를 프롬프트 파일에 정리하고, 새로운 채팅 세션을 생성하여 설계서와 codebase를 추가하여 실행하는 기법이 실제로 시도되고 있으며, 이 방법을 통해 어느 정도 패턴화된 화면 구현이라면 초안(Draft)으로서 충분히 쓸 만한 수준의 출력을 얻을 수 있었다고 합니다. 다만 앞서 언급했듯이 정답률이 완벽하지는 않으므로, "80%는 완성되었다는 전제하에 나머지 20%를 사람이 수정한다" 정도의 마음가짐으로 맡기는 것이 안전합니다.

• ✅ 설계서나 I/F (Interface) 사양서는 "기존 코드를 읽게 하여 정리하게 만드는" 방식이 특히 효과적임
• ✅ 테스트 사양서는 곧바로 코드를 작성하게 하지 말고, 관점 표 (Test View Table)를 먼저 만들게 한 뒤 누락된 부분이 없는지 리뷰함
• ✅ 장애 조사 시에는 로그나 스택 트레이스 (Stack Trace)를 그대로 붙여넣어 원인의 실마리를 찾게 함
• ✅ 영향 범위 조사는 #codebase를 사용하여 호출 측 (Caller)을 목록화한 뒤, 사람이 직접 검증함
• ◎ 모든 테크닉은 "Copilot의 출력을 맹신하지 않고, 마지막에는 사람이 확인한다"는 전제하에 사용하는 것이 안전함