＜ Embedded/General Operating System ＞ 
- Task, Memory, File-system structure analysis 
- Module, Device driver programming 
- Real-time system 
- Low-power consumption system 
- Virtual System

연구주제 : QoS 지원 운영체제 실시간 커널 기술 연구

연구 내용 요약

범용 응용 프로그램을 위한 CPU 스케줄링기법은 우선순위 기반으로 시스템 자원을 적절히 분배하는데 어려움이 있다. 멀티미디어 시스템과 같이 특정 태스크에 일정한 퍼포먼스를 유지할 필요가 있는 시스템은 QoS(Quality of Service)를 필요로 한다. 우선순위 기반 알고리즘은 이를 만족하기 어렵다. 때문에 시스템 자원을 태스크 요구사항에 맞게 적절히 분배하기 위한 스케줄링 알고리즘이 요구된다. 연구주제인 비례지분 스케줄링 기법은 QoS를 보장하기 위한 방법으로 CPU 자원을 태스크들의 상대적인 또는 절대적인 지분에 비례하여 할당하는 기법이다. 비례지분 스케줄링에서 가장 중요한 평가 지표는 공정성(fairness)이라는 개념이다. 이는 지분으로 예약한 자원량과 실제 할당 받은 자원량의 차이인 '공정성 서비스 오차'라는 척도로 계산 될 수 있다. 연구를 통해 '공정성 서비스 오차'를 기반으로 태스크 자원 할당량을 동적으로 변화하여 오차율을 점점 낮추는 스케줄링 기법을 개발 했다.

Q . 자발적으로 최고 수준의 목표를 세우고 끈질기게 성취한 경험에 대해 서술해 주십시오.

1) 먼저, 관련 대표 경험 2가지를 간략하게 작성해 주십시오. (각 50자 이내)
- 언제, 어디서, 어떤 일을 수행했던 경험인지 간략하게 기술할 것

① 2014년, 전자부품연구원, 팀내 프로젝트 관리 및 소프트웨어 형상관리를 위한 시스템 도입
② 2016년, 텔레칩스, 양산 제품의 불량 선별을 위한 System Level Test 구현

2) 위에 작성한 2가지 경험 중 1개를 골라 좀 더 상세하게 작성해 주십시오. (1,000자 10 단락 이내)
- 본인이 설정한 목표/ 목표의 수립 과정/ 처음에 생각했던 목표 달성 가능성/ 수행 과정에서 부딪힌 장애물 및 그 때의 감정(생각)/ 목표 달성을 위한 구체적 노력/ 실제 결과/ 경험의 진실성을 증명할 수 있는 근거가 잘 드러나도록 기술

