메인 콘텐츠로 건너뛰기

진짜 개발자의 일: “작동함”을 증명하는 코드까지 전달하기

PR을 올리고 나서 이런 말을 해본 적이 있을 것입니다.
“테스트는 아직 못 했는데, 대충은 맞을 거예요.”

AI 코파일럿이 코드 절반을 써주는 시대, 이런 태도는 그냥 부족한 정도가 아니라 팀의 시간을 빼앗는 심각한 민폐입니다. 이제 소프트웨어 개발자의 일은 “코드 작성”에서 끝나지 않습니다. “이 코드가 실제로 동작함을 증명하는 것”까지가 우리의 업무 범위입니다.

이 글에서는 왜 “증명된 코드”가 중요한지, 수동 테스트와 자동화 테스트를 어떻게 설계하고 보여줘야 하는지, 그리고 코딩 에이전트까지 활용해 검증을 자동화하는 방법까지 실전 관점에서 정리해 보겠습니다.

결론부터 말하면, 앞으로의 개발자는 다음을 함께 가져가야 합니다.

  • 내가 쓴 코드가 실제로 돌아가는 화면, 로그, 테스트 결과

  • 구현을 롤백하면 실패하는 자동화 테스트

  • 에이전트(LLM 도구)까지 동원해 “검증 과정 자체”를 자동화하는 사고방식


코드 작성만으로는 부족하다: “증명 책임”이 개발자의 핵심 역할

AI 도구 덕분에 이제 누구나 거대한 PR을 쉽게 만들 수 있습니다. 문제는 리뷰어입니다.
테스트도 안 돌린 거대한 PR 한 덩어리를 받는 순간, 리뷰어는 사실상 다음과 같은 역할을 떠맡게 됩니다.

  • 요구사항이 제대로 구현됐는지 일일이 손으로 돌려보기

  • 엣지 케이스를 찾아가며 버그를 대신 발견해주기

  • 자동화 테스트가 없다면, 재발 방지 장치까지 대신 고민하기

이건 리뷰가 아니라 대리 개발 + QA입니다. 게다가 AI가 생성한 코드는 “거의 맞는” 경우가 많아서, 눈으로 보기엔 그럴듯하지만 실제로 돌려보면 엉뚱한 데서 터지는 경우가 많습니다1.

그래서 현대적인 의미의 소프트웨어 개발자는 다음까지 책임집니다.

  1. 코드가 요구사항을 만족하는지 직접 확인한다.

  2. 이 과정을 재현 가능한 형태(명령어, 스크린샷, 동영상, 테스트 코드 등)로 남긴다.

  3. PR에 이 “증거”를 포함해서 올린다.

리뷰어가 해야 할 일은 “검증”이 아니라 “판단”이어야 합니다.
“이 방식이 더 좋은가?”, “설계 방향이 맞는가?” 같은 고급 판단에 시간을 쓰도록 만들어야 합니다.

이를 위해 필요한 것이 두 가지입니다. 수동 테스트자동화 테스트입니다.


수동 테스트: 직접 돌려보지 않은 코드는, 그냥 안 된다고 생각하라

먼저 수동 테스트부터 짚어보겠습니다.
수동 테스트라고 하면 QA 팀의 업무 같지만, 실제로는 개발자에게도 필수적인 기술입니다23.

핵심은 간단합니다.

  1. 시스템을 특정 “초기 상태”로 맞춘다.

  2. 내가 수정한 기능을 실제로 사용해본다.

  3. 기대한 결과가 나왔는지 눈과 손으로 확인한다.

여기서 중요한 것은 “재현 가능하게” 만들어 두는 것입니다.
좋은 수동 테스트는 다음 두 가지 특징을 가집니다.

1) 누구나 따라 할 수 있는 단계로 정리하기

예를 들어, 장바구니 할인 버그를 고쳤다고 해보겠습니다.
PR 설명에 이렇게만 쓰면 리뷰어는 아무것도 알 수 없습니다.

“장바구니 쿠폰 버그 수정했습니다. 잘 됩니다.”

