좋은 머신러닝 업무 문서는 무엇이 다를까: 실험과 판단을 기록하는 8가지 원칙

머신러닝 엔지니어로 일하다 보면 모델을 만드는 것만큼이나 실험 결과를 정리하고, 의사결정의 이유를 문서로 남기는 일이 많다.

어떤 모델을 왜 실험했는지, 파라미터는 왜 그렇게 정했는지, 결과에서 무엇을 알게 되었는지, 그리고 다음에는 무엇을 해야 하는지를 계속 기록해야 한다.

그런데 일을 하다 보니 실험 결과를 많이 적는다고 해서 좋은 머신러닝 업무 문서가 되는 것은 아니었다.

내용은 다 있는데 왜 이 실험을 했는지 잘 모르겠거나, 결과는 많은데 그래서 결론이 뭔지 애매한 경우가 있었다. 반대로 분량은 길지 않은데도 지금 어떤 문제가 있고, 왜 이걸 했고, 다음에는 뭘 할지가 금방 이해되는 문서도 있었다.

그 차이가 뭘까 생각하면서 몇 가지 원칙을 정리해두기 시작했다. 아직 잘 지킨다고 하기는 어렵지만, 문서를 쓰거나 실험을 정리할 때 한 번씩 돌아보는 기준으로는 꽤 유용했다.

 

왜 하는 일인지 먼저 쓴다

가장 먼저 신경 쓰게 된 건 문서의 시작이었다.

작업을 한 사람 입장에서는 보통 이렇게 쓰기가 쉽다.

Augmentation을 추가해서 실험했다.
Learning rate를 조정했다.
새로운 feature를 넣어봤다.

당사자 입장에서는 아무 문제가 없다. 이미 며칠 동안 그 문제를 생각했으니까 왜 augmentation을 했는지도 알고 있고, 왜 그 feature가 필요했는지도 알고 있다.

문제는 다른 사람이 읽을 때다.

읽는 사람은 그 며칠의 맥락을 공유하고 있지 않다. 그래서 가능하면 작업 내용보다 먼저 현재 상황과 문제를 써두는 편이 낫다.

가령 이미지 분류 모델의 augmentation 실험이라면,

현재 모델은 training set에서는 성능이 높지만 validation set에서는 성능이 크게 떨어진다. 특히 촬영 각도나 밝기가 달라지는 경우 오류가 늘어난다. 학습 데이터의 촬영 조건에 과하게 맞춰진 문제인지 확인하기 위해 augmentation을 적용해본다.

정도만 있어도 충분하다.

이렇게 써두면 뒤에 나오는 결과를 보는 기준도 생긴다. 단순히 accuracy가 올랐는지만 보는 게 아니라, 처음에 문제가 됐던 촬영 조건에서 실제로 성능이 나아졌는지를 보게 된다.

결국 문서 앞부분에서 해결하려는 문제를 먼저 적는 건 배경 설명을 친절하게 붙이는 것 이상의 의미가 있다. 뒤에 나올 실험과 숫자를 어떤 질문을 가지고 읽어야 하는지 먼저 정해주는 일이기도 하다.

머신러닝 실험은 해결책보다 원인 분석이 먼저다

머신러닝 일을 하다 보면 방법을 바꾸는 건 쉽다.

성능이 안 나오면 다른 모델을 돌려볼 수 있고, feature를 더 넣을 수도 있고, sampling을 바꿀 수도 있고, 하이퍼파라미터를 다시 잡을 수도 있다.

그래서 오히려 조심해야 하는 게 있다.

“안 되네. 그럼 다른 거 해보자.”

이 흐름이다.

예를 들어 이탈 예측 모델의 recall이 낮다고 해보자.

recall이 낮다는 건 결과일 뿐이다. 원인은 여러 가지일 수 있다.

positive 데이터가 너무 적을 수도 있고, label이 좋지 않을 수도 있다. 이탈을 구분할 정보가 feature에 없을 수도 있고, 단순히 threshold가 목적에 맞지 않을 수도 있다.

이 경우에 원인을 구분하지 않고 모델부터 바꾸면 실험은 많이 하는데 배우는 건 별로 없는 상태가 되기 쉽다.

