STARF 방식으로 일하는 법

지금껏 내가 잘못된 방식으로 일하고 있었다는 것을 알게되었다.

지금까지는 나는 이렇게 일했었다.

- 어떤 일이 주어지면 이를 해결하기 위해 어떠한 방법들이 있는지 파악하고,

- 가장 효율적인 방법을 채택해서 일을 하고 요청자에게 전달하는..

아주 단순한 방식으로 일을 하고있었다.

 

나는 이 방법이 개발자로서, 엔지니어로서 기술에 집중할 수 있는 가장 효과적인 방식이라고 생각했고

이렇게 일하는 것이 가장 효율적이고, 올바른 방법이라고 생각했었다.

기획자는 기획만 전문적으로 하고, 개발자는 개발만 전문적으로 하고, 인프라는 인프라만 전문적으로 하고...

 

하지만 그것은 나를 더 성장시키지 못하게 하는, 스스로를 틀에 가둬버리게 되는 아주 잘못된 생각이였다.

 

 

STARF 방식

최근에 나는 STARF 라는 업무 방식을 알게 되었고, 뒤통수를 한대 맞은 느낌을 받았다.

그동안 나는 스스로를 개발자(혹은 엔지니어)라는 틀에 가둬놓고 실제로는 그저 주어진 일만 하는..

Input을 받으면 Output을 출력하는, 마치 함수와 같은 방식으로 일을 하고 있었다는 것을 깨닫게 되었다.

 

흔히 개발자는 문제를 발견하고 해결하는 사람이라고 한다. 코딩은 그 과정의 도구일 뿐이라고 하고,

하지만 나는 스스로를 개발자라고 지칭했으면서 개발자처럼 생각하고 일하지 않았던 것 같다.

 

STARF 방식을 알고나서는 그동안 내가 일하고 있던 방식에 대해서 틀렸다고 생각하진 않지만, 더 성장하기는 어렵다고 판단했다.

따라서 나는 앞으로 반드시 STARF 방식으로 일하려고 한다.

처음엔 어색하고 어렵겠지만, 지속하다보면 점차 익숙해지면서 습관처럼 스며들어

나도 모르게 이렇게 생각하고 행동하고 일하고 있을 것이라고 예상(희망)한다.

 

자, 그럼 STARF 방식이 정확히 무엇일까?

한번 알아보자.

 

---

Situation(상황)

내가 발견한 혹은 해결해야할 상황을 정확하고 자세하게 파악한다.

이 상황이 어디에서 발생했으며, 언제 발생했으며, 왜 중요한지를 파악한다.

특히 해당 상황으로 인해 발생하고 있는 손해 혹은 불편사항이 무엇인지 수치화하여 파악하는것이 중요하다.

내가 상황에 대해 직접 파악하기 어렵다면 이 상황을 가장 잘 아는 사람에게 집요하게 물어봐야 한다.

모르는 것에 대해서 집요하게 물어본다고 아무도 뭐라할 사람 없다.

만약 그런 사람이 있다면 그 사람을 개선시켜라.

예시

1. 특별 할인 상품 구매 이슈
매주 약 500명의 고객이 특별 할인 상품 구매 기능의 문제로 인해 간헐적으로 정상적인 서비스를 사용하지 못하고 있으며
이로인해 매주 약 5000만원 정도의 매출 손실을 보고 있음.
장애 발생 시 복구하기까지 약 2~3시간 정도 소요됨.
이 이슈의 원인으로 애플리케이션이 급격한 트래픽을 인입받았을 때 많은 부하를 받은 서버가 다운되어 발생하는것으로 파악됨.
이 이슈로 인해 특별 할인 상품 뿐만 아니라 일반 상품 구매자들도 장애 전파를 받고 있는 상황이라 빠르게 해결해야할 것으로 판단됨.


2. 계정 찾기 기능의 다양한 옵션 제공
잊어버린 계정 찾기 기능의 옵션 부족으로 매월 4000건의 고객 불편사항을 인입받고 있으며,
다양한 옵션의 계정 찾기 기능을 만들어달라는 요청이 지속적으로 인입되고 있음.
기존에 제공했던 계정 찾기 기능은 이메일 방식으로 찾기만 제공하고 있었으며,
휴대폰 인증 방식으로 찾기, 본인 인증방식으로 찾기, 질문과 답변 방식으로 찾기 등 다양한 옵션을 추가 제공할 수 있을 것으로 판단됨.
고객이 요구하는 계정 찾기 기능 옵션을 추가하게 되면 월 4000건의 고객 불편 사항을 해소할 수 있을것으로 판단되며,
측정되는 월 잠재 매출액 약 2억원 정도의 효과를 볼 수 있을것으로 판단됨.

 

 

