1000페이지 영어 스펙 문서, 번역은 구글 번역기

1000페이지 영어 스펙 문서, 번역은 구글 번역기

1000페이지 영어 스펙 문서, 번역은 구글 번역기 아침 9시, 스펙 문서와의 싸움이 시작된다 출근한다. 피곤하다. 어제 테스트는 또 실패했다. 화면을 켠다. 메일함에 스펙 문서 링크가 떠 있다. Reference Manual. 1047페이지. PDF 파일명에는 'v2.3_EN'이라고 적혀 있다. 한국어 버전? 없다. 당연하지, 있을 리가. 팀장이 어제 말했다. "이 칩셋 쓰려고 하니까 이거 한 번 읽어봐. 핵심만." 핵심만. 1047페이지 중 핵심이 뭔데. 일단 열어본다. Chapter 1. Overview. Chapter 2. Pin Configuration. Chapter 3. Electrical Characteristics. 여기까진 괜찮다. 그림도 있고 테이블도 있고. 그런데 Chapter 5. Register Description부터 지옥이 시작된다. "Register 0x24: CTRL_REG_A (Control Register A)" 좋다. "Bit 7-5: Reserved. The bit must be set to 0." 확인했다. "Bit 4: FS1. Full-scale selection. Setting this bit will enable the full-scale mode operation as specified in the electrical characteristics section." 음. 여기부터 애매한데. 번역기를 켠다. "비트 4: FS1. 풀 스케일 선택. 이 비트를 설정하면 전기 특성 섹션에 지정된 대로 풀 스케일 모드 작동을 활성화합니다." 뭔 소린데. "Full-scale mode operation as specified in the electrical characteristics section." 여기서 'as specified'가 뭔지 알려면 electrical characteristics를 다시 봐야 한다. 그걸 번역기로 돌리면 또 다른 용어가 나온다. 그 용어를 다시 찾아봐야 한다. 악순환. 10시, 일단 구글 번역기를 믿어본다 신입 때는 달랐다. 신입 때는 영어를 열심히 공부했다. 회사에서 영어 교육도 해줬고. 비즈니스 영어. Technical English. 근데 배운 게 다였다. '설정하다' '활성화하다' 이런 건 번역기도 한다. 문제는 칩 제조사 엔지니어들의 영어다. 그들은 데이터시트를 쓸 때 최대한 간결하게 쓴다. 한 문장에 정보를 때려 넣는다. 중괄호도 많고, 약자도 많고, 암묵적인 가정도 많다. "The register must be read back after programming to ensure proper synchronization." 번역기: "프로그래밍 후 레지스터를 읽어 적절한 동기화를 보장해야 합니다." 그런데 이게 뭔 뜻인가. '레지스터를 읽어'는 뭐다. SPI로 읽어야 한다는 건가. 아니면 메모리 주소로 읽어야 한다는 건가. '동기화'는 뭔가. 칩 내부의 state machine과 host processor 사이의 동기화인가. 아니면 내부 clock과의 동기화인가. 영어 원문을 다시 읽어도 애매하다. 그럼 이제 뭘 한다. Slack에 올린다. "이거 뭔 뜻일까요?" 팀원 이준호가 답한다. 20분 뒤에. "아 이건 한 번 쓰고 나서 SPI로 읽어서 값이 제대로 들어갔는지 확인하라는 뜻 같은데요. 옆 회사 때 본 데이터시트도 이 칩이었는데 그렇게 했어요." '옆 회사 때 본 데이터시트'. 이게 임베디드 개발자의 성장이다. 데이터시트를 읽을 때 영어 능력이 아니라 경험치를 쓴다. 예전에 본 칩 중에 비슷한 게 있었나. 그렇다면 그건 뭐였나. 그리고 그건 왜 그렇게 동작했나. 구글 번역기의 한계다. 11시 30분, 번역기를 버린다 일단 정해진 시간이 있다. 점심 12시. 그 전에 끝낼 게 있는 데 아직 Register Description 20%밖에 안 봤다. 빠르게 스캔한다. Bit 3, Bit 2, Bit 1, Bit 0까지 모두 같은 방식이다. 각 비트마다 "Setting this bit will..."이 반복된다. 이제 번역기를 켜지 않는다. 그냥 원문을 읽는다. 한국어가 없다면, 영어를 바로 이해하는 수밖에 없다. 이건 새로운 기술이 아니다. 적응이다. 3년 차 때부터 시작했다. Reference Manual을 펼칠 때 한국어 번역을 찾지 않는다. 원문에서 바로 구조를 찾는다. Bit [7:5]라고 쓰여 있으면 7번 비트부터 5번 비트까지라는 건 번역이 필요 없다. R/W라고 쓰여 있으면 Read/Write다. 한국어 대사전보다는 기술 용어 사전이 필요해진다. 예: "LSB First"는 "Least Significant Bit First"다. 번역하면 '최하위 비트 우선'. 근데 이건 번역하는 순간 더 복잡해진다. 그냥 LSB라고 부른다. 같은 팀의 송미영 개발자는 어제 말했다. "한국어 번역본을 기다리기보다 영어 원문에 익숙해지는 게 빠르더라고요. 처음엔 힘들지만." 그 말이 맞다.12시 30분, 한국 자료를 찾아본 지 6개월이 지났다 점심을 먹으며 유튜브를 본다. 'STM32 Reference Manual 한국어' 검색 결과는 없다. 대신 '우리 회사 선배가 쓴 코드 예제'라는 수동적 학습 방법에 의존한다. 하드드라이브에 있는 폴더: /Legacy_Project/2019_Smart_Lock/firmware/src 여기엔 내가 입사하기 전 개발된 코드다. // Written by Park_JH (2019-08-14) // Reference: STM32L152 Reference Manual // Page 287: RTC_CR Register Description uint32_t rtc_init(void) { // Enable PWR clock RCC->APB1ENR |= RCC_APB1ENR_PWREN; PWR->CR |= PWR_CR_DBP; // This is critical: must read back after write // See page 312 of RM uint32_t dummy = PWR->CR; (void)dummy; return 0; }주석이 있다. "Page 312 of RM" 이 사람은 이 코드를 쓸 때 Reference Manual 312페이지를 봤다는 뜻이다. 6년 전에. 그리고 지금 그 페이지가 어디 있는지 몰라도, 이 코드를 복사+붙여넣기 하면 작동한다. 한국어 자료가 없는 대신 '선배 개발자의 코드'가 한국어 자료다. 이게 임베디드 회사의 생태계다. 문서화는 없다. 대신 '이미 작동하는 코드'가 있다. 14시, 구글 번역기의 두 번째 쓸모 그렇다고 구글 번역기가 완전히 쓸모없는 건 아니다. 쓸모 있게 사용하는 방법이 있다. 1단계: 원문을 3번 읽는다 "The FIFO buffer can be configured to generate an interrupt when the data count exceeds the programmable threshold level specified in the FIFO_THR register." 1차 읽음. 뭔 소린지 모름. 다시 읽음. FIFO. 버퍼. 임계값. 뭔가 관련이 있는 것 같다. 다시 읽음. 아, FIFO가 어느 정도 찼을 때 인터럽트를 날린다는 뜻인가? 2단계: 그 다음에 번역기를 킨다 번역기: "FIFO 버퍼는 데이터 개수가 FIFO_THR 레지스터에 지정된 프로그래밍 가능한 임계값을 초과할 때 인터럽트를 생성하도록 구성할 수 있습니다." 내 이해: FIFO가 FIFO_THR 이상으로 차면 인터럽트 발생. 이 값은 프로그래밍으로 설정 가능. 3단계: 코드로 검증한다 // FIFO threshold = 16 bytes CHIP->FIFO_THR = 16;// Enable FIFO interrupt CHIP->INTR_ENABLE |= INTR_FIFO_FULL;작동했다. 내 이해가 맞았다. 이게 올바른 방법이다. 번역기에만 의존하면 틀린다. 원문을 이해해야 번역기를 제대로 쓸 수 있다. 아이러니다. 15시, 중국산 칩의 악몽 어제 하드웨어 팀에서 메시지가 왔다. "이번에 BOM cost 깎으려고 중국산 센서 쓰기로 결정했습니다. 사용 가능한지 펌웨어로 확인해주세요." 첨부 파일: XC1234_Datasheet_ZH_V1.2.pdf 확장자는 PDF인데 전부 중국어다. 구글 번역기를 켜본다. 중국어 → 영어: "50% 확률로 맞음. 50% 확률로 뭔 소린지 몰라." 중국어 → 한국어: "70% 확률로 틀림. 문법이 산산조각." 그럼 이제 뭘 한다. 사진을 찍어서 온라인 이미지 번역기에 올린다. "寄存器 0x12: 控制寄存器" 이미지 번역기: "Register 0x12: Control Register" 그리고 영어 번역기로 다시 돌린다. "Register 0x12: Control Register" 번역기: "레지스터 0x12: 제어 레지스터" 원점이다. 팀장에게 메일을 보낸다. "중국산 센서 사용이 가능하지만, 데이터시트가 중국어만 있어서 약 2주 정도 더 필요할 것 같습니다." 회신: "알겠습니다. 그래도 빨리 부탁합니다. BOM cost가 30% 줄어듭니다." 30%. 2주 vs 30% cost reduction. 회사가 뭘 선택할지는 뻔하다.16시, 그래도 살아가는 방법 Slack에서 임베디드 커뮤니티 링크를 찾는다. Reddit의 r/embedded EEVblog의 Electronics Design Forum STM32 공식 포럼 이 곳들엔 같은 고민을 하는 사람들이 있다. "Has anyone used the XC1234 sensor? The datasheet is only in Chinese..." 21분 뒤에 답이 온다. "Yeah, that's the old model. Use the XC1234A instead. English datasheet available on their official site." 구글 번역기보다 빠르다. 이제 이게 내 방법이다.영어 원문 읽기 구글 번역기로 검증 해석이 안 되면 온라인 커뮤니티에 물어보기 코드로 테스트하기 안 되면 오실로스코프로 파형 확인이 과정은 길다. 어떨 때는 하나의 레지스터 설정이 3시간이 걸린다. 그런데 이제 익숙하다. 펌웨어 개발자는 본래 이렇게 산다. 혼자 영어 문서와 싸우면서. 아무도 도와주지 않는다. 마케팅 팀은 한국어로 된 기획안을 준다. 하드웨어 팀은 한국어로 설명한다. 펌웨어 팀은 영어로 된 데이터시트를 받는다. 그리고 혼자 이해한다. 17시, 결론 대신 내일 계획 오늘도 Register Description 40%까지만 봤다. 내일 또 이어서 본다. 내일도 구글 번역기를 키고 닫는다. 계속해서 원문을 읽는다. 그리고 6개월 뒤쯤이면 이 칩의 모든 레지스터를 외우지 않아도 직관적으로 이해할 것이다. 이게 경험이다. 한국 대학교 임베디드 강의에선 안 배운다. 교재는 모두 한국어고, 한국 교수도 영어 문서를 피한다. 그래서 졸업생은 회사 와서 깜짝 놀란다. "아, 우리 이 칩 쓰는데 이 영어 문서 한 번 보고 시작해." 그 순간부터가 진짜 펌웨어 공부다. 불행인가. 그냥 일이다.내일도 출근해서 1000페이지를 펼칠 것이다. 구글 번역기는 여전히 50%만 맞출 것이다. 근데 괜찮다. 나머지 50%는 경험과 코드와 오실로스코프로 채운다.

