이번엔 조금 재미있는 이야기를 하려고합니다.
이전 편은 길게 썼더니 보기가 힘드네요.
 
말 그대로 과연 북한은 핵무기를 몇개 가지고 있는가? 인데
공학자의 관점에서 이야기해보겠습니다.

 

 
예전 게시글에서 이야기한 "논거를 가지고 이야기" 하는 것이 어떤 것인지 예를 들어보겠습니다.
 
아래 기사를 보면 분명 북한은 미국에 핵무기를 날릴 수 있는 기술이 있을 것 같습니다.
다만 재진입 기술이 없어서 제대로 도달할 가능성이 낮다고 생각되는데 일단
50%라고 가정합시다.
 
김정은씨는 부하한테 미국에게 99% 확율로 한방먹일 가능성이 얼마인지 그럼 몇 방을
미국한테 날려야하는지 물어봅니다.
 
"날래 보고 하라우"
 
과학자는 계산해보니 50% 확율로 미국에 핵무기를 떨어뜨릴 수 있다고 보고합니다.
그래서 중간 관리자가 반반이니 핵무기 2대만 있으면 된다고 보고합니다.
 
"떨어뜨릴 확율이 반반이니 예산도 절약하고 단 2대만 만들면 100% 미제를 조질 수 있습니다"
 
스위스 유학파 김정은씨가 이야기합니다.
 
"아오지 가라우"
 
이번에 과학자가 직접 보고합니다.
 
계산을 해보니 우리 탄도는 50% 확율로 미국에 떨어뜨릴 수 있습니다.
위원장님의 99% 확율로 미제놈을 조지려면 제 계산 결과는 아래와 같습니다.
 
위원장님의 요청대로 반대로 핵무기가 안 떨어질 확율은 1%이하여야 합니다.
즉 1/100 이하로 만들려면, 핵무기 한방당 1/2 확율로 안떨어짐이 연속적으로 발생하여야 하는데,
첫번째 사건과 두번째 사건은 독립적인 상황 즉, 독립상황 (independent event) 이므로
이렇게 계산할 수 있습니다.
 
(1/2) * (1/2) * (1/2) * .... * (1/2) 가 1/100 보다 작아지는 최대 개수로 생각하면 됩니다.
 
그래서 1/(2^N) < 1/100 을 만족하는 최소 N 을 구합니다.
2의 6승은 64 이므로 , 7이 답이겠군요.
 
"장군님, 우리 기술로 미제를 99% 조지려면 핵무기 7대를 만들어야 합니다.
 정확한 확율은 7대 만들시 99.9922% 정도 됩니다.  예산 편성 바랍니다"
 
스위스 유학파 김정은씨가 대답합니다.
"날래 진행하라우!"
 
따라서 , 현재 북한은 최소 7기 이상의 핵무기를 가지고 있다 라는게
저의 상상속의 생각입니다.
 
만약, 북한이 핵무기 보고서에 3개나 4개로 보고하면 미국은 코웃음을 칠겁니다.
거짓말 하고 있다고.
 
엔지니어는 이렇게 이야기해야합니다.
"감"을 가지고 이야기하지 말아야 합니다.
데이터로 말해야 합니다.
 
"2대만 만들면 되겠는데요" 라고 문돌이 처럼 말해서 아오지 가지 맙시다.
 
 
 
 
 
 

 

프로그램은 오래 짜왔지만 경력에 비하여 코딩 실력은 그리 뛰어나지 않다고 생각됩니다.
다만 제가 잘하는 걸 생각해보면 
나름 버그 없는 프로그램 (제가 개발한 제품들은 보통 24시간 꺼지지 않거나 하루 12시간 이상
계속적으로 사용되는 금융 데이터 처리하는 제품) 을 만들고, 
문제 발생시 디버깅 대처 능력이 매우 빠르다는 것입니다.
 
펌웨어 변경시마다 수십억 이상의 배상건이 발생할 가능성이 있는 시스템을 다루면서
극도의 긴장감과 공포속에서 나날을 보냈던 기억이 납니다. 
펌웨어 오류로 옆동네에서 회사 파산하고 개발자 도망가고 그런 모습들을 보면서 나한테도 그런일이 생길까
노심초사하던 시절이 있었습니다. 이 일도 익숙해지면 그냥 그렇더라구요. 
 
