<< 리눅스 커널 및 리눅스 시스템 Track>>

리눅스 커널의 동작 원리 (저자 직강 방식)

 - 리눅스 커널의 주요 디버깅 툴
 - 프로세스, 태스크 스케줄링 
 - 인터럽트 및 인터럽트 후반부
 - Soft IRQ, 워크큐
 - 커널 동기화, 배리어
 - 시그널, 시스템 콜
 - 가상 파일 시스템, 주요 파일 시스템
 - 매모리 매니지먼트

리눅스 디바이스 드라이버 Overview 

- 리눅스 디바이스 드라이버의 전체 구조
- 디바이스 드라이버 디버깅 피쳐
- 모듈 디바이스 드라이버 기본 구조
- 캐릭터 디바이스 드라이버
- 블락 디바이스 드라이버
- 플렛폼 디바이스 드라이버
- 디바이스 트리 및 최적화
- 인터럽트 핸들링, Top-half와 Bottom Half
- 디바이스 드라이버 동기화 이슈 

리눅스 시스템 리소스 모니터링  

- 리눅스 OS 와 프로세스 이해
- 리눅스 SW 동작원리
- 리눅스 메모리(Stack / Heap) 분석과 이해
- 리눅스 OS 이해와 커널함수 추적
- 리눅스 파일 Read / Write 처리과정
- 리눅스 시스템 트러블슈팅


<< Arm 프로세서 Track >>

Arm 프로세서(64비트 Armv8-A 아키텍처) 동작 원리 (저자 직강 방식)

- 레지스터(Register)
- 어셈블리 명령어
- AAPCS(함수 호출 규약)
- 익셉션 레벨(Exception Level)
- 익셉션(Exception)
- 크래시 폴트 핸들링 매커니즘
- GIC(Generic Interrupt Controller)
- 트러스트존(Trustzone)
- 가상화(Virualization)
- 메모리 배리어와 캐시
- MMU(Memory Management)

Arm 프로세서(32비트 Armv7-A 아키텍처) 동작 원리 (저자 직강 방식)

- 레지스터(Register)
- 어셈블리 명령어
- AAPCS(함수 호출 규약)
- 동작 모드 
- 익셉션(Exception)
- 크래시 폴트 핸들링 매커니즘
- GIC(Generic Interrupt Controller)
- 트러스트존(Trustzone)
- 가상화(Virualization)
- 메모리 배리어와 캐시
- MMU(Memory Management)

 


리눅스 커널과 Arm 프로세서 인터페이스 (저자 직강 방식)

- 프로세스의 스택과 함수 호출 규약
- 익셉션 레벨, 동작 모드와 커널 공간
- 컨텍스트의 의미와 레지스터
- 컨텍스트 스위칭
- 시스템 콜, 시그널
- 스핀락, 배리어
- 페이지 폴트, 페이지 테이블 
- 트러스트존 드라이버

<< 크래시 덤프 분석 및 트러블슈팅 Track >>

TRACE32와 crash-utility 로 크래시 덤프 분석으로 리눅스 커널 분석하기

 - 주요 리눅스 커널 구조 디버깅(프로세스, 태스크 스케줄링, 메모리, 파일 시스템) 
 - 깨진 콜 스택 복원
 - CMM 스크립트 작성으로 커널 자료 구조를 파싱 
 - Crash-Utility로 주요 메모리 정보 프로파일링 
 - 예제 크래시 덤프 분석 (락업, 메모리 오염, BUG, 패닉)

 

트러블슈팅 - 주요 예제 덤프 분석(TRACE32, crash-utility 사용)

 - 예제 크래시 덤프 분석 (락업, 메모리 오염, BUG, 패닉)
 - ftrace 메시지 분석하기
 - ftrace 메시지와 메모리 덤프로 주요 리눅스 커널 구조 디버깅 
 - 깨진 콜 스택 복원
 - 디버깅 패치 작성 방법

