[카테고리:] 일기

  • 반복되는 꿈

    2026년 9월 21일

    꿈은 대개 무작위다. 앞뒤가 없고 아침이면 사라진다. 그런데 가끔 같은 세계로 돌아간다. 지난번의 장소가 그대로 있다. 내가 쓰던 능력도 그대로다. 거기서 또 하나의 인생이 조금씩 이어진다.

    설정

    그 세계에는 설정이 둘 있다.

    나는 날 수 있다. 내 대학 졸업은 취소되어 있다.

    그 안에서는 어느 쪽도 이상하지 않다. 사람이 날 수 없다는 생각이 들지 않는다. 마흔이 넘어 졸업이 취소될 리 없다는 생각도 들지 않는다. 렘수면에서는 모순을 잡아내는 자리가 꺼진다. 이야기를 짓는 자리는 켜져 있다.

    높이와 자세

    높이는 늘 같다. 지면에서 1미터와 2미터 사이다. 그보다 높이 오르지 않는다.

    자세는 배영이다. 얼굴이 위를 보고 등이 아래를 향한다.

    1~2 m
    <그림 1> 높이와 자세

    뇌에는 나는 동작의 운동 프로그램이 없다. 걷기가 있고 수영이 있다. 없는 것을 만들 때는 있는 것을 가져다 쓴다. 그래서 배영이다.

    높이 오르지 못하는 것은 나만의 일이 아니라고 한다. 사람들은 대개 구름 위를 날지 않는다. 지면을 스치듯 난다.

    속도

    속도는 날마다 다르다. 어떤 날은 오토바이만큼 나간다. 어떤 날은 기어간다.

    힘껏 젓는다. 풍경은 그대로다.

    그런 날은 자세를 바꾼다. 팔의 각도를 눕힌다. 몸을 편다. 가끔 통하고 가끔 통하지 않는다. 꿈을 꾸면서도 나는 원인을 찾고 있었다.

    렘수면에서 몸은 잠긴다. 근육으로 가는 길이 끊긴다. 명령은 나가고 응답은 오지 않는다. 물엿 속을 젓는 느낌이 거기서 나온다.

    이 꿈은 나쁘지 않았다.

    서른여섯

    문제는 다른 쪽이다.

    꿈에서 내 졸업은 취소되어 있다. 학력은 고졸이다. 나는 수능을 다시 친다. 한 번이 아니다. 4년을 친다. 5년을 친다.

    꿈속의 나는 서른여섯이다. 깨어 있는 나는 마흔여섯이다.

    고통스러웠다.

    꿈이었다. 그러나 렘수면에서는 감정을 만드는 자리가 깨어 있을 때보다 더 활발하고, 그것을 누르는 자리만 꺼진다. 조절 장치가 빠진 채로 감정만 돈다. 줄어든 고통이 아니었다. 완충 없이 그대로 받은 고통이었다.

    점수

    견디기 어려운 것은 떨어지는 일이 아니었다.

    해마다 점수가 낮아졌다.

    준비하지 못해 떨어지는 꿈이 있다. 그것은 불안이다. 내 꿈은 그것이 아니다. 준비했고, 여러 해를 쳤고, 결과는 나빠졌다.

    불안이 아니라 쇠퇴다.

    스무 살은 해낼 수 있는지를 묻는다. 마흔여섯은 그것을 묻지 않는다. 예전만 못해지고 있는지를 본다. 쏟는 것은 그대로인데 나오는 것이 줄어든다. 꿈은 그것을 숫자 하나로 바꾸어 해마다 조금씩 깎아 보여주었다.

    거기에 졸업 취소가 붙는다. 종이 한 장을 잃은 것이 아니다. 서 있던 자리가 없어진 것이다. 그래서 꿈속의 나는 고졸 신분이 된다.

    같은 꿈

    적어 놓고 보니 두 꿈이 하나였다.

     나는 꿈수능 꿈
    장면힘껏 젓는다. 기어간다.해마다 친다. 졸업하지 못한다.
    감각넣은 것이 나오지 않는다
    차이자세를 바꾸면 가끔 반응한다무엇을 해도 내 손 밖이다

    같은 감정에 옷을 두 벌 입힌 것이었다. 차이는 하나다.

    나는 꿈에는 손잡이가 있다. 자세가 내 쪽에 있다. 돌리면 가끔 반응한다. 수능 꿈에는 손잡이가 없다.

    괴로움의 크기를 정하는 것은 상황의 나쁨이 아니었다. 돌릴 손잡이가 하나라도 있느냐였다.

    덮어쓰기

    반복되는 악몽에는 이미지 리허설 요법이라는 것이 있다고 한다. 절차는 짧다.

    1. 깨어 있을 때 그 꿈을 적는다
    2. 결말을 고쳐 쓴다
    3. 고친 것을 자기 전에 5분에서 10분, 몇 주 동안 재생한다

    지우는 것이 아니라 덮어쓰는 것이다. 한 번 꾼 꿈은 기억이 되고, 그 기억이 다음 꿈의 재료가 된다. 같은 세계로 돌아가게 되는 까닭이 거기 있다. 그렇다면 이쪽에서 재료를 넣을 수도 있다.

    내 것이라면 이렇게 고쳐 쓰겠다. 시험장에 들어가 앉는다. 감독관이 명단을 확인하고 말한다. 선생님은 이 시험 대상이 아닙니다. 이미 끝내셨습니다. 가방을 들고 나온다. 복도가 길고 조용하다.

    시험을 잘 보는 결말로 고치지 않는다. 점수를 잘 받는 것으로 고치면 점수로 증명해야 한다는 전제를 그대로 두는 것이 된다. 시험이 나와 무관해져야 전제가 깨진다.

    꿈은 근거를 모아 결론을 내지 않는다. 감정에서 시작해 이야기를 뒤로 짓는다. 검증하는 자리가 꺼져 있다. 반박할 사람이 없다.

    그러니 그 성적표는 자료가 아니다. 다만 그 숫자가 어디에서 나왔는지는 안다.

    오늘 밤에도 그 세계로 갈지 모른다. 가면 조금 빨리 날고 싶다.

  • 와이어 엔코더의 추억

    2022년 여름, 책상 위에 자동감김 릴 하나가 올라왔다. 잡아당기면 풀리고 놓으면 되감기는, 사원증 줄 같은 그 물건이다. 여기에 자석 하나와 칩 하나를 붙여서 AGV 가 앞차를 따라가게 만드는 것이 그해의 숙제였다. 2023년 3월에 손을 뗐다.

    줄 하나면 된다

    추종제어(following control)의 요구는 단순했다. 앞차와 뒤차를 와이어로 잇고, 뒤차가 앞차를 일정한 거리에서 따라가게 한다. 그러려면 두 가지만 알면 된다.

    • 와이어가 얼마나 풀려 있는가 — 길이 L
    • 와이어가 어느 방향으로 당겨지고 있는가 — 각도 θ

    L 이 목표보다 길어지면 가속하고 짧아지면 감속한다. θ 만큼 조향한다. 실제로 제어는 어렵지 않았다. 어려운 것은 이 두 값을 싸게, 그리고 튼튼하게 재는 일이었다.

    자석 하나, 칩 하나

    릴의 회전축에 지름 방향으로 착자된 자석(diametric magnet)을 붙인다. 그 위 1–2 mm 떨어진 자리에 AS5600 을 올린다. AS5600 은 홀 소자 배열로 자기장의 방향을 읽어 각도를 내놓는 12 비트 자기 각도 센서다. 한 바퀴를 4,096 으로 나누고, I2C 로 읽는다.

    AS5600 기판과 릴 허브
    <그림 1> 왼쪽이 AS5600 기판, 오른쪽이 자석을 물린 릴 허브

    와이어를 당기면 릴이 돌고, 릴이 돌면 자석이 돌고, 자석이 돌면 각도가 바뀐다. 그 각도에 드럼 원주를 곱하면 길이가 된다. 이 구조의 좋은 점은 닿는 데가 없다는 것이다. 축과 센서가 접촉하지 않으니 마모가 없다.

    대신 에어갭을 지켜야 한다. 1–2 mm 를 벗어나면 센서가 읽는 자기장 세기가 범위 밖으로 나간다. 기구적으로는 이 1 mm 를 유지하는 것이 전부였다.

    릴 뚜껑에 취부한 센서 기판
    <그림 2> 릴 뚜껑 위에 센서 기판을 얹어 에어갭을 맞춘다

    길이축과 조향축, 두 군데를 재야 하므로 AS5600 은 두 개를 썼다.

    다회전을 세는 스무 줄

    AS5600 은 절대각을 준다. 그런데 그 절대각은 한 바퀴까지다. 4,095 다음은 0 이다. 와이어가 열 바퀴 풀렸다면 그 열 바퀴는 따로 세어 주어야 한다.

    degAngle = output * 0.087890625;
    // 한 샘플 사이에 반 바퀴 넘게 튀었다면, 돈 것이 아니라 경계를 넘은 것이다
    if ((lastOutput - output) >  2047) revolutions++;
    if ((lastOutput - output) < -2047) revolutions--;
    position = revolutions * 4096 + output;

    이 가정이 성립하려면 샘플링이 충분히 빨라야 한다. 와이어가 갑자기 풀릴 때가 위험하다. 한 샘플 사이에 반 바퀴 이상 돌아 버리면 회전수를 통째로 놓치고, 그 뒤의 길이는 전부 틀린다. 이 방식의 한계는 분해능이 아니라 속도에 있다.

    각도 환산 계수 0.087890625 는 360 을 4,096 으로 나눈 값이다. 코드에 이 숫자가 그대로 박혀 있다.

    0.038

    길이 환산은 실측으로 맞췄다.

    WireLength = position * 0.038 - 80;  // -80 은 오프셋 → 향후 파라미터로 조정

    0.038 은 카운트당 밀리미터다. 한 바퀴가 4,096 카운트이므로 0.038 × 4,096 ≈ 155.6 mm, 드럼 지름으로 환산하면 약 50 mm 가 된다. 보고서에는 설명용으로 지름 100 mm 를 가정해 원주 314 mm 라고 적어 두었지만, 실제 릴은 그 절반쯤이었다.

    뒤에 붙은 -80 은 오프셋이다. 와이어를 끝까지 감았을 때가 0 이 아니라서 뺀 값이다. 주석에 “향후 파라미터로 조정”이라고 써 두었고, 실제로 나중에 밖으로 뺐다.

    디버거에 찍힌 한 순간
    revolutions1
    output (원시 각도)2,000
    position1 × 4,096 + 2,000 = 6,096
    degAngle2,000 × 0.087890625 = 175.78°
    WireLength6,096 × 0.038 − 80 = 151.6 mm

    숫자가 손으로 계산한 값과 맞아떨어지는 것을 확인하고 나서야 다음으로 넘어갔다.

    릴을 열다

    그런데 그 0.038 이 처음부터 맞지는 않았다. 환산 상수가 어긋나서, 드럼 지름을 직접 재려고 릴을 분해했다.

    릴 내부의 판 스프링
    <그림 3> 뚜껑 안쪽. 이 얇은 판 스프링이 되감기의 전부다

    안에는 태엽처럼 감긴 얇은 판 스프링이 들어 있었다. 와이어를 되감는 힘은 전부 여기서 나온다. 뚜껑을 여는 순간 그 스프링이 풀렸고, 다시 감는 요령을 몰라 끝내 복원하지 못했다. 릴을 새로 주문해야 했다.

    그때 배운 것은 이것이다.

    재려고 분해했다가, 잴 대상을 잃었다.

    지금 생각하면 열 필요가 없었다. 와이어를 일정 길이만큼 뽑아 자로 재고, 그동안 올라간 카운트로 나누면 계수가 나온다. 그 다음부터는 그렇게 했다.

    자를 대고 와이어 길이를 실측하는 모습
    <그림 4> 뚜껑을 열지 않고도 구할 수 있었던 값

    상수는 밖으로

    값을 올리는 쪽은 블루투스였다. 상위 B&R PLC 가 커맨드를 내리면 수신 보드가 답하는 구조다.

    커맨드응답
    −10조이스틱 값
    −11와이어 엔코더의 길이와 각도 (float)
    −12파라미터 쓰기 — 길이축·조향축의 드럼 직경과 오프셋

    세 번째가 중요했다. 드럼 직경과 오프셋을 펌웨어에 박지 않고 PLC 에서 써 넣을 수 있게 해 두었다. 릴을 교체하면 직경이 미세하게 달라지는데, 그때마다 펌웨어를 다시 구울 수는 없다. 이건 잘한 결정이었다.

    블루투스 모듈의 전원은 MCU 가 트랜지스터로 끊었다 붙일 수 있게 오픈 컬렉터로 물려 두었다. 모듈이 먹통이 되면 사람이 가서 전원을 뽑는 대신 펌웨어가 재기동한다.

    같은 수신 보드 이야기는 무선조종기 개발의 추억 에 따로 적었다. 거기서 커맨드 10 과 11 을 언급했는데, 그 11 이 바로 이 와이어 엔코더다.

    굴러갔다

    2023년 초, 프로토타입으로 AGV 추종 구동에 성공했다. 만능기판 위의 Nucleo-F429ZI, 점퍼선, 그리고 테이프로 붙인 릴이 전부였다.

    AGV 추종 구동에 성공한 프로토타입
    <그림 5> 굴러간 날의 책상

    돌아보면 제어가 가장 쉬운 부분이었다. 남은 질문은 전부 기구 쪽이었다. 와이어가 늘어지면 어떻게 되는가. 사람이 걸려 넘어지면. 릴 스프링의 수명은 몇 만 번인가. 현장의 분진 속에서 에어갭 1 mm 가 유지되는가.

    그 질문들에 답하기 전에 다른 문제가 먼저 왔다.

    이미 걸려 있었다

    이 방식에 이미 특허가 걸려 있다는 것을 뒤늦게 알았다. 변리사에게 상담을 받았고, 회피가 쉽지 않다는 답을 들었다. 보고했지만 그대로 추진하라는 답이 돌아왔다. 결국 제품으로는 나가지 않았다.

    기술적으로 되는 것과 팔아도 되는 것은 다른 문제다. 그리고 그 둘 사이의 거리는 대개 구현이 끝난 다음에야 보인다. 선행 특허 조사는 착수 전에 하는 것이다. 다 만들어 놓고 하는 조사는 조사가 아니라 확인이다.

    3월에 손을 뗐다. 릴은 서랍에 들어갔다.

    남은 것은 몇 개다. 자석 하나로 각도를 읽는 방법, 다회전을 세는 스무 줄, 열기 전에 생각하라는 것, 그리고 만들기 전에 찾아보라는 것.

    요즘도 자동감김 릴을 보면 손이 먼저 간다. 다만 뚜껑은 열지 않는다.

  • 무인지게차 연재-1

    삼성전자 P4 현장에 무인지게차(AFL, Automated Fork Lift) 세 대를 넣고 2년을 붙들었다. 기록할 것이 많아 다섯 편으로 나눈다. 1편은 2024년 2월, 개발자 세 사람이 한꺼번에 사표를 낸 시점부터 그해 7월 내가 지게차와 함께 현장에 들어가기까지의 이야기다.

    12024년 2월, 세 사람이 한꺼번에 나갔다

    이 프로젝트를 만든 개발자 세 명이 같은 시기에 퇴사를 신청했다. 삼성전자 P4 현장에 지게차 세 대를 반입하기 여섯 달 전이었다.

    일정은 이미 박혀 있었다. 72시간 연속 테스트를 통과한 뒤 7월에 현장 반입. 그 일정을 그대로 둔 채 만든 사람들이 빠졌다. 인수인계 기간으로 잡힌 것은 약 한 달, 후임은 두 명이었다. 나와, 원래 지게차팀에 있던 사원 한 명.

    다른 사람이 개발한 코드를 분석하기란 결코 쉬운 일이 아니다. 그것을 한 달 안에 끝내라는 일정이었다. 설계서는 없었다. 받은 것은 IAR 워크스페이스 하나와, 현장에서 값을 만지며 남긴 메모장 파일 하나였다.

    2두 달, 읽기만 했다

    2월부터 3월까지 약 두 달을 인수인계와 공부에 썼다. 타깃은 STM32F407VET6, Cortex-M4 단일 칩이다. 컴파일러는 IAR EWARM, RTOS는 없다. 파일 헤더마다 2017년부터 2020년까지의 날짜가 박혀 있었다. UserDriver 폴더에만 모듈이 서른 개 남짓, 소스와 헤더를 합쳐 2만 5천 줄가량이었다.

    덩치 큰 파일부터 열었다. 주행 제어를 담은 LGV_Control.c가 4,248줄, 상태 관리인 LGV_State.c가 2,276줄, 반사판 항법을 처리하는 NAV350.c가 1,130줄. 한 파일이 4천 줄이라는 것은 함수 하나가 수백 줄이라는 뜻이고, 그 안에 지난 몇 년의 현장 대응이 층층이 쌓여 있다는 뜻이다.

    반대로 main.c는 290줄뿐이었다. 메인 루프가 하는 일은 워치독을 물고 현재 좌표를 백업 레지스터에 쓰는 것이 전부다.

    낯선 구조는 아니었다. 로보스타에 있을 때 DSP의 RTOS 구조에서 메인 루프 안에 코드가 한 줄도 없는 프로그램을 다뤄본 적이 있다. 메인이 비어 있다는 것은 실제 일이 다른 문맥에서 돈다는 뜻이다. 그래서 바로 인터럽트 쪽을 찾아갔다.

    while(1)
    {
        IWDG_ReloadCounter();
    
        pos = POS_GetEstPosition();
        RTC_WriteBackupRegister(RTC_BKP_DR2, (s32)pos.x);
        RTC_WriteBackupRegister(RTC_BKP_DR3, (s32)pos.y);
        RTC_WriteBackupRegister(RTC_BKP_DR4, (s32)(pos.phi*RAD_TO_DEG10));
    }

    main.c — 메인 루프는 위치를 백업할 뿐, 제어는 하지 않는다

    이 백업 레지스터의 뜻은 나중에 알았다. 전원이 나가도 마지막 좌표와 레이어를 기억해 두었다가 재부팅하면 그 자리에서 다시 시작하기 위한 장치다. 현장에서 지게차 전원을 내렸다 올려도 위치를 잃지 않는 이유가 이 네 줄에 있었다.

    3진짜 심장은 SysTick 안에 있었다

    1ms 주기 SysTick_Handler 안에 시분할 스케줄러가 통째로 들어 있었다. RTOS 없이 나머지 연산 하나로 태스크를 배분하는 구조다.

    if((SysTickCount%100)==1) EXTI_GenerateSWInterrupt(SW_IRQ_STATE_UPDATE);
    if((SysTickCount%25) ==2) NAV_TransCheck();
    if((SysTickCount%50) ==4) Gyro_SendCmdCheck();
    if((SysTickCount%50) ==6) EXTI_GenerateSWInterrupt(SW_IRQ_POSITION);
    if((SysTickCount%50) ==8) EXTI_GenerateSWInterrupt(SW_IRQ_AGV_CONTROL);
    if((SysTickCount%50)==10) State_CanSendNavi();

    나머지 값 1, 2, 4, 6, 8, 10 — 같은 주기 안에서 시점을 어긋내 충돌을 피한다

    주기가 같아도 나머지 값을 하나씩 어긋나게 두어 한 틱에 두 가지 일이 겹치지 않게 만들어 놓았다. 뒤에 기능을 추가할 때마다 나는 이 빈 나머지 값을 찾아 끼워 넣어야 했다.

    더 흥미로운 것은 EXTI_GenerateSWInterrupt였다. 소프트웨어 인터럽트를 일부러 발생시켜 우선순위가 다른 컨텍스트에서 무거운 연산을 돌린다. EXTI 라인 5번부터 9번까지가 각각 상태 갱신, 항법 수신 처리, 위치 추정, 주행 제어, 명령 해석을 맡고 있었다. RTOS의 태스크를 인터럽트 우선순위로 흉내 낸 셈이다.

    ★ 이런 구조에서는 타이밍 설계가 코드가 아니라 나머지 값 안에 숨는다. 왜 25인지, 왜 나머지가 6인지는 소스 어디에도 적혀 있지 않다. 문서가 없으면 만든 사람의 머릿속을 역산하는 수밖에 없다.

    4하드웨어는 CAN 버스에 매달려 있었다

    소프트웨어 구조가 잡히자 배선을 따라갔다. 이 모션컨트롤러 보드는 혼자 일하지 않는다. CAN 버스에 여러 보드가 물려 있고 각자 고유한 ID로 대화한다.

    차량 상태를 올려 보내는 VIU 보드가 0x220, 포크의 리프트·틸트 센서를 담당하는 FIU 보드가 0x241, 조향을 맡은 EPS 보드가 별도 ID를 쓴다. 안전 스캐너와 디지털 입출력은 CREVIS I/O 링크가 CANopen 방식으로 0x181, 0x281, 0x601, 0x701을 오간다. 컨트롤러가 상위로 올려 보내는 상태 패킷은 0x260부터 0x271까지 열두 개였다.

    위치 인식은 SICK NAV350 레이저 스캐너가 기둥에 붙은 반사판을 읽어 삼각측량하는 방식이다. 여기에 자이로와 휠 엔코더를 섞어 좌표를 추정한다. 별도 NX 보드를 붙여 SLAM으로 대체하는 경로도 Position.c 안에 준비되어 있었지만, 현장에서 쓰는 것은 반사판 방식이었다.

    5상태 기계와 알람 16종

    지게차의 동작은 상태 기계로 표현된다. 수동 모드가 0번대, 자동 모드가 10번대다. 정지(10), 준비(11), 정상 주행(12), 감속 정지(13), 일시정지(14), 이동 완료(15), 알람 정지(16), 안전 감속(17), 포킹(18), 충전(19), 그리고 비상정지(20).

    장애가 나면 알람 번호가 뜬다. 정의된 알람은 16가지. 비상정지, 범퍼 접촉, 모션 에러, 맵 에러, 경로 이탈, 헤딩 초과, 항법 에러, 적재 실패⋯. 뒤에 현장에서 내가 가장 많이 보게 될 것이 9번 ALARM_NAV_ERROR와 8번 ALARM_LOCAL_TARGET_OVER다. 이때는 그저 번호였다.

    헤더를 읽다가 11번, 12번, 13번 옆에 “정의만 되어 있음”이라고 적힌 주석을 봤다. 선언만 하고 구현하지 않은 것들이다. 이런 흔적이 코드 곳곳에 흩어져 있었다.

    6호기마다 다른 빌드, 그리고 남겨진 메모

    가장 당황스러웠던 것은 상수 헤더였다. 차량 고유 값이 전부 #ifdef로 갈려 있었다.

    //#define SOOSUNG_NO1
    //#define SOOSUNG_NO2
    #define DOOSAN_NO1
    //#define DOOSAN_CB
    
    #ifdef DOOSAN_NO1
    #define STEER_WHEEL_LENGTH          (1525)
    #define WHEEL_SPEED_SCALE_FACTOR    (1.52)
    #define NAV_CENTER_POS_OFFSET_X     (1172)
    #define NAV_CENTER_POS_OFFSET_THETA (6)   // 2024.08.21 = -6
    #endif

    LGV_Constant.h — 호기를 바꾸려면 주석을 옮기고 다시 빌드해야 한다

    1호기용 펌웨어와 2호기용 펌웨어가 다른 바이너리라는 뜻이다. 현장에서 급하게 올리다가 호기를 착각하면 지게차가 엉뚱한 곳으로 간다. 이 구조를 파라미터 방식으로 바꾸는 일은 한참 뒤에야 손댈 수 있었다.

    프로젝트 폴더에는 메모장 파일도 하나 있었다. 만든 사람이 현장에서 값을 만지며 남긴 기록이다.

    *수정한 파라미터
    1. gDiffAng : 40 → 45로 변경
    2. AFL_GetEpsCurAng : 150 → 50 변경
    3. NAV_CENTER_POS_OFFSET_THETA : -6 → +6으로 변경
    4. steer = 850 // 변경 시도했으나 결과가 더 안 좋아 850 유지

    인수인계로 받은 유일한 문서 — 설계서가 아니라 현장 기록이었다

    “결과가 더 안 좋아 유지”라는 문장을 한참 들여다봤다. 이 값들이 이론이 아니라 수십 번의 시도에서 나왔다는 뜻이다. 근거는 없고 결과만 있는 숫자. 함부로 건드릴 수 없는 숫자다. 그리고 앞으로 내가 만들 숫자도 결국 같은 종류일 것이라는 예감이 들었다.

    7그리고 나는 프로젝트에서 빠졌다

    두 달을 읽고 나니 지도가 대강 그려졌다. 그 무렵 나는 이 프로젝트에서 제외되었다.

    기술적인 이유는 아니었다. 조직 안의 문제였고, 여기에 길게 적을 일은 아니라고 본다. 다만 결과만 적자면, 두 달간 만든 지도를 덮고 다른 일로 갔다. 남은 후임은 한 명이 되었다.

    87월, 대타로 다시 불려 갔다

    2024년 7월, 반입을 코앞에 두고 남아 있던 그 사원마저 퇴사를 신청했다. 만든 사람도, 넘겨받은 사람도 모두 빠진 자리에 내가 대타로 들어갔다.

    2024.02개발자 3명 퇴사 신청 (반입 6개월 전). 인수인계 1개월, 후임 2명
    2024.02~03인수인계와 코드 분석 약 2개월
    2024 봄프로젝트에서 제외됨
    2024.07남은 후임 1명도 퇴사 신청 → 대타 투입, 지게차 3대와 함께 P4 반입
    2024 연말코드를 어느 정도 파악. 안정화 시작

    1편이 다루는 구간 — 2024년 2월부터 7월까지

    7월에 지게차 세 대와 내가 삼성전자 현장에 들어갔다. 문제는 엄청나게 많았다. 그리고 나는 소스코드를 100퍼센트 파악한 상태가 아니었다. 두 달 읽고 넉 달 손을 뗀 코드였다.

    현장에서는 원인을 묻는다. 언제 고쳐지느냐고 묻는다. 나는 그 질문에 답할 수 있는 상태가 아니었다. 아는 것과 모르는 것의 경계가 어디인지조차 흐릿한 채로, 매일 알람 번호를 들여다봤다. 그때 받은 압박과 스트레스는 지금도 또렷하다.

    돌아보면 안정화가 시작된 것은 2024년 연말부터다. 코드가 좋아져서가 아니라, 내가 코드를 어느 정도 알게 된 시점이 거기였기 때문이다. 결국 이 프로젝트에서 가장 오래 걸린 일은 고치는 일이 아니라 읽는 일이었다.

    다음 편에서는 2024년 7월의 현장을 적는다. 반사판을 놓쳐 좌표를 잃는 문제, 랙 앞에서 포크가 빗나가는 문제, 그리고 로그 한 줄 없이 원인을 찾아야 했던 시간에 대해.

어제 방문자 : 3 명오늘 방문자 : 1 명전체 방문자 : 584 명