나/생각 주머니

덤벙대는 개발자를 위한 글 : 내가 버그 발생률을 획기적으로 낮춘 방법

Lou Park 2023. 1. 21. 16:29

나는 어떤 사람인가?

학창시절 필통도, 샤프도, 지우개도 반년 이상 들고다녀 본적이없다. 모두 잃어버렸다. 우산은 말할 것도 없지, 이젠 아예 유치원생이 들고다닐 것 같은 샛노란 우산을 사서 까먹지 않게 한다. 본가에 내려가서 다시 올라올때도 노트북 충전기나 뭐 하여튼 중요한 것을 꼭 하나씩 빠뜨리고 올라와서 부모님이 택배로 다시 보내주신다. 장기 기억력은 남들보다 뛰어나지만 초 단기 기억력은 아주 나쁘다. 34 + 23과 같은 간단한 암산을 하다가도 중간에 까먹어버린다. ADHD일까? 검사는 받아보지 않아서 모르겠다. 슬프지만 이런 나를 받아들이는 중이다.

 

영화 <메멘토>를 보면 주인공은 단기 기억상실증을 앓고있어 온 몸에 문신을 하고 다닌다. 내가 다음에 할일, 이미 했던 일들을 기억해야하기 때문이다. 어렸을때는 그저 재밌게 봤던 영화중에 하나였지만, 이제는 내가 메멘토의 주인공처럼 살고있다. 개발자로서 쏟아지는 요구사항, 에러 처리, 그리고 한 명의 팀원으로서 주변 사람들을 챙기고 이끄는 일들은 내가 노력하지 않는다면 불가능할지도 모른다.

 

crontab을 사용하거나 at 명령어로 어떤 작업들을 예약해뒀을때 그 작업이 돌아가지 않을까봐 불안했던 적이있는가? 대부분은 본인이 작성한 프로그램이 작동하지 않을까봐지, 타임존을 제대로 설정했다면 컴퓨터에서 그 시간에 작업이 촉발되지 않을 것이라고는 크게 걱정하지 않는다.

 

나도 일에 대해서는 그렇게 믿을만한 사람이 되고 싶었다. 일상생활에서는 여전히 지우개를 잃어버리겠지만…ㅋㅋㅋ 작년 말쯤 “원숭이도 실수할 수 없는 코드” 포스팅을 작성하면서 나의 실수들을 복기하고 부족한 점들을 커버하기 위해 부단히 노력했다. 그리고 어느새 그게 몸에 익은 것 같아서 어떻게 내가 덤벙대지 않고 일을 하게되었나 공유해보려 한다.

 

측정가능한 목표를 정하자, KPI는 99.5%

지난 90일 Crashlytics 통계

이건 Firebase Crashlytics 통계인데 지난 90일간 통계를 보면 비정상 종료 미발생률이 96.62%로 보인다. (12월초 통계는 외부적 요인에 의한것…) 물론 개발중인 버전 포함한 수치이긴하지만 거의 4%가 크래시라는건데 굉장히 큰 수치다. 버그가 나면 무조건 안드로이드 팀부터 의심을 받았다. ㅋㅋㅋ 그도 그럴 것이… 대부분 안드로이드의 문제가 맞았으니까.

 

안드로이드 팀을 내가 리드하고 있다보니 진짜 개발 그만둬야하나라는 생각까지 갔다. 다른 앱은 어떤데? 첫 회사이다보니 다른 회사들의 사정을 몰랐다. 그러다 안드로이드 개발자 단톡방에서 비정상 종료 미발생 통계 KPI를 뭘로 잡냐는 말이 나왔는데, 99.5%라고 누군가 대답했다. 당시 우리 앱에서는 “그게 돼?”하는 수치였지만 나도 이 99.5%를 목표로 달려가겠다고 다짐했다.

 

그렇다. 첫번째 해야할 일은 측정가능한 목표를 정하는거다.

요즘은 99.5%는 가뿐하게 넘어간다.

그냥 목표를 정했을 뿐이긴 하지만, 목표를 뚜렷하게 설정하니 내가 잘하고 있는지, 못하고 있는지 확실하게 구분이 갔다. 원래는 96%가 되어도 평가 기준이 모호했기에 문제 의식을 크게 못느꼈지만, 이제는 확실하게 어떤 버전이 문제였다, 그럼 왜 문제였냐? 문제 인식, 원인을 추적하고 해결할 수 있게 되었다.

 

키보드보다 펜을 먼저