Task(목표 설정, 과제 설정)

Situation(상황)을 해결하기 위한 목표 및 과제를 설정한다.

이 상황을 해결함으로써 달성하고자 하는 목표는 무엇인지, 목표를 달성하기 위해 어떤 과제를 수행해야 하는지, 과제를 수행하면서 발생되는(혹은 과제를 수행하지 않으면 발생되는) 리스크는 무엇인지 정확하게 파악한다.

 

목표 및 과제를 설정하면서 업무에 대한 일정도 고려해야한다. (시간은 무한하지 않기 때문에)

또한, 목표를 달성하고 나서 피드백을 어떻게 받을 것인지, 어떤 피드백을 받고자 하는지, 피드백에 대해서 어떻게 조치할 것인지 까지도 목표 설정에 추가해야 한다.

 

하지만 완벽하게 수행하기 위해서 너무 상세하게 계획하면 시작조차 못할 수 있기 때문에 핵심에 집중해서 빠르게 실행하도록 해야한다.

어차피 실행하면서 상황이 바뀔 수 있고, 내가 파악했던 문제도 달라질 수 있기 때문에 일단 빠르게 결정하고 신속하게 행동하는것이 중요하다.

예시

1. 특별 할인 상품 구매 기능 이슈 해결
- 목표 설정
    - 급격한 트래픽 증가 상황에도 신속하게 대응하여 특별 할인 상품 구매 기능에 문제가 없도록 조치할 것.
        - 매주 약 500명의 고객 불편사항을 해소할 것.
        - 기존 발생했던 매주 약 5000만원 가량의 매출 손실을 제거할 것.
    - 특별 할인 상품 구매 기능으로 인해 다른 서비스들이 장애를 전파받지 않도록 조치할 것.
- 과제 설정
    - 급격한 트래픽을 인입받았을 때 서버를 신속하게 Scale-out 할 수 있도록 Auto Scaling을 구성한다.
        - 예상되는 리스크
            - 트래픽을 해소하고 나서 증설한 서버의 갯수를 신속하게 줄이지 않으면, 불필요한 인프라 비용이 낭비될 우려가 있음.
                - 따라서 트래픽 완화 시점을 파악하여 서버 갯수를 Scale-in 하는 방안에 대해 검토해야한다.
    - 특별 할인 이벤트를 진행하기에 앞서 예상 되는 트래픽을 가늠하고 그 만큼 미리 서버를 증설하는 업무 프로세스를 정의한다.
    - 서버 부하 모니터링 시스템을 갖춰 약 70% 이상의 부하가 감지될 경우 즉시 개발팀에게 알림을 발송하도록 한다.
- 예상 일정
    - Auto Scaling 구성 방법에 대한 PoC 진행 - 약 1주 소요 예상
        - Auto Scaling 구성 일정은 PoC 진행 후 도출될 예정
    - 마케팅 팀과 업무 프로세스 개선안에 대해서 논의 진행 - 약 2시간 소요 예상
        - 업무 프로세스 개선안 문서 작성 - 약 1시간 소요 예상
    - 서버 부하 모니터링 시스템 방안 및 기술 검토 - 약 1주 소요 예상
        - 현재 다른 팀에서 구축하고 있는 서버 부하 모니터링 시스템이 있는지, 있다면 어떻게 구성했는지 알아볼 것 - 약 1일 소요 예상
        - 서버 부하 모니터링 시스템 구축 일정은 향후 도출될 예정
- 피드백
    - 과제 달성 후 마케팅 팀에게 개선작업에 대한 피드백을 요청한다.
        - 피드백에서 부족한 부분을 확인하여 다음 Task를 수립한다.
    - 마케팅 도메인 기획팀과 고객 불편사항 해소한 내용에 대해서 고객에게 피드백 받을 수 있는 방법을 논의한다.
        - 고객의 피드백에서 부족한 부분을 확인하여 다음 Task를 수립한다.

2. 계정 찾기 기능의 다양한 옵션 제공
- 목표 설정
    - 고객 불편사항으로 꾸준하게 인입되었던, 휴대폰 인증으로 계정 찾기 기능을 우선적으로 추가할 것.
        - 기존 발생했던 매월 약 4000건의 고객 불편사항을 해소할 것.
        - 잠재적인 월 매출액 2억원을 이끌어낼 것.
            - 4000명의 고객 * 평균 주문 금액 약 5만원 = 2억 1천 5백만원