＜단 0.01%의 불량도 용납할 수 없다, "불량 선별 시스템 개발"＞

    불량품 선별 작업은 최고의 고객 만족을 위한 첫걸음입니다. 저는 텔레칩스에서 고객께 양질의 제품을 납품하고, 불량은 사전에 감별할 수 있는 System Level Test 프로젝트에 소프트웨어
 개발자로 참여했습니다. 해당 프로젝트에서 디바이스(UART, I2C, SPI, eMMC, USB, GPU, VPU 등)들의 정상 동작 여부를 판별하는 작업을 추가하여 보다 면밀한 검증이 가능한 시스템을 구축했습니다.

    제품 개발에서 불량품을 선별하는 것은 매우 중요 작업입니다. 불량품으로 고객과 분쟁이 발생하는 경우에 회사는 막대한 손실을 입을 수 있습니다. 또한, 활용 가능한 제품을 효율적으로 선별하는 것은 비용절감으로도 이어집니다. Chip 생산은 공정상의 이유로 100% 양품이라는 보장이 없습니다. 따라서 고객에게 제품이 전달되기 전에 불량을 미리 선별하는 작업은 필수적입니다. 많은 Chip을 효율적으로 선별하기 위해서는 자동화된 테스트 시스템이 필요합니다. 텔레칩스에서는 기계적으로 소켓에 Chip을 삽입하여 시스템이 정상 부팅하는지의 여부로 Chip을 선별했습니다. 하지만, 단순한 부팅 테스트는 모든 불량을 선별하지 못하고 불량을 지나쳐 버리는 경우가 있습니다.
    회사 내에 테스트기술팀과 Chip QA팀이 존재했지만, 해당 부서는 하드웨어적인 감별을 주로 했기 때문에 소프트웨어로 불량을 선별하기 위한 시스템 개발 담당자는 없었습니다. 해당 프로젝트에 참여하면서 처음 부딪힌 어려움은 주먹구구식으로 개발된 시스템을 수정하는 일이었습니다. 불량 선별이 중요함에도 불구하고 그동안은 문제가 발생할 때만 대응하는 구조였기 때문에 시스템이 어떻게 개발되었는지에 대한 히스토리가 없었으며, 지속적인 개발 결과물을 유지하기 위한 형상관리조차 되어 있지 않았습니다. 그동안 정상임에도 불량으로 선별된 제품도 있었고, 불량임에도 정상으로 제품이 출하된 경우도 있어 고객사로부터 클레임을 받는 경우도 있었습니다. 이런 구조를 개선하기 위해 우선 주먹구구 형태로 추가된 선별 기능을 단일화된 구조로 변경했습니다. 단일화된 형태를 만들면 테스트 툴을 자동화하여 빌드할 수 있기 때문에 매번 반복적으로 사람이 작업해 줄 필요가 없습니다. 자동화된 시스템은 휴먼에러가 발생할 가능성도 미리 차단하는 것이 가능합니다.
    두 번째로 맞게 된 어려움은 저 혼자 모든 테스트를 할 수 없다는 것입니다. 간단한 Controller의 경우 단순 Read/Write 작업을 수행하여 테스트 결과를 비교하는 작업으로 정상 동작했는지 확인이 가능합니다. 하지만, 보다 전문지식이 필요한 GPU, VPU, USB 등의 기능 테스트는 다른 팀원의 도움이 필수적이었습니다. 다른 팀원에게 프로젝트의 요구사항과 준비되어야 하는 기능들을 부탁하기 위한 의사소통은 쉽지 않았습니다. 다행스럽게도 미리 작업해 두었던 내용을 문서화 해두었기에 내가 아니더라도 누구든 처음부터 개발환경을 쉽게 구축해서 테스트할 수 있게 했기 때문에 다른 팀원들은 빠르게 시스템에 적응하여 제가 정한 Error 선별 규칙들을 차례대로 적용할 수 있었습니다. 
    프로젝트 참여 결과로 이전에는 선별하지 못했던 디바이스들의 동작상 오류를 감별할 수 있었습니다. 또한, 기존에는 체계적으로 관리되지 못했던 System Level Test software를 형상관리 하에 운영될 수 있게 하였으며, 테스트 환경 구축도 자동화된 스크립트 명령 하나면 누구든 적용할 수 있도록 만들었습니다. 

Q. 새로운 것을 접목하거나 남다른 아이디어를 통해 문제를 개선했던 경험에 대해 서술해 주십시오.
1) 먼저, 관련 대표 경험 2가지를 간략하게 작성해 주십시오. (각 50자 이내)
- 언제, 어디서, 어떤 일을 수행했던 경험인지 간략하게 기술할 것

① 2016년, 텔레칩스, 1000대 중 한 대에서만 발생하는 동작 오류 해결
② 2016년, 텔레칩스, 제한적 driver 기능을 범용 리눅스 프레임워크와 연동

2) 위에 작성한 2가지 경험 중 1개를 골라 좀 더 상세하게 작성해 주십시오. (1,000자 10 단락 이내)
- 기존 방식과 본인이 시도한 방식의 차이/ 새로운 시도를 하게 된 계기/ 새로운 시도를 했을 때의 주변 반응/ 새로운 시도를 위해 감수해야 했던 점/ 구체적인 실행 과정 및 결과/ 경험의 진실성을 증명할 수 있는 근거가 잘 드러나도록 기술

