chocokeki

종교의 부활이라고 하니까 좀 애매한데

종교가 죽어가고 있다.

그런데 ai 출시 이후 다시 부활할 수도 있다.

1. ai에 의한 그럴사한 설득력 있는 설교문을 생성할 수 있다.

2. ai가 생성하는 엄청나게 자극적이고 매력적인 컨텐츠의 늪에서 빠져나오기 위해서는 다시 정신적인 고전으로의 회귀를 주장하는 운동이 생겨날 수도 있다. 그 중 하나가 종교 부흥

3. 자극적인 즉 도파민 과다에서 뇌를 쉴 수 있게 해주는 그런 요소가 참선이 될 수 있는데 종교는 참선이 될 수 있나?

일단 기독교는 참회나 찬송으로 되려 반대로 감정을 강하게 자극하는 식으로 종교를 디자인 한다

기독교에서 숨도 못 쉴 정도로 잠오게 거룩하고 고요하고 잠잠하게 진행하는 거 봤음?

그런 교회는 벌써 다 망했음

신나는 엔터테인먼트 요소를 잔뜩 넣어야 사람들이 뿅가서 종교 다니지

근데 그 역할은 ai가 해주고 우리는 그것에서 벗어나기 위해 종교를 다시 찾지도 않을까라는 추측을 하는거잖어?

그러니까 기독교는 인기 없을 것임

그럼 대충 맞아보이는게 불교, 이슬람교 이런 느낌인데 이슬람교는.....알라후아크바르 이미지가 너무 강하고

불교를 좀 리뉴얼해서 세련되게 참선 이미지를 강조하고 마음의 고요를 위해 가질 수 있는 수행 정도로 프로파간다를 설정하면 나쁘지 않아보인다

그런데 인류 역사가 그래왔듯 누가 그런걸 좋아해

그런걸 좋아했다면 도서관에 사람이 폭파될 정도로 많았겠지

ai가 주는 강력한 쾌락의 늪에 빠져 헤어나오지 못하여 뇌가 녹아버릴 수도

표현이 뇌가 녹는다는거지 뭐 진짜 시냅스 연결이 헤응응 되겠어?

아니 그렇게 될 수도 있지 않을까?

전기를 맨날 10000KV로 주다가 10V로 신호를 보내면 신호가 왔는지도 모를꺼 아녀 ㅋㅋㅋ

예전에 고민하고 머리를 쥐어뜯던 부분에 대해 좀 정보를 남겨보려고 한다.

어딜 봐도 이런 내용은 거의 없더라

원론적인 내용이라 그런가?

최근에는 MCU도 하이 퍼포먼스가 기본이라 SMP형식의 멀티코어 시스템이 등장하고 있다.

여기서 궁금한 부분이 있을 것이다.

멀티코어? 그럼 펌웨어를 어떻게 디자인 해야하는거야?

2가지 방법이 있다.

하나는 편리하게 자원을 나눠서 하나는 0번 코어에서 돌게 하고 나머지 하나는 1번 코어에서 돌아가게 하고

각자 다른 펌웨어 주고 물론 flash영역도 각자 나눠 갖고 이런식으로 디자인할 수 있다.

2개의 다른 펌웨어가 하나의 MCU에서 돌아가는 형식인거지

그럼 다른 방법은?

윈도우나 안드로이드 폰 처럼 하나의 펌웨어에서 SMP 멀티코어를 직접 관리하도록 할 수도 있다.

개략적인 그림만 그려보자

이 그림이 잘 안그리고 확신이 안 서서 처음에 삽질을 좀 했다.

별거 아니긴 한데

어차피 MCU core라는게 코드가 돌아가는거잖어

reset handler가 시작되어 돌아가는 주소를 어딘가에 설정하면 되는거고 사용하는 sram 영역은 미리 linker descriptor로 디자인 하면 되는거잖어

그 HOST core들을 동일한 플래시 펌웨어로 돌릴 수 있도록 단 하나의 펌웨어 파일로 돌아갈 수 있도록 디자인을 해볼 수 있다.

대략의 flow는 이런식이다.

MCU 자체 설정에 core를 동시에 켜거나 HOST core의 일부만 먼저 시작하거나 그런식으로 옵션을 설정할 수 있다.

