소설001: 내 눈을 보면 안 돼 - 제8화. 리더의 눈빛

이전 이야기 : https://thepin.tistory.com/209

제8화. 리더의 눈빛

“이번 QA 자동화 TF(Task Force), 이한결 대리가 리딩해봐.”

박성우 팀장의 파격적인 제안이었다. 입사 1년 차, 그것도 온갖 구설수에 올랐던 내가 프로젝트 리더(PL)라니. 하지만 박 팀장의 눈빛은 단호했다.

“기술적인 실력은 이미 증명했고, 무엇보다… 저번 보안 사건 때 보니까 멘탈이 좋더구만. 팀원들 잘 이끌어봐.”

그렇게 나는 4명으로 구성된 TF팀을 맡게 되었다. 윤서아 대리, 최진호 주임, 그리고 신입 사원 두 명.

하지만 시작부터 삐걱거렸다.

“아니, 이걸 언제 다 짭니까? 기존 업무도 바빠 죽겠는데.”

최 주임은 대놓고 불만을 터뜨렸다. 신입들은 눈치만 보고 있었고, 윤 대리조차 지친 기색이 역력했다. 마감 기한은 2주. 수천 개의 테스트 케이스를 자동화 코드로 변환해야 하는 강행군이었다.

일주일이 지나자 팀은 한계에 다다랐다.

새벽 1시. 사무실 공기는 무겁게 가라앉아 있었다.

“아, 진짜! 미치겠네!”

최 주임이 키보드를 거칠게 내려쳤다. 그의 외침에 모두의 시선이 쏠렸다.

“누가 develop 브랜치에 강제 푸시(Force Push)했어! 윤 대리님이 오후 내내 작업한 거 다 날아갔잖아!”

범인은 겁에 질린 신입 사원이었다. 그는 울먹이며 고개를 숙였다.

“죄… 죄송합니다. 제가 브랜치를 헷갈려서….”

“죄송하면 다야? 지금 네가 덮어쓴 코드 복구하려면 몇 시간 걸리는 줄 알아? 리더라는 놈은 뭐하고 있었는데!”

날카로운 화살이 나에게 날아와 박혔다. 고성이 오갔다. 윤 대리가 지친 얼굴로 중재하려 했지만 역부족이었다. 팀원들의 눈에는 짜증과 피로, 그리고 서로에 대한 불신이 가득했다. 팀은 와해 직전이었다.

나는 자리에서 일어나 그 광경을 지켜보았다.

‘멈춰야 해. 이대로 두면 전부 무너진다.’

익숙한 유혹이 뱀의 혀처럼 나를 유혹했다. 내 능력을 쓰면 된다. 최 주임의 분노를 잠재우고, 신입 사원의 공포를 지워줄 수 있다. ‘우리는 할 수 있다’는 거짓된 희망을 강제로 주입할 수도 있다. 그러면 이 지옥 같은 소란은 1분 안에 정리된다.

내 눈동자가 보라색으로 일렁이려 했다.

하지만 나는 주먹을 꽉 쥐고 눈을 감았다.

‘아니야. 그건 가짜 평화야. 마약성 진통제일 뿐이야.’

기억을 조작해서 만든 팀워크는, 진짜 위기 앞에서는 모래성처럼 무너질 것이다. 나는 더 이상 괴물이 되고 싶지 않았다. 나는 능력이 아닌, 리더로서 이 상황을 해결해야 했다.

“잠깐 주목해주세요.”

나의 차분한 목소리가 소음을 갈랐다. 날 선 시선들이 나에게 꽂혔다. 최 주임은 ‘네가 뭘 할 수 있는데’라는 표정으로 나를 노려봤다.

나는 화이트보드 앞으로 걸어갔다. 그리고 마커를 들었다.

“지금 우리에게 필요한 건 서로를 탓할 시간이 아니라, 다시는 이런 일이 생기지 않게 할 ‘시스템’입니다.”

나는 미리 준비해둔 문서를 화면에 띄웠다.

“우리가 힘든 건 실력이 없어서가 아닙니다. ‘규칙’이 없어서입니다. 서로 다른 스타일로 코드를 짜고, 중구난방으로 합치니까 충돌이 나는 겁니다.”

화면에 [QA Automation Guideline]이라는 제목이 떴다.

“앞으로 남은 일주일, 이 가이드라인대로만 움직입니다. 브랜치 전략, 코드 스타일, 커밋 메시지까지 제가 다 정해뒀습니다. 고민하지 말고, 이대로만 하세요. 모든 책임은 제가 집니다. 코드 리뷰도 제가 가장 먼저, 가장 마지막까지 보겠습니다. 여러분은 이 규칙 안에서 마음껏 실력을 발휘해주세요. 실수는 제가 다 막겠습니다.”

