논문 원고를 본격적으로 붙잡으니, 실험보다 설명 구조가 더 어렵다. 코드를 돌리고 결과를 얻는 일은 오래 해왔지만, 왜 이 두 케이스를 택했고 왜 이런 전처리와 점수 보정이 필요한지 처음 보는 사람에게 납득시키는 건 완전히 다른 종류의 작업이다.
오늘 교수님과 이야기하면서 받은 코멘트도 대부분 그쪽이었다.
| 피드백 | 지금 내가 받아들인 숙제 |
|---|---|
| 분량이 더 필요하다 | 실험 데이터와 해석을 더 많이 풀어 써야 한다 |
| Chronos 같은 foundation model도 봐라 | 기존 모델군 밖의 비교 실험을 추가해야 한다 |
| 용어를 더 정확히 써라 | 단순 supply chain보다 national import 쪽 표현이 낫다 |
결국 원고에서 막히는 부분은 숫자가 아니라 맥락이다. 실험을 한 사람에게는 당연한 과정도, 논문 심사자 입장에서는 왜 그런 단계를 넣었는지 하나씩 설명해야 한다. 특히 TRS 보정 과정은 “그냥 잘 맞게 만든 것 아닌가”라는 질문을 받기 쉬워서, 이론적 근거와 중간 비교를 같이 보여줘야 할 것 같다.
지금 원고는 겨우 뼈대가 잡힌 느낌이다. 두 케이스 비교, TRS 파이프라인, 모델 결과, 조기경보 해석까지 흩어져 있는 내용을 하나의 흐름으로 묶어야 한다. 실험만 놓고 보면 이미 꽤 멀리 왔는데, 문서로 옮기려니 여전히 시작점 같은 기분이 든다.
지금 가장 아픈 지점
내가 알고 있는 맥락이 너무 많다는 점이다. 연구를 오래 붙잡고 있으면 설명을 생략하게 된다. 그런데 논문은 그 생략을 허용하지 않는다. 왜 이게 중요한지, 왜 이런 선택을 했는지, 어디까지 주장할 수 있는지를 처음부터 다시 써야 한다.
그래서 당분간은 모델을 하나 더 붙이는 것보다, 지금 있는 결과를 어떻게 설명 가능한 구조로 바꿀지에 더 시간을 써야 할 것 같다. 아이러니하게도 논문 후반으로 갈수록 코딩보다 문장이 더 어렵다.