교수님도, 인터넷에 글을 읽어봐도 매번 강조하는 부분이 키보드로 바로 코딩을 하기보다 생각부터 먼저 하라는거다. 나처럼 3년차에 접어들은 프론트엔드 개발자들은 이제 대부분의 요구사항이 생각도 하지 않아도 될 정도로 쉬울지도 모른다. “좋아요 기능 추가해주세요”등이 그렇다. 디자인부터 먼저 쳐내버리고 음~ 어떻게 할까하면서 코드로 바로 뛰어들기 쉽다. 하지만 이 루트로 가다간 다음과 같은 3갈래 길 밖에 안나온다.

  • 중간에 예상하지 못한 복병을 만나서 삽질
  • 다 만들었다고 보여줬는데 기획팀에서 원하던게 아님
  • 배포전 QA나 배포 후 예상하지 못한 오류로 인해 크래시

ㅁㄹㅋ...

생각하자. 아무리 간단한 요구사항이라도 다시 한 번 더 의도를 확인하고, 어떤 예외상황은 없는가, 어떻게 구현해야하는가 다시 생각해봐야한다. 좋아요 기능을 예로 들었으니 덧붙이자면…기획서에 있는걸 생각하는 것만으로는 생각을 했다고 볼 수 없다. 1인당 좋아요 1개에요, 좋아요 끝나면 애니메이션 재생해주세요, 10초마다 한번씩만 좋아요하게 해주세요 등등… 다른 사람이 생각한거 말고 실제 구현하는 입장에서 한 번 고려해보는 것이다.

  • 유저가 발생시키는 좋아요 이벤트들을 어떻게 처리할 것인가?
    • 그냥 바로 API 호출? Channel? Flow? RX?
    • 따다닥-!을 어떻게 처리할것인가? 쓰로틀을 걸 방법 찾기, 어느정도가 적당한가?
  • 좋아요가 서버에서 처리중일때 어떻게 표현할 것인가?
    • 작게 로딩을 보여줄 것인가, 일단 숫자를 올려버려?
    • 실패하면 오류 메세지를 보여줄것인가, 그냥 모르는척 숫자만 내릴까?
    • 처리중에 유저가 나가버려도 메모리 leak이 발생하지 않게끔 구현하자
  • 로그인 안한 유저가 좋아요를 하면 어떡하지?
  • 이 부분은 다른 곳에서도 쓸 수 있을거같은데 모듈로 빼놓을까?

이렇게 고민하다가 기획자들이 생각 못한 부분들에 대해서는 한 번 더 확인시키고, 예외 상황들과 내가 개발 해야할 부분들은 체크 리스트로 정리하고 체크 해나가면서 개발하는 것이다. (체크박스를 하나씩 없애가는건 부가적 재미요소이기도 하다.) 나도 이 방법을 사용하고 대규모 커뮤니티 개편을 마친적이 있었는데, QA때 자잘한 UI 버그 수정정도만 하고 무사히 넘어가게 되었다.

 

TDD가 테스트 코드 작성하는게 느리다고는 하지만 코드에 확신을 가질 수 있어서 오히려 더 빠를 수도 있어요! 라고 하는게 이 맥락과도 비슷하다. 내가 내 코드의 커버리지를 알고 있기에 문제가 있어도 원인 파악이 빠르고, 예측할 수 있다.

 

이슈 전파하기

내가 A라는 한 사람과만 협업하여 일을 해야한다고 해도, Slack DM을 이용하지 않고 채널로 일을 하면 좋다. A에게 “이거 가능한지 조사해보고 알려드릴께요~”라고 DM을 했다고 치자.

나는 한 시간에 걸쳐 조사를 끝내고, A에게 이 사실을 말하는걸 깜빡했다. 아마도 A는 나를 계속 기다리다, 까먹을 거다. 또 다른 부서와도 연결되어 있을 경우, 서로가 서로를 기다리며 작업은 교착상태(Deadlock)에 빠질 수 있다.

 

어쩌다 회의에서 “그거 어떻게 되었어요?”로 이슈가 다시 수면위로 올라올때 “아~ 그때 Lou가 조사해보고 알려준다고해서 기다리고있어요”라는 말이 나온다. 또 기다린다. 스케쥴이 지체되고 이것은 어마어마한 비용의 낭비다.

 