그래서 가능하면 실험 전에 한 줄이라도 가설을 적는다.

Positive class가 전체 데이터의 3% 정도이고, 오분류의 대부분이 positive를 negative로 예측한 경우다. 우선 모델 구조보다 class imbalance가 얼마나 영향을 주는지 확인한다.

이렇게 해두면 결과가 안 좋아도 의미가 남는다.

sampling 방식을 바꿨는데도 거의 변화가 없다면 “이번 실험 실패”로 끝나는 게 아니라, 최소한 class imbalance 하나만으로는 현재 문제를 설명하기 어렵다는 정보가 생긴다.

같은 현상이라도 원인이 다르면 해야 할 일이 달라진다. 그래서 해결책을 찾기 전에 지금 보고 있는 현상이 왜 생겼는지부터 문서에 적어보려고 하는 편이다.

결정에는 이유를 한 줄이라도 남긴다

나중에 과거 실험 문서를 다시 볼 때 가장 답답했던 건 결과가 없는 경우보다 이유가 없는 경우였다.

예를 들어 이런 기록이 있다.

threshold = 0.3

그 당시에는 분명 이유가 있었을 것이다. 그런데 몇 달 지나고 나면 기억이 안 난다.

왜 0.3이었지? 0.5는 왜 안 썼지? 0.25도 비교했나?

결국 다시 확인해야 한다.

그래서 요즘은 수치 자체보다 왜 그렇게 정했는지를 같이 남기려고 한다.

이 문제에서는 false negative의 비용이 더 크기 때문에 recall을 우선했다. Threshold를 낮추면서 precision과 recall 변화를 확인했고, recall 80% 이상을 유지하면서 precision이 급격하게 떨어지기 전인 0.3을 운영 후보로 정했다.

완벽한 근거일 필요도 없다. 데이터가 부족해서 임시로 정한 값이라면 그것도 그대로 쓰면 된다.

현재 데이터만으로 최적값을 판단하기 어려워 0.3을 초기값으로 사용한다. 운영 데이터가 쌓이면 다시 조정한다.

이 정도만 남아 있어도 나중에 훨씬 이해하기 쉽다.

우선순위나 평가 기준, 파라미터처럼 판단이 들어가는 지점에서는 왜 그렇게 정했는지를 한 줄이라도 남겨두는 편이 좋다. 근거가 약한 결정과 근거가 없는 결정은 꽤 다르다.

한계를 안 쓰는 게 더 위험할 때가 있다

실험 결과가 잘 나오면 한계를 적기가 괜히 아쉬울 때가 있다.

AUC가 0.82에서 0.86으로 올랐는데, 굳이 “다만…”으로 시작하는 문장을 붙이고 싶지 않은 마음도 생긴다.

그런데 일을 하면서 보면 한계가 있는 결과 자체보다, 그 한계를 모르는 상태가 더 위험했다.

가령 새로운 feature를 추가하면서 학습 데이터도 6개월치에서 1년치로 늘렸다고 하자. AUC가 0.82에서 0.86으로 올랐다.

이걸 바로

새로운 feature를 추가해서 AUC가 0.04 개선됐다.

라고 쓰기는 어렵다. feature 때문일 수도 있고 데이터가 많아진 영향일 수도 있기 때문이다.

그럴 때는 그냥 그대로 쓰는 게 낫다.

이번에는 feature 추가와 데이터 기간 확대가 동시에 들어가서 두 효과를 분리하기 어렵다. 일단 이 구성에서 개선 가능성은 확인했지만, feature 자체의 효과는 데이터 조건을 고정해서 다시 확인할 필요가 있다.

이렇게 쓰면 결과가 약해지는 게 아니라 오히려 어디까지 해석할 수 있는지가 분명해진다.

그래서 한계를 적을 때는 가능하면 무엇이 한계인지, 왜 그런 한계가 생겼는지, 다음에는 어떻게 확인할 것인지를 같이 적으려고 한다.

한계를 잘 적는다는 건 결과를 스스로 깎아내리는 일이 아니라, 이 결과를 어디까지 믿어도 되는지 알고 있다는 뜻에 더 가깝다.

표를 만들었으면 한 번 더 생각한다