먼저 시작하는 HOST core를 Master Core라고 하자

동시에 시작해도 별 상관은 없다 reset handler에서 디자인을 잘 하면 되니까

Master Core가 부팅을 시작하면 reset handler로 시작되겠지?

램 영역은 어느정도 디자인을 잘 해야한다.

Master/Slave Core가 각기 독립적으로 사용하는 sram 영역(stack, bss, data 등)

그리고 둘이 같이 접근해서 공유메모리 처럼 사용할 수 있는 sram 영역

이런식으로 디자인을 잘 해야 한다.

인제 Master Core가 리셋 핸들러를 탐험하기 전 먼저 자기가 master core인지 slave core인지 HW를 통해 확인을 해야한다.

보통 SMP 시스템에서는 자기가 어떤 코어이고 코어의 상태가 어떤지 알 수 있다.

ready 상태인지 아니면 열심히 달리고 있는 상태인지 꺼져있는지 등등

자신이 Master Core라는 것이 확인 되었으면 OS로 사용하는 램 영역을 초기화하고 자기가 필요한 램 영역을 초기화 한다

디자인하기 나름이지만 Slave Core영역도 미리 초기화 해줄 수도 있고 이건 뭐 상관 없다.

그럼 main으로 점프해서 클럭설정도 하고 HW 초기화를 잘 진행한다.

그럼 Slave Core는 뭘 하고 있는가?

HW적으로 설정하여 POR이후 즉시 대기 상태로 있을 수 있으면 그대로 기다리고 있는다.

만약 그런게 불가능하면 자신이 Slave Core임을 확인하고 Master Core가 어떠한 flag 세팅을 하기를 기다리며 계속 대기 상태로 유지 되고 있으면 된다.

Master Core가 자기 세팅할 것을 완료했다면 Slave Core를 활성화 시킨다.

HW 설정으로 동작하도록 할 수도 있고 sram의 flag를 세팅하여 코드 진행을 가능하도록 할 수도 있다.

즉 쉽게 말해서 같은 코드를 디자인하여 사용하더라도 내부에 조건문으로 core 1일 때 core 0일 때의 루틴을 나누면 된다는 이야기

램? 램은 위에서 말했듯 각자 core가 사용할 수 있는 독립적인 영역을 미리 linker descriptor에 잘 디자인 해야 한다.

core 2개가 동시에 stack을 사용할 수는 없잖어

보통 Core의 권한 레벨에 따라 Stack Pointer 같은 것을 설정할 수 있는 레지스터들이 존재하며(MSP, PSP 같이)  이것을 Reset Handler에서 램 초기화 하기 전에 미리 세팅을 해줘야 한다.

그럼 뭐 펌웨어 하나로 각자 램 사용해서 잘 굴러갈 수 있는거지 뭐

물론 해당 코드는 어느 하나 코어의 독점 사용이 아니라 동시에 이용할 수 있다는 점

이걸 사용해서 동일한 연산을 수행하여 결과를 동시에 받아 그것을 비교하여 다수결로 사용하는 lockstep을 구현할 수도 있겠으나 실제 어떤식으로 구현 되어있는지는 잘 모르겠다 궁금하긴 하다.

lockstep으로도 사용할 수 있을 것 같기도 하고 SMP니까 병렬처리로 사용할 수도 있을 것 같고 실제 어떤 식으로 쓰는지는 몰?루

그리고 보통 SMP 시스템에는 HW 적인 semaphore을 지원하여 서로 동시성 문제 없이 통신을 할 수 있도록 한다.

OS 스케쥴러는 어떤식으로 디자인 되어있을랑가

실제 본적은 없는데 멀티코어면 코어당 내부 timer 있으니까 timer 주기 마다 각자 OS sram 영역에서 스케쥴링 하는건가

그럼 각 멀티코어의 스케쥴 끼리는 통신하는게 거의 없는 건가

윈도우 SMP 시스템이랑 다르게 MCU는 레지스터 백업해서 stack 메모리에 넣는걸 굳이 shared 메모리에 넣어서 idle 코어가 뭔지 찾은다음 idle코어에서 복구한다음 돌리지 않아도 될 것 같은데 그게 나으려나?

