직장을 옮겨 연구직을 하기 전까지 저는 "중견" 제조 업체에서 RTOS 관련된 platform 개발 엔지니어였습니다.사실 Electronics(전자제품) firmware/RTOS 개발자가 IT의 영역에 들어가는지 확실하지 않지만 하여간 제조업에서의 SW 개발자의 업무를 경험을 바탕으로 정리해 보고 싶었습니다. 또한 본문은 제가 근무 했던 회사를 기준으로 하여 업체마다 세세한 차이가 있을수 있습니다. 적당히 일반화해서 읽어주세요. 내용이 길고 스크롤 압박있습니다. ㅠ.ㅠ
- 먼저 제가 일했던 회사는 연구소에 제품개발인력이 200명 내외, 생산 인력이 1200명 정도인 중견(?) 회사였고, 일본 회사와 joint venture로 QCD 달성 (품질, 비용, 납기)이 목표이고 5S(정리,정돈,청소,청결,질서)를 생명으로 안전제일 패치와 회사 로고 및 명찰을 오버로크한 근무복을 입고 초등학교처럼 운동장에서 월례조회를 하고 社歌 제창을 한 후 구호를 외치는 전형적인 제조업체였습니다. (이게 옛날이야기가 아니라 2000년 중반까지 그랬습니다. 나름 일본계라서 그게 더 심했슬수도 있겠지만 하여간 일반적인 IT 근무환경하고는 많이 다를듯...)
- 제조업체는 거의 어느 회사가 개발 단계가 있습니다. 회사마다 부르는 이름이 다르긴 한데, 제가 있던 곳은 "기능시작 - 설계시작(DVT) - 기술시작(EVT) - 양산시작(MVT) - (시)양산단계 - 양산(SOP)" 이렇게 구분했어요. 몇 번 ODM을 할 때 발주사에서도 제시한 개발단계나 회사를 옮긴 후에도 비슷한 단계가 있어 처음에는 "여기도 이렇게하네.." 하며 신기했지요.
- 기능 시작은 기초적인 설계와 Chip 및 OS 선정을 바탕으로 업체에서 reference board를 받아서 과연 그것들이 우리 제품의 spec상의 실제로 구현할 수 있나를 평가합니다. 기본 source code를 재사용하여 기본 기능만 구현하여 평가하게 되는데 이 때 OS나 Chip이 새로운 것이라면 이것들을 공부하고 기존 source code를 포팅하는 작업을 수행합니다.
아시다시피 선정기준은 단지 성능만 고려하면 좋겠으나 RTOS들 중에는 로얄티를 낼지 buyout할지에 따라 cost 차이가 큰 경우가 있기때문에 양산 예상 대수를 예측하여 선택하게 되죠... 한번은 VxWorks로 하기로 결정하고 중간에 비용문제로 Nucleus로 OS가 변경되어 중간에 미친 적도 있어요.. ㅠ.ㅠ
- 설계 시작 단계가 되면 기능 시작에서 문제점으로 밝혀진 점을 수정하여 상품수준의 설계를 시작합니다. 이 때가 가장 빡세게 설계하고 매일같이 design review(DR)하고 선임자에게 엄청깨지고 욕 먹고 하면서 설계 및 구현의 기초를 착실히 다집니다. 아무래도 C로 구현을 많이 하고 flash/EEPROM footprint를 최소화하기 위해 정말 듣도 보도 못한 테크닉들 동원되죠. 하여간 pointer에 치를 떨며 timing chart 보면서 task를 어떻게 설계해야 될지 고민함다. (저 같은 경우에는 pointer는 별문제가 없었는데 timing chart를 보면서 task 설계하는 것이 정말 어려웠어요. ㅠ.ㅠ)
또한 외주업체들 솔루션을 통합하면서 "아... 업체스펙에는 이게 된다는데 왜 내가 하면 동작 안하는 거임?"을 외치며 외주업체 기술 지원팀에게 매일 전화를 하면서 하소연합니다. "제발 잠깐 들어와서 봐주셈...". 한번은 저희가 거의 최초 고객으로 사용한 chip이 있었는데 chip bug인지도 모르고 정말 뺑이 쳤던 기억이 나네요. "우리가 뭘 잘못했을까.."하고...
슬슬 기구나 전장쪽에서 기구품이나 PSU, board가 나오기 시작하고 소프트웨어 팀에서 만든 binary가 board에 올라갑니다. 그에 따라 제품도 기본적인 동작을 시작합니다. 그런데 이 때 기구부에서 모터 선정을 새로 한다던가..(토크 부족등으로...) 액츄에이터 위치가 변경되거나해서 timing이 변경되거나 board 디버깅을 한다던가 하면... 계속 코드를 update해야 합니다. "아~ x발..." 하면서...
그리고 이 단계 초기에는 hardware팀이 불쌍한 듯... 외주에서 artwork해 온 board에 SMD 부품을 팀원들이 수삽(인두로 땜질)합니다. SMD 부품은 기계로 땜질하라고 있는 애들이라고 알고 있었는데... 또... ball grid array 부품들은 socket을 박더라구요. 불쌍했습니다. 게다가 엄청난 점퍼 와이어 디버깅 신공! (이 때 디버깅 툴을 쓰고 있는 SW팀에 소속된 것에 얼마나 고마워했는지 몰라요.)
또한 중간에 test spec에 따라서 test를 해야 하는데 이 때마다 디버깅 할게 산더미 처럼 떨어집니다. 특히 코드 수정은 돈이 안든다는 믿음 때문에 hardware 버그도 sw로 수정하라는 압력이 장난아님... ㅠ.ㅠ
- 기술 시작 단계가 되면 이제 양산 준비가 들어가야 합니다. 이 때부터는 "이 테마(프로젝트)는 양산 간다"는 확신으로 작업하기 때문에 생산부서, 자재부서, 고객지원(A/S), 품질보증, 소프트웨어 품질 보증 인력들이 모두 투입됩니다. 소프트웨어팀의 경우 코드는 이미 상대적으로 "안정화 되었다고 가정"하기 때문에 보통 양산 지원용 치구(JIG)나 라인에서 제품을 테스트 할 수 있는 tool 개발에 시간 할당을 합니다. 개발쪽은 제품은 알지만 보통 생산을 모르기 때문에 생산쪽 전문가들은 생산기술(회사에 따라서는 제품기술) 인력들이 spec을 주면서 협업을 하고... 물론 이 때도 왠만하면 생산 지원을 안할려고 노력 했습니다. 저는. (하지만 이럴때마다 뺀질거린다는 이유로 뽑히곤 했슴다.) 왜냐하면 생산지원에 관계되면 지방에 있는 공장 라인에서 살아야 해서요...
기술 시작용 제품을 초기에는 수십대에서 최종단계에서는 수백대 정도 따로 조립하는데, 제조업체에서는 현재 생산중인 라인을 세우고 생산인력들이 기술시작제품을 조립하기는 힘들기 때문에... (사실 제품 라인이 바뀌면 인력들도 충분히 훈련시켜야 합니다.) 보통은 개발 인력들과 생산기술 인력들이 공장에 pilot 라인에 모여 앉아서 제품을 조립했어요. 이렇게 조립하면서 생산부서에서 조립성 평가나 라인에서 과연 조립할 수 있는가? (실제로 지정된 시간내에 조립을 완료해야 하기에 너무 복잡하거나 어려우면 재설계하라고 합니다.) 이 때 저는 에어 드라이버, 전동 드라이버, e링 체결법, 몰드 깨졌을 때 베이킹 파우더 신공, ABS와 PS 구분하여 본드질하기등등... 이런 저런 생활에 필요한 잡다한 테크닉들 많이 배웠습니다.
이 때부터는 개발에서만 사용하던 BOM(bill of material) 정보와 설계 정보가 생산과 자재부서 쪽으로 완전히 공개되어 제품설계가 지정된 프로세스에 따라서만 변경이 가능합니다. (기록을 남기는 것이죠...) 그리고 SW쪽에서는 공식적인 update가 모든 테스트 기종에 적용되도록하고 version 관리를 시작합니다. 제가 일했던 99년말부터 2000년대 초중반에는 software version용 tool을 구입을 안해줘서 회사 파일서버에 날짜별로 golden compile 결과와 전체 소스 코드를 버젼관리했었는데, 지금은 대부분 Clearcase 같은 tool로 버젼관리하고 ClearQuest 같은 툴로 error reporting하고 밤에 자동으로 버젼관리툴에서 checkout하여 build하고 그럴겁니다.
내용이 쓸데없이 너무 길어 졌네요... 호응이 좋으면 (제발~!) 다음편에서 계속~
- 먼저 제가 일했던 회사는 연구소에 제품개발인력이 200명 내외, 생산 인력이 1200명 정도인 중견(?) 회사였고, 일본 회사와 joint venture로 QCD 달성 (품질, 비용, 납기)이 목표이고 5S(정리,정돈,청소,청결,질서)를 생명으로 안전제일 패치와 회사 로고 및 명찰을 오버로크한 근무복을 입고 초등학교처럼 운동장에서 월례조회를 하고 社歌 제창을 한 후 구호를 외치는 전형적인 제조업체였습니다. (이게 옛날이야기가 아니라 2000년 중반까지 그랬습니다. 나름 일본계라서 그게 더 심했슬수도 있겠지만 하여간 일반적인 IT 근무환경하고는 많이 다를듯...)
- 제조업체는 거의 어느 회사가 개발 단계가 있습니다. 회사마다 부르는 이름이 다르긴 한데, 제가 있던 곳은 "기능시작 - 설계시작(DVT) - 기술시작(EVT) - 양산시작(MVT) - (시)양산단계 - 양산(SOP)" 이렇게 구분했어요. 몇 번 ODM을 할 때 발주사에서도 제시한 개발단계나 회사를 옮긴 후에도 비슷한 단계가 있어 처음에는 "여기도 이렇게하네.." 하며 신기했지요.
- 기능 시작은 기초적인 설계와 Chip 및 OS 선정을 바탕으로 업체에서 reference board를 받아서 과연 그것들이 우리 제품의 spec상의 실제로 구현할 수 있나를 평가합니다. 기본 source code를 재사용하여 기본 기능만 구현하여 평가하게 되는데 이 때 OS나 Chip이 새로운 것이라면 이것들을 공부하고 기존 source code를 포팅하는 작업을 수행합니다.
아시다시피 선정기준은 단지 성능만 고려하면 좋겠으나 RTOS들 중에는 로얄티를 낼지 buyout할지에 따라 cost 차이가 큰 경우가 있기때문에 양산 예상 대수를 예측하여 선택하게 되죠... 한번은 VxWorks로 하기로 결정하고 중간에 비용문제로 Nucleus로 OS가 변경되어 중간에 미친 적도 있어요.. ㅠ.ㅠ
- 설계 시작 단계가 되면 기능 시작에서 문제점으로 밝혀진 점을 수정하여 상품수준의 설계를 시작합니다. 이 때가 가장 빡세게 설계하고 매일같이 design review(DR)하고 선임자에게 엄청깨지고 욕 먹고 하면서 설계 및 구현의 기초를 착실히 다집니다. 아무래도 C로 구현을 많이 하고 flash/EEPROM footprint를 최소화하기 위해 정말 듣도 보도 못한 테크닉들 동원되죠. 하여간 pointer에 치를 떨며 timing chart 보면서 task를 어떻게 설계해야 될지 고민함다. (저 같은 경우에는 pointer는 별문제가 없었는데 timing chart를 보면서 task 설계하는 것이 정말 어려웠어요. ㅠ.ㅠ)
또한 외주업체들 솔루션을 통합하면서 "아... 업체스펙에는 이게 된다는데 왜 내가 하면 동작 안하는 거임?"을 외치며 외주업체 기술 지원팀에게 매일 전화를 하면서 하소연합니다. "제발 잠깐 들어와서 봐주셈...". 한번은 저희가 거의 최초 고객으로 사용한 chip이 있었는데 chip bug인지도 모르고 정말 뺑이 쳤던 기억이 나네요. "우리가 뭘 잘못했을까.."하고...
슬슬 기구나 전장쪽에서 기구품이나 PSU, board가 나오기 시작하고 소프트웨어 팀에서 만든 binary가 board에 올라갑니다. 그에 따라 제품도 기본적인 동작을 시작합니다. 그런데 이 때 기구부에서 모터 선정을 새로 한다던가..(토크 부족등으로...) 액츄에이터 위치가 변경되거나해서 timing이 변경되거나 board 디버깅을 한다던가 하면... 계속 코드를 update해야 합니다. "아~ x발..." 하면서...
그리고 이 단계 초기에는 hardware팀이 불쌍한 듯... 외주에서 artwork해 온 board에 SMD 부품을 팀원들이 수삽(인두로 땜질)합니다. SMD 부품은 기계로 땜질하라고 있는 애들이라고 알고 있었는데... 또... ball grid array 부품들은 socket을 박더라구요. 불쌍했습니다. 게다가 엄청난 점퍼 와이어 디버깅 신공! (이 때 디버깅 툴을 쓰고 있는 SW팀에 소속된 것에 얼마나 고마워했는지 몰라요.)
또한 중간에 test spec에 따라서 test를 해야 하는데 이 때마다 디버깅 할게 산더미 처럼 떨어집니다. 특히 코드 수정은 돈이 안든다는 믿음 때문에 hardware 버그도 sw로 수정하라는 압력이 장난아님... ㅠ.ㅠ
- 기술 시작 단계가 되면 이제 양산 준비가 들어가야 합니다. 이 때부터는 "이 테마(프로젝트)는 양산 간다"는 확신으로 작업하기 때문에 생산부서, 자재부서, 고객지원(A/S), 품질보증, 소프트웨어 품질 보증 인력들이 모두 투입됩니다. 소프트웨어팀의 경우 코드는 이미 상대적으로 "안정화 되었다고 가정"하기 때문에 보통 양산 지원용 치구(JIG)나 라인에서 제품을 테스트 할 수 있는 tool 개발에 시간 할당을 합니다. 개발쪽은 제품은 알지만 보통 생산을 모르기 때문에 생산쪽 전문가들은 생산기술(회사에 따라서는 제품기술) 인력들이 spec을 주면서 협업을 하고... 물론 이 때도 왠만하면 생산 지원을 안할려고 노력 했습니다. 저는. (하지만 이럴때마다 뺀질거린다는 이유로 뽑히곤 했슴다.) 왜냐하면 생산지원에 관계되면 지방에 있는 공장 라인에서 살아야 해서요...
기술 시작용 제품을 초기에는 수십대에서 최종단계에서는 수백대 정도 따로 조립하는데, 제조업체에서는 현재 생산중인 라인을 세우고 생산인력들이 기술시작제품을 조립하기는 힘들기 때문에... (사실 제품 라인이 바뀌면 인력들도 충분히 훈련시켜야 합니다.) 보통은 개발 인력들과 생산기술 인력들이 공장에 pilot 라인에 모여 앉아서 제품을 조립했어요. 이렇게 조립하면서 생산부서에서 조립성 평가나 라인에서 과연 조립할 수 있는가? (실제로 지정된 시간내에 조립을 완료해야 하기에 너무 복잡하거나 어려우면 재설계하라고 합니다.) 이 때 저는 에어 드라이버, 전동 드라이버, e링 체결법, 몰드 깨졌을 때 베이킹 파우더 신공, ABS와 PS 구분하여 본드질하기등등... 이런 저런 생활에 필요한 잡다한 테크닉들 많이 배웠습니다.
이 때부터는 개발에서만 사용하던 BOM(bill of material) 정보와 설계 정보가 생산과 자재부서 쪽으로 완전히 공개되어 제품설계가 지정된 프로세스에 따라서만 변경이 가능합니다. (기록을 남기는 것이죠...) 그리고 SW쪽에서는 공식적인 update가 모든 테스트 기종에 적용되도록하고 version 관리를 시작합니다. 제가 일했던 99년말부터 2000년대 초중반에는 software version용 tool을 구입을 안해줘서 회사 파일서버에 날짜별로 golden compile 결과와 전체 소스 코드를 버젼관리했었는데, 지금은 대부분 Clearcase 같은 tool로 버젼관리하고 ClearQuest 같은 툴로 error reporting하고 밤에 자동으로 버젼관리툴에서 checkout하여 build하고 그럴겁니다.
내용이 쓸데없이 너무 길어 졌네요... 호응이 좋으면 (제발~!) 다음편에서 계속~