- 과제 설정
    - 애플리케이션 구조를 여러 계정 찾기 기능 옵션을 적용할 수 있는 로직으로 리팩토링 한다.
    - 고객에게 가장 많은 요청을 받았던 휴대폰 인증 방식으로 계정 찾기 기능을 개발한다.
        - 예상되는 리스크
            - 인증 번호를 수신받을 휴대폰 번호를 입력받아야 하므로 개인정보 관련 보안 준수사항을 검토한다.
            - 개인정보를 입력 받을 때 중간에 공격당하여 고객의 개인정보가 탈취되지 않도록 네트워크 구성 및 보안 프로세스를 검토한다.
- 예상 일정
    - 개인정보 관련 보안 준수사항 검토 - 약 2일 소요 예상
        - 보안팀과 논의 하며 작업 방향에 대해 논의할 것. 이에 따라서 일정이 약 2일 정도 늘어날 수 있음.
    - 기존 로직 리팩토링 - 약 3일 소요 예상
    - 휴대폰 인증 방식 개발 - 약 7일 소요 예상
    - 새로운 feature QA 진행 - 약 2일 소요 예상
    - 운영 배포 준비 - 약 1일 소요 예상
- 피드백
    - 회원 도메인 기획팀에게 고객 불편사항을 해소한 내용에 대해서 고객 피드백을 받을 수 있는 방법을 논의한다.
        - 고객의 피드백에서 부족한 부분을 확인하여 다음 Task를 수립한다.

 

 

Action(행동)

Task(목표, 과제)를 수행하기 위해 행동한다.

가장 중요한 것은 내가 오너십을 가지고 주도적으로 업무를 진행해야 한다는 것이다.

 

혹여 특정 Task에 대해서 업무 지원이 필요한 경우,

내가 동료의 핵심 역량을 파악하여 해당 Task에 적절한 동료에게 업무 지원을 요청해야한다.

요청한 업무에 대해서도 맡기고 끝나는것이 아니라,

내가 꾸준히 추적해야하며 동료가 업무를 진행함에 있어서 진행상황이 어떻게 되고 있는지 혹은 어떤 장애물을 맞딱뜨렸는지 지속적으로 파악해야 한다. 장애물에 대해서는 자세히 파악해야하며 함께 해결해야 한다.

또한 혼자서 장애물을 해결하기 어렵다고 판단했을 경우, 빠르게 동료에게 전파하여 신속하게 해결할 수 있도록 한다.

 

또한 업무를 진행하다보면 앞서 계획했던 대로 업무를 진행하기 힘든 경우가 생길 수 있는데(아마 반드시 생길 것이다), 이 때 가장 중요한것은 유연하게 대응하는 것이다.

목표를 달성하기 위해서 행동해야 하는 모든 상황들에 대해서, 유동적으로 Task를 재설정하고 다시 행동할 수 있어야 한다.

예시

1. 특별 할인 상품 구매 기능 이슈 해결
- Auto Scaling 구성 방법에 대한 PoC 진행 - 담당자 : 홍길동(본인)
- 마케팅 팀과 업무 프로세스 개선안에 대해서 논의 진행 - 담당자 : 홍길동(본인)
    - 업무 프로세스 개선안 문서 작성 - 담당자 : 홍길동(본인)
- 서버 부하 모니터링 시스템 방안 및 기술 검토 - 담당자 : 홍길동(본인)
    - 현재 다른 팀에서 구축하고 있는 서버 부하 모니터링 시스템이 있는지, 있다면 어떻게 구성했는지 알아볼 것 - 담당자 : 강감찬(동료)
        - 장애물
            - 다른 팀의 업무가 바빠서 다른 팀의 서버 부하 모니터링 시스템에 대해서 물어보기 어려운 상황.
            - 대안책
                - 우리 팀이 직접 서버 부하 모니터링 시스템을 구축할 수 있는 방법을 검토한다.
                    - 기술검토 대상 :
                        - AWS CloudWatch + AWS Lambda + AWS SNS
                        - Prometheus + Grafana
                            - On-Managed 서비스가 있는지, 아니면 직접 구성해야하는지 검토할 것.

