근 3개월 넘게 진행된 과제가 1차 일단락 되려고 한다.

당연히 끝이 아니라 이제 반환점이지만, 그래도 시스템 시험이 오늘 종료될 예정이니 홀가분하다.

시스템 시험 진행이 매끄럽지 못해서 많이 아쉽고, 최종 성적도 기대만큼 높지 않고, 몇 몇 문제는 원인을 못 찾고 디버깅 패치로 대응하는 것이 못내 아쉽다.

그래도 그래도 그간 고생한 거 생각하면 휴…

이젠 좀 더 재밌는 일에 신경을 좀 더 써야지.

시간이 갈 수록 S/W의 중요성에 대해 말하는 사람이 많아지고, 그 만큼 관심이 많아지는 듯하지만 그렇다고 효과적인 대안을 제시하는 경우는 별로 없다.

S/W의 품질을 높이기 위해 그들이 취하는 방식은 언제나 “뭔가”를 더 시키고, 더 요구하는 것이다.
단계마다 숫자를 확인하고, 그들이 생각하는 기준을 맞출 수 있는 지만을 확인한다.

그렇다고 기본적인 품질을 보장할 수 있도록 반드시 필요한 “시간”을 충분히 주지는 않는다.

이번에 하고 있는 과제 역시 “잘못된 계획”덕에 H/W에게는 필요한 충분한 시간이 주어졌지만 S/W에게는 전혀 그렇지 않다.
신규 보드를 받은 지 15일만에 BT(Block Test)를 하라는 게 말이나 되는 소리냐는 말이다.

누가 계획을 세웠는 지는 모르겠다. H/W는 신규보드니까 크게 바뀐다고 생각하는데 S/W는 그냥 예전대로만 하면 된다고 생각하니. 그 “예전대로”, “현재 수준으로만”이라는 조건을 만족시키는 것이 H/W의 의존성을 많이 갖을 수 밖에 없는 임베디드 시스템에서는 그리 녹녹한 일이 아니라는 걸 왜 모르는 건지. (물론 그런 하드웨어 의존성을 잘 구분해 놓은 구조여야 한다는 것은 인정. 제길. 다행히 많은 코드들이 그렇게 구현되어 있지만, 그런 코드가 어디에 있는 지 뭘 고려해야 하는 지를 모른다는 것이 문제다. 어이가 없지만 그게 사실이고)

회의에서 제일 자존심 상하고, 듣기 싫은 소리가 “H/W는 별 탈없이 잘 끝났네”, “S/W가 준비가 안되서”라는 소리다. 자기들이 S/W를 뭘 안다고.

S/W 개발의 가장 큰 문제는 바로 시간이라고 한다. H/W는 비교적 정확한 예측이 가능하지만 S/W는 전혀 그렇지 않다는. 그래서 필요하다고 생각하는 시간을 제시해도 수긍하지 않는다. 그리고 그 예측 역시 너무나 쉽게 한다. 도전적인 것이 아니라 엉터리로 계획을 한다는 것이 바로 문제다.

확실히 깨달았다.

프로젝트 실패의 원인 중 50%는 소통의 문제라는 것을 그리고 30%는 멍청한 일정. 그리고 나머지.

실은 멍청한 일정이 소통 문제를 일으킬 수도 있겠지만, 소통의 문제가 가장 커 보인다. 그리고 소통의 문제는 개발자들의 기본 자세가 문제가 크다고 생각한다.

내가 아는 것을 남도 알고 있겠거니 하는 생각.

바벨탑을 만들고 있다는 심정이다.

기다림의 연속이다.

시험을 하러 가서 문제 발생하면 담당자가 수정하길 하염없이 옆에서 기다려줘야 하는.

어제는 저녁에 연동 시험하러 갔다가 문제가 발생해서 담당자 수정하는 동안 옆에서 깜빡 졸았다. 전날 새벽 2시에 자고, 오후에 자리 이동까지 해서 힘들어서 그랬나 보다.

그래도 진척이 조금 있어서 다행이긴 한데 비협조적인 다른 팀과 함께 일하는 거나 절대적인 일정이 문제다.

쩝.