그런 와중에 살기위한 대책으로 자연스레 학습이 되었는데
버그 없는 코딩 이전에 버그 찾는 방법을 알려드립니다. 대부분 이걸 필요로 하실 겁니다.
 
펌웨어의 경우 문제가 발생하면 보통 2가지중 하나입니다.
   하드웨어냐 펌웨어냐!
   1) 펌웨어 엔지니어는 하드웨어를 의심하고 하드웨어 엔지니어는 펌웨어를 의심합니다.
   2) 답은 자신을 의심하세요. 남을 의심하는 것은 나에 대한 완벽한 논거가 확립된 뒤에야 
      의심하시면 됩니다.
 
제가 디버깅 하는 순서로 주로 현장 시스템인 경우입니다.
너무 원론적인 거라 잘 적용이 안될 수는 있지만 해결 방법은 대동소이합니다.
 
사례를 들면 좋은데 너무 전문적으로 가게 되어서 일반적인 방법론으로 풀어봅니다.
 
1. 전체를 파악한다.
   보고자가 말하는 의중을 제외하고 사실 데이터만 수집한다.
   직접 현상을 확인해본다. 책상머리에서 상상으로는 해결이 불가하다.
   참고로 보통 보고자들은 이상 발생에 대하여 과장보고하는 경우가 일반적입니다.
2. 그 중에서 확실한 것은 제외한다. 확실하다는 것은 이론과 실증을 통하여 자기 확인이 아닌
   정확한 데이터에 기반한 확실한 것을 말합니다.
   정확하게 이론과 실증입니다. 10년동안 잘 돌던 코드는 약간의 실증만 있는 코드 입니다. 
   이론으로 바탕되지 않은 코드죠. 해당 코드 부분을 잘라서 거의 모든 경우의 데이터 입력을 통한 
   시뮬레이션 후 일치를 확인하고 믿어야 합니다.
3. 2번을 생각하면 거의 모든게 의심스러워 집니다. 왜냐하면 데이터시트도 제대로 안보고 만든게 많기 때문이죠.
   이제서야 보기 시작합니다.
4. 발생 빈도를 확인한다.
   단 한번 발생하고 안했느냐. 지금도 계속 발생하느냐. 특정 조건에만 발생하느냐(이 경우는 해피한 경우입니다)
5. 약간은 좁혀진 범위에서 의심가는 부분을 과도하게 반복시켜서 재현이 되는지 확인한다.
   여기서 과도한 반복이 어려운 경우가 제일 문제가 되긴 합니다만 세상에 방법이 없는 건 없습니다.
   3개월에 한번 발생한다면 배포한 단말기들의 프로그램을 변경(의심부분 로그만 확인)하고 
    재현될때까지 정말 3개월동안 기다린 적도 있습니다. 총 수정까지 1년이 걸렸구요.
6. 과도한 반복을 통한 재현이 되면 거의 그 부분이 확실한 겁니다.
   그럼 재현이 잘 되니 점차 함수의 범위를 좁힐 수 있습니다.
   계속 큰데서 작은데로 범위를 좁혀갑니다.
   일반적으로 여기서 실수하는데 처음부터 의심가는 부분 작은데서만 집중하면 해결이 안됩니다.
   의외로 내가 확신했던 부분에서 오류가 발생합니다.
7. 확실한 코드 부분을 찾으면 동일한 상황을 만들어서 정확히 재현시켜 봅니다.
   그러면 100% 확인이 된 겁니다.
8. 이상하게도 재현이 안된다 라는 상황이 있습니다. 그러면 5번 참조. 재현이 됩니다.
   몇달만에  한번 생기더라도 그물을 쳐놓고 몇달 기다리면 됩니다.   
   이 문제로 회사가 망하는 게 아니라면 내부적으로 그 부분을 과도하게 동작하도록 처리하고
    최대한 많은 단말기에 다운로드해서 상황을 지켜봅니다. 발생이 더 잘되면 기뻐하면 됩니다.
9. 그럼에도 나는 완벽하다면 슬슬 하드웨어를 의심해야 됩니다.
   모든 데이터를 수집하세요. 날짜별 발생 빈도, 단말기 위치, 그날의 온도 습도 까지도 등등 
   빅데이터 처럼 모을 수 있으면 찾기가 더 쉽습니다.