그게 되긴 하겠네 그러겠네여 그럼 slave core는 timer가 안 돌면 스케쥴링이 뭐 어떻게 되냐?

master core에서 HW irq 발생 시켜서 slave core 쪽 int handler에 해당 HW irq 등록하고 그럼 해당 HW irq에서 권한 상승 시켜서 context switching...?

느릴 것 같은뎅

core간 cross로 context switch를 해도 되고 그정도 까지는 안 해도 되고

궁금하네잉

간만에 정말 제대로 된 휴대폰 뽑았다는 생각이 든다.

하루 써봤지만 정말 최고의 만족도를 보인다.

완성도도 상당히 높다는 생각이 든다.

아마 S23은 명기로 남을 것 같다

진짜 만족스럽다.

진짜 이게 맞나 싶네

그냥 전설들은 전설로 남아있었을 때가 멋졌던 거 같다

메인이 되는 앨범의 노래 자체가 준비가 덜 된 건 아닌가 싶은데 내가 너무 부정적인걸까 ㅋㅋㅋ

아니 물론 헌터X헌터 처럼 그림 없이 그냥 콘티에다가 대사만 써서 연재 해줘도 감사합니다 하는 경우가 있긴 한데

아니 헌터x헌터는 그냥 ai 작화가 그림 그리고 시나리오는 ai 학습 시켜서 해줘도 감사합니다 여튼 여기서 줄이고

필터 없이 그냥 다 대놓고 말해보자

일본 레전설 그룹의 형아들이 모여서 뭔가 앨범 내고 공연도 한데

근데 정작 앨범은 존나게 공개도 안되고 라이브 공연하는데 쉬이이이이이이발 새로 만든 앨범의 노래는 뭔가 완성도가 조오오오오온나게 이상해보이고

라이브 공연 중 또 엄청 오랜 시간 각자 개인기 장기 자랑하고

피아노랑 바이얼린 역시나 나오더라고

그치 안 나오면 심심하지

근데 그걸 왜 연합 유닛에서 하고 앉아있는지 난 이해가 안되네

심지어 부르는 곡 중 몇 가지는 새로 만든 곡도 아니고 그걸 왜 여기와서 부르고 앉아있는지도 모르겠음

보컬 셀렉이 맞나 싶은데? 걍 이거 요시키 작곡에 보컬 토시 대신 하이도 가져다가 붙여서 노래 부르라고 시킨 거 처럼 뭔ㄱ ㅏ안 어울려, 목소리 톤이랑 곡의 분위기 조합이 영 꽝인데

마지막으로 할아버지가 가터밸트 하고 오신건 어후......진짜 감당 안되던데

AI에 의해 사람이 더 좋아할 법한 디자인이 자동 생성된다면

어떠한 주제와 어떠한 분야든지 말이다.

즉 랜덤 넘버라고 치면 랜덤에 대한 seed를 인간이 적당히 등록하면 나오는 결과물을 가지고 이후 적당한 추가 노력으로  생산한 결과물이 범람한 세상이 된다면?

심지어 그 결과물을 적당하게 대다수가 좋아한다면?

사람이 처음부터 심오하게 고민하여 만들어낸 대상들이 급격하게 줄어들고 점차 사라지게 될까?

구체적으로 좀 더 말하자면

음악을 예로 들면 AI에 의해 적당히 창작된 곡에 적당히 AI가 붙인 가사를 사람이 다듬어서 발매하는데 대중의 호응이 상당히 좋아서 이런식의 프로세스가 당연해지는 시간이 다가온다면 사람의 창작을 위한 의지나 노력은 제약되고 줄어들게 될까 아니면 그런 환경을 기반으로 더 성장하고 커지게 될까?

모든 것은 안좋은 흐름이 선행되고 그 이후 이에 대한 피드백으로 변혁이 발생하겠지? 

사내 보안 프로그램의 취지는 좋은데 얘들 때문에 컴퓨터가 굉장히 느려지고 너무 불안정해지는 문제가 있다.

보안 프로그램 제작자의 뚝배기를 몇 차례고 날려버리고 싶을 때가 많다.

