도메인 과학자와의 협업

공통 언어 만들기

왜 필요한가. 분야가 다르면 같은 단어를 다른 뜻으로 쓴다. 문제는 모르는 단어가 아니라 안다고 생각하는 단어다. 모르는 단어는 묻지만, 아는 단어는 묻지 않는다. 그래서 오해가 회의록에 남지 않고 결과물에서야 드러난다.

용어 대응표. 협업 초기에 자주 쓰는 단어를 모아 양쪽의 뜻을 나란히 적는다. 다음은 자주 엇갈리는 예다.

대응표는 사전이 아니라 프로젝트 문서다. 이 프로젝트에서 각 단어를 어떤 뜻으로 쓸지 정하고, 애매한 단어는 수식어를 붙인다. 예를 들어 "validation"은 "검증 분할(validation split)"과 "실험 검증(experimental validation)"으로 나누어 쓴다.

서로의 '당연한 가정' 드러내기. 용어보다 더 깊이 숨는 것이 가정이다. 각 분야에서 너무 당연해서 말하지 않는 것들이 있다.

• ML 쪽의 당연한 가정: 데이터는 서로 독립이고 같은 분포에서 나왔다. label은 정답이다. 데이터가 많을수록 좋다. 평균 오차가 작으면 좋은 모델이다.
• 도메인 쪽의 당연한 가정: 측정에는 불확도가 있다. 같은 날, 같은 장비, 같은 배치의 측정은 서로 닮았다. 물리량은 보존·대칭·단조성 같은 제약을 따른다. 극단값(파괴, 고장, 희귀 사건)이 평균보다 중요할 수 있다. 결과는 메커니즘으로 설명되어야 한다.

이 가정들은 충돌한다. "데이터는 독립"이라는 ML 가정과 "같은 배치는 닮았다"는 도메인 지식이 만나면 분할 방법이 바뀐다(15.4장). "label은 정답"과 "측정에는 불확도가 있다"가 만나면 목표 오차의 하한이 정해진다. 드러내는 방법은 단순하다. 첫 회의에서 서로에게 **"당신 분야에서 이 데이터를 처음 받으면 무엇부터 확인하는가?"**를 묻는다. 대답에 상대 분야의 당연한 가정이 들어 있다.

문제 정의 합의

왜 필요한가. 도메인 과학자가 가져오는 질문과 ML로 풀 수 있는 질문은 대개 정확히 겹치지 않는다. 도메인 과학자는 "이 전해질이 왜 빨리 열화되는지 알고 싶다"고 말하고, ML 연구자는 "그럼 열화 속도를 예측하는 모델을 만들자"고 듣는다. 예측 모델이 "왜"에 답하지 않을 수 있다는 사실은 몇 달 뒤에야 드러난다.

교집합을 찾는다. 좋은 협업 문제는 네 조건의 교집합에 있다.

1. 과학적으로 의미 있다: 답이 나오면 도메인 과학자의 결정이나 이해가 바뀐다.
2. ML로 풀 수 있다: 입력·출력·평가가 정의되고, ML이 기존 방법보다 나을 이유가 있다.
3. 데이터가 있거나 만들 수 있다: 양·질·접근 조건이 문제에 맞는다.
4. 검증할 수 있다: 결과가 맞았는지 확인할 방법(실험, 독립 데이터, 이론)이 있다.

교집합을 찾는 대화에서 ML 연구자는 방법보다 결정을 묻는다.

• 이 질문의 답이 나오면 무엇을 다르게 하는가? (어떤 실험을 먼저 하는가, 어떤 후보를 버리는가)
• 지금은 그 결정을 어떻게 내리는가? 그 방법의 비용과 한계는?
• 어느 정도 맞으면 쓸모가 있는가? 틀리면 어떤 손해가 나는가?
• 결과를 믿으려면 무엇을 보여 줘야 하는가?

도메인 과학자는 반대로 ML이 할 수 없는 것을 묻는다. 데이터에 없는 조건에서도 맞는가? 왜 그런 예측을 했는지 설명할 수 있는가? 불확실성을 함께 주는가?

문제 정의서. 대화의 결과를 1.3장의 문제 정의 문서 양식에 쓰고, 협업에 필요한 항목을 더한다.

"두 질문의 관계"와 "범위 밖" 항목이 핵심이다. 예측 모델이 메커니즘을 설명하지 않는다면, 그 사실을 처음부터 적어 둔다. 기대가 맞춰져 있으면 실망도 없다.

