AI R&D 코드 리뷰를 3주간 돌려봤더니 바뀐 것

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

리뷰 없이 돌리던 실험이 먼저 흔들렸습니다

문제는 모델 성능보다 실험 맥락이었습니다

AI R&D 업무를 하다 보면 성능 지표가 조금만 오르거나 내려도 하루 분위기가 달라집니다. 저도 처음에는 모델 정확도, 학습 시간, 데이터 개수만 열심히 봤습니다. 그런데 3주 동안 코드 리뷰를 실제로 돌려보니, 성능보다 먼저 봐야 할 것은 왜 이 실험을 했는지 설명할 수 있는 구조였습니다.

특히 (주)천조기술연구원처럼 연구 개발 흐름을 다루는 조직이라면, 코드가 단순히 실행되는지만 보면 부족합니다. 연구 코드는 제품 코드와 달리 시행착오가 많고, 임시 변수나 실험용 스크립트가 빠르게 늘어납니다. 문제는 그 임시 코드가 어느 순간 기준 코드처럼 굳어지는 데 있었습니다.

• 실험 목적이 주석이나 문서에 남아 있지 않으면 다음 사람이 같은 실험을 반복합니다.
• 데이터 전처리 조건이 코드 안에 숨으면 결과 재현이 어려워집니다.
• 평가 기준이 매번 바뀌면 성능 개선인지 착시인지 구분하기 어렵습니다.

팁: AI R&D 코드 리뷰는 문법 검사가 아니라, 실험의 의도를 다음 사람이 이어받을 수 있는지 확인하는 과정으로 잡는 편이 훨씬 효과적입니다.

첫 주에는 리뷰가 조금 번거롭게 느껴졌습니다. 실험 하나 끝내기도 바쁜데, 변수명과 데이터 경로까지 설명하라고 하니 속도가 줄어든 느낌이었습니다. 하지만 막상 세 번째 실험부터는 이전 코드의 의도를 빨리 파악할 수 있어 오히려 재작업 시간이 줄었습니다.

3주 동안 써본 리뷰 방식은 가볍게 시작해야 했습니다

처음부터 엄격한 규칙을 만들면 연구자가 피곤해집니다

제가 처음 시도한 방식은 실패에 가까웠습니다. 일반 소프트웨어 개발팀처럼 브랜치 규칙, 승인자 지정, 커밋 메시지 형식까지 한 번에 정하려고 했습니다. 그런데 AI R&D 현장에서는 실험 속도가 빠르고, 가설이 자주 바뀌기 때문에 너무 촘촘한 규칙은 금방 부담이 됩니다.

그래서 두 번째 주부터는 리뷰 항목을 세 가지로 줄였습니다. 데이터가 무엇인지, 모델 설정이 왜 바뀌었는지, 결과를 어디에서 확인할 수 있는지만 보게 했습니다. 이 정도로 낮추니 연구원들이 리뷰를 감시가 아니라 기록 보조 도구처럼 받아들이기 시작했습니다.

1. 실험 코드 상단에 데이터셋 이름과 기준 날짜를 적습니다.
2. 하이퍼파라미터를 바꾼 이유를 한 줄로 남깁니다.
3. 결과 파일, 로그, 그래프 위치를 같은 형식으로 연결합니다.
4. 실패한 실험도 삭제하지 않고 실패 이유를 짧게 남깁니다.

권위 있는 연구 조직의 기록 습관을 참고했습니다

연구 조직의 신뢰는 결과 하나가 아니라 축적된 기록에서 나온다고 느꼈습니다. 예를 들어 한국과학기술연구원 관련 설명을 보면, 연구기관이 어떤 역할과 맥락 속에서 움직이는지 이해하는 데 도움이 됩니다. AI R&D도 결국 개인의 감각보다 조직의 축적 방식이 중요했습니다.

