자유로운 확장과 재활용

토비의 스프링 책을 읽다가 DI(Dependency Injection)에 대해 정리된 설명을 읽는다. A→B라는 의존관계를 갖는 오브젝트가 있을 때 A와 B사이에 표준화된 인터페이스를 두면 A는 변경하지 않으면서 B의 구현을 B1, B2, B3로 자유롭게 확장할 수 있다고 한다. A 오브젝트 관점에서 보면 자신은 B의 변경에 영향을 받지 않고 재활용해서 사용될 수 있고, B 오브젝트 관점에서 보면 A를 재활용하면서 자신의 구현을 자유롭게 변경하며 확장해 나갈 수 있는 것이다. 자유로운 확장 그리고 재활용에 방점이 찍혔다.

오늘 하루

오늘 개발한 모듈을 테스트하는데 하드웨어 제조사에서 제공한 라이브러리가 메뉴얼 대로 동작하지 않음을 발견한다. Wireshark로 네트워크 패킷을 분석해 보니 요청 메시지에 대한 응답이 두개의 TCP 패킷으로 분리되어 수신되고 있었고 라이브러리에서 해당 메시지를 하나로 조립해서 읽어주지 못하고 있었다. 메일을 보내봐야 겠다.

표준 없음

하드웨어를 다루는 일을 하다보면 표준 인터페이스가 없는 장비를 제어하는 경우가 많다. 제조사에서 각자 자체적으로 인터페이스 스펙을 정해서 배포하는데 이 자체적으로 정의한 스펙을 따라 소프트웨어를 구현하다보면 오늘 처럼 잘 안되는 경우가 종종 있다. 일단 문서부터 어떤 목적을 위해 이것저것을 차례로 하면 된다고 적혀있는 경우가 드물고 그냥 A to Z 같이 API 목록이 쭉 나열되어 있고 숨바꼭질 하듯 필요한 절차를 찾아서 수행해 줘야 하는 경우가 많다. 오랜 숨바꼭질 뒤에 필요한 절차를 이해하고 문서대로 코드를 작성하더라도 뭔가 안되는 경우가 많고 한참 삽질을 하다보면 문서가 잘못 적혀 있었거나 문서대로 동작하지 않는 제품인 경우도 허다했다. 그리고 나는 그것을 찾아내야 하는 입장에 놓인 적이 많았다. 문득 이런 문제를 해결한 경험이 내 개인에게 얼마나 가치가 있는지 질문하게 된다.

재활용이 되나?

왜냐하면 이런 경험은 대게 재활용이 되지 않기 때문이다. A라는 제조사 제품의 결함 때문에 삽질한 경험은 B라는 제품을 다룰 때는 큰 도움이 되지 않는다. B 제품을 다룰 때는 새롭게 삽질을 시작하는 것이다. 이런 류의 문제를 다루다 보면 여기저기 끈질기게 들쑤시다 갑자기 원인을 찾게 되는 경우가 많다.

진귀한 경험