저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[홍보] 프로그래머스: '리눅스 시스템 및 커널 전문가' 부트캠프(Boot Camp)  (0) 2023.05.11
유데미에 '리눅스 시스템 소프트웨어 강좌'를 오픈했습니다. 한번만 도와주세요!(feat: 목표는 300명 등록)  (0) 2023.05.11
유데미 강사부트캠프 2기 - 8주차 후기  (0) 2023.05.11
[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11

제가 인프런에 '시스템 소프트웨어 개발의 모든 것 - 시스템 반도체와 전기 자동차 중심' 강좌를 만들어서 오픈했습니다. 링크는 아래와 같습니다;

 

시스템 소프트웨어 개발의 모든 것 강의 링크

그 동안 여러 세미나에서 시스템 반도체와 전기 자동차 분야에서 시스템 소프트웨어 개발을 하고 싶은데 어떻게 무엇을 준비해야 할지 모르겠다는 질문을 많이 받았습니다. 제가 세미나에서 답을 드린 내용을 잘 정리하고 압축해 강의를 만들었습니다.

강의 내용을 압축하면 다음과 같습니다;

 1. 시스템 소프트웨어 개발자로 실전 프로젝트에서 어떤 일을 하는지 세세히 설명을 합니다. 
 2. 시스템 반도체와 전기 자동차 업계에서 리눅스 시스템 소프트웨어 개발자가 어떤 일을 하는지 자세히 다룹니다. 
 3. 각각 어떤 소프트웨어 스택으로 시스템 소프트웨어 관련 구조가 구성됐는지도 상세히 설명합니다.

여러분 중에 시스템 소프트웨어 분야를 진출하기를 희망 하시거나 혹은 실전 프로젝트에서 어떤 일을 하는지 궁금하신다면 이 강의를 참고하시면 좋겠습니다.

 

 

 

저작자표시

'리눅스 시스템 개발 스토리' 카테고리의 다른 글

유데미에 'Armv8-A 아키텍처 Overview - 64비트 Arm Cortex-A Processor 기반'를 오픈했습니다.  (1) 2023.05.03
임베디드 소프트웨어 개발자들과는 왜 일하기 어려울까?  (0) 2019.02.12
임베디드 소프트웨어 개발자 양극화는 얼마나 심각할까?  (0) 2019.02.11
리눅스 커널은 정말 오픈 소스 프로젝트일까?  (0) 2019.02.11
그 동안 프론트 앤드, 백 앤드와 같은 애플리케이션 기반 중심의 프로그래밍 코스가 부트 캠프로 진행됐는데요. 드디어 국내 최초로 리눅스 커널 및 시스템 전문가 부트 캠프가 개설됐습니다. 국내 최강의 강사진(교수, 개발자)으로 구성된 부트 캠프이니, 시스템 소프트웨어 분야로 진로를 고민 중이거나 이 분야로 이직을 준비 중인 개발자 분들은 꼭 참여하셨으면 좋겠습니다. * 마감일(~03/09)
 
시스템 소프트웨어 분야의 전망에 대해 조금 더 말씀드리면;
 
최근에 시스템 반도체와 전기 자동차에 많은 투자가 이뤄지고 있는데요. 개발 관점으로 들여다 보면 '시스템 반도체와 전기 자동차'의 핵심은 시스템 소프트웨어(리눅스 커널, Arm 아키텍처)입니다. 또한 맥킨지를 비롯한 다양한 비즈니스 업체에서 '2030년에는 시스템 반도체와 전기 자동차 분야를 중심으로 현재(2023년 대비) 10배 이상의 시스템 소프트웨어 개발자가 증가할 것으로 '예상하고 있어, AI, 빅데이터, 클라우드 개발자 만큼 인기 있는 직종으로 떠오를 것으로 예상합니다.
 
 
.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[Udemy] Possible Education Programs for system software developers (offline)  (0) 2023.12.21
유데미에 '리눅스 시스템 소프트웨어 강좌'를 오픈했습니다. 한번만 도와주세요!(feat: 목표는 300명 등록)  (0) 2023.05.11
유데미 강사부트캠프 2기 - 8주차 후기  (0) 2023.05.11
[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
제가 유데미에 '초보 시스템 소프트웨어 개발자 벗어나기'라는 강좌 만들어서 오픈했습니다. 링크는 아래와 같습니다;
 
 
 
 
여러분 중에 시스템 소프트웨어 분야를 진출하기를 희망 하시거나 혹은 실전 프로젝트에서 어떤 일을 하는지 궁금 하신다면이 강의를 꼭 등록해서 들으셨으면 좋겠습니다. 
 
클래스의 목차를 보시면 아시겠지만 시스템 소프트웨어 개발자로 실전 프로젝트에서 일을 하는지에 대해 대해서 굉장히 자세하게 설명을 하고요. 특히 시스템 반도체와 전기 자동차 업계에서 리눅스 시스템 소프트웨어 개발자가 어떤 일을 하는지 자세히 설명합니다.
 
 
 
클래스의 내용을 보시면 아시겠지만 리눅스 커널이나 Arm 아키텍처에 대한 소개와 컨셉 그리고 실전 프로젝트에서 활용이 될만한 실용적인 내용을 잘 정리했습니다. 
 
 
 
시스템 소프트웨어 개발자가 되기 위해서 어떤 주제를 공부해야 하는지 궁금해하시는 분에게 큰 도움이 될 것이라 생각됩니다.  
 
여러분 중에 시스템 소프트웨어 분야를 진출하기를 희망 하시거나 혹은 실전 프로젝트에서 어떤 일을 하는지 궁금 하신다면 이 강의를 꼭 들어 주셨으면 좋겠습니다.
 
감사합니다.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[Udemy] Possible Education Programs for system software developers (offline)  (0) 2023.12.21
[홍보] 프로그래머스: '리눅스 시스템 및 커널 전문가' 부트캠프(Boot Camp)  (0) 2023.05.11
유데미 강사부트캠프 2기 - 8주차 후기  (0) 2023.05.11
[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
*본 포스팅은 유데미 강사부트캠프 2기 SNS 챌린지 참여 후기로 작성되었습니다.
 
유데미 2차 부트 캠프에 참가해 '멘토'로부터 티칭(Teaching)에 대한 고급 노하우를 전수 받았다. 마지막 세션에서 진행된 '임동준'님은 세미나를 통해 너무나도 유익한 정보를 전수했다. 티칭 뿐만 아니라 개발자로써 새로운 지식을 배울 때 적용하면 좋을 만한 내용이 많았다. 
 
1. 난해한 내용은 1가지만 설명하자
 
낯선 개념을 1가지 이상 설명하면 입문자는 더욱더 혼돈에 빠진다. 어려운 개념은 1가지 씩만 설명하자. 새로운 기능을 배울 때 이 규칙을 적용하면 좋겠다.
 
2. 소프트웨어를 배울 때 방향

 

자전거를 배울 때 자전저를 학습하는 사람이 있다. 기어나 브레이크의 깊이 있는 동작 원리를 배운다. 문제는 쉽게 지루해진다는 것이고 자전거를 못 탈 수도 있다. 자전거를 배울 때는; 일단 평지에서 자전거를 타는 방법을 익힌 다음에, 경사가 있는 곳을 올라갈 때 만나는 문제점(기어 사용)에 대해 고민하는게 좋다. 
 
이는 소프트웨어에도 적용될 수 있다. 일단 뭐라도 간단히 만들어보고 문제를 만나면 차근 차근 해결하는 방식으로 강의를 구성하면 좋겠다.
 
3. 핵심을 찌를 수 있는 간단한 예시
 
아주 간단한 예제 코드나 실습을 통해 입문자가 배우려는 내용의 핵심 원리를 파악할 수 있다. 입문자가 무엇인가를 따라하면서 자연스럽게 소프트웨어의 핵심 원리를 체득하는 방식이다. 세미나나 강의를 구성할 때 꼭 참고하면 좋은 내용이다.
 
4. 아무리 설명해도 못 알아들을 때
 
이런 상황에서는 내가 설명하려는 내용을 내가 어떻게 체득했는지는 생각해 볼 필요가 있다. 내가 체득했던 방식을 입문자가 실습으로 따라하게 강의를 구성하거나 내가 실습으로 보여줄 수도 있다. 
 
5. 잦은 피드백
 
농구에서 슛을 쏜 다음에 골이 안 들어갔다는 것을 1시간 후에 확인하면 어떨까? 농구 실력이 늘지 않을 것이다. 피드백은 자주 받는게 좋다. 강사는 학생이 제대로 이해를 했는지, 학생은 본인이 제대로 이해했는지 자주 확인하는 과정이 필요하다. 
 
세미나 도중에 실시간으로 질문을 받고 바로 피드백을 받으니 정말 유익했다. 
<아래는 스틸 것>
 
 
2022년 최고의 세미나였다고 생각된다.
 
#유데미, #유데미코리아, #유데미강사되기, #유데미부트캠프, #강사부트캠프, #유데미강사부트캠프, #강사되기, #강사양성
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[홍보] 프로그래머스: '리눅스 시스템 및 커널 전문가' 부트캠프(Boot Camp)  (0) 2023.05.11
유데미에 '리눅스 시스템 소프트웨어 강좌'를 오픈했습니다. 한번만 도와주세요!(feat: 목표는 300명 등록)  (0) 2023.05.11
[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
[에세이] '글로벌 소프트웨어 업체가 인도에 주목하는 이유/인도와 비교했을 때 한국 소프트웨어 개발은?  (0) 2023.05.11
7.1(금) 오전 10시에 'ftrace를 이용해 리눅스 커널 정복하기' 주제로 발표했다.
발표를 하면서 느꼈던 점과 사진을 몇 가지 남긴다.
 
세미나 관심도
 
생각보다 엄청난 인원이 세미나에 참석했다. 대략 120명은 넘게 참석했던 것으로 예상한다.
발표를 시작한지 오분 정도 지났을 때 자리가 부족해 뒤에 서서 듣는 학생들이 보였다. 
 
그 동안 수 많은 세미나를 진행했지만 가장 감동적인 순간이었다. 
저 멀리 어둠 속에 서서 발표를 듣는 참석자들의 실루엣은 앞으로 잊지 못할 기억으로 남을 것이다.
 
발표를 듣다가 다른 발표장을 떠나는 경우가 많은데 2시간 동안 이어진 발표 시간 동안
거의 대부분 참석자들이 자리를 지켰다. 
 
사진 1: 발표 1시간 전에 발표 장소에 도착해 자료를 리뷰했다.
 
 
 
사진 2: 첫 소개를 하는 순간이다. 이 때 저 멀리 어둠 속에 서서 세미나를 듣는 분들이 보였다.
 
 
 
사진 3: 블로그와 유튜브를 홍보했다. 이 때 카메라 플래시가 많이 터졌다.
 
 
 
사진 4: 시스템 소프트웨어 개발자와 업계 현황에 대해 설명 중이다. 
 
 
사진 5: ftrace에 대해 설명 중이다.
 
 
 
사진 6: 태스크 스케줄링과 관련된 주요 기능을 설명 중이다.
 
 
오픈 소스 Contribution 방법 소개
 
발표 시간이 부족해 10분 정도를 오버해 다음 발표자인 박병철님께 바톤 터치를 했다. 
 
발표를 하는 도중에 참석자 분들이 발표 자료 화면을 휴대폰으로 찍느라 플래시가 계속 터졌다. 
동료인 박병철님이 발표할 때 카메라 플래시가 너무 자주 터져서 발표를 잠시 멈추고 
잠시 사진을 찍는 시간을 주기도 했다. 
 
몇몇 분들은 노트북으로 게임을 하듯이 엄청난 스피드로 
발표 내용을 타이핑했다. 박병철님의 인기는 대단했다. 
 
사진 7: 발표 문서를 열고 전체 화면을 설정하는 중이다. 
 
 
 
사진 8: 병철님의 이메일 주소가 나온 순간, 엄청난 카메라 플래시가 터졌다.  
 
 
사진 9: 본인 Contribution 이력을 소개했다. 사진을 유심히 보자. 
lockdep에 대해 어떻게 생각하는지 알 수 있다.
 
 
사진 10: 병철님(왼쪽 윗 부분에 있음)이 참석한 커널 서밋 사진이다.
가장 앞 열에 리눅스 토발즈(붉은 색 반팔 티)가 있다.  
 
 
 
사진 11: 리눅스 커널 커뮤니티의 개발 문화를 소개하고 있다. 
 
 
사진 12: 오픈 소스에 Contribution 하는 방법을 아주 친절하고 쉽게 설명 중이다.
 
 
Q/A: 질의 응답
 
발표가 끝나고 Q/A 시간을 진행했는데 예정된 30분을 넘어 45분 동안 진행했다.
학생들이 끊임없이 질문을 이어갔기 때문이다. 질문을 하신 분들에게 경품으로 내가 쓴 책을 
선물로 전달했는데 준비한 12권 책이 5분만에 동이 났다.
 
사진 13: 질의 응답을 받는 순간이다. 
 
 
사진 14: 디버깅 방법, TRACE32과 같이 실무와 관련된 질의가 많았다.
 
 
사진 15: 책을 선물할 때 모습(정말 좋아하셨다.)
 
 
* 사진을 찍어 주신 이파란님께 정말 감사드린다.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

유데미에 '리눅스 시스템 소프트웨어 강좌'를 오픈했습니다. 한번만 도와주세요!(feat: 목표는 300명 등록)  (0) 2023.05.11
유데미 강사부트캠프 2기 - 8주차 후기  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
[에세이] '글로벌 소프트웨어 업체가 인도에 주목하는 이유/인도와 비교했을 때 한국 소프트웨어 개발은?  (0) 2023.05.11
[임베디드 에세이] 한국 시니어 임베디드 개발자의 처참한 현실 (2022년)  (0) 2023.05.11
Q) 지금 사용하는 v4.4 (커스터마이즈 개발이 되어있는) -> v4.9 까지의 .patch 를 소스에 적용하면
커널의 안정적인 동작을 보장하는 것은 머지한 개발자 몫인가요?
 
A) 네, 머지한 개발자의 몫입니다. 머지한 다음에 제대로 부팅하지 못하면 스스로 해결해야 합니다.
 
Q) 머지하면서 이해가 가능한가요? 함수 하나 하나보기도 힘든데 ㅜ 그냥 기계적인 머지만 해도 안정적인 커널이 보장될나요? (잘 모름)
 
A) '머지하면서 이해'는 사실 상 불가능합니다. 리눅스 커널을 구성하는 기능이 다양하고 코드의 복잡도가 낮아져서 패치를 보고 바로 이해하는 것은 어렵습니다. '기계적인 머지만 해도 안정적인 커널이 보장'은 거의 불가능합니다. 
 
