우리는 이렇게 일합니다.
와이피랩스 엔지니어가 직군과 상관없이 따르는 일하는 방식입니다. 백엔드 개발 절차는 백엔드 개발 흐름에 따로 있습니다.
일을 받고 진행하기
엔지니어는 기능을 맡는 스쿼드와, 같은 직무끼리 모인 챕터(예: 백엔드 챕터)에 함께 속합니다. 스쿼드 작업이 챕터 작업보다 먼저입니다. 작업은 모두 Jira로 관리하며, 성격에 따라 들어오는 프로젝트가 다릅니다.
| 프로젝트 | 담는 작업 | 알아둘 점 |
|---|---|---|
| Y26H1 | 제품 기능 작업 | 스쿼드 작업도 여기에 있음. 스쿼드는 컴포넌트로 구분 |
| BE | 백엔드 챕터 작업(인프라, 비용, 코드 정리 등) | 우선순위는 챕터 리드가 정하고, 일 정은 비교적 자유롭게 잡음 |
| QA | QA 담당자가 찾은 버그 | 작업자에게 바로 배정됨 |
| PMT | 장애 회고 | 아래 "장애가 나면" 참고 |
Y26H1은 스쿼드별 보드가 아니라 2026년 상반기를 기준으로 만든 제품 프로젝트입니다. Jira 이름은 [Product] '26Q1/Q2/Q3이며, 지금도 제품 작업은 여기에 만듭니다. 기능마다 에픽이 하나 있고, 그 아래에 PRD·백엔드·프론트엔드·QA 작업이 각각 붙습니다. 스프린트를 하는지는 스쿼드마다 다릅니다.
Y26H1과 BE 작업 상태는 To Do → In Progress → Done으로 옮깁니다. Y26H1은 직접 옮깁니다. BE는 브랜치나 PR을 만들면 In Progress로, 머지하면 Done으로 자동으로 바뀝니다. Done은 머지했다는 뜻이고, 배포됐다는 뜻은 아닙니다.
일정이 밀릴 것 같으면
맡은 작업의 일정은 리드가 하나하나 확인하기보다 각자 관리하고 공유합니다. 한번 공유한 일정은 지키도록 노력하고, 맞추기 어려울 것 같으면 리드가 묻기 전에 먼저 알립니다. 일정이 밀리는 것 자체보다 밀릴 것 같은 시점에 바로 알리는 것이 중요합니다. 알릴 때는 아래 두 가지를 적습니다.
- 왜 밀리는지: "구현이 잘 안 된다", "다른 업무에 밀렸다"가 아니라 어떤 부분이 예상보다 오래 걸리는지, 어떤 업무 때문인지
- 새로 예상하는 완료일
이유가 구체적이어야 같이 해결 방법을 찾거나 우선순위를 조정할 수 있습니다.
장애가 나면
장애 대응이 끝나면 PMT 프로젝트에 장애 하나당 티켓 하나를 만들어 회고를 남깁니다. 설명은 아래 순서로 씁니다.
- 요약
- 타임라인
- 왜 발생했나
- 왜 못 막았나
- 알람은 동작했나
- 조치 계획(Action Plan)
조치 계획의 각 항목은 서브태스크로 답니다. 티켓 상태는 Draft → In Review → In Action → Done 순서로 옮깁니다.