덧글
자라 2009/05/21 16:02 # 답글
"코드 수정은 돈이 안든다는 믿음 때문에 hardware 버그도 sw로 수정하라는 압력이 장난아님... ㅠ.ㅠ"완전 공감합니다!
중년아무로 2009/05/21 23:01 #
사실 SW 수정에 따른 일정 지연 이런 것들이 전부 비용인데... "수정할 때 일정 조심해라.."란 한마디면 계속 밤새서라도 일정 맞추니... 이런 개념이 없는 듯해요..
이상훈 2009/05/22 13:44 #
공감 버튼 없나.. ㅡ.ㅡ;; "HW 구멍을 SW로 막으라!" ... 어디가나 있나보군요...ㅋㅋㅋ
고스 2009/05/21 20:23 # 답글
아 저는 더 작은 일본의 중소 기업에서 일하고 있습니다.일본 회사의 특성이 역시 많이 비슷하군요
전 PSOS라는 RTOS가 들어가 있는 플렛폼과 OS없는 플렛폼에서 몇번 일을 한적이 있네요.
마이컴 펌웨어 작업이 주로 여태 했던 일인거 같습니다.
RTOS에서 작업할때 정말 timing이라는 것때문에 제일 고생한거 같습니다.
사수가 프로젝트 하나 같이 끝내고 다음꺼 시작할때 이제 트라우마가 되지 않았냐고 물어보더군요 --;
또 이야기 듣고 싶습니다!!
중년아무로 2009/05/21 23:03 #
저도 입사후에 처음한 테마가 OS없이 Big loop와 인터럽트 핸들러로 된 코드였어요^^그런데 지금 생각해 보면 일본계 업체여서 배울 수 있던 것이 꽤 되는 것 같아요.
천하귀남 2009/05/21 20:53 # 답글
정말 어디서 듣기 힘든 좋은 이야기 감사합니다. ^^
xeraph 2009/05/21 21:55 # 답글
오.. 다음 글도 기대합니다.
써니 2009/05/21 22:50 # 답글
링크 했습니다! 연재를 기대합죠~!
중년아무로 2009/05/21 23:03 # 답글
천하귀남, xeraph, 써니 / 감사합니다.^^
작은울림 2009/05/22 16:58 # 답글
글 잘 읽었습니다. ^^