많은 임베디드 개발자분들은 브링업을 끝내면 뿌듯해 합니다. 아무 동작도 안하던 보드에서 불이 들어오고 신호가 전송됩니다.
그러면서 다음과 같은 생각을 합니다.
* 이제 프로젝트를 다 마무리했구나.
이처럼 브링업을 끝내면 프로젝트가 마무리될 단계라 예상합니다. 하지만 브링업은 프로젝트 전체 일정에서 초반 단계일 뿐입니다.
프로젝트의 초반 단계라? 잘 감이 안 오죠? 야구를 예로 들어볼까요?
브링업을 끝냈다면 야구의 2회초 정도로 볼 수 있어요. 자, 그럼 2회 말부터는 무엇을 할까요?
각 드라이버 별로 브링업이 끝나면 이제부터 SW 인증 테스트를 거칩니다. 여기서 SW 인증 테스트가 무엇일까요?
* 구현된 SW가 사이드 이팩트와 같은 문제없이 제대로 동작하는지 점검하는 과정을 의미해요.
이제부터 SW 인증 테스트에 대해서 조금 더 자세히 이야기해볼께요.
SW 인증 팀이란
IT 업체마다 팀을 구성하는 방식이 다른데 보통 내부에서 SW 인증 팀을 구성합니다. SW 인증 팀에서는 테스트 시나리오에 따라 검증을 수행하죠.
한 가지 예를 들어볼까요? 센서를 테스트하는 경우를 생각해볼께요. 수 천번 이상 센서가 제대로 동작하는지 자동화나 직업 테스트를 수행합니다.
이 과정에서 센서가 제대로 작동하지 않는다고 판단하면 SW 인증 팀에서 이를 버그로 잡는 거죠.
인증 팀에서 버그를 잡으면 로그나 메모리 덤프와 함께 해당 개발자에게 버그를 할당합니다.
센서가 제대로 동작하지 않으면 센서 담당자에게 버그가 레포트되는 거죠. 이 때 센서 담당자는 문제의 원인이 무엇인지 분석해야 합니다.
SW 인증 기간은 얼마나 될까
프로젝트의 규모나 난이도에 따라 다르지만 인증 테스트의 기간은 짧게 3~4개월이고 길면 1~2년입니다.
이 기간에 임베디드 개발자들은 많은 스트레스를 받습니다. 버그를 할당받은 개발자들은 버그를 수정해야 하기 때문이죠.
버그를 수정하는게 별 것도 아닌데 무슨 스트레스를 받냐고요? 음, 이런 질문을 할 수도 있겠네요.
임베디드 개발자가 받는 스트레스
임베디드 개발자가 버그를 할당 받으면 스트레스를 받는 이유는 버그를 수정할 시간이 충분하지 않기 때문입니다.
무엇보다, 주위 매니저들이 압박을 하기 때문이죠.
* 언제, 버그를 수정할 수 있나요?
보통 처음에는 친절한 척 하면서 매니저들이 위와 같이 질문을 하는데, 한 6시간 정도 지나면 다음과 같은 질문을 합니다.
* 그 버그를 수정 못하면 큰일나는데, 언제까지 분석할 수 있나요?
* 아직도 문제를 분석하지 못했다고요? 아, 이런!
1~2일 동안 문제를 분석하지 못하면 매니저들의 본성을 알 수 있는 단계까지 옵니다. 뭐가 막 날라다니죠.
버그를 잘 잡기 위해선 디버깅을 잘해야 함
로그나 덤프를 차근 차근 분석하면, 그 과정에서 자연히 문제의 근본 원인을 파악하는 경우가 많습니다.
그런데 압박을 받게 되면 개발자는 차분히 문제를 분석할 수 없게 됩니다.
여기서 중요한 의문이 생깁니다. 버그를 잘 잡으려면 뭘 잘해야 할까요? 정답은 디버깅입니다.
디버깅를 잘하면 문제의 원인을 더 빨리 찾을 수 있기 때문에 임베디드 개발자가 야근을 하느냐 마느냐는 '디버깅 실력'에 달려 있습니다.
이렇게 SW를 안정화는 과정에서 임베디드 개발자는 많은 문제를 만나게 되는데 이를 해결하는 과정으로 실무 능력이 많이 업그레이드 됩니다.
프로젝트 막바지에 만나는 처절한 버그
프로젝트 막바지가 되면 이상한 버그를 만나게 됩니다. 테스트를 3일 동안 돌리면 발생하는 버그죠. 희한한게 하루 동안 테스트를 돌리면 버그가 발생하지 않습니다.
이런 버그를 할당받으면 정말 개고생을 할 가능성이 높습니다. 꼭 이런 버그를 SW 인증 테스트의 마지막 기간에 확인됩니다.
뭐 SW 인정 담당자는 눈을 크게 뜨고 이렇게 말하죠.
* 이 버그 수정되지 못하면 프로젝트 일정은 연기시킬 수 밖에 없다.
이런 분위기가 되면 임베디드 개발자들은 야근은 기본이고 심하면 집에도 못 가게 됩니다. 버그를 수정하지 못하면 집에 못간다니! 참 처절하죠.
이 때 프로젝트를 책임지는 매니저들은 어떤 기분일까요? 잘 상상이 안가죠.
이해를 돕기 위해 좀 끔찍한 비유를 들면 '목에 칼이 들어와 칼로 목이 썰리는 느낌"이라고 할 수 있어요.
제가 개인적으로 아는 매니저가 한 말인데요. 음, 좀 살벌하죠.
버그를 일정 내에 잡지 못하면 프로젝트의 일정이 연기될 수 있어요. 만약 제대로 버그를 잡지 않고 SW를 납품할 수 있는데요.
안타깝지만 SW를 납품하고 나서 꼭 사고가 터지곤 하죠.
버그를 수정하면서 업그레이드되는 개발 능력
그래서 어느 개발 업체이건 디버깅을 잘하는 개발자를 인정해줍니다. 디버깅을 잘해야 가끔 문제가 재현되는 버그를 수정할 수 있어요. 이 능력은 제품 일정을 맞추는데 필요한 핵심 역량이라 볼 수 있죠.
여러분의 목에 칼이 들어와 목이 칼에 썰리고 있는데 누군가 칼을 부러트린다고 생각해봐요.
당연히 여러분을 구해분 분에게 고마움이 생기지 않을까요?
무엇보다 잡기 어려운 버그(문제)를 해결하는 과정에서 정말 창의적인 디버깅 방법을 배울 수 있어요.
관련 부서와 해당 업체의 모든 디버깅 방법이 쏟아져 나오기 때문이죠. 평소에 공유하기 꺼려하는 디버깅 스킬도 등장하죠.
무협 영화를 보면 마지막 결투에서 모두 필살기를 보게 되잖아요? 주위 고수 임베디드 개발자의 필살기를 구경할 수 있는 중요한 순간이죠.
음, 이해를 돕기 위해 한 가지 예를 들어볼까요?
프로젝트 막바지에 갑자기 크래시가 발생했는데요. 확인해보니 ASSERT로 익셉션이 발생했는데, 평소에 아무런 이상없이 동작하는 함수에서 발생을 한 거였어요. 전 완전 멘붕에 빠졌죠. 이거 2일 안에 해결해야 하는데.
그런데 문제의 로그를 1분 동안 봤던 고수 개발자분이 지나가면서 이야기하듯 말하는 거였어요.
* '스택이 깨졌네'
디버깅을 해보니 정말 스택이 Stack Overflow로 깨졌더라고요. 코드를 좀 보고 난 후 스택 사이즈를 키운 후에 문제는 사라졌어요. 정말 며칠 개고생을 할 상황을 모면했죠.
최근 덧글