2. 계정 찾기 기능의 다양한 옵션 제공
- 개인정보 관련 보안 준수사항 검토 - 담당자 : 홍길동(본인)
- 기존 로직 리팩토링 - 담당자 : 홍길동(본인)
- 휴대폰 인증 방식 개발 - 담당자 : 홍길동(본인)
    - 장애물
        - 개발 과정에서 예상보다 시간을 많이 허비하여 일정이 지연될 것으로 파악됨.
        - 대안책
            - 프로젝트 매니저에게 빠르게 이 사실을 알리고 할당받을 수 있는 일정을 확보해볼 것.
                - 만약 불가능하다면,
                    - 생략 가능한 테스트 코드를 검토하여 테스트 코드 작성 시간을 줄여 개발 일정을 확보할 것.
                    - 생략 가능한 기능을 제거하여 개발 시간을 줄이는 방안 검토할 것.
- 새로운 feature QA 진행 - 담당자 : 강감찬(동료)
- 운영 배포 준비 - 담당자 : 강감찬(동료)

 

 

Result(수치화된 결과 측정)

내가 수행한 업무를 통해 이전 상황 대비 어떤 결과를 얻었는지 측정한다.

결과에는 내가 얻은 교훈도 포함된다.

 

모든 업무를 끝내고 결과를 보았을 때 성공했을 수도 있고 실패했을 수도 있다.

물론 성공을 추구해야겠지만, 실패를 통해서 성장하는것 또한 성공 못지않게 중요하다.

어쩌면.. 실패를 통한 성장이 더 중요할 수도 있다. 하지만 올바른 실패(성장할 수 있는 실패)이어야 한다.

얻는 것이 없는 의미없고 소모적인 실패는 최악이며 최대한 피해야 한다. (예: 똑같은 실수를 반복하는 것)

 

가장 중요한 것은 결과에 대해서 반드시 수치화 해야 한다는 것이다. (퍼센트, 숫자, 매트릭, 시간과 일자 등)

• 금전적 지표 (비용 절감, 수익 창출)
• 시간적 지표 (매년, 매월, 매주, 매 시간 개선)
• 영향도 지표 (고객 혹은 동료에게 미치는 영향)
• 품질 지표 (서비스 품질, 장애 제거 및 최소화)

결과를 측정한다는 것은 내가 수립하고 실행했던 목표와 행동을 통해 예상한 결과가 도출되었는지 검증하는 행위이다. 이것은 나에게 경험치가 된다.

이것을 바탕으로 이번에 부족한 점은 무엇이였는지, 진행 과정에서 어떤 절충을 했는지(시간, 품질, 비용 등), 어떻게 성공(혹은 실패)했는지, 다음에는 어떻게 다르게 해볼 수 있을지를 회고 해볼 수 있다.

예시

1. 특별 할인 상품 구매 기능 이슈 해결
- 결과
    - Auto Scaling 설정에 대한 추가적인 인프라 비용 발생.
        - 최대 트래픽 기준으로 기존 서버 비용 대비 약 약 500만원 정도의 추가 인프라 비용 발생.
    - 기존 발생했던 고객 불편사항을 99.8% 해결함.
        - 매주 약 5000만원의 매출 손실을 10만원 정도로 줄임.
        - 추가된 인프라 비용을 제거하고, 약 4500만원 정도의 추가 매출을 확보함. (수익 창출)
    - 급격한 트래픽으로 발생하는 장애 시간이 2~3 시간에서 5분으로 단축됨. (품질 개선, 장애 시간 단축)
    - 서버 부하 모니터링 업무로 인해 개발팀 내에 장애 대응 TF를 신설하여 매주 2명씩 교대로 장애 대응 업무를 담당하기로 함. (동료에게 미치는 영향)

2. 계정 찾기 기능의 다양한 옵션 제공
- 결과
    - 고객에게 휴대폰 인증 방식으로 계정 정보 찾기 기능 제공.
        - 기존 이메일 인증 방식 대비 약 2.5배 정도 더 많이 휴대폰 인증 방식이 활용되는 것을 확인. (고객에 미치는 영향)
        - 월 약 4000여 명의 고객이 계정 정보를 찾아서 구매를 발생.
            - 월 약 1.2억원 정도의 추가 매출액을 확보함. (수익 창출)
                - 예상했던 잠재적 추가 매출액 대비 60%의 효과를 달성.
            - 기존 월 4000건의 고객 불편사항을 직접 대응하던 콜센터의 리소스 부하를 개선함. (동료에 미치는 영향)
    - 개발 과정에서 네트워크 보안 허점을 파악하여 해결. (품질 개선)
        - 프라이빗 네트워크 내에서 민감정보를 일부 암호화하지 않았던 부분을 발견함.
            - 비록 내부망 안에서의 통신이지만 공격자가 내부망에 침입하여 스니핑하게 된다면 일부 민감정보를 탈취할 수 있다고 판단하여 즉시 암호화 처리를 수행함.

 

 

