1% 개발, 99% 유지보수 – 4. 인텔 드라이버발 위기

이 글이 다루는 시기: 2013년 5월

= 첫 버전 공개로부터 9개월차


이후로 나래온 툴은 그런대로 잘 나갔다.

다운로드 수도 끝 간데 없이 오르고 있었다.

네이버 개발자 센터 메인이 바뀔때까지 거의 항상 1위였고

그러나 나래온 툴의 앞날에 대형 사건이 몰려오고 있었으니…

나래온 툴의 전성기가 언제였나? 하면 딱 고를 수는 없지만,
나래온 툴의 위기가 언제였나? 하면 딱 고를 수 있는 때가 하나 있다.

총체적 난국. 극복하지 못했다면 나래온 툴은 거기서 끝났을 것이다.
나래온 툴에서 수동 트림을 돌리면 데이터가 파괴되었던 것이다.

처음 시작은 카페에서 올라온 몇 개의 증언이었다. 어느 것이 문제인지 확인하지 못하고 있던 찰나, SSDSAMO ‘머쨍’님의 증언으로 문제가 되는 드라이버 목록을 확보할 수 있었다. 당시 사안이 사안이었으므로 사과문을 돌린 후 긴급 작업에 들어갔다. 밥을 먹으면서도, 강의를 들으면서도 문제를 해결할 생각만 가득했다.

리스트를 받은 뒤 가장 먼저 시도해본 일은 엔디언을 바꿔보는 일이었다. 수동 트림을 만들 때 가장 고생했던 게 엔디언 문제였으므로, 내가 실수했을 가능성을 먼저 확인해보았다. 그러나 효과는 없었다. 내가 설정한 버퍼와 관련 없이 완전히 무작위로 트림이 들어가 전체 공간에 샷건을 대고 쏜 것 마냥 트림이 되었다. 개발 시작 후 처음으로 큰 실의에 빠졌다. 도대체 무엇이 문제란 말인가.

그러다 한 가지 생각이 번개처럼 스쳤다. 버퍼가 꼬인 게 아닐까? 확인은 같은 방식으로 버퍼를 사용하며 명령어 구성이 더 간단한 WRITE 명령어로 하였다. 확인해보니 디바이스로 전송되는 버퍼에 원래 내용과 완전히 다른 내용이 들어있었다. 드라이버 문제였다.

일어난 문제에 비해 일어난 문제의 이유는 별 게 아니었다. 인텔 드라이버 일정 버전이 어떤 IOCTL코드로 전송을 하면 버퍼가 꼬이는 것. 결국 다른 IOCTL 코드를 사용하는 것으로 이 사건은 막을 내렸다.

지나고 나서 생각해보면 이 사건에 배운 점은 사건을 대처하는 방법이었다. 여러 커뮤니티에 사과문과 사용 자제 공지를 돌린 뒤 진땀을 빼면서 뜬 눈으로 밤을 새웠던 이 사건은 지식보다 경험으로 뼛속 깊이 남아있다. 이 때는 처음이라 더 빠르게 대처하지 못한 게 한인데, 앞으로는 더욱 기민하게 대처하리라 다짐했다. 다행히 크게 늦지는 않았는지 사용자 풀의 큰 유출은 없었다.

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.