10. 통신문제 처럼 되었다 안되었다 하면 통신관련 소자의 클럭이나 크리스탈에 달린 커패시터 값을 확인하세요.
11. 펌웨어가 운영 중 소자 다운시 리셋을 걸어주고 초기화 과정을 다시 잘 실행하는 지 확인하세요.
12. 해당 하드웨어가 노이즈 테스트 및 정전기 테스트는 하였는지 확인하고 안했다면 테스트 해보세요.
    라이터 부싯돌로도 단말기가 죽는 수도 있습니다.
13. 보드의 여러 소자들의 최대 주파수 범위내로 동작시키고 있는지, 데이터 시트를 몽땅 다시 다 확인해보세요.
14. 역시 보드의 여러 소자들의 리셋 타이밍도 맞게 동작시키고 있는데 확인해보세요.
15. 그래도 못찾으면 펌웨어가 와치독을 제대로 사용하고 있는지 확인하세요. 
    최악의 경우 재부팅은 되어야 겠지요. 그렇게 해서 가끔씩 재부팅하는 체로 동작하게 하세요. 
   시간도 벌고 일단 살고 봐야 되니깐. 
   그 다음에 퇴사하세요. (농담입니다 ㅎㅎ)
 
    
다음번에는 죽은 하드웨어도 인공호흡으로 살리는 
"PCB 노이즈 대책 코딩 기법"에 대하여 한번 올려드리겠습니다.
이런게 이론으로 있는지는 모르겠지만 저는 효과가 있다고 봅니다.
 
하드웨어 엔지니어가 엉망이라도 우리 펌웨어 엔지니어는 살려 낼 수 있습니다.
너무 하드웨어만 탓하지 마세요. 담에는 하드웨어 엔지니어가 펌웨어 엔지니어를 살려 줄껍니다.

 

저희 회사 신입사원 책상에 붙여놓은 겁니다.
10년동안 절대 떼지 말라고 했습니다. 노력하면 7년 뒤에 이룰 수도 있지만 어려울거라 이야기했습니다.
 
그때 잠시 끄적여서 준거라 지금보니 많이 부족하네요. 반도 못적은 거 같은데
더 쓰면 미리 좌절할거 같아요.
 
내가 어디쯤에 있는지 궁금할 때 쯤 쳐다보라고 했죠.
요즘은 네비가 남은 시간을 알려주는데 개발자라는 먼길을 가는데 대략이라도 알아야 되지 않겠습니까?
 
포기할 사람은 빨리 포기하고 
멀리 갈 사람은 꾸준히 한번쯤 하늘을 쳐다보며 앞으로 나아가야죠.
 
아무것도 모르는 신입은 절대적인 건 아니지만 도움이 되실겁니다. 
이제 시작하시는 분들은 참고하세요. 
 
안녕하세요.
 
개발자 중에 학원 출신으로 그리고 전문대 출신으로 고민하는 친구들도 제법 있습니다.
제 직원중 한명이 전문대 출신이기도 해서 한번 공부의 중요성에 대해서 넓게 설명한 적이 있었는데
그 이야기는 너무 길고 간단하게 이야기 해보겠습니다.

 

 
결론은 개발하는데 이런게 직접적으로는 아무 관련이 없습니다.
다만 원리를 아는 사람이 좀 오래갈수가 있습니다.
 
 예를 들면
 트랙훈련장에서 운전을 전문으로 배운 사람과 자동차 엔진 만들다가 혼자 운전 배운 사람이 있을때
 트랙을 돌면 당연히 트랙에서 전문적으로 배운 사람이 이기겠지만,
 사하라 횡단을 하는 레이스에 참가하면 운전 겨우하는 사람이지만 고장난 차를 빨리 수리해서
  운전만 배운 사람을 이길 수도 있습니다.
 
  주어진 상황에 따라 다르니 어느 쪽이 좋다고는 할 수 없습니다.
  다만 오래 가려면 엔진을 만져본 사람이 조금 낫다라는 정도입니다.
 
  하지만 현실은 사하라 사막이 많은 편입니다.
 
새싹시리즈 말고 노땅 시리즈 입니다.
나름 오래된 사람들(이렇게 말하는 저도 슬픕니다만)만 참고요~~

 

 
1. 시간이 갈수록 내가 쥐고 있던 라이브러리는 의미가 없어지고 오픈 소스가 더 믿음직스럽다.
2. 마이컴에도 C++ 시대가 왔다. C++ 모르는자 점차 먹고 살기 어려워 진다.
   문법이 아닌 개념이해 필수! 폴리모옵티즘,유서빌러티,인헤리턴스.
