'펌웨어'에 해당되는 글 2건

  1. 2010/02/09 응용프로그램은 혼자 돌아가지 않는다.
  2. 2009/11/09 [프로그래밍 일반]성급한 일반화의 오류

응용프로그램은 혼자 돌아가지 않는다.


개발을 하다보면 이런저런 일이 많이 생기겠지만, 제가 겪은 일 중에 가장 황당한 일은 하드웨어와 연동된 응용프로그램을 개발하면서 겪은일이었습니다. 

하드웨어로부터 데이터를 받아서 윈도우 프로그램에서 실시간으로 보여줘야하는 프로그램. 

펌웨어 단에서는 실제 많은 필터와 함께 로직이 들어가 있지만, 수 많은 데이터를 처리하기에는 아무래도 PC보다는 당연히 처리속도에 대한 성능이 느린것이 사실입니다. 그렇다면, 과부하가 걸리는 모든 로직이나 필터알고리즘을 PC의 윈도우 프로그램으로 올리는 것이 해답일까요?

느린것은 사실이다. 그러나, Conversion 이 해답은 아니다. 
 
DIY USB Remote Shutter Trigger v2
DIY USB Remote Shutter Trigger v2 by Roger Smith 저작자 표시비영리변경 금지

분명 펌웨어 라는것은 성능상의 한계를 가지고 있습니다. 때문에 데이터를 처리하는 과정에서 과부하가 심하게 걸리는 로직이나 그러한 부분은 PC에서 처리하는게 맞겠지요. 하지만, PC와 작은 하드웨어를 비교할때 단순히, CPU와 Ram의 숫자놀이로만 비교해서는 안됩니다. 그러한 비교를 통해서 펌웨어의 로직을 너무 많이 응용프로그램 단으로 가져오게 되면 반드시 문제가 생기게 됩니다. 특히, 실시간이 생명이 응용프로그램은 말이죠. 


우린 사용자의 환경을 모른다. 
 
Working
Working by totalAldo 저작자 표시

가장 큰 문제는 바로 사용자의 PC 환경입니다. 단순히, PC의 하드웨어 스펙이 아니라, 실제 사용자가 윈도우 상에 우리회사의 소프트웨어 말고 다른 어떤 응용프로그램을 실행 시켜놨냐가 관건이라는 것입니다. 메신저도 돌아가고, 윈도우 파일 검색도 돌아가고, 조각모음도 하면서, 자사의 실시간 소프트웨어를 실행시켜서 좋은 Performance를 기대하기란 쉽지 않습니다. 특히, 실시간으로 사용자에게 무엇인가 보여주어야 하는 프로그램이라면 더더욱 그렇습니다. 


사용자 중심의 소프트웨어 최적화가 필요하다. 
 
Kitchen Cupboard Make-Over: After
Kitchen Cupboard Make-Over: After by Pieter Pieterse 저작자 표시비영리


            사용자 중심의 소프트웨어 최적화가 필요하다는 생각이 듭니다. 
 

사용자가 우리가 만든 프
로그램에서 기
대하는 것이 무엇인지 먼저 고민을 해 봐야 합니다. 실시간 그래프를 보여주는 것이 목적인 심전도 디스플레이 프로그램이라면, 정확한 실시간성이 보장되어야 겠지요. 그렇다면, 사용자가 어떤 환경에 있더라도 실시간 성이 보장될 수 있도록 최적화 해야 한다고 생각합니다. 

사용자의 PC는 개발자의 PC와 다릅니다. 때문에 많은 응용프로그램을 켜두고 테스트 하면서, 사용자가 우리 프로그램에 대해서 어떻게 느낄지를 곰곰히 생각해 나가면서, 응용 프로그램의 최적화를 시작해야 한다고 생각합니다


저작자 표시 비영리 변경 금지
Technique/etc 2010/02/09 12:16
Trackback 0 : 댓글을 오로지 페이스북으로만.

[프로그래밍 일반]성급한 일반화의 오류



Day 308: X
Day 308: X by theogeo 저작자 표시


성급한 일반화의 오류란, 몇가지의 부분을 보고 전체를 일반화 시켜서 판단하는 오류를 말한다.
예를 들면, 
 
  A라는 한국인이 개고기를 먹는다.
  B라는 한국인이 개고기를 먹는다.
  그러므로, 모든 한국인은 개고기를 먹는다.

이러한 성급한 일반화의 오류를 필자도 저번주에 펌웨어 보정 필터를 개발 하면서 겪었기에 이렇게 글을 쓰게 되었다. 특정 수치를 넘는 데이터에 대해서만 평균값을 취해서 버퍼의 한 포인트를 삽입하는 형식으로 보정 필터를 개발하는데, 특정 수치를 설정하는 과정에서 필자가 성급한 일반화의 오류를 범했다.



센서에서 가까운 A라는 점에서 획득한 데이터와 센서에서 가장 먼 B라는 점에서 획득한 데이터만을 분석해서 특정 수치를 기준점을 잡는 작업을 했는데 가운데 있는 점이라던지, 사각지대에 있는 포인트의 경우 데이터가 다르게 나온다는 것을 인지 하지 못하는 문제가 발생하였다.

실제로 굉장히 많은 포인트를 검사하고 분석해서 필터의 조건과 기준 점을 정해야 함에도 불구하고 귀찮은 관계로 몇몇의 점을 가지고 설정한 결과 보정 필터의 부작용이 나타나는 부분도 있었고, 조건과 기준점을 피해가는 점도 있었다.

프로그래밍을 하면서 굉장히 많이 이런 오류가 발생하는 것을 보았다. 본래, 시간과 비용이 정해진 회사에서의 프로그래밍의 경우 사실 정답이 아님에도 불구하고 결과만을 위해서 편법을 쓰거나 과학적이지, 논리적이지 못한 방법이 동원되는것 같다. 결과적으로 결과가 좋으면 다행일지도 모르지만, 제품화되어서 사용자가 사용하는 순간이 우리에게는 진정한 결과가 보여지는 순간이라고 생각되어 진다.

어쩌면, 나는 A와 B 포인트를 분석하면서 직감적으로 성급한 일반화의 오류가 발생될 여지를 알고 있었을 지도 모르겠다. 그러면서도 빨리 끝내고 싶은 마음에 그런 오류를 발생하지 않을것이라고 기대하고 넘어갔는지도 모르겠다.






 
저작자 표시 비영리 변경 금지
Technique/etc 2009/11/09 13:17
Trackback 0 : 댓글을 오로지 페이스북으로만.