최상급 성능의 CPU가 있더라도 보안프로그램이 설치되는 순간부터 개똥컴보다 윈도우 사용 반응 속도에 문제가 생기고 심심하면 프리징 걸리는 상황이니 화딱지가 안날래야 안 날 수가 없다.

이 현상에 대해 정확한 분석은 해보지 않았으나 추측하기로는 priority inversion 문제가 있는 것으로 예상된다.

나의 경우는 다음과 같은 세팅으로 상당히 많은 안정성 증가를 얻었는데 방법을 공유해보고 싶다.

민간신앙이 될 수도 있겠다만....

짜증나는 Genian에서는 효과를 봤다.

1. 보안 프로그램 프로세스의 우선순위를 높음(HIGH)로 맞춤

(작업 관리자 -> 우클릭 -> 우선순위 설정 -> 높음)

프로세스는 보통 여러개고 숨겨진 상태의 프로세스도 많다.

이 부분에 대한 내용은 생략

2. 해당 프로세스의 CPU를 멀리 던져버림

processor affinity를 적용하는건데 이 부분은 더욱 명확한 근거가 없긴 하다.

그냥 웬지 0, 1번 core는 보통 많이 사용하니까 다른쪽 core를 사용하도록 명시적으로 가이드 하는게 낫잖나 싶은 생각이 들어 적용했다. 그냥 0, 1번에 고정 시키는게 더 나을지 어떨지 바꿔가며 해보기 바란다

막 4번 5번 하나씩 다 돌려가며 시험 해볼 필요는 없다

작업 관리자 -> 우클릭 -> 선호도 설정 -> 모든 프로세서 un check -> CPU 가장 마지막꺼 2개 정도 체크

오토모티브 산업에 진입을 고민 중인 임베디드 분야 사장님이 계시다면 이 글이 참고가 될 수도 있으리라 봅니다.

수년전 선행 및 실차 양산 a-z까지 뛰어본 경험으로 작성된 글이며 우리나라 환경과 맞지 않을 수도 있습니다.

대략 병 내지 정 정도 되는 하청 업체 분들에게 이글을 추천드립니다.

오토모티브, 즉 자동차 산업은 IT가 아니라는그런 느낌이 다소 있습니다.

공장에서 부품을 뽑아내고 그 부품을 공급하고 이런 산업이라는 이미지가 어느정도 있는 것 같습니다.

하지만 자동차 산업은 점점 더 IT화 되가고 있으며 오토모티브에 발을 담근 이력이 없으시거나 단순하게 생각하는 경우 상당히 골치 아픈 일이 될 수 있으므로 멘땅헤딩 진입을 별로 추천드리지 않습니다.

정말 간단한 동작을 하는 파트가 있습니다.

너무 간단한 동작을 합니다. 별로 복잡한 것도 없어보입니다.

그거 별거 아닌거 같은데 만들어서 납품 뚫으면 대박나겠는데? 라고 생각할 수 있습니다.

문제는 자동차가 돌아댕기는 환경이 예상외로 무쟈게 험악하다는점입니다.

1. 고온 문제

불지옥 대한민국 한여름에 야외 주차된 차량이 어떻게 되는지 잘 아시리라 봅니다.

그 뙤약볕에 달궈지면 갑자기 칩들이 오동작을 합니다.

온도 스펙 맞는 제품 쓰면 되는거 아니냐? 라고 생각하겠지만 네 맞습니다. 그런데 단가도 올라가고 항상 100%의 신뢰도를 갖는 것은 아닙니다. 제품이 동작 한다/안 한다의 개념이 아니라 동작을 가끔 안한다 이런 골치아픈 문제가 생기게 됩니다. 온도 테스트는 후반부에 진행하는데 기능 개발 다 해놓고 후반부 와서 온도로 빠꾸 맞으면 사장님 하늘이 노랗게 되는 멋진 모습을 보실 수 있으십니다. HW 보드 설계 다시 해야할 가능성도 있거든요

2. 저온 문제

4계절이 뚜렷한 우리나라 겨울에는 블리자드가 폭풍치는 저온환경이 되면 각종 센서들이 헛짓을 합니다.