대신 다음처럼 구체적으로 쓰는 겁니다.

  1. docker compose up으로 로컬 환경 실행

  2. 관리자 계정으로 로그인 (admin@example.com / password)

  3. “신규 쿠폰 10%” 생성, 유효기간 오늘로 설정

  4. 프론트에서 임의 상품 2개 장바구니에 담기

  5. 쿠폰 코드 NEW10 입력 후 적용

  6. 총액이 10% 할인된 값으로 표시되는지 확인

  7. 새로고침 이후에도 할인 상태 유지되는지 확인

그리고 가능하다면 실제 터미널 로그나 스크린샷을 PR 코멘트에 붙입니다.
리뷰어 입장에서는 “아, 이 사람은 실제로 돌려봤구나”를 명확히 알 수 있습니다.

2) “행복 경로”만 말고, 엣지 케이스도 일부 포함하기

초보자는 보통 “잘 될 때만” 테스트합니다.
중급 이상이 되면 다음 질문들을 던집니다.

  • 쿠폰이 만료된 경우에는?

  • 장바구니가 비어 있을 때 쿠폰을 쓰면?

  • 이미 다른 쿠폰이 적용된 상태에서 또 넣으면?

수동 테스트는 결국 “깨지는 순간을 찾는 능력”을 키우는 과정입니다.
이 능력이 쌓일수록, 버그는 QA 단계가 아니라 로컬에서 잡히게 됩니다.

보여주는 것이 중요하다

가능하면 다음 형태로 “증명 자료”를 남기는 습관을 들이세요.

  • 텍스트로 정리된 테스트 절차 + 결과

  • 터미널 명령어와 출력 로그

  • 화면 동작을 찍은 짧은 동영상(GIF)

  • 중요한 UI 변경이라면 전·후 비교 스크린샷

이걸 PR 설명에 함께 올리면, 리뷰어는 코드를 보기 전부터 안심합니다.
“이 변경이 실제로 어떻게 동작하는지”를 머릿속에 그리면서 코드를 읽을 수 있기 때문입니다.


자동화 테스트: “구현을 되돌리면 반드시 깨지는” 안전장치 만들기

수동 테스트만으로는 충분하지 않습니다.
한 번 수동 테스트로 확인한 기능도, 이후 수정 과정에서 언제든 다시 깨질 수 있습니다.
그래서 자동화 테스트는 선택이 아니라 필수입니다456.

자동화 테스트의 역할은 단순합니다.

  • 시스템을 특정 상태로 맞추고

  • 코드를 실행한 뒤

  • 결과가 기대값과 같은지 자동으로 검증한다.

그리고 중요한 조건이 하나 있습니다.

내가 추가한 구현을 제거하면, 이 테스트는 반드시 실패해야 한다.

그렇지 않다면, 테스트는 “구현과 동떨어진 장식품”에 불과합니다.

좋은 단위 테스트의 핵심: 작고, 명확하고, 목적이 분명해야 한다

AWS, Zencoder 같은 곳에서 정리한 단위 테스트 베스트 프랙티스를 보면, 공통된 원칙이 있습니다45.

  • 하나의 테스트는 하나의 행동만 검증한다.

  • 테스트 이름만 봐도 “무엇을, 어떤 상황에서, 어떻게 기대하는지” 알 수 있어야 한다.

  • Arrange–Act–Assert 패턴처럼 구조가 명확해야 한다.

예를 들어, 장바구니 할인 로직에 대한 테스트는 이렇게 작성할 수 있습니다.

  • 주문총액_쿠폰10퍼센트적용_정확히할인된다

  • 쿠폰만료_할인적용되지않는다

  • 장바구니비어있음_쿠폰적용시예외발생

테스트 이름만으로도 어떤 행동을 검증하는지 드러납니다.
이렇게 테스트가 쌓이면, 그 자체로 “살아 있는 문서”가 됩니다5.

자동화 테스트가 주는 이점