참고로 커널 버전을 통채로 업그레이드하는 작업은 배포판 업체(레드헷, 구글 안드로이드) 혹은 SoC 업체(퀄컴, 엔비디아) 내부 커널 개발자들이 진행합니다.
 
Q) 기존 v4.4 에서 만든 기능을 기존 v4.4 와 비교, 따로 빼서(우리꺼) 패치 v4.9 기반에서 넣는다. (이게 더 볼 량이 적지 않을까요?)
 
A) 이렇게 진행할 수도 있는데요. 특정 태그의 커밋을 통채로 머지하는 Git Merge를 진행합니다.
 
Q)  커널 코드를 직접 수정하지 않아도 되는 부분은 가능하면 처음부터 모듈 프로그래밍으로 modprobe .*.ko module 을 사용한다.
 
A) 모든 경우에 대응할 수 있습니다. 물론 커널 모듈 드라이버가 인터페이스를 정확히 맞춰서 개발한다면 말이죠.
 
Q) 유저에서 BPF 피쳐를 사용하여 커널 관련 기능을 사용하는 추세라서 (예를 들어, SentinelOne 같은 특정 분야 1위 기업) 커널 코드 수정에 필수적인 부분? 이런 점도 궁금하네요.
 
A) v5.17 부터 BPF 기능을 추가로 확장한 BPF CO-RE를 지원합니다. 조금 더 자세한 내용은 아래 링크를 참고하세요.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