＜제한적 기능 뛰어넘기, "리눅스 프레임워크 연동"＞

    Clock 드라이버 개발을 담당하게 되어 리눅스 3.4 커널 이후부터 적용된 "common clock framework"를 도입하는 업무를 수행했습니다. 해당 업무 결과로 다른 디바이스 드라이버 담당자들은 clock 구조에 대한 깊은 지식 없이 간단한 function 호출(clk_enable, clk_disable, clk_set_rate 등)만으로도 clock 설정을 할 수 있도록 도왔습니다.

    업무를 하며 느꼈던 딜레마는 "잘 되는 걸 왜 뜯어 고치냐?"였습니다. 기능상에 전혀 '문제가 없는 것처럼'보이는 기능을 굳이 변경할 필요가 있을까? 하지만, 어떤 소프트웨어도 완벽하지 않으며 고객의 요구사항은 날이 갈수록 다양하게 변화합니다. 잘 동작한다고 해서 그대로두면 이후 발생할 문제들을 적극적으로 대응하기가 어렵습니다. 제가 Clock 드라이버를 리눅스의 프레임워크와 연동되도록 수정했던 이유도 이와 같습니다. 
    초기 열정적이었을 때와는 다르게 새로운 기능을 도입하는 것은 쉽지 않았습니다. 수정된 내용이 기존 방식과 달리 익숙하지 않다 보니 실수가 발생했습니다. 그러니 주변의 시선은 점점 냉혹해졌습니다. "기존에 잘 되던걸 쓰지 왜 수고스럽게 변경하느냐"는 것입니다. 하지만, 기존 Clock 설정 방식은 매우 복잡하고 유연하지 않았습니다. Audio 디바이스를 예로 들면, 출력하려는 음원에 따라 Controller에 제공해야 하는 Clock이 달라집니다. 이를 Audio 드라이버 담당자가 직접 Clock 값을 계산하여 Controller에 적용하려면 Chip에서 Clock을 어떻게 설정하는지 모두 알고 있어야 했습니다. 본인 업무 외에도 다른 업무를 해야 하는 부담을 갖게 되는 것입니다. 또한, clock 설정 구조를 정확히 알지 못하니 설정을 하려고 할 때마다 저에게 내부/외부 할 것 없이 수시로 문의가 왔습니다.  이런 요구사항이 앞으로도 끊임없이 있을 것이라 생각했습니다. 
    새로운 기능을 구현하는데 많이 시간이 소요되었지만, 기존 드라이버를 리눅스 프레임워크와 호환 가능하도록 수정했습니다. 구체적으로는 기존에 하드코딩된 형태로 직접 레지스터 제어만 가능했던 clock 드라이버를 리눅스에서 범용적인 형태로 사용 가능하게 만든 clock framework와 연동되도록 수정했습니다. 해당 수정으로 인해 clock 설정이 필요한 다른 드라이버들은 clock 드라이버에 대한 구체적인 변경사항에 대한 이해 없이 리눅스에서 제공하는 몇 가지 API만 사용하면 설정 가능할 수 있도록 했습니다. 이러한 변경사항은 하드웨어를 점점 추상화하려는 리눅스의 지향점과 맞닿아 있어 사용자와 개발자의 편의성을 더욱 높일 수 있습니다. 초기 도입과정에는 불평불만이 있었지만, 현재는 다른 드라이버 담당자들도 만족스럽게 새로 구현된 API를 사용하게 되었습니다.  

Q. 지원 분야와 관련하여 특정 영역의 전문성을 키우기 위해 꾸준히 노력한 경험에 대해 서술해 주십시오. (1,000자 10 단락 이내)

- 전문성의 구체적 영역(예. 통계분석)/ 전문성을 높이기 위한 학습 과정/ 전문성 획득을 위해 투입한 시간 및 방법/ 습득한 지식 및 기술을 실전적으로 적용해 본 사례/ 전문성을 객관적으로 확인한 경험/ 전문성 향상을 위해 교류하고 있는 네트워크/ 경험의 진실성을 증명할 수 있는 근거가 잘 드러나도록 기술