3. 코드 제네레이션에 대한 반감은 집어치우고 신봉하자.
   나도 그런식으로 짤 수 있지만 내가 짠거는 허접하고 칩제조사에 만든거는 위대하다.
   공부는 집에서 결과는 회사에서.
4. CPU 하나 선택하면 평생 먹고 살았는데 지금은 CPU 가리면 노땅된다.
   오늘은 ST , 내일은 느네사스, 모레는 PIC, 글피는 NXP .  다 거기서 거기다.
   양산시 모든점 고려해서 10원이라도 싸면 CPU 바꾸자. 요새는 별거 아니다.
5. 슈퍼개발자 소용없다. 아무리 답답해도 후배 키우자. 결국 나한테 도움이 된다.
   너무 잘 가르쳐주어도, 너무 안 가르쳐 주어도 문제지만, 둘중 하나라면 너무 잘 가르치는 걸 선택하자.
6. 크로스 플랫폼은 당연하다. 맥도 가오가 아니라 필요하면 쓴다.
7. 최신 개발방법론도 도입해보자 (기존에 우리들이 하던거에 멋드러진 이론만 입혔을 뿐 거기서 거기다)
8. 자바, 파이썬도 하면 된다. 영어 잘하면 다른 언어 배우기 쉽듯 거기서 거기다.
9. 모든 기술은 나를 편하게 하기 위한 도구일 뿐 내 영역을 침범하는 적이 아니다.
   마치 인공지능 시대를 거부하는 일자리는 잃어버리지 않도록 몸부림치는 사람이 아니길.
10. IT를 모르는 평범하고 다양한 사람들 많이 더 만나 볼 것.
 

 

지금 안적으면 다시 까먹을 것 같기도 해서 한번 적어봅니다.

순전히 개인적인 의견이므로 이런 견해도 있구나 생각하시길..(너무 진지하게 받아들이지는 마세요.)

 

참고로 저는 전자공학 전공에 20년차 펌웨어 개발하고 있습니다.
 
원래 질문자는 컴공 4학년이었습니다. 그 기준에서 한번 적어봅니다.

 

 
1. C 공부 열심히.
2. 리버스 엔지니어링도 좋고 asm 공부도 좋고 컴공이면 크랙파일 한번 만들어봄도 좋음.
3. 컴퓨터 구조론 및 OS 과목 수강 (저는 전자공학과였는데 학부제로 바뀌면서
    4학년때 졸업못할 각오하고 컴공 전공 C++ 수업 이수)
4. 전자공학 과목 중 기초 회로 소자 쪽 청강 혹은 독학
5. MOOC 사이트 가서 임베디드 관련 과목 수강 (요즘 관심있는 중학생도 이정도는 합니다)
6. 아두이노 제외 임베디드 저속 보드 하나 리눅스 기반 보드 하나 사서 유튜브 보고 따라하기
7. CPU 하나는 선정해서 (STM 추천) 해당 보드로 각 주변기기기능 하나씩 구현
   (오늘은 ADC, 내일은 UART 이런식으로)
8. 독신으로 살거나 마음이 매우 넓은 여성과 결혼 (한다면 되도록 빨리)
   이유는 설명하기가 길어서 생략.
9. 어정쩡한 대기업 취업보다 기술있는 중소기업 찾기. (대기업 잘못가면 사람 압박하는 기술을 배웁니다)
10. 운동 열심히 (한국에서는 체력이 약하면 프로그램하다 죽을 수도 있음)
11. 영어공부 열심히. 그래서 한국 탈출. 죽지 않으려면! (약간 과장이니 이해 바람)
12. Github 는 나의 친구
13. Git 는 내 애인

14. 디버깅시 아니 땐 굴뚝에 연기나랴. 모든 일에는 이유가 있다라는 확신.

15. 프로그램하다가 오늘 요일을 잘못안적이 있다면 자질이 조금 있는 겁니다. 무서운 집중력 필요.
   (혹 산만한 성격이면 다른 일을 추천드립니다.) 
16. 소설 많이 읽기. 인간에 대한 인문적인 이해력 함양. 고급 엔지니어로 가기 위한 필수 덕목입니다.
    프로그램을 사용하는 것은 사람이니깐요.
 

 

밤이라서 급하게 적어서 생각나는 건 대략 이정도입니다.

참고가 되었으면 합니다.

+ Recent posts