모델이 할 수 있는 주문의 상/하한을 결정하는 공식을 고객사가 수정해달라고 하는 경우가 종종 있다. 문제는, 모델은 해당 공식에 대해 학습되어 있지 않은 채 프로덕션 단에서 수정해야 했다는 것이다. 빨리 고쳐야 하니 말이다. 물론 성능이 떨어질 것임은 숙지시켰지만, 이럴거면 왜 AI를 쓰는가 하는 의문이 생긴다. 여튼 우리는 개쩌는 AI를 만들어 낼 것이므로 성능 향상을 계속 지향하고 있다.
하지만 걸림돌이 몇 가지 있었다. 해당 공식에 대한 설명은, 전-전 팀장님에게 들은, 고객사에서 수정요청해서 급하게 반영한 공식에 대한 설명 뿐이었다. 심지어 내 머리 속에 유일하게 남아있었다. 대충, "합성함수를 사용한다 + 그래서 이런저런 요건을 만족하는 방정식을 만들려고 하는데 + 빡세서 수치 몇 개 대입해서 하드코딩 했다". 딱 이 내용이었다. 그리고 이 내용에 대한 주석은 전혀 없었다.
이렇게 되면 코드만 보면 절대로 의도를 알아차릴 수 없다. 공식을 자세히 밝힐 수는 없지만, 파라미터의 값에 따른 case문 형식의 하드코딩이 들어간 시점에서, 이미 그 방정식의 성질은 유추할 수 없게 된다. 여튼 그래서 기억을 더듬어 다시 해당 공식의 의미는 정리해 놨다. 팀원들에게도 설명해 두긴 했는데, 문서화 했었나, 안했었나... 여튼 내 노트에 있는데 조만간 업데이트해야겠다. 주석도...
또, 고객사에서 수정해달라고 하기 전부터 이용되고 있던, 모델이 학습된 환경과 동일한 공식의 의도 또한, 주석이 없다. 다만 다행인 것은, 이건 하드코딩은 아니다. 1차함수, 지수함수, 로그함수, 합성함수가 이용되었는데, 몇 가지 상수는 있지만, 괜찮은 수준이다. 하지만 처음에 코드에서 이 공식을 뽑아낸 직후엔 의도를 파악하지 못했다가, 어제 학습 데이터 프로세싱 돌리면서 시간이 떠서 이걸 보다보니, 그제서야 파악할 수 있었다.
이 공식은 완벽하지는 않지만 생각보다 현재 고객사가 요청했었던 요건들을 어느정도 반영하고 있었다. 이걸 모르고 있었기 때문에, 현재 고객사가 요청한 것들을 만족시키기 위해, 쓸데없이 프로토콜에 새로운 필드를 심고, 두 개의 파라미터로 공식을 만들게 되었다. 그냥 하나의 파라미터로 이용하는 공식을 좀 더 가다듬으면 되었는데 말이다.
이렇게 또 소중한 경험을 쌓게 되었다(리버스 엔지니어링). 나도 평소에 주석은 좀 장황한 절차가 있는 경우 스텝에 대한 설명 정도를 적는 정도인데, 앞으로는 해당 함수의 의도도 잘 적어놔야겠다. 특히 1차함수 혹은 사칙연산의 범위를 벗어난 경우는 그 식의 의도는 물론, 함수의 성질까지 무조건 적어야겠다.