기업 연구개발의 관점에서는 기술 기업 사례를 다룬 지식백과 항목처럼 기술의 적용 분야와 사업 흐름을 함께 보는 태도가 필요합니다. 코드 리뷰도 마찬가지였습니다. 코드 자체만 보는 것이 아니라, 그 코드가 어떤 연구 목표와 연결되는지 보는 일이었습니다.

리뷰를 해보니 장점보다 단점이 먼저 보였습니다

가장 큰 단점은 속도가 느려진다는 감각입니다

솔직히 첫 며칠은 답답했습니다. 바로 학습을 돌리고 싶은데, 리뷰 요청을 남기고 확인을 기다려야 했습니다. 특히 작은 수정까지 모두 리뷰 대상으로 삼으면 AI R&D 특유의 탐색 속도가 크게 떨어집니다. 그래서 저는 모든 코드를 리뷰하지 않고, 결과 해석에 영향을 주는 코드만 리뷰 대상으로 좁혔습니다.

예를 들어 로그 출력 문구나 임시 시각화 코드는 가볍게 넘겼습니다. 반대로 데이터 필터링 조건, 학습률, 평가 지표, 샘플링 방식은 반드시 확인했습니다. 이 기준이 생기자 연구자들도 무엇을 보여줘야 하는지 빨리 감을 잡았습니다.

• 리뷰 대상: 데이터 전처리, 모델 설정, 평가 기준, 결과 저장 방식
• 자율 처리: 주석 정리, 파일명 변경, 임시 그래프, 개인 테스트 코드
• 보류 항목: 외부 공유 전 리포트 문장, 민감 데이터 포함 여부

장점은 실패한 실험을 다시 볼 수 있다는 점이었습니다

AI R&D에서는 성공한 실험보다 실패한 실험이 더 많은데, 보통 실패 코드는 빨리 잊힙니다. 그런데 코드 리뷰를 남기니 왜 실패했는지 흔적이 남았습니다. 같은 데이터 누락, 같은 라벨 오류, 같은 평가 착시를 반복하지 않는 데 꽤 큰 도움이 됐습니다.

특히 세 번째 주에는 이전에 버렸던 실험 하나를 다시 살렸습니다. 당시에는 성능이 낮아 폐기했지만, 리뷰 코멘트를 보니 평가 데이터 분포가 달랐습니다. 조건을 맞춰 다시 돌리니 결과가 완전히 달라졌고, 그때부터 팀 안에서 리뷰의 필요성을 조금씩 인정하는 분위기가 생겼습니다.

전문가식으로 거창하게 시작할 필요는 없습니다. 연구 코드 리뷰는 “이 코드를 다음 주의 내가 다시 이해할 수 있는가?”라는 질문 하나로도 충분히 출발할 수 있습니다.

제가 가장 효과를 본 리뷰 문항은 다섯 가지였습니다

긴 양식보다 짧은 질문이 오래갔습니다

처음에는 리뷰 양식을 표처럼 길게 만들었습니다. 하지만 아무도 꾸준히 쓰지 않았습니다. 실제로 유지된 것은 짧은 질문 다섯 개였습니다. 질문이 짧아야 실험이 많은 날에도 부담 없이 남길 수 있었습니다.

아래 문항은 3주 동안 계속 살아남은 항목입니다. 복잡한 조직용 문서가 아니라, AI R&D 실험자가 바로 복사해 쓸 수 있는 정도로 맞췄습니다. 이 정도만 해도 연구 흐름을 파악하는 데 필요한 핵심 정보는 대부분 남았습니다.

1. 이번 실험의 가설은 무엇인가요? 단순히 성능을 올린다가 아니라, 어떤 조건이 좋아질 것이라고 보는지 적습니다.
2. 이전 실험과 달라진 점은 무엇인가요? 데이터, 모델, 지표 중 하나라도 바뀌면 반드시 남깁니다.
3. 결과를 확인할 파일은 어디에 있나요? 로그 경로가 없으면 리뷰는 금방 말싸움이 됩니다.
4. 실패했다면 가장 의심되는 원인은 무엇인가요? 틀린 추측이어도 다음 실험의 출발점이 됩니다.
5. 이 코드를 재사용해도 되는 범위는 어디까지인가요? 연구용 임시 코드인지, 공통 모듈 후보인지 구분합니다.

