코딩 테스트 그리고 임베디드 제어와의 관계

코딩 테스트 스터디를 하다보면 참 임베디드 제어 엔지니어들은 할말이 없어진다.

이유는 임베디드 제어 코드를 좀 치는 사람이라면 모두가 공감할 것이다.

코딩 테스트에 가장 많이 사용되는 for 문, search 알고리즘들을 과연 임베디드 코드에서 사용할 것인가 ?

대답은 절대 아니다.

 

for문을 사례로 한번 들어보자.

for 문이 반복문을 줄여주는 특효약으로 보여주지만, 시스템이 for문에서 조건문이 만족하지 못 할 경우 시스템이 다운 될 수 있다. 이는 실시간이 중요시 되는 임베디드 시스템에서는 거의 극악의 코드로 판단 된다. 사실 while 문, break 문 예외 처리를 위한 예약어들을 13년가 사용해 본적인 없다. 사용 즉시 동료 검토에서 엄청난 욕을 받게 되어있다.

 

그렇다면 for문을 대신할 수 있는 문법 대안은 어디에 있는가? 

임베디드에서 for문을 쓸일이 과연 있을까? 

왜냐하면 오프라인 코드가 아니라 한 실행 주기가 지나가고 나면 다시 실행이 되기 때문에 반복문의 의미가 약하기도 하다.

 

두번째 요소인 search 알고리즘은 임베디드 시스템에서는 사용하기 정말 어렵다. 왜냐면 평균을 구하면 코딩 테스트에서는 값을 모두 알고 있기 때문에 대부분 sum/n 형태로 구한다. 실제 임베디드에서는 이동 평균을 사용한다. 더욱이 임베디드 제어 엔지니어들은 라이브러리를 직접 작성한다. 차량에서는 특히 일반적인 라이브러리에 대한 안정성이 의심되기 때문에 사용이 금지된다. 대표적으로 라이브러리 사용 시 입력값 오류로 인한 오버 플로우 이슈가 발생 되기도 한다. 이것도 사실 조심히 사용하면 될 일이지만, 회사 정책인지.. 아니면 앞서 언급한 이유에서인지 주변에서 모두 동일한 관성으로 작업을 하고 있다. 그래서인지 물리량 해석시 sin, cosin만 나오면 다들 코드 치는 것보다 라이브러리를 얼마나 촘촘히 하고, 어떤 간격으로 가져 갈 것인지에 대한 고민에 시간이 더 많다. 참 생산성이 떨어지는 임베디드 코드이다. 

 

중략하고 결국 임베디드 제어 엔지니어에게 현재의 코딩 테스트는 적합하지 않고, 바른 평가 방법은 아니라는 생각이다.