어느정도 과장된 표현도 있으면서도 혹시 모르는 상황에서 회사 개발 시스템을 그려나가기 위함으로서라도 글을 써본다.
“누가 이런 구조로 개발하래?”
“이 설계 누가 한거야?”
“생산에서 또 문제래… ㅜㅜ”
물론 이런 대화 내용은 픽션일 수 있으나, 어느 회사에서나 충분히 있을 대화거리이다…
그런데 조금 아이러니 한건 전부 내가 들어오기전부터 이렇게 문제를 가지고 있음에도 굴러가고 있는게 턱이 다리 끝까지 내려올 만큼 엄청 나에게는 충격적이였다.
#1. 하드웨어 개발자의 회사생활 현실
회사에 들어와서 가장 충격을 받은 건 개발자가 “시스템을 만들고, 개선하는 사람” 이 아니라,
“불을 끄는 사람” 취급 당한다는 거였다.
현실패턴…
- 제품 이슈 발생
- 원인 모름(특히 전임자가 만들어 놓은 시스템)
- 나와 관련이 없는 일에도 개발자 호출
- 실측, 디버깅, 보드 수리
모든 개발자의 몫..
이게 한 두번이면 이해 할 수 있지만, 일상이 되면 답이 안나온다.
#2. 그래서 나는 버티는 게 아니라, 표준을 만들기로 했다.
찐 근무하고 있는 회사로서는 그 담당자의 실력에 따라, 하드웨어 설계 기준, Block Diagram, Sequence 구조 등의 문서등이 존재 해야 하지만, 대부분의 제품에서는 그런 구조가 없었다.. ㅠㅠ
그리고… 나의 자리에는 퇴사자의 제품만 4개의 장비가 내 자리에 방치 되고 있어서 내 업무의 퍼포먼스가 낮아지고 있다..
뭐랄까… 회사마다 디자인(설계) 문서 들이 존재 하지만, 당장 내가 회사를 만든다는 생각으로 대충 끄적여 보자면 표준문서와 내용들은 각 분야의 담당자가 봐도 만들어야 할 자료라고 생각이 된다.
| 표준문서 | 내용 | 관련 내용(나의 개인의견…) |
|---|---|---|
| Hardware Design Rule | EMI 대응, Net Naming Rule, 기본 Circuit Design Guide | 설계 완성도 향상, 도면의 일관적인 보는 방법, 고장난 부품/회로 판단가능 |
| Firmware 구조 | File Structure, State Machine Rule | 검증된 시스템, 어려운 문법을써도 쉽게 해석 가능(누구는 주석을 많이 쓴다고 좋은 코드라고 하더라… 어떻게든 잘 돌고 잘 써먹을수있게 코드를 작성해야 좋은데…) |
| Trouble Shooting Guide | 제품별 Issue 대응 체크리스트 | 시스템 블럭다이어그램과, 회로도의 보는 방법, 부품 특징 숙지 |
| 생산 대응 문서 | PCB 수리 기준, Soldering Rule, Debug Flow | 회사내의 시스템에 맞는 재작업기준, 폐기 기준이 존재하면 좋을텐데… 개발자로서 솔더링 룰도, 전반적인 디버깅 할 수 있는 내용도 시스템에 녹여 내면 좋을텐데…. |
내 개인적인 의견이 담긴 표이다…
문서라는것은 사람과 내용을 공유하고, 실무 담당자가 회사를 떠나더라도 잘 활용이 되게 문서를 만드는건데…
현실은!
#3. 왜 이런 상황이 발생할까?
이게 현실이다…
- 문서를 만들어도 생산팀/수리부서 은 보지 않음.
- ISO 시스템? A 인증서? 그건 회사 개인기!
(돈주고 사온 시스템) - 문서를 만들어도 생산팀/수리부서 은 보지 않음.
- 생산은 ERP 혹은 엑셀문서로 일함.
- 개발자는 생산과 서비스팀에게 입으로 설명해야함.
#4. 현실 대응 – 나는 이렇게 버텼다
앞서 만든 표와 비슷한 내용으로 해당 문서가 만들어 지면 서로 공유가 되고 정확한 표준이 생기고 추가적인 부분이 생기면 개정도 하고 할텐데, 문서 자체를 남기지 안는다.
생산과 서비스팀은… 이런 문서를 볼수록 시스템의 이해도가 높아지고, 그러면서 원인을 쉽게 찾아내고 해결함으로서 업무시스템 효율 극대화
품질부서에서는… 연구소에서 놓친 부분이 없는지도 검토가 될 수 있고 있다면 개정을 할 수 있고…
각 시스템의 개발자는 설계된 자료가 유효한지 검토가 되고, 추가적으로 이직시에 도움이 될텐데…
서로 윈윈 하는 문서들을 남겨 놓으려고 하지 않는다.(저게 뭔 대외비라도 되나.. 되더라도 관련된 처벌규칙을 정해줘야 하는데.)
#5. 하드웨어 개발자의 생존 전략
이곳은 하드웨어 개발자를 위한 블로그 이다.
내가 대한민국에 만연한 환경에서 내 직업인 하드웨어와 내가 근무하는 회사를 잘 버틸지는 모르겠으나…
실무 개발자를 위한 후배님들을 위한 생존 키워드를 남기고자 한다.
무조건 남겨라
- Block Diagram
- Sequence Diagram
- 설계 기준
- Trouble Shooting Guide
무조건 기록해라.
- 어떤 문제가 있었는지?
- 어떻게 해결했는지?
- 어떤 노하우가 생겼는지?
나중에 쓸 곳이 있다.
- 사이드 프로젝트 기반
- 포트폴리오
- 기술블로그
- 면접 때 실무 경험
#6. 마치며 – 개발자의 자존감 지키기
개발자는 소방수가 아니다.
개발자는 만드는 사람이다.
내가 나를 지키지 않으면, 아무도 안 지켜준다.
개발자는 기술만 잘하는 게 답이 아니다.
기록, 정리, 구조화 = 나와 회사를 지키는 무기이다.
앞으로 하드웨어직을 하는한 픽션의 내용과 내가 겪었던 실무 삽질..
그걸 해결했던 방법을 솔직하게 남겨볼 생각이다…
긴 글을 읽어줄 사람이 있는지 모르겠지만 나의 생각을 조금씩 남기고 하드웨어를 그만둬야 겠다.
이 글을 작성하면서 생각나는 속담을 꼬아보았다.
“호랑이는 가죽을 남기고, 하드웨어 엔지니어는 설계와 기록을 남긴다.”
이건 하드웨어 엔지니어로서 포트폴리오, 설계자료, 메뉴얼, BOM, 소스코드, 기록, 노하우 등의 모든 엔지니어의 자산을 의미함.