SMART 목표는 번거로운 일이 될 필요가 없습니다 🎯
Source: Dev.to
목표 설정의 문제점
다시 리뷰 시즌이 돌아왔습니다. 매니저가 무서운 메시지를 보냅니다: “다음 분기 목표를 금요일까지 제출해주세요.”
빈 문서를 열고, “시스템 설계 실력을 높이겠다”라고 적었다가 바로 삭제합니다. 왜냐하면 “좀 더 구체적으로 적어줄 수 있나요?”라는 피드백을 받을 걸 알기 때문이죠.
대부분의 엔지니어는 두 가지 유형 중 하나에 속합니다:
- 모호한 목표 – “기술 역량을 향상시키겠다”, “커뮤니케이션을 개선하겠다”, “코드베이스를 더 많이 파악하겠다”. 실제로 이룬 건지 판단하기가 어려워 보입니다.
- 과도하게 야심찬 목표 – “Kubernetes, GraphQL, 머신러닝 전문가가 되면서 동시에 3명의 주니어를 멘토링하고 플랫폼 마이그레이션을 주도한다”. 3월이 되면 조용히 포기하게 됩니다.
모호한 목표는 추적이 불가능하고, 과도한 목표는 스스로를 좌절하게 만들 뿐입니다. 어느 쪽도 도움이 되지 않습니다.
SMART 목표가 실제 의미하는 바
SMART 프레임워크는 1980년대부터 존재했으며, 실제보다 복잡하게 여겨지곤 합니다. 핵심은 다음과 같습니다:
| 기준 | 의미 | 예시 |
|---|---|---|
| Specific (구체적) | 정확히 무엇을 할지 명시합니다. | “인증 모듈을 JavaScript에서 TypeScript로 전환한다.” |
| Measurable (측정 가능) | 언제 완료됐는지 판단할 기준을 정의합니다. | “인증 모듈이 모든 기존 테스트를 통과하고, 엄격한 TypeScript 설정이 활성화된 상태.” |
| Achievable (달성 가능) | 작업량에 대해 현실적으로 접근합니다. | 주요 기능에 집중하고 있다면, 전체 서비스를 재작성하기보다 하나의 모듈을 전환하는 것이 현실적이다. |
| Relevant (관련성) | 목표가 팀이나 커리어에 도움이 되는지 확인합니다. | 팀이 다른 언어로 전환한다면 해당 인증 모듈 전환은 의미가 없을 수 있다. |
| Time‑bound (시간 제한) | 명확한 마감일을 설정합니다. | “Q2 말까지” 대신 “언젠가” 라고 하지 않는다. |
실제 예시
SMART 버전
“주당 5시간씩 공부하여 3월 31일까지 AWS Solutions Architect 인증을 취득하고, 80% 이상 점수를 받은 연습 시험을 최소 3회 통과한다.”
비SMART 버전
“AWS에 대해 더 배우겠다.”
첫 번째 버전은 매주 해야 할 일을 정확히 제시하지만, 두 번째는 유튜브 영상을 하나 보고 진행했다고 주장하게 만들 뿐입니다.
목표 작성 실전 팁
연간 목표를 분기별로 나누기
12개월 목표는 추적하기 어렵습니다.
- 연간: “승진한다.”
- 분기별: “Q1까지 테크 리드 섀도우 프로그램을 완료한다.”
현실이 변하면 목표 업데이트
프로젝트가 전환되거나 목표가 비현실적이면 조정합니다. 수정된 목표가 포기된 목표보다 낫습니다.
리스트는 짧게 유지
집중된 3개의 목표가 흩어진 8개의 목표보다 낫습니다. 목표를 완수할 가능성이 높아지며, 이는 화려한 리스트보다 더 중요합니다.
개인 동기와 연결
“매니저가 시키길래 GraphQL을 배운다”는 “사이드 프로젝트에 쓰고 싶어서 GraphQL을 배운다”보다 완수율이 낮습니다.
목적을 기억
목표는 성과 리뷰에서 누군가를 감탄시키기 위한 것이 아니라, 스스로에게 의미 있는 일을 하도록 하고, 필요할 때 성과를 명확히 전달하기 위한 것입니다.
결론
SMART 프레임워크는 마법이 아니라, 스스로를 솔직하게 만들기 위한 체크리스트입니다. 다음 리뷰 시즌이 찾아올 때, 여러분은 구체적인 성과 증거를 가지고 있어 과정이 훨씬 덜 스트레스가 될 것입니다.