온도 스펙...? 맞는데 캘리브레이션이 문제네?

센서가 온도를 다 지원하는데 온도마다 각기 다른 동작 캘리브레이션이 필요하네?

그리고 저온의 가장 큰 문제는 추웠다가 낮이 되면서 따뜻해지면 혹은 제품이 동작하면서 발열이 발생하면 이슬이 생기거나 하는데 매우 골치가 아픕니다. 컴퓨터 시끄럽고 발열이 심하다고 겨울에 베란다에 내놓고 사용하면 이슬 때문에 맛가는거 아시죠?

3. 습도 문제

사막에 가서 필드 테스트 돌립니다. 이건 뭐 크게 문제가 안되는데 엄청 습한 환경, 염도가 많은 환경은 문제가 될 수도 있습니다. 우리나라 좋은 나라 장마(X),  우기(O)가 있는 나라, 내륙도 아니라 바다가 있어 염도도 신경 써야 하는 나라 ㅎㅎ

에이 이양반 뭘 모르는구만 그냥 PCB에 몰딩액 쫙 뿌려서 코팅해버리면 되

-> 몰딩액이 1, 2번 문제와 맞물려서 트러블을 일으키는 케이스를 보셨는지요 ㅎㅎ

열팽창 수축에 의해 몰딩액이 bga 타입 칩 아래로 흘러 들어가서 냉납 비슷한 현상을 발생시키거나 저항을 정말 미세한 힘으로 조금씩 아주 천천히 밀어버리거나!! 심지어 열 발산을 안하고 그대로 가지고 있거나 ㅎㅎ 이쯤되면 환장을 하게 됩니다.

게다가 건강에 문제가 있을 수 있는 제품이라면 양산할 때 취급 관리도 골치아프고 :)

이런 부분에 경험이 없으시면 당황하실 수 있으리라 봅니다.

4. 전자파

이게 좀 골치 아픕니다.

그냥 개발하는 환경에서는 잘 동작해요

별 어려운 기능이 아니에요 복잡한 일을 하는 것도 아니구요 그래서 보통 사업 시작하려고 하면 그거 무쟈게 간단한건데 그렇게 단가가 높아? 어이가 없네, 내가 나서겠다! 이런 스토리로 시작을 하는 케이스가 있나봅니다.

그런데 칩이 오토모티브 AEC-Q100 받았는데 자동차 안에 들어가서 돌리면 오동작을 하네요?

웃긴데 진짜 그렇습니다.

자동차 내부에 보이지 않는 전자파가 어마어마 한가봅니다.

단순히 램에 있는 데이터만 깨지는 게 아니라 레지스터 값도 바뀌고 PC 값도 바뀌고 인터럽트도 지 맘대로 발생하고 좀 골치 아픕니다.

케이스로 쉴딩도 잘 해야 하지만 칩 자체에서 제공하는 ESD 관련 fail safe나 기타 작업들을 신경써서 해야 합니다

SW 개발자도 신경 써야 합니다 :)

당연히 HW 개발자는 I/O 라인 설계도 이런 요소들 다 생각해야 하구요

테스트 할 때 건으로 쏴대면 칩이나 보드가 운명하는 것을 고려하여 충분히 수량을 뽑아놓아야 합니다.

5. 저전력

절전 모드에 대한 SW 및 HW 설계를 잘 하셔야 합니다.

SW 개발자들이 간과하는 부분이 있는데 HW는 OFF 처리하면 하나 둘 셋 으쌰 하고 바로 전류 값이 떨어지는 게 아니라 천천히 방전되는 그래프를 그리며 변동 됩니다.

더불어 사용하지 않는 HW에 대한 핀 상태 처리 및 sleep & wake up 트리거링에 대한 HW 전압레벨 그래프와 타이밍을 잘 맞추는 등의 작업이 진지하게 이뤄져야 합니다.

실차에서는 예상하지 못했던 CAN 통신이 더 들어온다거나 등의 요소들이 있으므로 이런 부분에 대한 대비도 필요합니다.

MCU 레벨에서 BOD나 ESD에 대한 flag, period에 대한 설정을 하는 부분이 있으니 확인하시기 바랍니다.

