연구 과제로 개발할 때

연구 과제로 개발을 하게 됐다. 일반 프로젝트와 다른 점은 목표가 숫자로 정해져 있다는 것이었다.

통신 성공률 N% 이상, 처리 지연 M ms 이하

이것이 계획서에 적혀 있고 그 수치를 달성했는지로 평가받는다.

Open Table of contents

측정 방법을 먼저 정했다

숫자가 목표면 어떻게 재는지가 먼저다. 같은 성공률도 ping 으로 재느냐 응용 계층에서 재느냐에 따라 달라진다.

몇 번 중 몇 번인가 (시행 기준)
몇 바이트 중 몇 바이트인가 (데이터 기준)
재시도를 포함하나 안 하나
어떤 조건에서 재나

이것을 안 정하면 나중에 논쟁이 된다. 결과가 나온 뒤에 정하면 유리한 쪽으로 정하려는 힘이 생긴다.

그래서 착수하면서 측정 방법을 Markdown 문서로 만들었다. 무엇을 어떻게 몇 번 재는지와 RTT 를 어느 지점 사이로 잴지까지 적었다.

측정이 매번 다르면 개선됐는지 알 수 없어서 조건을 고정한 시험 환경을 Bash 스크립트로 만들었다.

같은 거리, 같은 배치
같은 데이터 패턴
같은 시간 길이

그리고 crontab 에 걸어 자동으로 돌리게 했다. 사람이 매번 손으로 하면 조건이 흔들리므로 조건을 스크립트 인자로 박고 결과를 CSV 에 한 줄씩 쌓게 했다.

같은 조건에서 여러 번 돌려 awk 로 편차를 봤고 한 번의 결과는 못 믿는다. ping 만 봐도 손실률과 함께 왕복 시간의 최소와 평균과 최대와 표준편차를 같이 내놓는데 한 번의 숫자로는 성능을 말할 수 없다는 것이 기본 도구의 출력에 이미 들어 있다.

편차가 크면 그 자체가 개선해야 할 대상이었다.

최종 RTT 수치까지 가는 것이 한 번에 안 되니 중간 목표를 나눴다.

1단계: 동작만 (수치 무관)
2단계: 목표의 절반
3단계: 목표 달성
4단계: 여유를 두고 달성

4단계를 둔 이유가 있다. 시연이나 검증 때는 조건이 나쁠 수 있어서 딱 맞게 달성하면 그때 못 넘는다. 각 단계에서 CSV 의 어느 열을 보고 판정할지도 함께 정했다.

중간에 RTT 목표를 못 맞출 것 같은 부분이 보였다. 물리적 한계에 가까운 항목이라 노력으로 될 것이 아니었다.

일찍 알렸다. 계획서를 쓸 때의 가정과 실제가 다르다는 것을 말한 것이다.

늦게 알리면 남은 기간이 짧아 대안을 못 만든다. 일찍 알리니 조건을 조정하거나 다른 방법을 검토할 시간이 있었고 나쁜 소식일수록 일찍이 여기서 명확했다.

과제는 결과물뿐 아니라 과정도 제출하므로 처음부터 Markdown 에 기록을 쌓았다.

무엇을 시도했고 결과가 어땠는지
왜 그 방법을 택했는지
안 된 방법과 그 이유

안 된 것을 적는 것이 특히 필요했다. A 를 시도했으나 B 때문에 안 됐고 C 로 바꿨다가 있어야 최종 방법의 근거가 서고 그때의 CSV 를 함께 남기면 더 분명해진다.

이것은 평소 개발에서도 했으면 좋았을 것이다. 대개는 성공한 방법만 남기니까.

일반 프로젝트에서는 언제 끝인가가 애매할 때가 많은데 여기는 수치가 기준이라 명확했다. 넘으면 끝이고 못 넘으면 계속이다.

그것이 편했다. 다만 그 수치가 실제로 유용한 것을 재는가는 별개 문제였고 성공률이 높아도 RTT 가 크면 못 쓴다. 그래서 여러 지표를 함께 봐야 했고 계획서에 그것이 다 들어가 있는지 초기에 확인했다.