유데미 강사부트캠프 2기 - 8주차 후기  (0) 2023.05.11
[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[에세이] '글로벌 소프트웨어 업체가 인도에 주목하는 이유/인도와 비교했을 때 한국 소프트웨어 개발은?  (0) 2023.05.11
[임베디드 에세이] 한국 시니어 임베디드 개발자의 처참한 현실 (2022년)  (0) 2023.05.11
[에세이] 조직을 이동한 개발자에게 저지르는 관리자의 만행 ①  (0) 2023.05.11
'글로벌 기업이 인도에 주목하는 이유'
 
'글로벌 기업이 인도에 주목하는 이유'는 몇 가지로 요약할 수 있는데요.
 
1. 전 세계 소프트웨어 개발은 이미 인도 개발자가 지배하고 있어요. 아마 전 세계 개발자 중 80% 이상이 인도 개발자이구요. 글로벌 업체의 CTO도 대부분 인도 출신이에요.  
 
인도는 20~30년 전부터 지금 까지 대학교 입학 성적이 가장 뛰어난 순서대로 컴퓨터 공학과를 지원하고 있고요. 전 세계 국가에서 가장 많은 소프트웨어 개발자를 배출하는 나라일꺼에요. 공대 기피 현상이 있던 한국과는 다르죠. 수능 성적 순서대로 의대로 지원했잖아요. 
 
2. 인도 개발자는 영어를 잘한다는 점도 장점이에요. 어느 글로벌 업체에서도 인도 개발자들이 많으니 적응도 잘하고 영어도 잘하니 글로벌 IT 회사가 인도 개발자를 선호하죠.
 
인도는 국가 기관이나 대학교에서 사용하는 공식 언어를 영어로 사용해요. 인도는 각 지역마다 사용하는 언어가 너무 많아서 의사 소통에 문제가 있어 영어를 공식 언어로 써요. 
 
한국 분들 중에 인도 사람의 영어 발음은 알아 듣기 어렵다는 이야기를 종종하는데요. 인도 사람이 말하는 영어 발음을 한국 사람의 영어 발음 보다 미국이나 영국 사람은 훨씬 명확하게 이해한다고 하네요.
 
3. 똑똑한 인도 개발자 중에 정말 열심히 개발하는 친구들도 많아요. 똑똑한데 열심히 까지 한다! 더 잘할 수 밖에 없죠. 예전에 똑똑한 인도 개발자를 만나본 적이 있는데. 정말 차원이 달라요. 자괴감을 느끼게 할 정도였어요.
 
'인도와 비교했을 때 한국 소프트웨어 개발'
 
'인도와 비교했을 때 한국 소프트웨어 개발'은 매우 열악합니다. 최근 들어 소프트웨어 개발자의 대우가 좋아지고 있지만 애플리케이션 중심으로 개발하는 몇 개 개발 업체 밖에 한정되고요. 전반적인 소프트웨어 개발자의 대우는 글로벌 업체와 비교하면 열악한 수준이에요. 물론 대기업 개발자는 어느 정도 대우를 받고 있지만요. 
 
한국은 개발 인력도 적고 의사 소통(영어)이 잘 안되는 경우도 있고, 그래서 글로벌 업체가 한국에 R&D 센터를 오픈한다던가 해서 개발자를 영입하려고 하지 않습니다.
 
인도의 실리콘 벨리
 
인도는 방갈루루와 하이데라바드에 마이크로소프트, 퀄컴, 인텔, facebook, 구글과 같은 IT 업체의 R&D 센터가 전부 있고요. 이 지역을 중심으로 인도 개발자를 영입하고 있어요.
 
방갈루루와 하이데라바드에서 활동하는 많은 인도 개발자가 미국의 실리콘벨리로 진출합니다. 반대로 실리콘 벨리에서 방갈루루와 하이데라바드로 복귀하는 개발자도 많죠.
 
인도 개발자 친구를 만났더니 "젊었을 때 치열하게 미국 샌프란시스코(실리콘 벨리)에서 일하다가 어느 정도 개발자로써 자리를 잡으면 방갈루루와 하이데라바드에서 돌아오는게 트렌드"라고 하네요.
 
개인적으로 여러 인도 친구들과 교류하고 있는데, 다들 잘 지내고 있는 것 같네요.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[후기] '2022 한국 컴퓨터 종합 학술대회 (KCC2022)' - 'ftrace를 이용해 리눅스 커널 정복하기'  (0) 2023.05.11
[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
[임베디드 에세이] 한국 시니어 임베디드 개발자의 처참한 현실 (2022년)  (0) 2023.05.11
[에세이] 조직을 이동한 개발자에게 저지르는 관리자의 만행 ①  (0) 2023.05.11
[오제이튜브] 인터뷰#1: 오픈 소스 배포하면 뭐가 남나요?  (0) 2023.05.11
많은 개발자들이 커리어를 고민합니다. 어느 정도 연차가 쌓이면 다들 개발자 커리어에 대해 고민을 하기 시작하죠. 여러 개발자들이 커리어에 대해 고민하는데요. 조금이라도 도움을 드리는 차원으로 몇 가지 정보를 포스트합니다.
 
1. 한국의 임베디드 개발 업체의 특성과 전문성
 
한국 임베디드 업체의 특징은 너무나 당연한 이야기지만 제품 개발 중심입니다. 제품 스팩과 가격을 결정해 수주를 받는 구조죠. 국가 기관이나 대기업으로부터 수주를 받습니다. IT 생태계를 이루는 다양한 업체와 협업하기도 하죠. 그런데 대부분 개발 업무는 아래 카테고리 중 하나일 겁니다.
 
- 제품 스팩 검토, 데이터 시트 리뷰
- 데이터 시트에 맞게 페리페럴 브링업 및 기본 동작 구현
- 버그 수정 및 안정화
- 인증 테스트를 거친 다음에 제품 개발 완료
 
대부분 업계의 임베디드 제품은 다양한 부품과 소프트웨어를 사용하지만, '리눅스 + Arm 프로세서 + 메모리 + 페리페럴(제품 스팩)' 구조가 대세입니다. 그런데 제품 개발에 초점이 맞춰져 있다 보니 개발자로써 전문성을 키우기 어려운 상황이라는 점이 단점입니다.
 
가장 대표적인 예를 들면요; 1~2개 제품을 리눅스 드라이버와 Arm 프로세서에서 개발했다고 가정하겠습니다. 이 쯤 되면 리눅스 드라이버나 Arm 프로세서에 대해 좀 알 것 같단 느낌이 들어요. 그런데 새로운 프로젝트의 스팩이 만약 리눅스가 아니라 다른 RTOS이고, Arm 프로세서가 아니라 RISC-V 프로세서이라면 어떻게 해야 할까요? 나는 리눅스와 Arm 프로세서 기반으로 개발했으니 이런 프로젝트는 못한다고 거절할 수 있을까요? 대부분 새로운 제품에서 요구하는 RTOS나 RISC-V의 구조를 분석해야 합니다. 수주를 준 업체가 부품을 정하면 이에 맞게 해당 부품(메모리, 페리페럴)을 분석하고 개발하기도 합니다.
 
물론 주니어 개발자 시절에는 다양한 제품을 개발하면 경력에 도움이 됩니다. 개발의 시야를 넓힐 수 있고 다양한 실무 경험을 키울 수 있죠. 사실 업계에서 가장 선호하는 개발자가 이런 유형이기도 합니다. 또한 다양한 RTOS나 CPU 기반으로 개발하면 공통으로 알아야 하는 스킬(TRACE32, JTAG 디버거, 회로도 분석 방법)을 익힐 수 있습니다.
 
하지만 7년 이상 개발 경력이 쌓이면, (본인이 원치 않던) 시니어 개발자의 길로 접어 드는데요. 누군가 "당신이 개발자로써 전문성이 무엇인가"라고 묻는 다면 딱히 내가 뭘 정말 잘 안다고 답하기 어렵습니다. 저도 유사한 상황을 겪었습니다.
 
모든 한국의 임베디드 업체가 제가 언급한 방식으로 운영되지는 않습니다. 나름대로 원천 솔류션을 겸비한 업체도 있겠죠. 시니어 레벨로 들어서면 전문성에 대한 질문을 할 필요가 있습니다.
 
2. 한국의 임베디드 개발자의 테크 트리
 
만약 전문성이 그리 요구되지 않는 제품을 개발하다가 연차가 쌓이면 계속 원하는 개발을 할 수 있을까요? 그렇지 않습니다. 대부분 업체에서 '관리를 하라'고 요구합니다. 어떤 기능에 대해 '기능 리더'를 맡아 달라는 게 아니라, 프로젝트 전반을 책임져 달라고 요구합니다. 문서를 취합하고 고객사의 전화를 받는 역할까지 맡길 원하죠. 동시에 개발도 잘 하라고 합니다. 그게 선임급 개발자가 할 역할이라고 주장하죠.
 
사실 임베디드 업체의 '기술 이사'급 정도의 매니저나 임원은 2000년대 초반에 개발을 했거나 하드웨어 출신 개발자인 경우가 많습니다. 네이버나 카카오 같은 소프트웨어 업체는 팀장이나 임원이 80년 생들로 구성돼 있는데요. 임베디드 업체는 고인물이 많아서 임원이나 매니저들의 연령이 "60년대 중반 ~ 70년대 초반"으로 형성돼 있습니다. 개발과 관리를 동시에 할 수 없다고 불만을 토로하면 이 분들이 잘 들어줄까요? 대부분 "잠꼬대 같은 소리하는군"이라고 무시할 것입니다. 예전에 (20년 전에) 자신이 개발과 관리를 동시에 한 무용담을 1시간 넘게 할 것입니다. 물론 20년 전에 개발했던 RTOS는 전체 소스 라인이 1000 밖에 안되는 심플한 베어 메탈 코드인 경우가 대부분입니다.
 
대부분 개발자들은 관리를 하기 싫어하는데요. 강아지가 목 줄에 이끌리듯이 관리를 하기 시작합니다. 물론 개발을 병행하죠. 시간이 들어 관리 업무에 더 많은 시간을 할애합니다. 이 쯤에 커리어의 갈림길에 들어 섭니다. 
 
   "개발자의 길을 갈 것인가", "관리를 할 것인가" 
 
용기 있게 개발자의 길을 가겠다고 선언한 분이 있지만. 많은 분들이 현실에 타협하면서 관리를 하기 시작합니다. 그런데 개발을 잘하는 캐릭터를 겸비한 분은 관리 능력이 떨어지는 경우가 많습니다. 또한 10여년 전부터 관리를 했던 매니저에게 밀리는 상황도 겪죠. 결국 관리도 못하고 개발도 못해 회사에서 버림 받는 처참한 상황을 맡게 됩니다.   
 
그렇다면 시니어 개발자로써 전문성을 키우려면 어떤 방식으로 개발을 해야 할까요? 이 내용은 다음 포스트에서 업데이트하겠습니다.
 
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[리눅스개발] 커널 버전 업그레이드에 대해서(Q/A)  (0) 2023.05.11
[에세이] '글로벌 소프트웨어 업체가 인도에 주목하는 이유/인도와 비교했을 때 한국 소프트웨어 개발은?  (0) 2023.05.11
[에세이] 조직을 이동한 개발자에게 저지르는 관리자의 만행 ①  (0) 2023.05.11
[오제이튜브] 인터뷰#1: 오픈 소스 배포하면 뭐가 남나요?  (0) 2023.05.11
[글쓰기] 지적으로 게을러 보이는 표현 모음  (0) 2023.05.11
2~3년 정도 개발을 하면 프로젝트를 3~4개 정도 마무리합니다. 그런데 어느 시점이 되면 이런 느낌이 들 수 있어요.
 
    "이 팀은 정말 맞지 않네!"
 
시간이 더 지나면 나중에 "이 팀을 꼭 떠나야 겠다" 확신이 듭니다. 개발자가 회사나 팀을 떠나고 싶어하는 이유는 뭘까요? 예를 들까요?
 
    "조직 책임자가 자신의 성과를 인정해주지 않는다."
    "개발자로써 연량이 전혀 늘지 않는다."
    "연봉이 현저히 낮다!"
 
연봉이 너무 낮아 불만이 심하면 이직을 시도합니다. 그런데 팀장과 사이가 좋지 않거나 역량이 늘지 않는다는 느낌을 받으면 조직을 옮길 수 있습니다. 어느 정도 규모가 있는 회사에서는 팀을 옮길 수 있는 기회를 주기도 합니다. 대기업에서는 '사내 공모'라는 통해 개발자가 조직을 이동할 수 있는 기회를 주죠.
 
가끔 조직 이동을 고민하거나 꼭 조직 이동을 희망하는 개발자들이 있는데요. 이 분들이 참고하면 좋을 것 같아 "팀은 이동한 개발자에게 저지르는 관리자의 만행"에 대한 글을 포스팅합니다. 이런 정보를 모르고 당하면 정말 힘이 쭉 빠지거든요.

 

고과 바닥 깔기
 
팀(조직)을 이동한 개발자(새로운 팀원)가 가장 많이 받는 피해는 뭘까요? 고과를 낮게 받는 겁니다.
 
쓰레기 관리자들이 가장 많이 하는 짓거리는 최근에 조직을 옮긴 개발자의 고과를 바닥으로 까는 겁니다. 다른 조직에서 왔던 개발자를 희생양으로 삼는 거죠. 새로운 조직으로 가셨는데 고과를 깔지 않았다고요? 이 분은 그나마 운이 좋은 편입니다. 
 
한 가지 예를 들까요? 7월에 조직 이동을 했다고 칩시다. 어렵게 조직을 이동한 후, 이동한 조직의 책임자와 첫 면담을 합니다. 업무의 방향이나 목표를 이야기하면서 조직 책임자는 다음과 같이 말합니다.
 
   "우리 팀으로 이동하기 전에 했던 일은 올해 평가에서 제외하는게 낫지 않을까요?"
 
조직을 옮긴 개발자는 이 말을 처음 듣고는 그려려니 합니다. 속으로 "맞아, 예전에 내가 했던 개발 업무는 중요한게 아니지. 새로운 조직에서 해야 할 업무가 중요하지"라고 생각합니다. 이 말은 한 조직 책임자의 속마음을 모른채 말이죠. 그럼 이런 말을 한 조직 책임자의 속마음을 컴파일해볼까요?
 
   "이 새끼! 고과를 까야 겠네. 7월 이전에 아예 한 일이 없다고 하면 되겠구나"
   "7월까지 한 일이 없으니, 연말에 평가할 때 니가 한 일은 1/2 밖에 안된다고 해야 겠다!"
 
개발자가 조직을 옮긴 다음에 바로 Performance를 낼까요? 새로운 방향의 개발을 하면 어느 정도 적응하는 시간이 필요한 경우가 많습니다. 축구 선수 중에 분데스리가에서 프리미어 리그, 혹은 프리미어 리그에서 스페인 라리가 리그로 이적한 선수들도 적응 시간이 필요한 경우가 많죠. 그래서 새로 이동한 조직의 다른 팀원들 보다 Performance를 내지 못할 수도 있습니다.
 
그런데 가끔 이동한 조직에서 열심히 해 다른 동료만큼 일을 해내는 분들도 있습니다. 그런데 조직을 옮긴 개발자는 "내가 하는 일이 Performance를 제대로 내는 수준인가"라고 스스로를 의심하는 경우도 있습니다.
 
개발자가 새로운 팀에서 적응을 하던 말던, 관리자 입장에서 누군가 고과를 바닥으로 깔아야 하는 상황이면 팀에 새롭게 이동한 개발자를 희생양으로 삼는 경우가 있습니다.  
 
원래 조직 책임자는 고과 때문에 항상 골치입니다. 오랫동안 같이 일했던 팀원에게 고과를 잘 챙겨주지 못하는 상황이 많죠. 그런데 새롭게 팀으로 이동한 멤버도 잘 챙겨줄까요? 그렇지 않은 경우가 많습니다. 대부분 아주 좋은 희생양입니다. 그래서 조직을 옮긴 개발자는 고과를 좋게 받을 가능성이 아주 낮습니다.
 
새로운 팀원을 또 다른 조직으로 버리기
 
쓰레기 관리자가 저지르는 만행은 "팀에 새롭게 합류한 개발자를 다른 조직으로 보내버리는 겁니다". "팀에 새롭게 왔는데 왜 다른 팀으로 보내?"란 의문이 들 수 있는데요. 설명을 조금 더 읽어주세요.
 
회사의 운영 방식마다 다르지만 신생 조직이 자주 생기는 경우가 있습니다. 종종 신생 조직이 생기면 다른 팀에 있는 개발자를 착출합니다. 신입 사원이나 경력 사원으로 새로운 조직을 구성하는게 아니라 기존 조직에 있던 개발자로 팀을 꾸리는 것이죠. 
 
팀장(관리자) 입장에서는 신생 조직이 생겨서 팀원 중에 누군가를 보내 달라는 요청을 받게 됩니다. 이럴 때 쓰레기 관리자들이 저지르는 만행은 다음과 같습니다. 
 
    "최근에 자신의 팀으로 이동한 인원을 다른 신생 조직으로 보냅니다." 
 
기존에 같이 데리고 있던 인원은 보내기 싫고. 최근에 이동한 개발자를 다른 조직에 보내니 마음이 덜 불편합니다.
 
관리자(팀장) 입장에서, 다른 팀에서 자신의 팀으로 어떤 개발자가 오고 싶다고 하면 일단 받아 줍니다. 나중에 혹시 버리기 위한 카드로 남겨주는 것이죠. 
 
개발자가 팀을 옮기려는 결정을 할 때 많은 고민을 합니다. 선배를 만나 조언을 구하기도 하죠. 그런데 새로운 팀원을 버리는 카드로 받아주는 관리자가 있다니! 정말 안타까운 현실이죠.
 
설겆이 업무 할당
 
만행 정도는 아니지만, 쓰레기 관리자들이 하는 악습은 새로온 팀원에게 설겆이 업무를 할당하는 겁니다. 
 
프로젝트를 하다보면 누군가는 해야 할 꼭 필요한 업무인데, 다들 꺼려하는 일이 있습니다. 시료 샘플을 조립하거나 꾸준히 이미지를 빌드해서 배포하는 업무가 그 중 하나입니다. 혹은 팀의 총무나 자산을 관리하는 업무도 이 중 하나죠. 쓰레기 관리자는 새로운 팀원에게 이런 일을 시킵니다. 팀을 이동한 개발자는 새롭게 옮긴 팀에서 잘 적응하려고 이런 설겆이 업무를 할당 받아도 일단 열심히 하려는 경우가 많습니다. 이런 개발자를 이용해 먹는 겁니다.
 
팀 내에서 중요한 플래그 십 프로젝트에 아예 투입시키지 않습니다. 기존에 일을 잘하는 개발자들이 있는데 구지 팀에 새로온 멤버에게 시킬 필요가 없다고 생각합니다. 조직을 이동한 개발자에게 개발 난이도가 낮지만 업무량은 많은 프로젝트를 할당하는 경우가 많습니다.
저작자표시

'리눅스 시스템 개발 스토리 > 임베디드 에세이' 카테고리의 다른 글

[에세이] '글로벌 소프트웨어 업체가 인도에 주목하는 이유/인도와 비교했을 때 한국 소프트웨어 개발은?  (0) 2023.05.11
[임베디드 에세이] 한국 시니어 임베디드 개발자의 처참한 현실 (2022년)  (0) 2023.05.11
[오제이튜브] 인터뷰#1: 오픈 소스 배포하면 뭐가 남나요?  (0) 2023.05.11
[글쓰기] 지적으로 게을러 보이는 표현 모음  (0) 2023.05.11
[글쓰기] 중독성이 강한 '-것'  (0) 2023.05.11

+ Recent posts

티스토리툴바