HW 전원 블럭 설계 관련하여 어떤 소자를 쓰느냐에 따라 전압, 전류값 떨어지는 속도가 다를 수 있으니 이런 부분도 고려가 필요할 수 있습니다.

6. 코딩룰

4번의 이유나 기타 여러 이유로 안정성을 위해 여러 코딩룰 체크를 수행해야 합니다.

Misra-C나 Cert-C 등등등 동적, 정적 검증을 돌려야 합니다.

report가 나와야 하기 때문에 가짜로 할 수 없습니다. 모든 걸 justify 처리하는 건 좀 아니고 진짜 중요한 파트입니다.

특히 복잡도 처리작업 같은 것을 수행하면 리펙터링 수준까지 가기 때문에 하루 이틀내로 뚝딱 되는 일이 아닙니다.

문제는 이 작업을 수행하는 툴이 너무 비쌉니다. mathworks에서 polyspace 견적 한 번 받아보면 기절초풍을 할 것 같은 가격이 나옵니다. 호환 툴이 있긴 한데...... 저라면 polyspace 쓰겠습니다.

7. 전반적인 프로세스

아시겠지만 전반적인 진행 프로세스 단계가 있습니다.

그 단계 내부에 세부적인 단계도 있습니다. 그런 부분들을 미리 안다면 어느정도 일정이나 인력에 대해 대비하고 준비할 수 있습니다. 없다면....네? 갑자기 그걸 해오라구요?

8. 양산대응

양산하면 끝~ 이 아니라...양산공정에서 생각도 못한 문제가 발생할 수 있습니다.

SW를 어떻게 기록할 것인가 이런식의 소프트웨어 관련 이슈를 한 번 겪으시리라 봅니다.

특히 자동화가 결합되어야 한다면 :)

특히 양산하다가 장애가 발생하는 경우 엄청난 시간적 압박이 강하게 들어옵니다.

별 듣도 보도 못한 개발 외 부서에서 온간 잡 부서들과 잡 인원 및 기타 등등 알 수 없는 공장의 알 수 없는 인원들로부터 수많은 반복적인 상황 설명 및 분석 대응 설명 요청을 계속 받습니다.

이와 동시에 장애 원인 분석도 진행되어야 하며 테스트도 수행해야 합니다.

더불어서 문제현상이 발생한 제품의 시리얼 넘버 및 현재 제품이 언제 어디로 납품 되었는가, 수량이 정확하게 파악 되어야 합니다.

그리고 문제 현상을 수정한다면 제품을 모두 변경해야 하는지 업데이트로 해결이 가능한지 등의 요소들이 명확해야 하며 업데이트 혹은 교체에 소요되는 시간, 인력에 해당하는 것이 명확하게 있어야 합니다.

더불어 당장, 즉시 저 멀리멀리 하루 반나절 떨어진 곳 혹은 비행기를 타고 택시를 타고 한 참을 가야 하는 곳의 공장에 즉시 인력이 파견되어 제품 교체 혹은 업데이트 작업을 진행해야 합니다.

뭔가 공장의 인력이 친절하게 차량에서 제품 분해를 도와주고 공구도 빌려줄까요?

아니요 모든걸 완벽히 준비해가야 합니다.

공구, 인력, 작업 절차가 담긴 문서, 예비 부품, 테스트 도구, 심지어 멀티탭까지도

참고로 저는 해외로 나갈 때 릴케이블 한국에서 구비해서 갔었습니다.

구어체라 좀 복잡한데 진짜 다 하셔야 합니다

30분 자고 디버깅한 적도 있었고

7일간 같은 회사 양산팀과 싸우며 고객사에게 같은 내용 계속 설명했던 기억이 나네요

분위기 살벌합니다 ㅎㅎ

같은 회사 양산팀도 문제인데 회사 손해가 크니 진짜 원인을 밝히지 말자 묻어두고 가자 이런식으로 말하는 미친 케이스도 있습니다. 절대 이러시면 안됩니다. 진짜 나중에 고객에게 인도된 차량 직접 찾아가서 교체하고 이런식의 엄청난 상황이 나올 수도 있습니다. 비용은 당연히 배상 다 해야 합니다. 출장비 인력비 등등등