자동화 테스트를 잘 깔아두면 다음과 같은 장점들을 얻습니다4536.

  • 리팩터링할 때 마음이 편하다.

  • 새 기능 추가할 때, 기존 기능이 깨졌는지 바로 알 수 있다.

  • 버그가 다시 나타나는지(회귀)를 CI에서 자동으로 감시해준다.

  • 팀에 신규 합류한 개발자가 코드 사용법을 테스트로 빠르게 학습한다.

테스트는 초기에 조금 귀찮을 뿐, 시간이 지날수록 팀의 속도를 오히려 높여 줍니다.
“테스트 없이 빨리 가는 것”은 잠깐 빠른 척할 뿐, 결국 기술 부채로 돌아옵니다71.


AI 코딩 에이전트 시대: “테스트까지 시키는” 사람이 진짜 시니어다

2025년 이후 가장 큰 변화 중 하나는 코딩 에이전트의 폭발적인 성장입니다.
Claude Code, Cursor, 각종 에이전트 기반 도구들이 이제는 코드를 단순히 생성하는 수준을 넘어, 직접 실행하고, 테스트를 돌리고, 수정까지 반복합니다841.

하지만 여기서도 여전히 “책임”은 인간에게 있습니다81.

컴퓨터는 책임을 지지 않습니다.
PR에 이름이 찍히는 사람, 머지 버튼을 누르는 사람, 장애 대응을 하는 사람은 결국 인간입니다.

그래서 코딩 에이전트를 제대로 쓰려면 다음까지 요구해야 합니다.

1) 에이전트에게 “수동 테스트 절차”까지 생성·실행하게 하기

에이전트에게 단순히 말합니다.

“이 기능을 구현하고, 로컬에서 어떻게 실행해서 결과를 확인했는지까지 단계별로 보여줘.”

잘 세팅된 에이전트는 다음과 같이 행동할 수 있습니다.

  • dev 서버를 띄우고

  • curl이나 HTTP 클라이언트로 엔드포인트를 호출하고

  • 응답 JSON을 보여주면서 “이 값이 이렇게 바뀌었다”고 설명하고

  • 그 명령어들을 한 번에 붙여넣을 수 있는 스크립트 형태로 정리해 준다.

이걸 그대로 PR 설명에 붙이면, 리뷰어는 사람인지 에이전트인지 구분할 필요조차 없습니다.
“이 변경을 어떻게 검증했는지”라는 사실만 중요합니다.

2) 에이전트로 자동화 테스트 코드까지 생성시키기

현재 대부분의 에이전트는, 프로젝트에 테스트 코드가 조금만 있어도 그 패턴을 따라 테스트를 추가하는 데 꽤 능숙합니다84.

에이전트를 사용할 때는 이런 식으로 요청해 보세요.

  • “이 버그를 재현하는 실패하는 테스트를 먼저 만들어줘.”

  • “버그를 고치고, 기존 테스트가 모두 통과하는지 확인해 줘.”

  • “테스트에서 Arrange–Act–Assert 패턴을 지키고, 테스트 이름을 한국어로 의미 있게 지어 줘.”

그리고 반드시 다음을 확인해야 합니다.

  • 테스트가 정말로 실패했다가, 구현을 추가했을 때만 성공하는지

  • 외부 API, DB 같은 것들을 적절히 모킹했는지

  • 테스트가 우연히 통과하는 “취약한 테스트”는 아닌지

AI 도구가 테스트 작성의 허들을 크게 낮춘 덕분에 “테스트 없어요”라는 변명은 더 이상 통하지 않습니다84.

3) 좋은 테스트 구조는 에이전트도 “배운다”

흥미로운 점은, 에이전트가 프로젝트의 기존 테스트 구조를 굉장히 잘 “모방”한다는 것입니다84.

  • 폴더 구조가 깔끔하고

  • 픽스처, 헬퍼 함수가 잘 정리돼 있고

  • 테스트 이름, 스타일이 일관돼 있다면

에이전트는 그 패턴을 따라 새로운 테스트를 만들어 줍니다.
결국 좋은 테스트 문화를 만들어두면, 사람도 AI도 모두 거기에 맞춰 움직입니다.
반대로 테스트가 엉망이면, 에이전트도 그 엉망인 스타일을 증식시킵니다.