＜고착된 영역 벗어나기, "웹/서버 개발 경험"＞

    개발자로서 관성에 잦아들지 않고 변화에 익숙해지기 위해 임베디드 개발 외에도 웹/서버 개발을 경험했습니다. 그로 인해, 꾸준히 신기술에 대한 호기심과 역량을 향상할 수 있게 노력 했습니다. 반복적인 업무를 하다 보면 이미 모든 것을 알았다는 착각에 빠질 수 있습니다. 하지만, 기술은 끊임없이 발전합니다. 이전에 사용하던 방식도 언젠가는 퇴화하고 새로운 기술들이 도입되기 마련입니다. 때문에 변화에 즉각적으로 적응하는 능력이 필요합니다. 그러한 능력 함양을 위해 새로운 트렌드를 가까이할 수 있도록 기술동향을 파악하고 있습니다. 

    개발자의 역할이 세분화되면서 반복 작업은 많아진 반면, 다양한 기술을 접할 가능성은 줄어들었습니다. 임베디드 개발자로서 하드웨어를 제어하고 기능하게 하는 반복된 업무의 틀을 벗어나기 위해 새로운 분야의 기술을 접하려 노력했습니다. 임베디드 분야와 극과 극에 있는 기술인 웹/서버 개발 분야에 관심을 갖게 된 것도 그러한 '고착된 영역 벗어나기'의 발전입니다. 과거 임베디드 시스템은 '매우 제한된'이라는 수식어가 많이 붙었습니다. 근래에는 임베디드 하드웨어의 성능도 많이 향상되었기 때문에, 단순한 하드웨어 제어를 벗어나 더 다양한 업무 분야에 사용되고 있습니다. 현재까지 웹/서버 기술은 임베디드와 괴리가 있습니다. 하지만, 언젠가는 두 기술이 융합될 것이라 생각합니다. 그 예로 IoT 기술분야가 있습니다. IoT는 많은 임베디드 제품들이 네트워크에 연결되어 유기적 동작을 하는 기술입니다. 때문에 웹/서버 기술은 임베디드 분야에도 매우 중요해질 것이라 생각합니다. 웹/서버 프로그래밍에 대한 저의 관심은 현재 현업에서는 직접 쓰이는 경우가 많지 않지만, IoT 분야가 더 활성화되면 꼭 필요한 기술이 될 것입니다. 
    개인 프로젝트들을 수행하여 웹/서버 프로그래밍이라는 기존과는 다른 프로그래밍 언어와 새로운 기술을 접했습니다. 최근 기술 트렌드를 이끈 것은 대체로 모바일과 웹 서비스 기술들이기 때문에 그에 따른 발전 내용도 많았습니다. 임베디드에서는 정해진 개발 구조를 벗어나는 것이 드물지만, 웹/서버 기술은 하루가 멀다 하고 변화하고 있습니다. 이에 적응할 수 있도록 개인 서버를 구축하고 자료를 정리할 수 있는 Wiki 시스템을 도입하여 스스로 실행해보았던 프로젝트와 연관된 기술 분석 내용을 정리/기록했습니다. 개인 프로젝트 또한 규모는 작아도 형상관리를 하며 진행하는 것이 효율적이기 때문에 Gitlab이라는 형상 관리 툴을 직접 도입해보기도 하고 빠른 산출물을 내놓을 수 있는 python 프로그래밍 언어에 기반한 웹 프레임워크인 Django 를 기반으로 간단한 웹페이지를 제작했습니다. 그리고 해당 페이지로부터 자료를 주고받을 수 있는 REST API를 사용해보았습니다. IoT에서는 특히 다양한 장치들이 어떤 통신규약으로 데이터 전송을 할 것인가가 중요한 이슈입니다. Django 시스템을 접하며 배운 REST API는 IoT 장치에서의 데이터 교환 체계로도 적용 가능한 프로토콜입니다. 이런 경험들이 관성적으로 매번 반복하던 업무의 패턴을 확장해주고 새로운 시도를 가능하게 하는 지식의 원천이 되고 있습니다.

Q. 혼자 하기 어려운 일에서 다양한 자원 활용, 타인의 협력을 최대한으로 이끌어 내며, Teamwork을 발휘하여 공동의 목표 달성에 기여한 경험에 대해 서술해 주십시오.

1) 먼저, 관련 대표 경험 2가지를 간략하게 작성해 주십시오. (각 50자 이내)
- 언제, 어디서, 어떤 일을 수행했던 경험인지 간략하게 기술할 것

① 2009, 공모전, 악보를 카메라로 촬영, 음표 분석 후 노래하며 춤추는 로봇 개발
② 2015, 텔레칩스, 신규 프로젝트에서 이전에 개발된 적 없는 시스템 구조 구현

2) 위에 작성한 2가지 경험 중 1개를 골라 좀 더 상세하게 작성해 주십시오. (1,000자 10 단락 이내)
- 관련된 사람들의 관계(예. 친구, 직장 동료) 및 역할/ 혼자 하기 어렵다고 판단한 이유/ 목표 설정 과정/ 자원(예. 사람, 자료 등) 활용 계획 및 행동/ 구성원들의 참여도 및 의견 차이/ 그에 대한 대응 및 협조를 이끌어 내기 위한 구체적 행동/ 목표 달성 정도 및 본인의 기여도/ 경험의 진실성을 증명할 수 있는 근거가 잘 드러나도록 기술

