개발 프로젝트 추진에 관한 단상 #2

테스트에 관한 질문

1. 그 테스트가 필요해?
2. 그 테스트가 최적의 방법이야?

일정에는 기준선이기도 하다

일정이라는 단어에는 기준선이라는 개념이 포함된다.

약속한 메인 일정, 베이스라인.

하지만 기준선을 잡아놔도 상황이 바뀌니까 일정에 변화가 일어난다. 그래서 프로젝트를 진행하면서 그걸 계속 조정해줘야 한다. 왜 일정을 점검하고 조정을 해야할까? 목적은 크게 두가지이다.

1. 주어진 시간 내에 프로젝트를 끝낼 수 있을지를 점검하는 문제
2. 할 수 없을 것 같으면 불필요한 일들을 줄여야하는 문제
   1. 근데 이것은 쉽지 않다.

현행화 = update

기준선을 조정해서 현실에 맞게 실행할 수 있도록 바꾸는 작업을 현행화라고 한다. 프로젝트가 끝나는 일정은 바뀌지 않지만, 작업 단위간의 일정을 조정해서 무조건 기간 내에 완수하도록 개선한다.

단순작업은 단순하게 해버리고 반복하는게 맞다

단순작업은 단순하게 하고 백번 반복하면 된다. 일정을 세우는 것과 일정으로 토론하는 것은 단순작업이다. 시간을 많이 쓰면 안된다.

어짜피 계속 현행화 해나가야 한다.

데이터 정제 작업이 필요한 프로젝트의 경우

데이터 정제를 어떤 식으로 수행할 것인가. 팀원이 직접 하나하나 해도 되지만, 단순 아르바이트를 맡겨도 된다.

만약 데이터 정제하는 작업을 옆집 아줌마를 시킨다면, 잘됐는지 안됐는지 확인은 어떻게 할까? 데이터의 품질을 우리가 어떻게 확인할 수 있을까? 돈을 들였으니 확인은 해야한다. 팀원이 했더라도 확인은 해야한다.

일일히 하나씩 다 봐야할까? 믿고가?

답은 없지만 실행에 옮기기 전에 고민해볼 필요가 있다. 샘플링해서 본다던지 방법은 여러가지가 있을 수 있다.

그리고 데이터 정제와 검수는 비슷한 인력을 투입해야한다. 작업할때 처음부터 한명은 만들고 한명은 검수하는 식으로 구성을 해야한다. 예를 들어 1000명이 라벨링 작업을 한다면, 1000명이 검토하게 한다.

작업 로그를 쌓는다는 것의 중요함

보통은 회사에서 모여서 일을 한다. 하지만 점점 세상은 각자 일하는 것으로 바뀌고 있다. 이러한 환경에서 작업 로그를 쌓는 것이 더욱 중요하다.

그래서 Monday와 같은 툴로, 각 작업에 대한 로그를 남긴다. 또한 아침 저녁 짧은 10분 가량의 회의를 통해서 작업 현황을 공유한다. 오늘 뭐할지, 오늘 뭐했는지.

이렇게 서로의 생각을 적어놓으면 팀원 간에 바로바로 피드백을 할 수 있다. 발생할 수 있는 이슈에 대해서 미리 조언해줄 수 있고, 서로 이해하고 있는 바가 상충하지 않는지 확인한다.

물론 개발자들은 깃허브같은 것을 이용해서 소스 코드로 소통할 수 있다. 하지만 이것보다 개발 전에 이슈를 논의하는 것이 빠르다.