월요일 아침, 어제 밤 테스트가 또 실패했다

월요일 아침, 어제 밤 테스트가 또 실패했다

월요일 아침, 또 실패했다 지난 금요일 오후 5시. 나는 한 가지 결정을 했다. 이번 주말은 펌웨어 테스트에 바치겠다고. 양산 일정이 2주 남았고, 메모리 누수 문제가 자꾸만 나타나고 있었다. 재현율도 일정하지 않아서 더 답답했다. 혹시 특정 시나리오에서만 발생하는 건 아닐까 싶어서, 토요일 밤 10시부터 테스트 케이스를 짜기 시작했다. 테스트 자동화 스크립트를 짜고, 보드에 펌웨어를 올렸다. 그리고 돌렸다. 50번. 100번. 200번. 중간에 서버를 켜서 로그를 쌓기도 했다. 무언가 패턴이 있을 거야. 뭔가 타이밍 이슈가 분명히 있어. 그렇게 스스로를 다독였다.결국 새벽 2시. 내 눈은 이미 초점을 잃은 지 오래였지만, 모니터는 계속 켜져 있었다. 테스트 로그가 한 줄씩 쌓여간다. 잠에서 깨어나다를 반복하면서, 나는 휴대폰 알람을 6시로 맞춰놨다. 지금이라도 테스트 결과를 다시 확인할 수 있으려고. 일요일 아침. 침대에서 일어나자마자 가장 먼저 한 일은 회사 랩탑을 켜는 것이었다. 아내가 있었다면 지금쯤 싸웠을 것 같다. 하지만 나는 혼자였고, 혼자라는 건 아무도 나를 막을 수 없다는 뜻이었다. 테스트 결과 폴더를 열었다. test_result_20250120.txt 손가락이 떨렸다. 마우스를 클릭했다. Test Run 1: PASS Test Run 2: PASS Test Run 3: PASS ... Test Run 127: FAIL - Stack Overflow detected Test Run 128: PASS ... Test Run 200: FAIL - Memory corruption at 0x20019A4C한숨이 나왔다. 스택 오버플로우라니. 내가 이미 다 확인했는데? 재귀 함수도 없는데? malloc도 거의 안 쓰는데? 스택 사이즈는 충분하게 잡아놨는데?일요일 하루 종일 로그를 뒤졌다. 스택 오버플로우 전에 어떤 함수가 호출되었는가. 뭔가 재귀 호출이 숨어 있는 건 아닐까. 콜스택을 추적했다. 라이브러리 함수도 다시 읽어봤다. 혹시 RTOS 태스크 스위칭 중에 문제가 생기는 건 아닐까. 밤 11시. 나는 결론을 내렸다. 이건 펌웨어 이슈가 맞는 것 같은데, 타이밍이 맞아야 재현된다. 아마도 특정 조건—아마도 센서 데이터 처리와 블루투스 통신이 동시에 일어날 때—에서 벌어지는 문제인 것 같다. 그렇다면 월요일 아침, 하드웨어팀에 질문해야 한다.월요일 아침 8시 47분. 회사 자리에 앉자마자 모니터를 켰다. 본메일을 열었다. 토요일 밤 11시에 내가 보낸 이메일이 보였다.제목: 메모리 이슈 관련 질문 - 혹시 하드웨어 문제 아닐까요? 안녕하세요. 펌웨어 테스트 중 다음과 같은 증상을 발견했습니다.약 200번 중 2-3번 스택 오버플로우 발생 재현율이 일정하지 않음 센서 값 읽기와 BLE 전송 중에 주로 발생?혹시 센서 전원 공급 라인이 불안정하거나, 아니면 크리스탈 타이밍이 미세하게 어긋나는 건 아닐까요?제목을 다시 읽으니 한숨이 나왔다. 또 '펌웨어 문제 아니겠죠?' 하는 톤이다. 매번 이런 식이다. 내가 물어보는 것처럼 보이지만, 사실 나는 이미 내 것은 다 확인했다. 이제 남은 건 하드웨어 팀의 회신뿐이다. 카톡이 울렸다. 하드웨어팀 선임: "펌웨어 맞나? 우리 회로는 다 문제없는데..." 당연하다. 매번 이 반복이다. 나 혼자만 자기 것을 의심하고, 상대팀은 절대 자기 것을 의심하지 않는다.나는 다시 펌웨어 코드를 열었다. 이번엔 다르게 접근해보겠다. 스택 오버플로우가 맞다면, 스택 사용량을 동적으로 모니터링하는 코드를 삽입해야겠다. 높이수 마크를 남겨놓고, 런타임에 계속 확인한다면 어디서 스택이 터지는지 알 수 있을 것 같다. 코드를 작성했다. extern unsigned int _estack; extern unsigned int _sstack;uint32_t stack_high_water_mark = 0; uint32_t* stack_top = (uint32_t*)&_sstack;void update_stack_monitor() { uint32_t current_sp; asm volatile ("mov %0, sp" : "=r" (current_sp)); uint32_t used = (uint32_t)stack_top - current_sp; if (used > stack_high_water_mark) { stack_high_water_mark = used; // Log this } }이런 식으로 계속 모니터링하면, 진짜 스택이 얼마나 사용되는지 알 수 있다. 그리고 혹시 내가 놓친 부분이 있다면—혹은 라이브러리에서 몰래 큰 배열을 선언한다면—그걸 잡을 수 있을 것이다. 오전 10시. 회의실에서 양산 미팅이 있었다. 영업팀, 하드웨어팀, 펌웨어팀이 모였다. 일정을 확인했다. 14일 뒤 중국 공장으로 샘플을 보낸다고 했다. 샘플. 그 단어만 들어도 가슴이 철렁했다. 샘플이 괜찮으면 양산이 결정된다. 양산이 결정되면 내 코드는 이제 수정 불가다. 딱 이 상태 그대로 나간다. 나는 손을 들었다. "죄송한데, 아직 메모리 스태빌리티 이슈가 남아있어서요. 최소 1주일이 더 필요할 것 같습니다." 회의실이 조용해졌다. 영업팀 과장이 말했다. "메모리 문제라고? 그게 뭔 문제야?" 하드웨어팀 선임이 말했다. "펌웨어 쪽 문제 아닐까요?" 부장이 나를 봤다. "정확한 원인이 뭐야?" 나는 깊게 숨을 쉬었다. "저... 아직 정확히는 모릅니다. 타이밍 이슈인 것 같은데, 센서 입력과 BLE 통신 사이의 레이스 컨디션일 수도 있고, 아니면 진짜 스택 오버플로우일 수도 있습니다. 자동화 테스트로 재현을 기다리고 있어요. 로그에서 패턴을 찾으면 원인을 특정할 수 있을 것 같습니다." 부장은 고개를 끄덕였다. "좋아, 원인을 빨리 찾아." 회의실을 나왔을 때, 내 머리는 이미 다음 시도를 생각하고 있었다. 혹시 센서 드라이버에서 문제가 있는 건 아닐까. 아니면 타이머 인터럽트의 우선순위 설정이 잘못된 건 아닐까. 혹은 그냥 운이 없었을 거고, 계속 테스트하면 한 번은 성공할 거야. 오후 3시. 다시 보드 위의 LED를 본다. 초록 불이 깜박인다. 실행 중이다. 또 테스트를 돌리고 있다. 200번. 500번. 아마 밤새도록 돌릴 것 같다. 그리고 내일 아침, 월요일과 같은 절망감으로 깨어날 것 같다.결국 오늘도 또 다른 월요일의 시작일 뿐이다.

양산 D-7, 잠을 잘 수 없다

양산 D-7, 잠을 잘 수 없다

양산 D-7, 잠을 잘 수 없다 알람이 울린다. 5시 30분. 어제는 3시간 잤다. 그 전날은 2시간. 통패턴이다. 일주일 수면 시간을 계산하지 않는 게 정신 건강에 좋다. 침대에 누웠는데 눈이 감기지 않는다. 천장을 본다. 까만 천장. 거기에 코드가 보인다. if (sensor_value > THRESHOLD) { // 여기 로직이 맞나? }맞다. 틀렸다. 아니, 모르겠다. 일단 일어난다.D-7이라는 숫자 양산까지 일주일. 정확히는 7일. 168시간. 10,080분. 더는 세지 않는다. 세면 더 짧아 보인다. 오늘 아침 회의. HW팀 리더가 물었다. "펌웨어 테스트 상태는?" 나: "90% 정도요." HW팀 리더: "90%면 앞으로 7일 동안 마무리 되겠네요?" 아. 이미 계산이 되어 있었구나. 남은 10%는 뭘까. 아무도 모른다. 나도 모른다. 그래서 무섭다. 엣지 케이스의 악몽 어제 테스트 케이스 리스트를 다시 봤다. 문서는 총 47페이지. 펌웨어팀이 만든 게 아니라 QA팀이 만들었다. 아, QA팀은 테스트만 한다. 우리는 이 테스트를 통과하려고 코드를 짠다. 47페이지를 다 읽으면서 생각했다. '혹시 우리가 놓친 조건이 있나?' 예를 들면.온도 0도에서 켜졌을 때는 어떻게 되나? 전원을 뺐다가 5초 안에 다시 꽂으면? 시리얼 통신하는 도중에 전원 끊으면? 펌웨어 업데이트 중에 전원 끊으면?이런 것들. 생각하면 끝이 없다. 한 가지 놓친 게 있으면 리콜이다. 리콜 비용. CEO한테서 들은 소문은 '최소 3억'. 최악은 '10억 이상'. 우리 팀 연봉 다 더해도 그 정도다. 나 혼자면 20년을 일해도 못 버는 돈이다. 그럼 그만큼의 책임이 내 어깨에 있다는 뜻이다. 어제 저녁 10시. 새로운 엣지 케이스를 발견했다. 극저온에서 배터리가 들어갔을 때, 부트 시퀀스에서 전압 체크하는 타이밍이 밀릴 수 있다는 걸 알았다. 딱 1ms 차이. 1ms가 뭐 하는 건가 싶겠지만, 그 1ms 때문에 다른 인터럽트가 선점되고, 그럼 UART 버퍼가 터질 수 있다. 터지면 모니터링 명령이 날아가고, 장비가 시작되지 않는다. 회로도를 다시 봤다. 콘덴서 용량이... 아니다. 그건 HW팀 문제다. 그럼 우리가 할 수 있는 건? 타이머 할당을 바꾸거나, 인터럽트 우선순위를 조정하거나, 또는... 밤 12시. 코드를 고쳤다. 테스트를 돌렸다. 통과. 다시 돌렸다. 통과. 5번 더. 다 통과. 그런데 혹시 다른 케이스에서 망가진 건 아닐까? 회귀 테스트. 모든 테스트를 다시 돌린다. 3시간 30분. 다 통과. 아침 3시 30분. 잠에 든다.양산 후 되돌릴 수 없다 웹개발자 친구 있다. SI 회사 다닌다. "버그 있으면 그냥 배포 다시 하면 돼. 새 버전 올리고. 끝." 나: "..." "너는 왜 그렇게 신경 써?" 펌웨어는 롤백이 없다. 물론 기술적으로 불가능한 건 아니다. 펌웨어 업데이트 메커니즘이 있고, 장비를 수거해서 새 버전을 올리고 반송할 수 있다. 비용만 우리 회사에서 감당하면. 하지만 고객입장에서는? "이 제품 버그 있어서 교환해야 해요." 신뢰도가 떨어진다. 두 번 이상 리콜되면 우리 제품은 끝이다. 시장에서. 그래서 처음부터 완벽해야 한다. 완벽이라는 건 뭘까. 혼자서 생각하면 미친다. 여자친구가 있을 때. 그때도 이랬다. 야근 때문에 헤어졌다는 게 공식 이유지만, 사실은 이것 때문이었다. 내 정신이 여기 없었다. 펌웨어에. 양산에. 리콜의 악몽에. "넌 왜 항상 일에만 생각해?" "양산까지만. 양산 나가면..." 양산이 나갔다. 그 다음 날부터 다음 프로젝트의 양산이 시작됐다. 지금 여기 회사 카페. 아침 8시. 검은색 커피. 세 잔째. 옆 테이블 신입. 인턴. 밝다. 웃는다. 최고 7시간을 자는 거 같다. 나를 봤을 때 이런 생각이 있겠지. '저 사람 왜 저렇게 피곤해 보이지?' 답을 줄 수 없다. 말로는 불가능하다. 침대에 누워도 잠이 오지 않는다. 눈을 감고 기다린다. 5분. 10분. 20분. 그럼 차라리 일한다. 집에 가는 길. 9시 40분. 퇴근이 이른 날이다. 내일 테스트 결과를 생각한다. 실패하는 건 아닐까. 지금까지 다 했는데 갑자기? 그럼 HW팀 보고를 어떻게 하지. 우리가 못 찾은 버그가 있었다고? 아, 그리고 스펙 문서. 다시 읽어야 한다. 혹시 우리가 놓친 요구사항이... 이미 3번 읽었는데. 4번째 읽을까.D-6 회사 도착. 9시 15분. 테스트 결과 확인. 모두 통과. 다시 확인. 모두 통과. 한 번 더. 모두 통과. 그런데 이게 이상하다. 이렇게 잘 될 리가 없다. "혹시 테스트 자체에 문제는 없나?" 팀원이랑 테스트 코드를 다시 본다. 1시간. 이상 없다. 그럼 정말 다 잘 된 건가. 아니다. 뭔가 놓친 게 있다. 분명히. 야근할까. 아니다. 일단 오늘은 자자. 한 번 자본다. 제대로. 침대에 든다. 8시간을 자자고 다짐한다. 5시간을 잤다. 깼다. 또 코드가 생각난다. 포기한다. 회사로 간다. 그냥 이런 거다 이게 펌웨어 개발자의 삶이다. 양산까지 이런 거다. 웹개발자처럼 칼퇴할 수 없다. 배포 버튼 누르고 집 가면 끝. 문제 생기면 롤백. 대면 해결. 우리는 다르다. 보드에 코드가 올라가면 끝. 그 다음부턴 고객 손에. 고객이 전원을 켜면 우리 코드가 돈다. 온도 영하 20도인 한겨울에도. 습도 95%인 욕실에서도. 시골 할머니 손에서도. 모든 상황을 예상할 수 없다. 그래서 잠을 못 자는 거다. D-7이라는 숫자는 사실 숫자가 아니라 카운트다운이다. 남은 시간. 소진되어 가는 기회. 돌이킬 수 없는 경계선. 그 선을 넘는 순간, 우리 펌웨어는 세상으로 나간다. 그리고 나는 계속 그걸 생각한다. 밤마다. 천장을 보면서.내일도 버틴다. 그 다음날도. D-6일 때도 D-1일 때도. 그리고 양산 나간 후에도.