임베디드 개발자들의 성격
2009년 스마트폰 시대 부터 비에스피(BSP: Embedded Linux driver/Linux kernel)개발을 시작한 지 어언 9년이 흘렀다. 정말 9년 동안 수 많은 이슈를 만났고 이 놈들을 해결하면서 정말 고생도 많이 했다. 그런데 9년의 시간이 흐른 시점에서 한 가지 아쉬운 점은 나의 체험으로 느낀 점을 글로 남기지 못했다. 사실 그 당시 몸도 가누기 힘들 정도로 체력이 방전되어 어떤 글을 남긴다는 것은 상상도 하지 못했다. 이제 조금 나를 뒤돌아 볼 시점인 것 같다. 사실 요즘 조금 한가하기도 하다.
사실 난 원래 풤에어 혹은 비에스피(firmware, BSP)출신 개발자가 아니다. 난 2005년부터 휴대폰을 개발을 했는데 당시 피쳐폰(feature phone)의 유아이 혹은 미들웨어 유지 보수을 담당했었다. 구체적으로 벡터 폰트, 플레시 라이트 등등을 유아이 플렛폼에 맞게 포팅을 했다. 포팅한 함수들을 묶어서 SMS, Call, Camera 등등과 같은 어플리케이션(application) 담당자들에게 API를 제공했다. 이후 에디터 및 플레시 플러그인 까지 개발을 했었다.
그 당시 가끔 펌웨어 개발자(지금 임베디드, BSP개발자)들과 함께 논의를 하면서 디버깅을 할 일이 종종 있었다. 그런데 내 기억 속에서 펌웨어 개발자들은 성질이 참 더러웠다. 상당히 까칠하고 대화가 잘 되지 않는 놈들이었다.
그런데 지금 동료들의 99%는 임베디드 소프트웨어 개발자들이다. 9년 전 내가 생각했던 까칠하고 대화가 잘 안 되는 놈이라고 기억했던 놈들이 나와 내 동료들인 것이다.
우선 기술적인 내용을 적기 앞서 임베디드 개발자들에 인간적인 면 - 성격, 특징 등등-에 대해서 느낀 점에 대해서 할 말이 참 많다.
사실 난 요즘에도 직장 동료들(임베디드 개발자들)과 대화를 나눌 때 정말 답답하다. 이 녀석들은 차를 마시거나 술을 마실 때에도 대부분 기술적인 어떤 사실, 내용 및 생각에 대해서 말하기를 정말 좋아한다. 가끔 보면 상대방이 자신이 말을 듣고 어떤 반응을 보이는 지 개의치 않는 놈들도 볼 수 있다. 정말로 로보트가 갱스터 랩을 하는 것 같이 느낄 때가 많다.
가령 아래와 같은 소리를 40분 동안 숨도 쉬지 않고 열정적으로 말 하는 것이다.
"어제 코어덤프에서 스팩 오버플로우(stack overflow) 흔적을 본 것 같은데 프레임 포인터(frame pointer) 주소 근처의 덤프의 패턴이 일정하지 않는 것 같더라구. 그런데 스택이 깨져도 바로 커널 패닉이 발생하지는 않잖어? 스택이 깨질 때의 정확한 순간을 포착 해야 하는데 이를 위한 스팩 프로파일러란 패치가 있더라고. run queue에 쌓여 있는 프로세스에 대응되는 태스트 디스크립터(task descriptor)의 last_arrival이란 변수의 순서대로 정렬을 한 다음에 각각 프로세스 별로 스택 바운더리에 대한 스캔을 하면 좋을 것 같어. 이런 매카니즘으로 디버깅을 하면 사이드 이팩트나 시스템 성능 저하로 인한 커널 패닉이 일어나지는 않을 것 같다.
아니면 arm gcc에서 릴리즈하는 __builtin_return_frame이란 매크로 함수를 사용하는 것도 생각해 볼 수 있지. schedule 시 자주 호출하는 함수에 __builtin_return_frame(0)이란 함수를 추가해서 current란 매크로를 통해 현재 프로세스의 스택 경계 주소를 넘어섰는 지를 알아 볼 수도 있어."
물론 이런 종류의 주제에 대해 대화를 나누는 것은 반드시 필요하다. 우리와 같은 임베디드 개발자들이 업무이자 삶이기 때문이다. 그런데 만날 때 마다 이런 이야기만 하면 어떤까?
내가 쉬는 시간에 직장 동료들과 차를 마시며서 나누고 싶은 대화는 하고 있는 일이 힘든지, 주말에 뭐 했는지, 캠핑으로 갈 곳은 어떤지 등등이다. 인간 대 인간으로 소통하고 싶은 것이다. 그런데 문제는 70%정도 나의 직장동료들은 자신들이 좋아하는 기술적인 주제에 대해서만 끊임없이 이야기를 하고 싶어 한다. 이럴 때 난 도무지 로봇이랑 이야기를 하고 있는 것 같다.
아무리 많은 시간 이런 주제들에 대해서 서로 떠들어댄다고 해도 서로에게 어떤 친밀감이 생길 수 있을까? 다만 서로 어떤 기술에 대한 관심사가 있는 지에 대해서 알 수 있는 것이다. 이런 유형의 임베디드 개발자들은 감성이 매우 메말라있거나 사람을 어떻게 대해야 할 지 모르는 경우가 많다.
저번에 팀 회식에서 한 주임 연구원이 "요즘 정말 힘들다"라고 한 숨을 쉬며 말했다. 내가 봐도 그 친구가 엄청난 업무량과 압박감으로 스트레스를 많이 받고 있다는 것을 한 눈에 알 수 있었다. 일할 때 그 친구의 표정, 담배를 필 때의 고뇌에 찬 눈빛을 보기도 했지만, 그 친구가 처해 있는 상황(처음 엠베디드 개발 업무를 맡았는데 멘토가 없음)을 알고 있었기 때문이다. 난 처음 임베디드 개발을 할 때 그 아찔한 느낌을 아직도 생생히 기억한다. 한 겨울에 목욕탕에 들어가자 마자 바로 80도의 펄펄 끓는 온탕에 바로 들어가는 느낌.
그런데 그 친구의 넋두리를 듣던 내 직장 동료와 부서장이 정말로 예술적이면서도 창의적인 질문을 했다.
"니가 힘든 이유에 대한 백데이터(근거 자료, back data)가 뭐야? 한번 제시해 봐."
뜨악! 술이 확 깨는 순간이다. 커널에 로그가 남듯이 사람의 감정에도 로그가 남는 다고 생각하나? 정말 전두엽에 빵꾸가 난 놈이 아닐까? 정말로 내 상식으로 도저히 이해가 가지 않았다. 뭐 이 때의 느낌을 설명할 만한 단어가 떠오르지 않는다. 충격적이고 파괴적이라고 해야 할까. 내가 좀 극단적인 예시를 든 것 같지만 임베디드 개발에 과몰입한 개발자들의 모습을 볼 수 있는 하나의 그림자라고 봐야 겠다.
사실 난 원래 풤에어 혹은 비에스피(firmware, BSP)출신 개발자가 아니다. 난 2005년부터 휴대폰을 개발을 했는데 당시 피쳐폰(feature phone)의 유아이 혹은 미들웨어 유지 보수을 담당했었다. 구체적으로 벡터 폰트, 플레시 라이트 등등을 유아이 플렛폼에 맞게 포팅을 했다. 포팅한 함수들을 묶어서 SMS, Call, Camera 등등과 같은 어플리케이션(application) 담당자들에게 API를 제공했다. 이후 에디터 및 플레시 플러그인 까지 개발을 했었다.
그 당시 가끔 펌웨어 개발자(지금 임베디드, BSP개발자)들과 함께 논의를 하면서 디버깅을 할 일이 종종 있었다. 그런데 내 기억 속에서 펌웨어 개발자들은 성질이 참 더러웠다. 상당히 까칠하고 대화가 잘 되지 않는 놈들이었다.
그런데 지금 동료들의 99%는 임베디드 소프트웨어 개발자들이다. 9년 전 내가 생각했던 까칠하고 대화가 잘 안 되는 놈이라고 기억했던 놈들이 나와 내 동료들인 것이다.
우선 기술적인 내용을 적기 앞서 임베디드 개발자들에 인간적인 면 - 성격, 특징 등등-에 대해서 느낀 점에 대해서 할 말이 참 많다.
사실 난 요즘에도 직장 동료들(임베디드 개발자들)과 대화를 나눌 때 정말 답답하다. 이 녀석들은 차를 마시거나 술을 마실 때에도 대부분 기술적인 어떤 사실, 내용 및 생각에 대해서 말하기를 정말 좋아한다. 가끔 보면 상대방이 자신이 말을 듣고 어떤 반응을 보이는 지 개의치 않는 놈들도 볼 수 있다. 정말로 로보트가 갱스터 랩을 하는 것 같이 느낄 때가 많다.
가령 아래와 같은 소리를 40분 동안 숨도 쉬지 않고 열정적으로 말 하는 것이다.
"어제 코어덤프에서 스팩 오버플로우(stack overflow) 흔적을 본 것 같은데 프레임 포인터(frame pointer) 주소 근처의 덤프의 패턴이 일정하지 않는 것 같더라구. 그런데 스택이 깨져도 바로 커널 패닉이 발생하지는 않잖어? 스택이 깨질 때의 정확한 순간을 포착 해야 하는데 이를 위한 스팩 프로파일러란 패치가 있더라고. run queue에 쌓여 있는 프로세스에 대응되는 태스트 디스크립터(task descriptor)의 last_arrival이란 변수의 순서대로 정렬을 한 다음에 각각 프로세스 별로 스택 바운더리에 대한 스캔을 하면 좋을 것 같어. 이런 매카니즘으로 디버깅을 하면 사이드 이팩트나 시스템 성능 저하로 인한 커널 패닉이 일어나지는 않을 것 같다.
아니면 arm gcc에서 릴리즈하는 __builtin_return_frame이란 매크로 함수를 사용하는 것도 생각해 볼 수 있지. schedule 시 자주 호출하는 함수에 __builtin_return_frame(0)이란 함수를 추가해서 current란 매크로를 통해 현재 프로세스의 스택 경계 주소를 넘어섰는 지를 알아 볼 수도 있어."
물론 이런 종류의 주제에 대해 대화를 나누는 것은 반드시 필요하다. 우리와 같은 임베디드 개발자들이 업무이자 삶이기 때문이다. 그런데 만날 때 마다 이런 이야기만 하면 어떤까?
내가 쉬는 시간에 직장 동료들과 차를 마시며서 나누고 싶은 대화는 하고 있는 일이 힘든지, 주말에 뭐 했는지, 캠핑으로 갈 곳은 어떤지 등등이다. 인간 대 인간으로 소통하고 싶은 것이다. 그런데 문제는 70%정도 나의 직장동료들은 자신들이 좋아하는 기술적인 주제에 대해서만 끊임없이 이야기를 하고 싶어 한다. 이럴 때 난 도무지 로봇이랑 이야기를 하고 있는 것 같다.
아무리 많은 시간 이런 주제들에 대해서 서로 떠들어댄다고 해도 서로에게 어떤 친밀감이 생길 수 있을까? 다만 서로 어떤 기술에 대한 관심사가 있는 지에 대해서 알 수 있는 것이다. 이런 유형의 임베디드 개발자들은 감성이 매우 메말라있거나 사람을 어떻게 대해야 할 지 모르는 경우가 많다.
저번에 팀 회식에서 한 주임 연구원이 "요즘 정말 힘들다"라고 한 숨을 쉬며 말했다. 내가 봐도 그 친구가 엄청난 업무량과 압박감으로 스트레스를 많이 받고 있다는 것을 한 눈에 알 수 있었다. 일할 때 그 친구의 표정, 담배를 필 때의 고뇌에 찬 눈빛을 보기도 했지만, 그 친구가 처해 있는 상황(처음 엠베디드 개발 업무를 맡았는데 멘토가 없음)을 알고 있었기 때문이다. 난 처음 임베디드 개발을 할 때 그 아찔한 느낌을 아직도 생생히 기억한다. 한 겨울에 목욕탕에 들어가자 마자 바로 80도의 펄펄 끓는 온탕에 바로 들어가는 느낌.
그런데 그 친구의 넋두리를 듣던 내 직장 동료와 부서장이 정말로 예술적이면서도 창의적인 질문을 했다.
"니가 힘든 이유에 대한 백데이터(근거 자료, back data)가 뭐야? 한번 제시해 봐."
뜨악! 술이 확 깨는 순간이다. 커널에 로그가 남듯이 사람의 감정에도 로그가 남는 다고 생각하나? 정말 전두엽에 빵꾸가 난 놈이 아닐까? 정말로 내 상식으로 도저히 이해가 가지 않았다. 뭐 이 때의 느낌을 설명할 만한 단어가 떠오르지 않는다. 충격적이고 파괴적이라고 해야 할까. 내가 좀 극단적인 예시를 든 것 같지만 임베디드 개발에 과몰입한 개발자들의 모습을 볼 수 있는 하나의 그림자라고 봐야 겠다.
이렇게 팀동료의 입장에서 생각을 하지 못하고 오직 기술적으로 세상을 바라보다 보니, 다른 동료들과 업무 상 의사소통을 제대로 할 수 없다. 그래서 이들은 사람들과 제대로 어울릴 줄을 모르고 어울린 다고 해도 코드가 맞는 한 두명의 개발자들하고만 소통한다.
그래서 다른 분야 개발자들은 임베디드 개발자들과 일하기 어렵다는 말을 종종한다. 대부분 의사소통 문제다.
'리눅스 시스템 개발 스토리' 카테고리의 다른 글
| 인프런에 '시스템 소프트웨어 개발의 모든 것' 강좌를 오픈했습니다. (0) | 2023.10.23 |
|---|---|
| 유데미에 'Armv8-A 아키텍처 Overview - 64비트 Arm Cortex-A Processor 기반'를 오픈했습니다. (1) | 2023.05.03 |
| 임베디드 소프트웨어 개발자 양극화는 얼마나 심각할까? (0) | 2019.02.11 |
| 리눅스 커널은 정말 오픈 소스 프로젝트일까? (0) | 2019.02.11 |