공개된 채널에서 그 이야기를 했다면 중간에 다른 누군가 챙겨줄 수도 있다. 결국 내가 알려주는것을 까먹었다고 해도아까 말한 회의때 “Lou가 조사해보고 스레드에 남겨준다했는데 답글 안달린거보니 까먹은거같아요”라고 답해줄 수도 있다. 이렇듯 이슈를 공개된 채널에서 이야기하면 내가 회생불가인 덤벙거리는 인간이라고 해도 챙김받을 수 있다. “키보드 보다 펜을 먼저”가 TDD라면, “이슈 전파하기”는 오픈소스로 개발할때의 이점과 같다.

 

또 나와 같이 일하는 다른 사람들 역시 자동차를 타고 가면서 내 Slack을 읽고 있다고 생각하는 편이 좋다. 내 말을 중요하게 생각해주고 이렇게 얘기해놨으니 잘 알아들을 거같지만… 절대 아니다. 시속 70km로 지나가는 자동차에서 내 글은 스쳐지나갈뿐이다. 모두가 바쁘기에, 내가 알고있는 일이라면 2번 3번 확인시켜주는게 좋다.

네 확인했어요~

 

메모하기

짧은 Task나 아주 자잘한 요구사항들은 잊기 쉽다. 또, “에러 핸들링을 할 한줄을 적어야 겠다”라고 생각하는 순간 누군가 말을 걸어와 에러 처리를 까먹고 배포하고, 버그가 우수수- 떨어지는 것을보며 그때 말 건 남탓을 하기도 쉽다. 정신차리고 다시 생각해보면 말건사람 잘못이아니라 까먹은 나의 잘못이다.

 

짧은 Task가 들어오면 Notion이든 코드의 TODO.md든, 진짜 종이 메모장이든 만들어서 무조건 적어야한다. 나같이 덤벙대는 사람들은 그렇게 적은 메모장이 여러개일 경우 어디 적었는지 결국 까먹어버리는데 여기에서도 SSOT(Single source of truth) 원칙을 적용하면 좋다. 할 일은 모두 한 군데에서 관리하는거다. 이렇게만 해도 많이 좋아진다.

 

요즘 유튜브에서 재미로 간호사 썰을 많이 보고있는데, 대한민국 직장인 모두가 바쁠테지만 또 특히나 바쁜직종인 간호사들의 메모법도 차용할만 해보인다. 보통 Task 적을때 리스트 목록을 -로 표기하니깐, 할 일은 그렇게 표기하고 이미 한 일은 획을 하나더 추가해서 +로 표기를 전환한다.

+ 꽃밭에 물주기
- 빨래 널기
- 고양이 밥 주기

 

코드를 쓰다가 누군가 말을걸면 그냥 반사적으로 주석으로 TODO: 내가 생각하고 있었던 내용을 적어버리자. 그리고 얘기 끝나면 다시 그 라인에서 시작하면된다. 해당 주석 적을때까지만 “잠깐만요” 해둬도 된다. 어디까지 했더라 돌아보는 Context switching 비용은 상당히 크다. 이게 쌓이면 정신적 데미지가 된다. 그래서 회사에 불이나도 TODO를 남기고 주의를 돌려야겠다는 마음가짐이 있다. 진짜로 불이나면 좀 곤란하겠지만…?!

// TODO: 여기서 에러 핸들링 해야함

 

회사일은 회사 책상 메모장에, 그냥 일상에서 해야할 일은 손에다가 메모하고 있다.

근데 주위 사람들이 가끔 문신했냐고 물어봐줘서 까먹지 않을 수 있을 정도로 멋지게 적어야한다.

 

글을 마치며…

위와 같은 방법으로 많은 버그들을 줄이고 있고, 자신감도 붙고 있다. 하지만 여전히 난 출퇴근을 찍는걸 까먹어서 까먹지말라고 노트북에다 붙일 왕따시만한 스티커를 샀고, 우산을 들고가는걸 까먹을까봐 현관문에 걸리적거리게 우산도 걸어놓고 살고있다. 평균 이하로 꼼꼼한 나는 평균 이상의 꼼꼼함을 요구하는 직군에서 아직 고군분투중이다. 추가적으로 좋은 방법이 떠오르면 다음에 또 포스팅 해보도록 하겠다. 다른 도움될만한 팁이 있다면 댓글로 알려주셔도 좋을 것 같다.

' > 생각 주머니' 카테고리의 다른 글

본질을 이해하기  (0) 2024.01.06
주석은 중요하다  (0) 2023.10.15
UX 이야기 : 있어야 할 곳에 있다는 것  (0) 2022.10.22
원숭이도 실수할 수 없는 코드  (0) 2022.09.21
창의적인 생각에 관한 생각  (0) 2022.07.17