양산 문제 대응할 때 정확한 재현 조건 및 상황을 알 수 없는 경우가 상당히 많습니다.

그냥 증상만 전달 되는 경우가 많습니다. 가능하면 초기에 바로 연락해서 자세한 상황을 최대한 듣기를 추천드립니다.

일단 시간이 반나절 지나면 그 이후부터는 디버깅을 할 시간 조차 주어지지 않습니다.

만약 제품 개발도 직접 하시고 양산 공정도 직접 개발하셔야 하는 경우라면 고생이 많으시겠지만 양산 공정 단계에 대한 설계를 매우 꼼꼼하게 DB화 해서 작업하시기 바랍니다.

9. 인맥

환장 합니다.

어떻게든 다국적기업에 납품해서 양산라인 타면 납품한 회사의 주가에 큰 영향을 받기도 하고 그것을 하나의 세일즈 포인트로 삼을 수 있다는 것을 알기에 인맥을 타고 자신들의 제품도 한 번 써보라고 갑자기 치고 들어오는 케이스가 꽤 있습니다. 그 루트도 굉장히 상식의 범위를 넘어다니는데 이슈를 엉뚱한 곳에서 크게 키운 다음 그 이슈 관련해서 납품처의 인맥을 타고 내려오거나 현재 회사의 사장이나 기타 인맥을 타고 내려오거나 등등 다양합니다.

사용할 수 없는 이유를 논리적으로 거절해야 하기 때문에 골치가 좀 아픕니다.

객관적인 테스트 비교 자료를 제공하거나 성능 시험을 보여줘서 처참하게 발라버려야 하는 경우도 있습니다.

일말의 여지도 주지 않고 말이죠

아니 개발 초기에 껴들면 그러려니 하는데 어느정도 다 되가고 뭔가 될 것 같으니까 마지막에 수저 얹으려고 하는 드러운 놈들이 좀 껴서 치워내느라 짜증이 날 수도 있습니다.

물론 윗선에서 잘 처리한다면 아주 좋겠지만 말이죠

10. 양산 시작~!! 그리고 안정화 성공!!

고생 많으셨습니다

회사측으로부터 그간 고생한 것에 대한 보상을 두둑히 받았으면 좋겠습니다.

그런데 끝이 아니죠

다음 모델에 대해 준비하고 개발 진행 생각하셔야죠 :)

다음 모델은 다른 회사와 경쟁을 할 수도 있습니다. 이 부분은 오해의 소지가 있는데 요즘은 원래 공급처 다원화를 위해 차량뿐만이 아니라 다 그런식으로 진행이 됩니다.

그래도 이미 노하우가 어느정도 잡혀있으니 경쟁사보다 더 잘 해낼 수 있으리라 봅니다~

그런데 굿즈 파는게 좀 쓰기 부담스러운 제품들이 가득해서 꺼려지더라

왜....이렇게 제품 기획이 구리지

그냥 대충 아무 적당한 의류에 작고 이쁘게 DRX 로고 or 모노그램 패턴 넣었으면 되지 않았을까 ㅠㅜ

큰 울림을 내게 전해주는 사건이었다.

어느 누구도 가능하다고 생각하지 않았던 일들

하지만 그것을 가능하게 해준 것은 바로

꺽이지 않는 마음

사공이 많으면 배가 산으로 간다고 했던가

좀 그런 느낌이 든다

다들 해보고 싶은 것도 많고 표현하고 싶은 것도 많아서 그런건가

가장 문제가 되는 건 음향 감독인거 같은데 bgm이 전혀 안 어울리거나 촌스럽거나 몰입을 방해하거나 심각하지 않나 하는 생각이 든다.

세련되지 못하고 촌스럽다는 생각

뭔가 플젝을 총괄하는 사람의 경력이나 파워가 각 파트 별 작업하는 사람보다 좀 딸린가?

정확한 구조는 모르겠으나 아쉬움이 가득하다

그러다가도 놀랄만큼 우수한 엔딩이나 중간중간의 표현을 보면 좀 더 참고 계속 봐볼까 하는 생각도 들고

너무 사랑해서 까다로운 조건을 가지고 보는걸까? ㅋㅋㅋ