한 번은 이런적도 있다. SDLC(Synchronous Data Link Control)라는 데이터 링크 계층 프로토콜을 구현한 통신카드 드라이버를 구현하게 되었는데 인터럽트 기능이 동작하지 않았다. 영어로 된 두꺼운 스펙 문서를 보고 레지스터를 하나하나 다 설정해 보아도 메뉴얼 대로 동작하지 않았다. 제조사에는 문제 없다는 앵무새 같은 대답만 내 놓았다. 하다하다 안되서 통신 카드와 CPU 사이 데이터 버스를 오실로스코드로 찍어보는 희귀한 일을 하게 되었다. 물리적인 데이터 버스에 인터럽트 요청 핀이 있는데 해당 핀의 전압이 5V가 된 후에, CPU에서 응답 핀에 다시 5V를 실어주면 다음 사이클에서 I/O카드에서 8비트 데이터 버스에 인터럽트 벡터(인터럽트를 식별하는 ID 같은)값을 실어주는게 정상 절차였다. 오실로스코프로 전기적인 신호를 찍어보니 인터럽트 요청와 응답 핀의 전압은 5V로 트리거 되는데 데이터 버스에 벡터 값이 들어오지 않았다. 눈으로 신호를 볼 수 있어서 확실한 방법이었다. 그때 부터 데이터 버스에 인터럽트 벡터 값이 찍히도록 여러 가지 경우의 수의 설정을 바꾸어 보는데 장비에 순간 펑소리와 함께 연기가 났다. 그라운드 핀과 5V 핀을 찍어야 하는데 실수로 다른 핀을 찍어 쇼트가 난 것이었다. 정말 절망적인 순간이었고 크게 낙심했던 기억이 난다. 어쨋든 그 일로 해당 장비를 교체해야 했는데 해외 업체에서 새로 보내온 장비를 받고 다시 테스트를 시작하게 되었다. 그런데 분명 기능이 동작하지 않던 변함 없는 소스 코드인데 새로온 통신 카드에서는 인터럽트 기능이 정상 동작하는 것이 었다. 알고 봤더니 우리가 구매했던 통신 카드 4장이 있었는데 모두 통신카드에 내장된 FPGA에 문제가 있는 제품이었다. 내가 아마 실수로 카드를 태워먹지 않았다면 절대 해결하지 못했을 문제였다. 정말 다이나믹한 이 트러블슈팅 과정은 놀라운 일이었지만 잠시 생각해 본다면 다른 제품을 구현할 때 재활용할 수 있는 종류의 경험이 아니다. 내가 해당 I/O 통신카드 드라이버만 개발하는 사람이라면 다른 이야기겠지만 난 그렇지 않다.

그래도 남는 것

물론 남는 것도 있었다. 일단 문제를 해결한다는 끈질김이라는 자세가 내게 배였고, 문제의 표면에서 문제의 심장부로 점점 내려가며 원인을 찾아가는 많은 경험도 얻었다. 그 과정에서 정말 로우레벨에 있는 통신 I/O 데이터 버스 전기신호를 찍어보는 진귀한 경험도 했다. 문제를 해결하기 위해 로우레벨로 내려가는데 거리낌이 없어진 것 같고 여기 저기를 찍어봐야 겠다는 말로 설명할 수 없는 감각 같은게 생긴 것 같다.

데이터를 다루는 일

요즘 문득 하드웨어를 다루는 일에서 순수하게 데이터를 다루는 일로 내 커리어를 전향해 보는 건 어떨지 자문하게 된다. 10년차를 지난 개발자로써 현업에서 데이터베이스를 한 번도 다루어 본적 없는 진귀한 커리어를 가지고 있다. 지금 새로운 일을 시작해도 늦지 않았을까? 뒤 늦게 다른 사람들을 따라갈 수 있을까 확신할 수 없는 자문도 해 본다. 또한 모두가 그랬던 것은 아니지만 너무나 많은 무책임한 하드웨어 제조사들과 하드웨어 엔지니어들의 뒤치닥거리를 한 경험 그리고 말 그대로 ‘하드’한 하드웨어 엔지니어들과의 커뮤니케이션에 질리기도 한다. 누군가 이런 말도 해주었다. 너가 곁눈질 하는 이곳은 너무나 ‘소프트’한 기획자들과 또 다른 유형의 트러블이 있고, 암만 소프트웨어가 표준화되어 있다고 해도 라이브러리 개발사 마다도 다른 특성 때문에 너가 하드웨어를 다루며 경험한 것 처럼 독특한 경험을 할 때도 있다고. 다 비슷비슷하다.

고민

고민이 많은 요즘이다. 사실은 내 마음이 더 ‘하드’한 것은 아닌지, 내가 먼저 더 ‘소프트’해 져야하는 건 아닌지. 지금 잘하고 있는 하드웨어를 다루는 뾰족한 일에 더 집중해야 할지, 아니면 새로운 분야로 전향해 보야야 할지. 몇 달 뒤면 사십이 되는데 고민이다 고민.