PR을 올릴 때 꼭 포함해야 할 “작동 증명 세트”

이제 실제로 팀에서 쓸 수 있는 체크리스트를 정리해 보겠습니다.
PR을 생성하기 전에, 최소한 아래 4가지는 포함하는 습관을 들여보세요.

1) 변경 요약과 의도

  • 무엇을 왜 바꿨는지, 한두 문단으로 설명

  • 관련 이슈나 티켓 링크

  • 기능 플래그 / 마이그레이션 여부 등 위험도 정보

2) 수동 테스트 시나리오

  • 환경 구성 방법 (예: make dev, .env 설정 등)

  • 기능을 재현하는 단계별 절차

  • 실제로 얻은 결과(스크린샷, 로그, 동영상 링크)

예시:

로컬에서 docker compose up 실행 후,
/login 페이지에서 user@example.com 계정으로 로그인,
“프로필 수정”에서 이름 변경 후 저장,
새로고침했을 때 변경된 이름이 유지되는 것을 확인했습니다.

3) 자동화 테스트 변경 사항

  • 새로 추가한 테스트 파일/케이스 목록

  • 로컬에서 돌린 테스트 명령어와 요약 결과

  • 실패가 의도된 경우(예: TODO)라면 그 이유와 계획

예시:

CartService의 할인 로직을 검증하는 단위 테스트 3개를 추가했습니다.
pytest 전체를 로컬에서 실행했고, 152개 테스트가 모두 통과했습니다.
(pytest -q 결과 캡처 첨부)

4) 에이전트 사용 시 검증 방법

  • 에이전트에게 어떤 작업을 맡겼는지

  • 에이전트가 수행한 테스트/검증 내용 요약

  • 사람이 추가로 확인한 부분(특히 보안, 성능, 설계 관련)

이 정도만 꾸준히 해줘도 팀의 PR 품질은 한 단계 올라갑니다.
리뷰어 입장에서도 “이 사람의 PR은 기본 검증이 잘 되어 있다”라는 신뢰가 쌓입니다.


마무리: 코드보다 더 중요한 것, “나는 이게 된다는 걸 봤다”

요즘은 누구나 AI에게 “이 기능 구현해줘”라고 말해서 수백 줄짜리 코드를 얻을 수 있습니다.
하지만 “이 코드가 실제로 제대로 동작한다는 증거까지 함께 가져오는 사람”은 여전히 드뭅니다.

정리하면, 앞으로의 개발자가 가져야 할 기준은 이렇습니다.

  • 직접 실행해서 확인하지 않은 코드는, 작동한다고 말하지 않는다.

  • 구현을 지웠을 때 실패하는 자동화 테스트를 반드시 함께 넣는다.

  • AI 코딩 에이전트는 “코드 생성기”가 아니라 “테스트와 검증까지 대신 수행하는 도구”로 쓴다.

  • PR에는 항상 “어떻게 검증했는지”를 증거와 함께 기록한다.

AI가 코드를 대신 써주는 시대일수록, 인간 개발자의 가치는 “책임과 검증”에서 갈립니다.
다음 PR을 올릴 때, 이렇게 스스로에게 물어보면 좋겠습니다.

“이 코드를 리뷰하는 사람이 ‘이거 진짜 되는구나’라고 확신할 만한 증거를, 내가 충분히 넣었는가?”

그 질문에 자신 있게 “그렇다”고 답할 수 있다면, 이미 상위 10% 개발자의 습관을 갖추고 있는 것입니다.


참고

1Best Automated Code Review Tools for Enterprise Software Teams

2Manual Testing Tutorial for Beginners | BrowserStack

3Software testing - Wikipedia

4A Definitive Guide to Automated Unit Testing in 2026

5What is Unit Testing? - Unit Testing Explained - AWS

610 Software Testing Best Practices for Elite Teams in 2025

7Test Automation Strategy 2026 - 8 Tips for an Ultimate Plan

8Your job is to deliver code you have proven to work

이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.