＜천둥벌거숭이, "Teamwork를 배우다"＞

  담당 프로젝트를 되돌아보았을 때, 모든 일을 혼자 할 수 있을 거라 느꼈던 입사 초기와 달리 '나 혼자 해낸 일이 아니구나.'라고 느꼈습니다. 수시로 보드 시방을 부탁드렸던 하드웨어 팀의 부장님, 기본도 안 되어 있던 저에게 Chip의 부팅 원리부터 동작의 끝까지 함께 봐주었던 멘토 대리님, 그리고 연륜이라는 것을 보여준 DRAM 담당 대리님. 시작할 때엔 혼자 다 할 수 있을 것처럼 시작한 프로젝트였지만, 한 분 한 분의 도움을 받으며 프로젝트를 무사히 마무리했습니다.

    입사 초에 맡게 된 신규 프로젝트는 기존과는 다른 시나리오의 시스템이었습니다. 그것은 두 가지 저장 매체(SNOR, eMMC)로 보드를 부팅하는 것입니다. 부트로더는 Serial Flash, 메인 운영체제는 eMMC로 운용하는 방식으로 보안성을 보다 높이는 시스템입니다. 해당 시나리오는 회사에서 기존에 개발된 적이 없는 구조라 프로젝트 가능성 타진을 위한 빠른 대응이 필요했습니다. 
    경력으로 입사했지만 회사 시스템에 익숙해지지 않은 상태에서 맡게 된 중요한 업무였습니다. 처음에는 혼자 분석하는데만 열중했습니다. 경력으로 입사했기 때문에 다른 사람들에게 보다 잘 보이고 싶었고 내가 능력 있는 사람이라는 증명을 하고 싶었습니다. 멘토가 있음에도 물어보지 않고 혼자 멘땅에 헤딩을 하며 한참을 씨름했습니다. 하지만, 기본 원리 조차 모르는 상태에서 멘땅의 헤딩은 무용지물이었습니다. 팀의 성과에 중요한 프로젝트였기 때문에 나 개인의 자존심은 뒤로 하는 것이 옳다고 생각했습니다. 그 후로는 멘토 대리님에게 적극적으로 하나부터 열까지 물어보며 일을 시작했습니다. 그리고 Hardware, Serial Flash, eMMC 담당자 할 것 없이 찾아가며 도움을 요청했습니다.
    도움을 요청하는 과정 중 어려웠던 점은 직원들 사이에서도 서로 성향이 다르며 친밀도가 다르다는 것입니다. 멘토 대리님으로부터 많은 도움을 받았지만, 멘토 대리님과 Serial Flash 담당인 차장님은 사이가 좋지 않아, 서로 얘기하기를 꺼려했습니다. 처음엔 그런 전후 사정을 몰라 '왜 직접 Serial Flash 담당자에게 의견을 구하지 않을까' 생각했습니다. 후에 멘토 대리님을 설득했습니다. 현재 발생한 문제점을 최대한 상세히 공유하고 해당 프로젝트가 잘 진행되려면 필요한 것들이 무엇인지 공감대를 형성하여 대리님과 차장님의 관계를 개선할 수 있었습니다. 이 후 차장님의 도움을 받아 Serial Flash의 동작 방법을 알게 되어 업무를 이어갈 수 있었습니다. 
    업무가 마무리될 즈음 담당자들과 중국 현지 공장으로 출장을 가게 되었습니다. 출장지에서의 업무는 실제 제작된 보드에서 Working 테스트를 하는 것인데 예상과는 달리 이미 테스트된 코드가 정상 동작하지 않았습니다. 디버깅 결과 Bootcode가 정상적으로 DRAM에 로딩되지 않는 증상이었습니다. 프로젝트에서 맡게 된 업무가 Serial Flash에 Pre-bootloader를 write 하고 해당 영역을 부팅 시에 Chipboot 코드가 Read 할 수 있게 하여 부트 코드를 실행하는 부분이었습니다. 때문에 작업 초기에 Serial Flash에 Command를 전송하는 타이밍에 문제가 발생하면 이런 문제가 있었다는 것을 기억해 냈습니다. 시스템마다 타이밍 마진이 다를 수 있기 때문에 이런 일들이 종종 발생하는 것을 알았습니다. 결과적으로 Serial flash 명령 전송 타이밍을 수정하자 정상 동작이 확인되었습니다. 다른 동료 분들이 하신일에 비하면 큰 일은 아니었지만 그동안 여러 시도를 했던 노력들이 발휘된 순간이라 뿌듯한 경험이었습니다. 또한, Teamwork로 이룬 프로젝트 마무리 성과는 그동안 혼자 천둥벌거숭이처럼 행동했던 저를 겸손하게 했습니다.