도메인 전문가와 반복한다. 문제 정의서는 한 번에 완성되지 않는다. 데이터를 처음 보고, 첫 baseline을 돌리고, 첫 오류 분석을 하면 정의가 바뀐다. 중요한 것은 반복의 단위를 작게 하는 것이다. 몇 달 동안 혼자 모델을 다듬은 뒤 결과를 보여 주지 말고, 첫 주에는 데이터 요약과 이상해 보이는 측정 몇 개를, 둘째 주에는 가장 단순한 baseline의 오류를 도메인 단위로 보여 준다. 도메인 과학자가 "그 측정은 장비 교체 직후라 원래 이상하다"고 말해 주는 순간이, 혼자서는 몇 주가 걸렸을 발견이다.

평가 기준의 조율

왜 필요한가. ML 연구자는 test RMSE가 내려가면 진전이라고 느끼고, 도메인 과학자는 예측이 물리적으로 말이 되고 실험으로 확인될 때 진전이라고 느낀다. 두 기준이 따로 놀면, ML 연구자는 숫자를 개선했는데 도메인 과학자는 아무것도 바뀌지 않았다고 느낀다. 평가 기준은 문제 정의와 함께 결과를 보기 전에 합의한다(23.4장).

ML 지표와 과학적 타당성의 연결. 도메인 요구를 측정 가능한 점검으로 바꾸는 것이 조율의 핵심이다.

마지막 두 줄은 특히 중요하다. 후보 물질을 고르는 문제라면 평균 오차보다 상위 후보가 실제로 좋은가가 도메인 과학자의 관심이다. 예를 들어 무작위로 고른 후보의 적중률이 5%인데 모델이 고른 상위 10개 중 3개가 적중했다면, 모델은 무작위 대비 6배 효율적이다. 이 숫자는 RMSE보다 도메인 과학자의 결정과 직접 연결된다.

평가 기준 문서. 문제 정의서와 짝을 이루는 문서로, 다음을 적는다.

• 주 지표와 보조 점검: 무엇을 기준으로 성공을 판단하고, 무엇을 반드시 함께 보고하는가.
• 기준값: 무엇보다 얼마나 좋아야 성공인가. 기존 방법(물리 모델, 경험식, 전문가 판단)의 성능과 측정 반복성을 함께 적는다.
• 실패 시 결론: 기준에 못 미치면 무엇을 배웠다고 쓸 것인가(23.4장).
• 검증 단계: 회고적 평가 → 독립 데이터 → 전향적 실험 중 이 프로젝트가 어디까지 갈 것인가.

ML 지표 개선을 과학적 기여로 포장하지 않는다. RMSE가 5% 내려갔지만 그 차이가 측정 반복성보다 작다면, 그 개선은 도메인에서 구별할 수 없다. 예측이 보존 법칙을 어긴다면 평균 오차가 작아도 쓸 수 없다. 이런 경우 "과학적 발견을 가속했다"가 아니라 "벤치마크에서 지표를 개선했다"고 쓴다. 정직하게 쓴 작은 기여가 과장된 큰 기여보다 협업을 오래 지속시킨다.

데이터와 실험

왜 필요한가. ML 연구자는 데이터가 이미 있는 상태에서 협업을 시작하는 경우가 많다. 그러나 데이터가 어떻게 만들어졌는지 모르면, 누수를 막는 분할도, 의미 있는 오차의 크기도, 모델이 무엇을 배웠는지도 알 수 없다. 그리고 실험 데이터를 새로 만드는 협업이라면, 실험 설계 단계에서의 결정이 나중에 어떤 모델을 만들 수 있는지를 정한다.

실험 설계에 처음부터 참여하기. 도메인 과학자가 실험 계획을 세울 때 ML 연구자가 함께 있으면 다음을 반영할 수 있다.

• 조건의 범위와 분포: 모델이 일반화해야 할 조건을 데이터가 덮는가. 쉬운 조건에만 몰리지 않았는가.
• 반복 측정: 같은 조건을 몇 번 반복해 측정 반복성을 알 수 있는가. 이 값이 목표 오차의 하한이 된다.
• 그룹 정보: 배치·날짜·장비·작업자를 기록하는가. 그룹 단위 분할과 배치 효과 분석에 필요하다.
• 대조군과 음성 결과: 실패한 합성, 효과가 없는 조건도 기록하는가. 성공만 있는 데이터로는 성공과 실패를 구분하는 모델을 만들 수 없다.
• 순차 실험: 모델의 예측으로 다음 실험을 고를 수 있는가(능동 학습, 베이지안 최적화). 그렇다면 실험 주기와 모델 갱신 주기를 맞춘다.