머신러닝 문서를 쓰다 보면 표를 만드는 데 꽤 많은 시간을 쓴다.

모델별 accuracy를 정리하고, precision과 recall을 비교하고, 실험별 AUC를 줄줄이 놓는다. 그래서 표를 완성하면 왠지 분석도 끝난 것 같은 기분이 든다.

그런데 표는 결과를 정리한 것이지 해석한 것은 아니다.

예를 들어 전체 accuracy가 88%에서 91%로 올랐다고 하자. 처음 보면 당연히 좋아 보인다.

그런데 class별로 보니 A는 94%에서 96%, B는 86%에서 90%로 좋아졌는데 C는 71%에서 63%로 떨어졌을 수도 있다.

그러면 “전체 성능 +3%p” 하나만으로는 부족하다.

왜 C에서만 떨어졌는지 봐야 한다. C 데이터가 적은 건지, 다른 class와 경계가 애매한 건지, label 자체에 문제가 있는 건지 확인해야 한다.

더 중요한 건 C가 실제 서비스에서 얼마나 중요한 class인지다. 전체 accuracy를 조금 올리는 것보다 C를 놓치지 않는 게 훨씬 중요한 문제일 수도 있다.

그래서 수치를 적고 나면 한 번 더 묻게 된다.

이 숫자가 실제로 말해주는 게 뭔가?

정량적인 결과뿐 아니라 오류 사례도 마찬가지다.

“오분류 100건”이라고 묶기보다 어두운 이미지, 가려진 이미지, class 간 경계가 모호한 경우, label 오류처럼 나눠보면 다음에 해야 할 일이 달라진다.

숫자를 얻는 것과 숫자에서 의미를 찾는 것은 다른 일이다.

일을 한 순서와 문서를 쓰는 순서는 다르다

실제 업무는 깔끔하게 진행되지 않는다.

데이터를 보다가 모델을 돌리고, 결과가 이상해서 다시 데이터를 보고, 그러다가 feature 아이디어가 떠오르고, 모델 하나를 더 돌렸는데 뜬금없이 label 오류를 발견할 수도 있다.

그 과정을 그대로 쓰면 업무 일지는 되지만 읽기 좋은 문서는 잘 안 된다.

월요일에는 전처리를 수정했고
화요일에는 LightGBM을 돌렸고
수요일에는 feature를 추가했고...

이런 기록은 뭘 했는지는 알려주지만 왜 그 일을 했는지, 각각이 어떻게 연결되는지는 잘 보여주지 못한다.

그래서 문서를 쓸 때는 실제 작업 순서를 어느 정도 버리고 다시 묶는다.

예를 들어 고객 이탈 모델 개선이라면 데이터 품질, feature, modeling, evaluation 정도의 상위 구조를 먼저 만들고 그 아래에 작업을 배치할 수 있다.

이렇게 해보면 우선순위도 좀 더 잘 보인다.

label 자체가 잘못되어 있다면 모델 튜닝보다 label 검증이 먼저다. 즉 “중요해 보이는 일부터”가 아니라, 어떤 일이 끝나야 다음 일을 제대로 할 수 있는가도 봐야 한다.

문서를 쓰다가 계속 '기타', '번외', '추가로' 같은 항목이 생긴다면 한 번쯤 구조를 다시 생각해볼 필요도 있다.

내용이 너무 많아서라기보다, 아직 각각의 작업이 어떤 관계인지 충분히 정리되지 않은 경우도 있다.

 

다 쓴 다음에는 반대편에서 한 번 읽어본다

문서를 쓰는 동안에는 생각이 계속 바뀐다.

그러다 보니 앞에서 쓴 내용과 뒤에서 내린 결론이 묘하게 안 맞는 경우가 있다.

 

앞에서는

데이터 부족이 가장 큰 문제다.

라고 해놓고, 마지막에는

다음에는 모델 크기를 더 키워보자.

라고 적을 수도 있다.

 

둘이 반드시 모순인 것은 아니다. 다만 연결 설명이 없다면 당연히 “데이터가 문제라면서 모델은 왜 키우지?”라는 질문이 나온다.

또 결과에서는 “개선 폭이 작았다”고 해놓고 결론에서는 “의미 있는 개선을 확인했다”고 쓸 수도 있다.

 