팀원들이 웅성거렸다. 나는 한 명 한 명 눈을 맞췄다.

최 주임과 눈이 마주쳤다. 그는 흠칫하며 시선을 피하려 했다. 과거의 기억, 나를 향한 두려움이 남아있는 탓이었다.

하지만 나는 피하지 않았다. 그렇다고 능력을 쓰지도 않았다. 그저 담담하게, 그리고 간절하게 그를 바라보았다.

‘도와주세요, 선배님. 저 혼자서는 못합니다. 선배님의 경험이 필요합니다.’

내 눈빛에 담긴 건 조작된 명령이 아니라, 잠도 못 자고 지쳐버린 리더의 투박한 진심이었다.

최 주임의 눈동자가 흔들렸다. 그는 내 눈에서 보라색 광채를 찾으려는 듯 빤히 보다가, 이내 헛기침을 하며 시선을 돌렸다.

“…지키지도 못할 규칙 만들어서 일만 두 배로 만드는 거 아니야?”

그의 목소리는 여전히 퉁명스러웠지만, 날카로운 가시는 빠져 있었다. 비난이 아닌 질문이었다.

“제가 지키게 만들겠습니다.”

“윤 대리님, 신입분들도. 저 믿고 딱 일주일만 더 고생해봅시다. 제가 제일 늦게 퇴근하고, 제일 먼저 출근해서 코드 리뷰 다 하겠습니다.”

나의 말에 윤 대리가 피식 웃었다.

“리더가 그렇게 말하는데, 따라야죠.”

공기의 흐름이 바뀌었다. 강제로 주입된 평화가 아니었다. 서로의 피로를 이해하고, 시스템을 통해 문제를 해결하려는 의지가 만들어낸 진짜 팀워크의 시작이었다.

그날 이후, 우리 팀은 달라졌다. 가이드라인 덕분에 불필요한 충돌이 사라졌고, 업무 속도가 붙었다.

일주일 뒤, 우리는 기한 내에 자동화 프로젝트를 성공적으로 완수했다.

회식이 끝난 밤, 최 주임이 내 어깨를 툭 치며 말했다.

“야, 이한결. 너… 독한 놈인 줄만 알았는데, 진짜 리더가 다 됐네. 인정한다.”

그는 어색하게 헛기침을 하더니 덧붙였다.

“아까 네가 리뷰해준 코드, 덕분에 버그 하나 잡았다. 고맙다.”

나는 밤하늘을 올려다보며 웃었다.

능력을 쓰지 않아도, 사람의 마음은 움직일 수 있다.
아니, 능력을 쓰지 않았기에 비로소 닿을 수 있었다.

그것이 내가 리더가 되어 배운 첫 번째 교훈이었다.

 

---

다음 이야기 : https://thepin.tistory.com/211

소설001: 내 눈을 보면 안 돼 - 제9화. 붕괴의 시련

 

[부록] 한결이 공유한 QA 자동화 가이드라인 (QA_Automation_Guideline.md)

# QA Automation Collaboration Guideline

## 1. Git Branch Strategy (브랜치 전략)

우리는 **Git-flow** 전략을 간소화하여 사용합니다.

- **main**: 배포 가능한 안정적인 상태 (Production Ready).
- **develop**: 개발 중인 코드가 통합되는 브랜치. 모든 PR(Pull Request)의 목적지.
- **feature/기능명**: 개별 기능 개발 브랜치. (예: `feature/login-test`, `feature/payment-module`)
  - 작업 완료 후 `develop` 브랜치로 PR 생성.
  - 본인 로컬에서 테스트 통과 후 Push 할 것.

## 2. Python Code Convention (코드 컨벤션)

가독성을 위해 통일된 스타일을 유지합니다.

- **Formatter**: `Black` 사용 (Line length: 88).
- **Naming**:
  - 변수/함수명: `snake_case` (예: `get_user_data()`)
  - 클래스명: `CamelCase` (예: `LoginPage`)
- **Docstring**: 모든 함수에는 기능을 설명하는 주석을 포함할 것.

## 3. Test Case Structure (테스트 구조)

유지보수를 위해 **POM (Page Object Model)** 패턴을 준수합니다.

- **pages/**: 웹 페이지별 요소(Locator)와 행위(Method)를 정의.
- **tests/**: 실제 테스트 시나리오. 로직 없이 `pages`의 메서드만 호출하여 구성.
- **utils/**: 공통 유틸리티 (드라이버 설정, 데이터 로더 등).

## 4. Commit Message Rule

- `[Type] Description` 형식을 따릅니다.
  - `[Feat]` 새로운 기능 추가
  - `[Fix]` 버그 수정
  - `[Refactor]` 코드 리팩토링 (기능 변화 없음)
  - 예시: `[Feat] 로그인 페이지 자동화 스크립트 추가`