백지(白紙)라는 것이 있다.
책이나 보고서의 표지가 그림 없이 흰 종이로 되어 있기 때문이라고 들었습니다.
다시 찾아보니 반쯤 맞았네요.
여기서 제가 이야기하고 싶은 것은 문제가 발생했을 때 문제의 원인, 해결 과정, 해결 후 처리 과정 등을 완벽하게 기술한 ‘백서’를 작성해야 한다는 것입니다.
백서의 중요성, 막연한 것이 대충 느껴졌다.
2년 전 한빛미디어 박태웅 이사님으로부터 다스베이더의 GitHub 서버가 약 9시간 동안 다운된 후 2~3개월 동안 계속해서 사건의 원인과 처리 방법을 업데이트했다는 이야기를 들었습니다.
제가 모르기 때문일지도 모르지만, 한국에서 일어난 많은 사건들에 대해 처음에는 언론에서 사건에 대한 다양한 이론과 내용만 다루었고 결론을 내린 보도는 본 적이 없는 것 같습니다.
사건은 적절하게 준비되어 공개되었습니다.
(언론에서 소개하지 않아서일지도 모르지만…) 이런 사건에 대한 백서를 만드는 목적이 누구의 잘못인지 밝히기 위한 것은 아닌 것 같습니다.
적절한 백서를 통해 원인을 분석하거나 합리적인 추정을 정리하고, 사후 처리 및 해결 과정을 정리하고 공개한다면 유사한 사고를 예방하기 위한 가이드북이 만들어질 것입니다.
뭔가 큰 것에 대한 백서일 뿐만 아니라, 자신이 개발하고, 작업하고, 테스트한 것들을 잘 정리해야 한다는 점이 포인트입니다.
예전 같았으면 노트에 적어두었을 텐데, URL, 사진 등 적어둘 것이 많으니 블로그를 잘 활용해야겠다는 생각이 듭니다.
그래서 어제 nRF 개발 환경을 구성하려고 시도한 방법들을 모두 적어두고, 적어놓은 내용을 계속해서 추가하는 글을 썼습니다.
STM32라고 하면 STM32CubeIDE 같은 nRF52832/40의 대표적인 통합 개발 환경이 있는지도 모르고, 개발 도구/환경 등의 다양한 조합이 있고, 인터넷에서 찾아보는 자료들도 있습니다.
성공하신 부분만 요약해 보세요… 최신 버전에서는 화면 구성이 종종 다른데, 성공한 조합에는 +알파? 조금 다른 조합은 어떨까요? … 어제 아침부터 저녁 7시까지 두 번의 회의와 잡일 사이에 혼자서 nRF 개발 환경을 구성하느라 6~7시간을 고생했고, 블로그 포스팅을 작성하는데 1시간 이상이 걸렸지만 아직 끝나지 않았습니다.
. LED를 깜빡이는 작업, UART를 통해 데이터를 전송하는 작업, SD 메모리에 텍스트 파일을 저장하는 작업까지 했다면 아두이노용 부트로더를 업로드해서 끝냈을 텐데요. 다만, 아두이노 라이브러리에 없는 기능을 구현하려면 적절한 API/SDK를 사용해야 하고, 다른 사람이 한 것을 따라하고 싶다면 그 사람이 한 것과 같은 환경에서 따라해 보세요. 사용하고 Arduino로 전환하십시오. 실험을 통해서만 다른 환경에서 작동하는지 알 수 있습니다.
개발 환경의 다양한 조합을 살펴볼 수밖에 없습니다.
그래서 이 내용을 찾아보고, 그 과정에서 배운 내용을 정리하다가 내용을 더 추가하게 되었는데… 결과적으로 내용이 길어지기 시작했습니다… 지금 돌이켜보면 좋았을 것 같아요 작업하는 동안 최소한 스크린샷을 찍어두었습니다.
적어도 제가 헷갈렸던 부분은 다시 적어서 정리가 된 것 같아요. 웃긴 이야기인데 어제 파이썬으로 직렬통신을 검색하다가 3년쯤 전에 썼던 글을 봤습니다.
짧은 것들은 구글닥스로 정리하고 블로그에는 좀 더 정리된 글을 써보도록 할게요… 그러다가 좀 더 정리되면 군데군데 비어있더라도 좀 더 체계적으로 정리해보도록 할게요, 심지어 WikiDocs를 통해서도요. 이제는 돌아서려고 하면 종종 잊어버리곤 하는데… 어쩔 수가 없네요.. ㅎㅎ 그렇죠.