그래서 마지막에는 내용을 더 추가하기보다 한번 반대 입장에서 읽어보려고 한다.

내가 이 결론에 동의하지 않는 사람이라면 어디를 물을까? 다른 설명은 없을까? 이 결과만 가지고 정말 여기까지 말할 수 있을까? 평균값 때문에 특정 그룹의 악화를 놓친 건 아닐까?

 

그리고 아주 기본적인 것도 같이 본다.

표와 본문의 숫자가 맞는지, 같은 용어를 계속 같은 의미로 썼는지, 앞뒤의 평가가 일관되는지.

생각보다 이런 것만 확인해도 문서가 많이 정리된다.

 

어디까지 하면 끝나는 업무인지를 미리 정한다

사실 이건 필자도 잘 안 되는 부분이다.

머신러닝 업무는 파고들수록 할 게 생긴다. 모델을 보다가 데이터 이슈를 발견하고, 데이터를 보다 새로운 feature가 떠오르고, 그걸 확인하다 보면 다른 모델까지 궁금해진다.

다 재미있고 필요한 일처럼 보인다.

 

그러다 보면 처음 하던 일은 끝이 안 난다.

그래서 가능하면 일을 시작할 때 이번 작업의 완료 조건도 적어두려고 한다.

예를 들어,

Transformer 모델의 최적 성능을 찾는다.

라고 하면 사실 끝이 없다.

반면,

현재 baseline보다 가능성이 있는지 확인해서 추가 실험 여부를 결정한다.

라고 하면 이번에 어디까지 해야 하는지가 훨씬 분명하다.

 

모든 실험이 처음부터 완벽할 필요도 없다.

처음에는 “이 방향을 더 볼 가치가 있는가?”를 확인하는 실험일 수 있다. 어느 정도 가능성이 확인된 이후에는 변수를 통제해서 정말 A가 B보다 나은지 검증하는 실험을 할 수도 있다.

둘은 목적이 다르다.

 

지금 하는 실험이 어떤 판단을 하기 위해 필요한지만 분명하면 된다.

작업이 끝난 뒤에는 세 가지 정도를 남기려고 한다. 무엇을 했는지, 무엇을 알게 됐는지, 그래서 다음에 뭘 해야 하는지.

“버그 수정 완료”보다는 “어떤 조건에서 왜 문제가 생겼고 어떻게 해결했는지”가 남아 있는 편이 다음에 훨씬 쓸모가 있다.

 

결국 확인하고 싶은 건 하나다

이렇게 적고 보니 원칙이 꽤 많지만, 실제로 문서를 다 쓴 뒤 확인하는 것은 의외로 단순하다.

이 문서만 읽은 사람이 내가 지금 무엇을 하고 있는지, 왜 하고 있는지, 그래서 다음에는 뭘 할 건지 이해할 수 있는가.

여기에 하나를 더 붙인다면,

같은 정보와 비슷한 제약을 가진 사람이 봤을 때 “왜 이런 판단을 했는지는 알겠다”고 느낄 수 있는가.

정도다.

 

결론에 반드시 동의할 필요는 없다. 다른 판단을 할 수도 있다. 그래도 적어도 왜 이런 결론이 나왔는지까지는 따라갈 수 있어야 한다.

그래서 요즘은 업무 문서를 단순히 결과를 정리하는 곳이라고 생각하지 않으려고 한다.

 

문서에 목적을 적으려면 일을 시작하기 전에 목적을 생각해야 하고, 판단의 이유를 적으려면 왜 그런 선택을 했는지 스스로 설명할 수 있어야 한다. 숫자를 해석하려면 metric 하나만 보고 넘어갈 수도 없고, 한계를 쓰다 보면 지금 결과로 어디까지 말할 수 있는지도 자연스럽게 생각하게 된다.

 

결국 문서를 쓰는 방식이 일하는 방식에 영향을 준다.

처음에는 일을 잘 설명하려고 이런 원칙들을 정리하기 시작했는데, 계속 쓰다 보니 오히려 반대에 더 가까운 것 같다.

잘 설명하기 위해 생각을 정리하는 게 아니라, 제대로 생각하기 위해 문서를 쓴다.