임베디드 개발자로 일하다 보면 어느 순간 정체기가 옵니다. 처음에는 LED를 깜빡이고, UART로 문자를 찍고, 인터럽트를 걸어 동작이 바뀌는 것만으로도 빠르게 성장하는 느낌이 듭니다.
그런데 어느 시점부터 같은 자리를 맴도는 느낌이 듭니다. 코드는 어느 정도 짜는데, 그 코드가 회로·제어·검증과 어떻게 맞물리는지는 잘 보이지 않는 시기입니다.
처음에는 본인이 게을러서 그런가 싶어 야근을 늘려도 보고, 새 프레임워크나 새 MCU를 따라가 보기도 합니다. 그런데 정작 막힌 부분은 그곳이 아닐 때가 많습니다. 한 직무 안에서 코드 줄만 늘려서는 풀리지 않는, 시야의 문제일 가능성이 높기 때문입니다.
주변 주니어 개발자들이 비슷한 지점에서 막히는 것을 보며 정리해 둔 여섯 가지 관점이 있습니다. 비법이라기보다는, 코드 바깥의 시스템을 조금씩 보는 습관에 가깝습니다.
1. 직무 바깥쪽을 한 단계만 더 보기
가장 먼저 권하는 것은 본인 직무에서 한 단계만 바깥을 보는 일입니다. 펌웨어 개발자라면 회로 쪽을 한 단계, 회로 엔지니어라면 펌웨어 쪽을 한 단계 더 보는 식입니다. 깊이만 파는 것은 분명 중요하지만, 어느 시점이 지나면 깊이만으로는 풀리지 않는 문제가 늘어납니다.
예를 들어 펌웨어에서 이상 동작이 보일 때, 코드만 들여다보면 답이 안 나오는 경우가 의외로 많습니다. 그라운드가 길게 돌아가는 PCB 패턴, 부족한 디커플링 커패시터, 엉뚱한 게이트 저항 값이 원인이라면 코드를 아무리 다듬어도 같은 증상이 반복됩니다. 회로를 설계하는 입장에서도 마찬가지입니다. 펌웨어가 어느 시점에 어떤 라인을 토글하는지 모른 상태로 그린 회로는, 동작은 하지만 마진이 부족한 회로가 되기 쉽습니다.
후배 개발자에게 자주 권하는 표현이 "옆 직무의 언어를 알아듣는 정도까지만이라도 가보자" 입니다. 직접 회로를 그릴 수 있을 필요는 없지만, 동료가 회로도를 펼쳐 놓고 설명할 때 주요 노드의 의미가 보이는 정도. 펌웨어 동료가 인터럽트 우선순위 이야기를 할 때 흐름이 떠오르는 정도면 충분합니다. 이 정도만 되어도 회의 자리에서 오가는 단어가 다르게 들리기 시작합니다.
시스템 전체가 어떻게 돌아가는지 한 번이라도 직접 그려보는 경험은 의외로 큰 차이를 만듭니다. 본인 직무가 전체 어디쯤에서 어떤 입력과 출력을 가지는지 한 페이지로 정리해 보는 것만으로도, 평소에 흘려 듣던 말이 다르게 들립니다. 이 한 단계의 시야 확장이 정체기 초입에서 가장 효과가 좋은 편입니다.
2. 데이터시트와 레퍼런스 매뉴얼을 직접 읽기
검색과 예제 위주의 학습은 빠른 출발에는 분명 좋습니다. 그런데 어느 순간부터 비슷한 패턴만 반복되고 깊이가 잘 쌓이지 않는다는 느낌이 든다면, 데이터시트와 레퍼런스 매뉴얼을 직접 펼쳐 보는 습관을 들이는 편이 도움이 됩니다.
데이터시트 초반부에 배치되는 경우가 많은 Block Diagram은 그 부품의 정체성을 한 장으로 보여 줍니다. 어떤 입력이 들어와서 어떤 블록을 거쳐 어떤 출력이 나가는지, 어떤 클럭과 어떤 전원이 어디로 들어가는지가 모두 한 그림에 담겨 있습니다. 이 그림을 천천히 따라가는 것만으로도, 그 칩이 어떤 용도로 설계되었는지가 눈에 들어옵니다.
레퍼런스 매뉴얼의 레지스터 표는 처음엔 부담스럽게 느껴집니다. STM32 같은 경우 1500페이지가 넘는 문서도 흔합니다. 그런데 자세히 보면 챕터 단위로 거의 독립적으로 쓰여 있어서, 처음부터 끝까지 읽을 필요는 전혀 없습니다. 지금 다루는 페리페럴 챕터만 펼쳐서 레지스터 비트의 의미를 한 번 따라가 보면, 그 다음부터는 다른 페리페럴도 비슷한 패턴으로 읽힙니다.
처음 몇 번은 시간이 더 걸립니다. 라이브러리 함수 한 줄로 끝낼 일을 굳이 매뉴얼까지 펼쳐서 확인하는 게 비효율적으로 느껴지기도 합니다. 그런데 그 시간이 누적되면서, 라이브러리가 어디까지 해주고 어디서부터는 본인이 책임져야 하는지 감이 생깁니다. 이 감각이 있는 사람과 없는 사람은 디버깅 속도부터 차이가 납니다. 결국 일차 자료를 읽을 줄 아는 것이 임베디드 개발자의 가장 큰 무기 중 하나라는 생각이 듭니다.
3. 측정과 디버깅 능력
코드를 잘 짜는 능력보다, 동작이 의도와 다를 때 측정으로 가설을 세우고 검증하는 능력이 결국 차이를 만듭니다. 임베디드 시스템은 코드 한 줄과 실제 동작 사이에 회로, 전원, 타이밍, 노이즈 같은 변수가 많아서, 책상 앞에서 코드만 노려보고 있어서는 풀리지 않는 문제가 자주 생깁니다.
오실로스코프, 로직 분석기, 프로토콜 분석기 같은 기본 장비의 사용법을 익혀 두는 편이 좋습니다. 모든 기능을 다 다룰 필요는 없습니다. 신호 한 채널을 안정적으로 띄우고, 트리거를 원하는 지점에 거는 정도. 로직 분석기로 SPI나 I2C 같은 통신을 캡처해서 디코딩해 보는 정도면 출발로 충분합니다. 이 정도 능력만 있어도 디버깅 시간이 크게 줄어듭니다.
장비를 다룰 줄 아는 것보다 더 중요한 것은, 측정 결과를 펌웨어 동작과 연결해 해석하는 사고입니다. 파형을 보면서 "이 시점에 인터럽트가 들어왔어야 하는데 왜 늦었지", "이 라인이 왜 풀업이 약해 보이지" 같은 질문을 떠올릴 수 있어야 측정이 의미를 가집니다. 단순히 파형을 찍었다는 사실만으로는 디버깅이 끝나지 않습니다.
후배 개발자들에게 자주 하는 말이 "찍어 봐야 안다" 입니다. 머리로 추정한 동작과 실제 파형이 달라서 놀라는 경험을 몇 번 해 보면, 그 다음부터는 추측 대신 측정을 먼저 떠올리게 됩니다. 추측에만 의존하던 사람이 측정 기반으로 사고하기 시작하는 시점이, 한 단계 성장하는 분기점이라고 느낀 적이 많습니다.
4. 결정의 근거를 글로 남기기
의외로 가장 저평가되어 있다고 느끼는 습관은, 결정의 근거를 글로 짧게라도 남기는 일입니다. "왜 이 부품을 골랐는지", "왜 이 게이트 저항 값으로 바꿨는지", "왜 이 인터럽트 우선순위로 설정했는지" 같은 항목을 두세 줄짜리 메모로라도 적어 두는 습관입니다.
당시에는 너무 당연해 보이는 선택이라도, 6개월만 지나면 본인이 왜 그 선택을 했는지 잘 떠오르지 않습니다. 부품 단종 이슈가 생기거나, 이상 동작이 발견되어 다시 그 회로로 돌아왔을 때, 결정의 근거가 남아 있는지 여부에 따라 들어가는 시간이 크게 달라집니다. 근거가 없으면 결국 모든 가능성을 다시 검토해야 합니다.
협업과 이직 자리에서도 이 기록은 가장 강력한 자산이 됩니다. 면접에서 "이런 프로젝트를 했습니다"라고 말하는 사람은 많지만, "이 부분에서 이런 트레이드오프가 있었고, 이런 이유로 이 방향을 선택했습니다"라고 설명할 수 있는 사람은 의외로 드뭅니다. 후자는 결정의 근거를 평소에 글로 정리해 둔 사람일 가능성이 높습니다.
거창한 양식은 필요 없습니다. 위키든, 사내 노션이든, 텍스트 파일이든 본인이 다시 찾을 수 있는 곳이면 됩니다. 한 결정당 두세 줄, 길어도 한 단락. 처음에는 어색해도 한두 달만 꾸준히 하면 본인의 사고 흐름이 그대로 정리된 자료가 쌓입니다. 임베디드 개발자에게 이 정도로 비용 대비 효과가 큰 습관은 흔치 않다고 느낍니다.
5. 작은 프로젝트로 통합 경험
회사에서 맡는 직무는 생각보다 좁게 잘려 있습니다. 누군가는 모터 제어 알고리즘만, 누군가는 진단 통신 스택만, 누군가는 회로 검증만 담당하는 식입니다. 이런 환경에서 오래 일하면 본인이 맡은 부분은 깊어지지만, 시스템 전체를 한 번도 끝까지 가 본 적이 없는 상태가 되기 쉽습니다.
시간을 내서라도 회로 설계, PCB 발주, 펌웨어 작성, 동작 검증까지 한 번 끝까지 가 본 사람과 그렇지 않은 사람의 시야 차이는 꽤 큽니다. 본인이 PCB를 그려 보면 부품 배치와 라우팅이 펌웨어 동작에 어떤 영향을 주는지 체감하게 되고, 직접 발주해 보면 양산에서는 왜 부품 선정과 검증에 더 많은 검토가 필요한지 감을 잡게 됩니다.
규모는 적당히 작게 잡는 편이 좋습니다. 너무 야심 차게 시작하면 끝까지 가지 못하고 멈추는 경우가 많습니다. 저전압·소전력 범위의 학습용 모터 드라이버, 센서 보드, 간단한 전원 모듈 같은 주제는 자료도 많고, 한 번 끝내고 나면 직무에 도움이 되는 경험이 쌓이는 좋은 출발점입니다. 전동킥보드나 BMS처럼 에너지와 안전 리스크가 큰 주제는 보호회로, 전원 차단, 시험 환경을 갖춘 범위에서 다루는 편이 안전합니다.
목표는 결과물의 완성도가 아니라 한 사이클을 끝까지 돌려 본다는 데에 두는 편이 낫습니다. 전원이 들어와서, MCU가 부팅되고, 센서를 읽고, 액추에이터를 움직이고, 그 결과를 다시 보드에서 확인하는 흐름을 본인이 끝까지 책임져 본 경험. 이 한 사이클을 완주해 보면, 그 이후부터 회사 업무에서 마주치는 부분 작업들이 전체 그림 위에 자연스럽게 얹힙니다. 이 차이는 시간이 지날수록 더 크게 벌어집니다.
6. 표준 문서·기술 영문 문서 읽기에 익숙해지기
임베디드 분야의 핵심 자료는 대부분 영문입니다. 데이터시트, 칩 회사의 Application Note, IEEE 논문, ISO나 IEC 같은 국제 표준 문서는 원문 영문 자료가 먼저 업데이트되거나 더 자세한 경우가 많습니다. 한국어로 잘 정리된 자료도 분명 있지만, 어느 시점부터는 한국어 자료만으로는 깊이의 한계가 보이기 시작합니다.
영문이라고 해서 처음부터 잘 읽힐 필요는 없습니다. 처음에는 한 페이지에 모르는 단어가 한가득이고, 한 챕터 읽는 데 한참 걸리는 게 자연스럽습니다. 그런데 신기하게도 분야가 한정되어 있다 보니, 같은 영역의 문서를 두세 권만 읽어 봐도 반복해서 등장하는 단어가 정해져 있습니다. 그 단어들에 익숙해지는 순간부터 읽는 속도가 부쩍 빨라집니다.
처음 시작은 본인 업무와 가장 가까운 칩의 데이터시트나 Application Note 한 편을 골라, 천천히 끝까지 읽어 보는 정도가 좋습니다. 모르는 용어는 그 자리에서 가볍게 검색해 보는 정도면 충분합니다. 어색하게 읽히던 문장이 어느 순간 자연스럽게 의미로 잡히는 경험이 한두 번 쌓이면, 그 다음부터는 영문 자료에 대한 거부감이 줄어듭니다.
표준 문서는 또 다른 결을 가지고 있습니다. 표현이 건조하고, 정의가 엄격해서 처음에는 더 어렵게 느껴집니다. 다만 표준 문서를 한 번이라도 직접 펼쳐서 정의를 확인해 본 사람은, 인터넷 글에서 잘못 인용된 내용이 보일 때 바로 의심할 수 있게 됩니다. 일차 자료에 직접 접근하는 능력은 임베디드 개발자에게 평생 가는 자산이 되는 편입니다.
흔한 함정
성장 이야기를 하다 보면 자연스럽게, 자주 보이는 함정도 같이 떠오릅니다. 첫 번째는 "도구가 부족하다"는 이유로 시작을 미루는 경우입니다. 오실로스코프가 없어서, 좋은 개발 보드가 없어서, 라이선스가 없어서 시작을 못 한다고 말하는 경우가 많습니다. 그런데 막상 좋은 도구가 손에 들어와도 시작을 못 하는 사람은 그대로인 경우가 많습니다. 처음에는 가지고 있는 것으로 시작하고, 필요해지는 시점에 도구를 보강하는 순서가 자연스럽습니다.
두 번째 함정은 "이론보다 일단 만들기" 일변도입니다. 손을 빨리 움직이는 것은 분명 좋습니다. 그런데 어느 시점부터는 만든 결과를 해석하기 위한 이론적 토대가 필요해집니다. 매번 비슷한 함정에 다시 걸리고 있다면, 만들기와 이론 학습의 비중을 한 번쯤 점검해 보는 편이 좋습니다. 손과 머리가 번갈아 가며 움직일 때 가장 빠르게 성장합니다.
세 번째 함정은 "회사에서 시키는 일만 한다"는 태도입니다. 회사 업무를 잘 해내는 것은 당연히 중요합니다. 다만 회사 직무는 앞서 말했듯 좁게 잘려 있는 경우가 많아서, 그 안에만 머물면 5년이 지나도 시야가 늘어나지 않을 수 있습니다. 일주일에 한두 시간만이라도 본인 관심 주제를 따로 파보는 시간을 가지는 편이, 길게 보면 회사에서의 평가에도 더 도움이 됩니다.
마지막 함정은 "다 알고 나서 하겠다"는 완벽주의입니다. 임베디드는 워낙 영역이 넓어서, 다 알고 나서 시작하려고 하면 영원히 시작하지 못합니다. 모르는 부분을 그때그때 채우면서 일단 한 사이클을 돌려 보는 쪽이, 결과적으로 더 많이 배웁니다. 모름을 인정하고 시작하는 용기가, 의외로 가장 강력한 성장 도구라는 생각이 자주 듭니다.
함께 읽으면 좋은 글
공식 참고 자료
임베디드 개발을 공부할 때는 블로그 글이나 강의만 보지 말고, 반도체 회사와 코어 벤더가 제공하는 공식 문서도 같이 보는 것이 좋습니다. 아래 자료는 ARM 계열 MCU와 STM32를 공부할 때 출발점으로 삼기 좋은 공식 링크입니다.
마무리
성장은 한 번에 오지 않고 계단식으로 옵니다. 한참을 평지처럼 느껴지다가, 어느 날 갑자기 한 단 올라가 있는 본인을 발견하는 식입니다. 정체기처럼 느껴지는 시기는 사실 다음 계단으로 가기 전 평지일 뿐이라는 생각으로 보면, 그 시기를 너무 무겁게 받아들이지 않아도 되는 것 같습니다.
여기 정리한 여섯 가지는 어느 것 하나도 단기간에 끝나지 않습니다. 다만 본인 페이스로 하나씩 쌓아가는 것이, 결국 가장 빠른 길인 경우가 많았습니다. 처음부터 여섯 가지를 모두 바꿀 필요는 없습니다. 지금 막힌 문제가 디버깅인지, 회로 이해인지, 문서 읽기인지 하나만 골라 다음 프로젝트에 반영해 보면 됩니다.