스타트업에서 일하면 누구나 빠르게 성장한다는 보장은 없습니다. 팀 규모가 작을수록 여러 일을 맡을 수 있지만 피드백과 학습 시간이 부족할 수도 있습니다. “빠른 성장”이라는 표현보다 어떤 문제를 맡고 어떻게 검증하는지 살펴보세요.
업무의 경계 정하기
기능 요청이 들어오면 목표 사용자, 필수 동작, 출시 시점, 실패했을 때의 영향을 먼저 적습니다. 모든 요청을 한 번에 만들기보다 작은 범위로 배포하고 결과를 확인하세요. 우선순위가 계속 바뀌면 이유와 포기한 일을 팀과 공유해야 합니다.
기술 빚과 운영 기록
속도를 위해 임시 구현을 했다면 왜 선택했고 언제 다시 검토할지 기록합니다. 테스트가 없는 중요한 경로를 방치하면 다음 기능을 추가할 때 수정 비용이 커질 수 있습니다. 오류 로그와 사용자 피드백을 보고 가장 영향이 큰 문제부터 고칩니다.
피드백을 받는 방법
정식 멘토가 없어도 작은 변경 단위의 코드 리뷰, 이슈 설명, 회고를 만들 수 있습니다. GitHub 풀 리퀘스트 안내처럼 변경 이유와 테스트를 함께 기록하세요. 혼자 개발한다면 다른 사람이 실행할 수 있는 README로 결정 과정을 남깁니다.
이직을 고민한다면 성장 기회뿐 아니라 업무량과 지원 체계를 비교해야 합니다. 이직 시점 점검의 질문을 적용해 보세요.