작은 표 하나가 회의를 줄여줬습니다

코드 리뷰와 함께 간단한 표를 붙였더니 회의 시간이 줄었습니다. 말로 설명하면 길어지는 내용을 한눈에 볼 수 있었기 때문입니다. 아래처럼 실험 단위로 정리하면, 누가 봐도 현재 상태를 빠르게 파악할 수 있었습니다.

• 실험명: baseline_v3, sampling_test_02처럼 검색 가능한 이름을 씁니다.
• 변경점: 데이터 20% 추가, 라벨 정제, learning rate 변경처럼 구체적으로 씁니다.
• 결과: 정확도뿐 아니라 실패 로그, 추론 시간, 오류 유형도 함께 적습니다.
• 다음 행동: 유지, 폐기, 재실험, 공유 중 하나로 표시합니다.

기술 투자나 연구개발 흐름을 볼 때도 같은 생각이 들었습니다. 현대기술투자(주) 지식백과 항목처럼 조직의 판단은 단일 숫자보다 맥락과 기록을 함께 볼 때 더 선명해집니다. AI R&D 코드 리뷰 역시 점수 하나보다 변경 이유와 다음 행동이 같이 남아야 쓸모가 있었습니다.

현실적으로 든 시간과 비용은 이 정도였습니다

하루 20분을 넘기지 않는 선이 가장 오래갔습니다

마지막으로 가장 현실적인 이야기를 하겠습니다. AI R&D 코드 리뷰를 도입한다고 해서 별도 솔루션이나 큰 예산이 꼭 필요한 것은 아니었습니다. 저희가 3주 동안 실제로 쓴 것은 Git 기반 저장소, 공유 문서, 실험 로그 폴더 정도였습니다. 비용보다 더 중요한 것은 시간을 얼마나 작게 쪼개느냐였습니다.

처음에는 리뷰 하나에 40분 이상 걸렸습니다. 하지만 문항을 줄이고 대상 코드를 좁힌 뒤에는 평균 15~20분 안에 끝났습니다. 연구자가 하루에 실험을 여러 개 돌리는 상황이라면, 모든 실험을 붙잡기보다 공유될 가능성이 있는 실험만 리뷰하는 방식이 현실적입니다.

• 초기 세팅 시간: 저장소 규칙과 문항 정리에 약 2~3시간
• 일일 운영 시간: 연구자 1명 기준 하루 15~20분
• 회의 절감 효과: 주간 회의에서 실험 설명 시간이 약 20~30분 줄어듦
• 추가 비용: 기존 협업 도구를 쓰면 별도 비용 0원에 가깝게 시작 가능

작게 시작하면 연구 속도를 크게 해치지 않았습니다

제가 느낀 적정선은 명확했습니다. 한 실험당 리뷰 코멘트는 3개 이하, 리뷰 대기 시간은 반나절 이하, 필수 문항은 5개 이하로 제한하는 것이 좋았습니다. 이 선을 넘으면 연구자들이 리뷰를 품질 관리가 아니라 행정 업무로 받아들였습니다.

숫자로 보면 꽤 현실적입니다. 3명이 참여하는 작은 AI R&D 팀이라면 첫 주 세팅에 3시간, 이후 주당 운영에 약 3~5시간 정도가 들었습니다. 대신 같은 실험을 다시 찾는 시간, 결과 파일을 묻는 메시지, 회의 중 조건을 되짚는 시간이 줄었습니다. 연구개발에서 하루를 아끼는 것보다 중요한 것은, 다음 실험을 더 정확한 위치에서 시작하는 것이라는 점을 3주 만에 체감했습니다.