데이터 생성 과정의 기록. 도메인 과학자에게는 당연해서 기록하지 않는 정보가 ML에는 결정적일 때가 많다. 장비의 교정 날짜, 측정 순서, 시료 보관 시간, 전처리 소프트웨어의 버전 같은 것이다. 데이터를 받을 때 데이터 문서(15.5장)의 "수집" 항목을 도메인 과학자와 함께 채운다. 질문은 구체적으로 한다. "측정 순서가 조건별로 무작위였는가?", "같은 시료를 두 번 잰 적이 있는가?", "이 열의 0은 측정값인가, 결측인가?"

시간 척도의 차이를 인정한다. 모델 학습은 몇 시간이고 실험은 몇 주다. 셀 수명 시험은 몇 달, 현장 관측은 계절 단위다. ML 쪽의 빠른 반복 리듬을 실험 쪽에 강요하지 않는다. 대신 실험을 기다리는 동안 할 일(기존 데이터의 오류 분석, 합성 데이터로 파이프라인 점검)을 계획에 넣는다.

협업의 운영

왜 필요한가. 좋은 문제 정의도 운영이 없으면 흐려진다. 바쁜 학기에 회의가 끊기고, 결과가 공유되지 않고, 저자와 발표 경로에 대한 기대가 어긋나면 협업은 조용히 끝난다. 협업의 운영은 연구의 일부다.

역할과 기대 관리. 시작할 때 다음을 명시적으로 합의하고 문서로 남긴다. 말로만 하면 각자 다르게 기억한다.

"각자의 목표"는 자주 빠지지만 가장 중요한 항목이다. ML 쪽 학생은 학회 마감에 맞춘 방법 논문이, 도메인 쪽 학생은 분야 저널의 과학적 결과 논문이 필요할 수 있다. 두 필요가 모두 정당하다. 하나의 논문으로 둘 다를 만족시키려 하기보다, 방법 논문과 응용 논문을 나누고 각각의 제1저자와 투고처를 미리 정하는 것이 갈등을 줄인다.

저자 기여와 발표 경로. 저자 기준은 프로젝트 시작에 합의하고, 기여가 바뀌면 다시 확인한다(23.12장). 학제 간 협업에서 특히 주의할 것은 데이터를 만든 사람의 기여다. 수개월의 실험으로 데이터를 만든 도메인 연구자를 감사의 글에만 쓰는 것은, 그 사람이 저자 기준(실질적 기여, 원고 검토, 최종 승인, 책임)을 충족할 기회를 주지 않은 것일 수 있다. 반대로 데이터를 넘겨준 것 외에 참여하지 않았다면 저자 기준을 충족하지 않는다. 기준을 미리 공유하고, 원고 검토에 참여할 기회를 준다. CRediT 역할로 기여를 기록해 두면 이 대화가 구체적이 된다.

주기적 검토. 리듬을 정한다(집필 시점 예시).

• 짧은 정기 회의(1–2주마다, 30분): 지난번 이후 한 것, 막힌 것, 다음까지 할 것. 결과는 도메인 단위의 그림으로 보여 준다.
• 깊은 검토(1–2개월마다): 문제 정의서와 평가 기준을 다시 읽고, 바꿀 것이 있는지 확인한다. 바꾸면 이유와 함께 기록한다.
• 결정 기록: 회의에서 내린 결정과 이유를 공유 문서에 한 줄씩 남긴다(23.7장). 석 달 뒤 "왜 이 분할을 썼더라"에 답하는 것은 이 기록이다.

결과 공유 방식. 상대 분야가 읽을 수 있는 형태로 공유한다. ML 연구자는 loss 곡선 대신 도메인 단위의 예측 대 측정 그림, 가장 크게 틀린 사례 목록을 보여 준다. 도메인 과학자는 측정 조건과 불확도를 함께 준다. 공동 산출물(코드 저장소, 데이터 문서, 결과 그림)은 양쪽이 접근할 수 있는 곳에 두고, 버전을 관리한다. 코드 저장소에 익숙하지 않은 협력자를 위해 결과 요약 문서를 따로 둔다.

협업이 어려워질 때. 결과가 기대에 못 미치거나, 한쪽의 참여가 줄거나, 저자에 대한 의견이 갈릴 수 있다. 처음에 합의한 문서로 돌아간다. 문제 정의서의 "실패 시 결론"과 "범위 밖", 역할 문서의 "의사결정" 항목이 이때 쓰인다. 합의 문서가 없다면, 지금이라도 쓴다.

참고 문헌

• Brand, A., Allen, L., Altman, M., Hlava, M., & Scott, J. (2015). Beyond authorship: Attribution, contribution, collaboration, and credit. Learned Publishing, 28(2), 151–155. — 협업의 기여를 기록하는 CRediT 역할 분류