Feedback(회고, 피드백)

내가 업무를 수행하고 고객에게 혹은 동료에게 어떤 피드백을 받았는지 확인한다.

또한, 피드백을 받지 못했다면 반드시 받아낼 수 있는 방법을 찾아야 한다.

피드백을 받아야 내가 목표를 달성했는지, 혹은 달성하지 못했는지 정확히 파악할 수 있다.

 

중요한 점은 피드백을 받을 때, 긍정적인 내용 보다는 정말 진실한 피드백을 받을 수 있어야 한다는 것이다.

피드백을 통해서 더 개선할 수 있는 포인트는 분명 존재한다. 따라서 항상 피드백을 받는 습관을 들이자.

예시

1. 특별 할인 상품 구매 기능 이슈 해결
- 피드백
    - 개발팀 피드백
        - 서비스를 좀 더 견고하게 운영할 수 있는 프로세스가 도입되어서 좋다.
        - 하지만 장애 대응 업무 프로세스를 자동화할 수 있다면 매주 2명씩 할당되는 장애 대응 업무 리소스를 최소화 할 수 있을 것으로 생각된다.
    - 고객 피드백
        - 기존에 이벤트 상품을 구매하려고 할 때 마다 장애가 발생해서 짜증났었는데 이제는 그러지 않아서 좋다. 다른 상품도 구매할 수 있어서 좋다.
        - 이벤트 상품이 많이 늘어났으면 좋겠다.
            - 개선포인트
                - 이벤트 상품군을 늘릴 방법을 검토해볼 것.

2. 계정 찾기 기능의 다양한 옵션 제공
- 피드백
    - 콜센터팀 피드백
        - 기존에 많은 부하가 있었던 고객 불편사항 건을 해소할 수 있어서 좋음.
            - 덕분에 다른 중요한 고객 대응에 집중할 수 있게 됨.
        - 하지만 꾸준하게 계정 찾기 기능의 다른 옵션에 대한 문의도 들어오고 있음.
            - 개선포인트
                - 다른 옵션들에 대해서 각각 몇 명의 고객이 요청하였는지 정확한 수치 요청할 것.
                    - 이를 개선함으로써 얻게 되는 잠재적 이익 및 고객 경험 가치를 산정할 것.
    - 고객 피드백
        - 서비스 가입 시 사용했던 이메일 주소도 잊어버려서 계정 정보를 찾으려면 이메일 계정을 찾거나 혹은 고객센터로 문의해야해서 많이 불편했었는데, 휴대폰 인증 방식을 도입하고 나서는 쉽고 빠르게 내 계정을 찾을 수 있어서 좋다.
        - 하지만 휴대폰 인증번호가 간혹 늦게 도착하는 경우가 있음.
            - 개선포인트
                - 휴대폰 인증번호가 늦게 도착할 경우 얼마나 늦게 도착하는지 시간 파악할 것.
                - 휴대폰 인증번호가 늦게 도착하게 되는 케이스를 검토하고 개선방안 수립할 것.
                    - 외부 솔루션의 문제인가?
                    - 내부 애플리케이션 혹은 인프라의 문제인가?

---

정리하며

 

위의 각 단계별로 모두 기록하여 정리하는 습관을 들이자.

STARF 방식으로 업무를 진행하고 기록하는 것은 개인적으로 많은 성장을 줄 것이라고 생각한다.

 

내가 어떤 상황을 포착했고, (Situation)

이를 해결하기 위해 어떤 목표와 계획을 설정했으며, (Task)

어떤 행동을 수행했고(동료에게 어떤 업무를 할당했고), (Action)

어떤 결과를 확인할 수 있었는지, (Result)

이에 추가적으로 고객에게(혹은 동료에게) 어떤 피드백을 받았고, (Feedback)

이를 통해서 어떻게 더 개선하는 작업을 진행했는지,

 

위와 같은 절차를 습관화 해서

문제를 포착하고 면밀히 파악할 수 있는 능력(Situation, Task),

주도적으로 행동할 수 있는 능력(Action),

결과와 피드백을 바탕으로 더 개선할 수 있는 능력(Result, Feedback)

을 꾸준하게 연습하며 발전시켜 나갈 수 있을 것이다.

 

나는 앞으로 STARF 방식으로 일하면서 더 성장하고자 한다.

그리고 나의 동료들에게도 이 방식을 전파해서 함께 성장하고 싶다.

이를 통해서 나는 궁극적으로 내 팀을 어벤저스 처럼 만들고 싶다.