파일을 만드는 일 다음의 작업
데이터 처리 과제에서는 Arrow 전환과 데이터 생성뿐 아니라, 연구자가 결과를 이어서 쓸 수 있게 정리하는 일이 남아 있었다. 데이터가 만들어졌다는 것과 다른 사람이 같은 조건에서 쓸 수 있다는 것은 다른 이야기였다.
기존 Arrow 기록이 원본 보존과 생성 경로를 다뤘다면, 이 글은 실행 규약과 완료 범위, 인수인계를 다룬다.
정리한 범위
과제에서는 데이터 생성·검증과 학습·API·Simulink 연계를 다뤘고, 실행 규약과 연구자 검수·인수인계 자료를 정리했다. 실무자의 요청과 기존 코드를 살펴본 뒤, AI 코딩 에이전트로 구현하고 구현 검토와 실행 결과 확인은 직접 했다.
1차 과제에서 끝낸 부분과 후속 고도화 제안도 나눠 적었다. 발표나 문서에 다음 방향을 적었다는 이유로 그 기술이 구현됐다고 설명하지 않는다.
상대의 컴퓨터에서 시작하는 순서
개인 프로젝트로 맡은 고객 과제였다. 회사 업무와는 별도로 진행했다. 연구자는 Windows를 사용했고 코딩에 익숙하지 않았다. 내 개발 환경의 명령을 그대로 복사하는 것으로는 시작하기 어려웠다.
PowerShell 기준으로 Arrow 생성, 사전 점검, 작은 CPU 학습 순서를 적었다. 기존 예제를 남겨두고 작은 데이터로 먼저 실행해 볼 절차를 마련했다. 실행·튜닝·검수 문서를 전달한 뒤 사용 방법을 전화로도 설명했다.
전체 데이터를 생성한 내 기록과 연구자가 작은 예제로 실행을 익히는 절차는 목적이 달랐다. 시작할 명령만 적지 않고 어떤 파일과 출력이 생겨야 정상인지 함께 남겼다.
인계 문서가 답해야 할 질문
| 질문 | 필요한 설명 |
|---|---|
| 무엇으로 실행하는가? | 입력, 환경, 실행 순서 |
| 무엇이 정상인가? | 결과 형식과 검증 기준 |
| 어디서 실패를 확인하는가? | 확인할 단계와 재현에 필요한 조건 |
| 어디까지 완료했는가? | 검증한 범위와 남은 제약 |
이 질문들이 문서 분량보다 중요하다. 자료가 많아도 실행 출발점과 정상 결과가 불분명하면 인계받는 사람이 처음부터 다시 해석해야 한다.
인계 뒤
인계 뒤 연구자에게서 직접 실행해 잘 쓰고 있다는 연락을 받았다. 실행 현장을 계속 관찰하거나 문서 배치별 효과를 비교한 것은 아니다. 이 연락을 특정 문서 구성의 효과로 단정하지는 않는다. 다만 자료 전달 다음에 실제 사용이 이어졌다는 피드백을 받은 것은 확인한 결과다.
다음 과제에 가져갈 기준
다음 과제에서는 시작할 때부터 완료 기준과 인계 방식을 함께 정하려 한다. 마지막에 문서를 붙이기보다, 상대가 어떤 결과를 어떻게 확인할지 먼저 맞춰 두는 편이 범위를 정하기 쉽다.