안녕하세요. 파이어하고싶은 임베개발자입니다.
Fire 당하기는 싫습니다.
작고 귀여운 모터드라이버 컴포넌트의 기초 기능 구현을 마치고 문득 드는 생각이 있어,
요즘들어 회사일로 시간이 어떻게 가는지는 모르겠지만
거의 일주일만에 집에서 키보드를 잡아봅니다.
나의 숙원사업과 Agile에 대한 비관론
저는 운 좋게도 주니어 시절 하나의 컴포넌트에 전력을 쏟을 기회가 있었습니다.
그 경험 덕분에 저는 지금, 애자일을 조금 다르게 바라보게 되었습니다.
Agile ? 되겠냐고~
그게 뭔데
개발일 하는 사람들은 "애자일(Agile)" 이라는 단어를 참 많이 듣게 됩니다.
"작동 가능한 것의 반복적이고 신속한 구현을 추구하는 개발문화"
누군가는 "허상" 이라 말하고
누군가는 "실력이 아주 좋은 사람들이나 쓰는 것" 이라 말하고
누군가는 "그냥 좋은 말 덩어리" 라 말하고
누군가는 "또 하나의 의미없는 구호"라 말하죠.
나도 별반 다르지 않았다.
저도 이런 생각은 별반 다르지 않아서
"아 또 구호 외치는구나" 생각하면서 그냥 코드치고 고치기를 반복했습니다.
오늘의 경험이 있기 전 까지는 말이죠.
새롭게 시도한 개발방식
나의 숙원사업
이번 개발에서는 제가 ASPICE를 적용받는 프로젝트로 실무 개발을 입문한 뒤로
숙원사업처럼 여겨오던 것을 어느정도 각 잡고 해봤습니다.
"제대로 설계한 기록을 남긴 뒤에 구현을 하고 싶다"
이 모듈을 구현하기 위해 알아야 하는 내용들(IC라던지, 통신이라던지)을 제대로 알고
구현해야 하는 기능이 무엇인지, 어떻게 흘러가야 하는지
뭐.. 사실 오늘도 스프린트 내일도 스프린트 이게 현실이니, 꿈만같은 소리죠
그래서 시제품도 제대로 나오지 않는 시점에
한번 승부수를 던져봤습니다.
'어차피 시제품도 없고 다 처음 보는 것들인데, 굳이 난장판부터 만들 이유 없지'
이런 생각도 좀 있었달까요?
그래서 결론은
일주일의 공수를 넣어서 천 줄 남짓 되는(한줌단 수준의) 기초 기능을 만들어낸게 전부지만
제법 만족스러웠습니다.
이게 되네?
데이터시트, 통신표준, MCU/MCAL/AUTOSAR 매뉴얼을 죄다 펼쳐놓고
모르는 개념들 중 이번 구현에 필요한 것들만 추려가며
하나씩 하나씩 사내 컨플루언스에 정리하고 또 정리했습니다.
솔직히 저도 이런식으로 각 잡고 해본적은 없어서
'이거 그냥 액추에이터 제대로 돌기는 커녕 내가 병목이 되서 아주 망해버리면 어쩌지'
어제 오후에 샘플 받은 이후로 이 생각만 하면서 걱정만 앞섰습니다.
그런데 웬걸,
오히려 샘플 도착하고 1.5일(이라고 하고 16시간이라고 적는다)만에
월월화수목금금...
기본 기능이 제대로 돌아가는 코드가 되었습니다.
네, 오히려 너무 잘 돌아가서 당황스러운 상태로 퇴근했습니다.
아유 배불러, 하고싶은거 다 해봤다!
1. IC의 상태를 어떻게 설정하고 상태기계를 어떻게 정의할지 하루종일 고민하기
2. 새로 접한 통신 프레임이 정확히 어떻게 동작해야 하는지 반나절 생각하고, 첫 단추부터 제대로 끼워진 자산화를 위해 오후 내내 자체 E2E 모듈 세번 갈아엎기
3. 협업팀이 센서-액추에이터 조합에 대해서 가장 적합한 구조체와 유니온을 선언하고 조건부 컴파일 설정하는 데 하루종일 쓰기
4. 인터럽트 처리를 위해 필요한 설정들을 정확히 이해하기 위해 하루종일 문서와 레거시 코드 찾아보고 코드에는 미리 선반영하면서 컨플에 정리하기
5. "대체 왜 저렇게까지 하는지 모르겠다" 소리 들으면서 하루종일 VsCode 켜놓고 모듈 구조 갈아엎기
진짜 하고 싶은거 다 해본 기능 개발이었네요.
다시 적고보니 배가 너무 불러서 내일 아침은 안 먹어도 될 것 같습니다.
그렇게 생긴 나의 Agile
덕분에 어깨가 사무실 천장까지 올라간 느낌이 된 저는
아주 자신있게 말할 수 있게 되었습니다.
애자일은 "신속 구현이다" 다만, "충분히 설계된 것을" 말이다.
이번에 3년차 치고는 나름대로 Show And Prove 한 게 아닌가 생각해봅니다.
부족한 인력으로 ASPICE 대응한다고 매일같이 테스트에서 나오는 결함을 수정하다가 하루가 가고
또 그거 여기저기 설명한다고 시간이 녹아서 사라지고
협력업체의 늦은 샘플 제작으로 새로운 기능을 급하게 개발하느라 또 실수하고
대기업에서도 자주 벌어지는 일입니다.
Q. 뭐? 대기업에서도 자주?
A. 죄송합니다. 자주가 아니라 항상 그렇습니다.
그런데 이게. 설계만 잘 되어있으면
어느정도 만회가 되기는 진짜 되더군요.
폭포수 방식에도 Agile은 가능합니다
V-Cycle 안에서 작은 변주 주기
기회가 생겼기에, 작은 변주를 주는 용기를 내보았습니다.
솔직히 이번처럼 한 모듈에 집중할 수 있었던 건 운이 좋은겁니다.
하지만 이 기회에 저는 설계와 구현을 끝까지 따라가며 시험해보고 싶었던거죠.
다행히도 짧은 스프린트로도 기본 기능이 안정적으로 돌아갔습니다.
사실 저희 회사가 쓰는 V-Cycle이라고 불리는 물건은 "다중 폭포수 방식"에 가깝습니다.
물에젖고 물만맞는 여기는 아마아마존~ 다중 폭포수 모델이 이렇게 생겼습니다. 아마존 익스프레스냐고
하나의 Cycle 안에서 개발 주기를 어떻게 운영할지는
그 개발조직의 전략적 결정에 따르는 거라서
이번에 3.5일 설계 + 1.5일 구현의 사이클을 두 번 하는 방법으로 변주를 좀 줘봤습니다.
- 맨땅에 문서뿐인 첫째주 : 전체 설계 + 통신과 모듈간 인터페이스 구현에 집중
- 샘플이 도착하는 둘째주 : 상세 설계 및 구현 + 디버깅에 집중
그리고 결과도 제법 좋았습니다.
그래서, 애자일(Agile) 방식은 어디에서나 통할 수 있습니다.
결국 애자일은 ‘급조한 구현’이 아닙니다.
훈련된 설계 위에서 집중한 구현이 있을 때 비로소 살아납니다.
제 개발 경력은 여기 계시는 분들에 비해서 아주 짧습니다.
하지만 제가 3년 조금 넘는 기간동안 겪어 본 개발일을 해오면서
프로세스와 애자일은 서로를 잘 보완하면서 공존할 수 있는 개념이라는 나름대로의 확신이 있습니다.
결국 조직이 Agile을 잘 소화해내는 비법은 특이한게 아니라
조직이 정도를 걸으면서 개발하는 것을 선택하고
하나의 스프린트를 개발자 본인이 밀도있게 운영한다면
그 경험이 더 빠르고 정확한 설계와 밀도있는 구현을 실현하는 훈련으로 작용해서
조직이 Agile을 잘 소화할 수 있게
강해지는것
이게 핵심이라고 생각합니다.
애자일은 구호가 아닙니다. 설계를 훈련한 개발자에게는 실제 방법론이 됩니다.
마무리
여러분 회사의 Agile은 어떻게 굴러가고 있나요? 저처럼 ‘운빨 집중 경험’ 해보신 적 있나요?
애자일이 말로만 좋은 개념이 되는 가장 큰 이유가 무엇인지 생각을 공유해주시면
우리 모두가 더 좋은 개발문화를 고민하는 데 큰 도움이 될 것 같습니다.