AI가 빨라질수록 주니어는 느려진다

시니어는 바쁘고, 주니어는 한가하다

작은 개발회사를 운영하고 있다. 배터리 관리 시스템(BMS), 자동차에 들어가는 소프트웨어, Linux나 RTOS 기반의 임베디드 장치를 만드는 회사다. 학교에서 잘 가르치지 않는 기술들을 다루는, 사람들이 가기 꺼려하는 시장이다.

요즘 고민이 하나 생겼다. 기술이 아니라 사람 문제다.

회사에 새로 들어온 사람들이 점점 할 일이 없어지고 있다. 정확히 말하면, 의미 있는 일이 없어지고 있다. 새로운 기술을 익히고 실력을 키울 기회가 아니라, 허드렛일만 돌아온다. 허드렛일을 하다 보면 실력은 안 늘고, 실력이 안 늘면 더 중요한 일을 맡기기 어렵고, 결국 시간만 때우는 시간이 늘어난다.

반면 시니어들은 그 어느 때보다 바쁘다. 그 많던 일들을 경력 많은 선배들이 다 가져가서, 혼자서 또는 AI 에이전트와 함께 처리하고 있다. 시니어 입장도 이해한다. 주니어를 가르치면서 함께 하려면 시간이 두 배로 걸리고, 스트레스도 배로 받는다. 차라리 내가 AI랑 하는 게 빠르다는 판단이 합리적인 상황이 되어버렸다.

AI가 만든 역설

AI가 우리 같은 임베디드 업계에도 빠르게 들어오고 있다. 사람들이 가기 꺼려하는 시장이라 오히려 AI의 도움이 크다. 시니어가 AI와 함께 일하면 생산성이 확연히 올라간다. 도메인 지식은 시니어 머릿속에 있고, 코드 작성과 반복 작업은 AI가 해주니까.

문제는 이 생산성 향상이 주니어의 존재 이유를 잠식한다는 것이다.

예전에는 시니어가 설계하고 주니어가 구현하는 분업이 자연스러웠다. 주니어는 구현 과정에서 삽질하고, 질문하고, 코드 리뷰를 받으면서 성장했다. 그 삽질 자체가 교육이었다. 그런데 이제 그 구현을 AI가 더 빠르고 정확하게 한다. 시니어 입장에서는 주니어에게 일을 주고, 설명하고, 리뷰하는 시간에 AI와 끝내는 게 효율적이다.

결과적으로 이런 악순환이 만들어졌다.

AI가 시니어의 생산성을 올린다
주니어에게 돌아갈 "의미 있는 일"이 줄어든다
주니어는 실력이 안 늘고, 동기가 떨어진다
시니어는 더더욱 주니어에게 일을 맡기기 어려워진다
시니어는 더 많은 일을 AI와 함께 처리한다
다시 1번으로

AI 이전에도 비슷한 구조는 있었다. 하지만 AI가 이 사이클의 속도를 극적으로 올려버렸다.

한국 중소 임베디드 업계의 특수성

이 문제가 더 뼈아픈 이유가 있다.

첫째, 학교에서 안 가르친다. RTOS나 BMS를 다뤄봤길 기대하는 건 욕심이다. 컴퓨터 구조까지는 힘들더라도, 컴퓨터공학과를 나왔으면 C 언어 정도는 익혀서 왔으면 좋겠다는 게 솔직한 바람인데, 현실은 그렇지 못하다. Python은 써봤어도 포인터를 다뤄본 적 없는 신입이 들어오면 기초부터 가르쳐야 한다. 그 간극이 너무 크다. AI가 이 간극을 메워줄 수 있지만, "무엇을 배워야 하는지"를 아는 것 자체가 경험에서 나오기 때문에 완전한 해결은 아니다.

둘째, 교육에 투자할 여유가 없다. 대기업이라면 신입 교육 프로그램을 3개월, 6개월 운영할 수 있다. 중소기업에는 그런 여유가 구조적으로 없다. 바로 실무에 투입해야 하는데, 실무를 할 수 있는 수준이 되려면 오래 걸린다. 이 모순 사이에서 주니어는 어정쩡한 위치에 놓인다.

셋째, 시장 자체가 작다. 임베디드, 특히 BMS나 자동차 소프트웨어 쪽은 한국에서 인력 풀이 넉넉하지 않다. 경력자를 구하기도 어렵고, 신입을 키우기도 어렵고. 그래서 결국 소수의 시니어에게 부하가 집중되는 구조가 고착된다.

AI에게 물어봤다

이 고민을 AI에게 던져봤다. 내 상황을 설명하고, 뭔가 방법이 없겠냐고. AI가 제안한 것들이 몇 가지 있었는데, 흥미로운 것들이 있었다.

"AI가 못 만지는 영역을 주니어에게 줘라."** 임베디드는 웹 개발과 다르다. AI가 BMS 펌웨어를 짜줄 수는 있어도, 오실로스코프로 신호를 찍고 타이밍 문제를 잡는 건 못 한다. 주니어에게 하드웨어 디버깅, 테스트, 검증의 오너십을 주면, 허드렛일이 아니라 AI가 가장 약한 영역에서 실전 경험을 쌓을 수 있다는 것이다. 이건 꽤 날카로운 지적이라고 생각했다. 임베디드가 가진 물리적 세계와의 접점**이 오히려 교육의 무기가 될 수 있다.

"시니어의 역할을 '선생님'에서 '리뷰어'로 바꿔라." 주니어에게 작지만 실제 제품에 필요한 문제를 던져주고, 주니어는 AI와 함께 풀어보게 하고, 시니어는 결과물만 리뷰한다는 구조다. 시니어의 시간 투입이 "교육 8시간"에서 "리뷰 1시간"으로 줄어든다. AI가 인내심 무한한 조교 역할을 하는 셈이다. 핵심은 문제의 정의와 리뷰의 질에 시니어의 경험을 집중하는 것.

"문서화를 교육 도구로 활용해라." 주니어에게 기존 시스템을 AI와 함께 분석하고 문서화하는 업무를 맡기면, 시스템을 이해해야 올바른 질문을 던질 수 있으므로 자연스럽게 학습이 된다. 동시에 산출물인 문서는 회사의 기술 부채를 해소하는 실질적 가치가 있다.

"주니어를 AI 도구 전문가로 키워라." 시니어는 도메인 지식이 깊지만, 새로운 AI 도구 활용에는 상대적으로 느릴 수 있다. 주니어에게 AI 파이프라인 구축, 자동화, 프롬프트 엔지니어링 역할을 주면, 즉시 가치를 기여할 수 있고 시니어의 생산성을 높이는 증폭기 역할도 된다.

아직 답은 없다

솔직히 말하면, 이 제안들을 듣고 "아, 이거다!" 하는 순간은 없었다. 각각 일리는 있지만, 우리 회사의 구체적인 상황에 바로 적용할 수 있는 것과 아닌 것이 있다.

다만, AI의 제안들을 관통하는 하나의 흐름은 느꼈다. 주니어의 역할을 "시니어의 축소판"이 아니라 완전히 다른 것으로 재정의해야 한다는 것. 예전에는 주니어가 시니어가 하는 일을 작은 규모로 따라하면서 성장했다. 이제 그 경로 위에 AI가 서 있다. 같은 길로는 안 된다. 다른 길을 찾아야 한다.

임베디드라는 분야가 물리적 세계와 맞닿아 있다는 점이, 어쩌면 다른 소프트웨어 분야보다 유리한 지점일 수 있다. AI가 코드를 짜줄 수 있어도, 보드 위의 LED가 왜 안 켜지는지, CAN 버스에서 왜 패킷이 유실되는지는 직접 손으로 잡아야 한다. 그 접점에서 주니어가 자랄 수 있는 공간이 남아 있을지도 모른다.

사실 당장 눈앞에 놓인 우리 회사의 문제를 풀어내는 것도 중요하지만, 조금만 떨어져서 보면 이게 우리만의 문제가 아닐 거라는 생각이 든다. 임베디드든 웹이든, 크든 작든, AI가 시니어의 생산성을 올리는 모든 조직에서 비슷한 구조가 만들어지고 있을 것이다. 그게 오히려 더 두렵다.

엔지니어라는 사람들은 원래 문제가 생기면 해결 방안을 찾아내는 DNA가 있다. 버그가 나면 원인을 추적하고, 시스템이 느리면 병목을 찾고, 요구사항이 바뀌면 설계를 다시 한다. 그런데 "사람이 자라지 않는 구조"라는 문제 앞에서는, 그 DNA가 잘 작동하지 않는다. 코드는 고치면 되지만, 사람과 조직의 문제는 디버깅이 안 된다.

구체적으로 어떤 식으로 도입할지는 좀 더 고민해보고 후속 글로 정리해보려 한다. 지금은 문제를 명확하게 인식한 것만으로도 한 발짝은 나아갔다고 생각한다. 답이 나오면 좋겠고, 나오지 않더라도 이 고민을 공유하는 것 자체에 의미가 있지 않을까.