QE 아르바이트 3주차 후기

아르바이트를 하게 된 계기

겨울 인턴 활동이 종료되고 나는 백수가 되었다. 갑자기 무직이 되자 정기적인 수입이 사라졌다는 불안감이 스몄다. 급하게 새로운 직장을 구하기는 싫었다. 그러던 중, 문득 건강하고 젊고 예쁜 몸으로 아르바이트를 할 수 있는 마지막 시간이라는 생각이 들었다. 앞으로 평생 프로그래밍만 하게 될 지도 모르는데! 나는 2년만에 알바몬을 다운로드 받아 아르바이트를 찾아 보기 시작했다.
 
사실 나는 옷 센스가 너무 없어서 옷가게 알바를 제일 해 보고 싶었지만 S사의 QA 알바가 눈에 들어왔다. 인턴 활동을 하며 QA분께 내가 개발한 SW에 대한 테스트를 부탁드린 적이 있었는데, 그럴 때마다 나는 QA분들은 어떤 업무적 환경에 있으며, 내가 테스트를 요청드리기 위해서 어떻게 소통하면 좋을지 궁금해 하곤 했다. 자세한 이야기는 다른 글에서 이야기해 보도록 하겠다. 모쪼록 해당 업무는 앞으로 내가 직업으로 삼게 될 프로그래밍과 굉장히 가까운 위치의 업무이다. 심지어 S사는 자율 주행 시스템을 개발하는 부서도 있었다! 나는 이 일과 회사가 나에게 멋진 경험을 선물해 줄 것이라는 생각이 들었다. 그렇게 나는 자동차를 만드는 회사인 H사, K사에게 하청을 받은 네비게이션을 만드는 회사인 L사에게 하청을 받은 SW를 만드는 회사인 S사에 QA 아르바이트생으로 입사하게 되었다. 
 

첫 출근과 장비 지급

처음으로 입사했을 때, 가장 새로웠던 점은 새로운 하드웨어 장비가 생겼다는 점이었다. 자동차 네비게이션 sw를 테스트 해보기 위해서는, 당연히 자동차 네비게이션이 필요했다. 물론 면허도 없는 나에게 자동차가 주어지지는 않았다. 나에게는 자동차에서 갓 떼어낸 것처럼 보이는 네비게이션과, 전원을 공급 하는 장비, PC와 연결하여 로그를 확인할 수 있도록 하는 장비, 자동차가 네비게이션으로 보내는 신호를 발생시키는 장비(후진, 시동 등)가 주어졌다. 이러한 장비들을 다루기 위해서는 충분한 지식과 노력이 필요할 것이 분명했다. 뭔가 비싸고 위험해 보이는 전자 장비가 내 몫으로 발급되는 것을 보며, 나는 내게 새로운 도전과 과제가 주어진 것을 실감하게 되었다.
 

S사에서, 나에게 맡겨진 업무

1. Daily Version SW가 공유되면, 해당 Version에 적용된 Commit 내용이 정말 잘 적용되었는지 확인하기
2. 매주 정식 업데이터 Version SW가 공유되면, 현재 해결해야 하는 Bug들을 전부 테스트하여 혹시 Side Effect로 함께 해결된 문제가 있는지 확인하기

내게 주어진 업무는 정확히 말하면 QA 업무는 아니었다. SW를 사용해 보며 에러를 찾아 내는 업무이고, 내가 맡은 업무는 현재 발견된 에러를 확인하여 프로그래머를 서포트하는 업무였다. 몇몇 상황에서 나는 QA보다는 QE라고 불리곤 했다.
 

환경 설정 - 분류

1️⃣ 하드웨어 구분

아니나 다를까, 첫 출근과 함께 지급받았던 뭔가 비싸고 위험해 보이는 전자 장비들을 다루기는 정말 어려웠다. 제일 먼저, 네비게이션은 나라별, 기능별로 다른 하드웨어 장비를 사용해야 했다. 내가 다뤄야 하는 하드웨어의 종류는 아래와 같았다.

	표준형	경제형
한국형	한국 표준형	한국 경제형
유럽형	유럽 표준형	유럽 경제형
호주형	호주 표준형	호주 경제형

심지어 여기에서 K사의 네비게이션인지, H사의 네비게이션인지 등 추가적으로 분류되는 사항도 더 있기도 했었다. 내가 테스트를 하기 위해서는 1) 테스트해 볼 버그가 위 종류 중 어떤 종류의 네비게이션에서 발생하는 버그인지 확인을 하고, 2) 해당 장비를 적절한 버전의 SW로 셋팅해야 했다. 그러니까, 내가 준비해야 하는 환경은 이러했다.

• 어느 나라의 장비인가?
• 표준형 장비인가, 경제형 장비인가?
• 어떤 버전의 SW로 테스트해야 하는가?

표준형 장비와 경제형 장비의 차이는 UI가 조금 달랐다. UI가 달라도 백엔드는 같은 코드를 사용할 줄 알았는데, 그렇지 않다고 하셨다.
 

2️⃣ 소프트웨어 구분

SW 버전은 1) 매주 사용자들에게 업데이트되는 버전인 정식 버전, 2) 개인적으로 빌드 서버에 접속하여 이미지 파일을 만들고, 이를 적용하는 Build 버전(이라 하겠다. 사실 정식 명칭은 없었다.), 3) 간헐적으로 CM분께서 빌드해 공유해 주시는 Daily 버전 이렇게 세 개가 있었다. CM분께서는 Daily 버전을 공유해 주시며, 어떤 Commit이 여기에 반영되었는지를 함께 공유해 주셨다. 우리 팀의 역할은 정식 버전에서 발생하고 있는 버그를 해결하는 것이었다. 그렇다는 말은, 유저들이 사용하고 있는 정식 버전에서 에러가 발생하고 있다는 것을 의미하는데, 나는 이게 굉장히 새로웠다. 에러가 나는 SW를 서비스하고 있다니! 물론 에러 없는 SW는 없겠지만, QA로써 SW의 모든 문제를 적나라하게 보고 있자니 감회가 남달랐다.

환경 설정 - 테스트 환경 조성

에러를 테스트하기 위해서는, 테스트 대상 SW를 네비게이션 하드웨어에 적용해야 한다. 이 때, 일반적으로 컴퓨터에 프로그램을 설치하는 것과는 아주 다른 상황이 펼쳐진다. 네비게이션에 음악은 넣어 봤어도, 새로운 소프트웨어를 넣는다니! 방법은 두 가지가 존재했다. 1) 네비게이션 전면에 있는 SD카드 입력란에 준비된 SD카드를 삽입하는 것과, 2) FWDN이라는 프로그램을 사용해 직접 네비게이션 하드웨어에 파티션을 나누고, 해당 파티션에 적용되어야 하는 이미지 파일을 직접 넣어 주는 것이다.

1️⃣ SD카드를 삽입하여 업그레이드

첫 번째 방식은 굉장히 편리했다! 관계자들이 공용으로 사용하는 서버 PC에 원격으로 연결하여 (이것도 전 회사에서는 처음이라 굉장히 어려운 개념이었는데, 이제는 경험이 쌓여 서버 IP만 듣고 알아서 SSH 20 port를 연결하는 내 모습이 굉장히 자랑스러웠다.) SD카드 데이터를 내려 받고, 본체에 끼우기만 하면 되는 방식이었다! 하지만, 이 방식을 활용하기 위해서는 다른 팀에게 업데이트 SD카드를 만들어 달라고 부탁해야 했다. 게다가 이 방식은 정말 정식 업데이트 방법으로, 유저들도 해당 방식으로 소프트웨어를 업그레이드해야 했다. 따라서, 유저가 실수로 다운그레이드 SD카드를 삽입하는 것을 방지하기 위해 아래 버전으로 변경하는 것은 제한되어 있었다. 따라서 우리 팀에서는 주로 두 번째 방식으로 소프트웨어 업데이트를 진행했다.
 

2️⃣ FWDN을 사용하여 업그레이드

FWDN이란, 어떤 제품의 이름이 아닌 Firmware Download라는 의미이다. 즉, 우리 팀에서 사용하고 있는 FWDM은 어떤 기성품이 아닌, 우리 네비게이션을 위해 태어난 프로그램이다. 네비게이션 작동을 위해서는 하드웨어와 임베디드 SW를 연결해 줄 펌웨어가 필요했다. OS를 설치하는 방법도 있었겠지만, OS를 구비하는 데에는 비용이 많이 들고, 고작 네비게이션을 작동시키는데 거창한 OS까지는 필요하지 않았던 것 같다. 따라서 FWDN은 펌웨어 셋팅, 플래시 메모리 파티셔닝, 파티션에 임베디드 SW 적용 이렇게 세 가지 과정을 수행했다. 사용 방식은 다음과 같다.

PCB (이해를 돕기 위한 사진)

제일 먼저, 네비게이션을 부팅 모드로 켜 주어야 한다. PCB 기판을 PC에 연결하고, 반대쪽을 네비게이션과 연결한다. 그 후 네비게이션 전원을 켜면 부팅 모드로 전원을 켤 수 있다. (이것도 너무 신기하다! PC-PCB-네비게이션 연결은 네비게이션에 전원이 들어오기 전에 연결되는데, 어떻게 전원이 들어옴과 동시에 부팅 모드를 감지할 수 있는거지? PCB는 어떤 역할을 하고 잇는 걸까? 으윽 이건 전자의 영역이니 다음번에 공부해보고 싶다. 전자 너무 궁금하다. 전자랑 물리...)
 

FWDN에 rom 파일을 올려 둔 모습

 
FWDN 프로그램에 부팅 rom 파일을 업로드 하고, 네비게이션과 PC를 USB로 연결한다. 연결이 감지되면 프로그램에 올려 둔 rom 파일대로 네비게이션에 펌웨어가 셋팅된다.

파티션 정보 입력란

이제 FWDN에 이미지 파티션의 개수와 크기를 입력해야 한다. 파티션이란, 프로그램의 플래시 메모리 영역을 기능 기준으로 구분하는 단위를 의미했다. 각 파티션은 다른 기능을 수행했고, 이에 필요한 이미지 파일도 각각 달랐다. (같은 것도 있었다.) 파티션은 기능을 분리함으로써 어떤 기능이 고장나면 다른 곳은 수정할 필요 없이 그 기능만 확인하면 되도록 프로그램의 응집도를 높이는 역할을 했다. 파티션 정보는 다양한 기준에 따라 달라졌으며, 따라서 정확한 숫자를 기입하기 위해 가이드 문서를 꼼꼼하게 살펴야 했다.
 
이렇게 직접 이미지파일을 지정하여 데이터를 네비게이션에 입력한 후 전원을 껐다 켜면 업그레이드된 임베디드 소프트웨어를 확인할 수 있었다.
 

자동화 시도

사실, 나는 DevOps 개발을 경험한 프로그래머로써 이 과정을 자동화할 수 있지는 않을지 고민했다. 파티션 정보는 파워포인트 파일로 공유되었는데, 굉장히 보기 어려웠다. 더도 말고 덜도 말고 딱 내가 테스트하려는 네비게이션이 PC에 연결되면 해당 기기에 알맞은 파티션 정보인 파티션 갯수, 크기, 필요한 이미지파일 이름을 자동으로 FWDN에 입력하는 기능을 개발하고 싶었다. 그러기 위해서는 FWDN을 GUI가 아닌, 코드 입력 방식으로 제어할 수 있어야 했는데, 이 FWDN 프로그램은 따로 API를 제공하지 않았다. 따라서 나는 해당 프로그램의 소스를 볼 수 있는 방법은 없을까 궁리 하였으나, ChatGPT가 이를 뜯어 말렸다. 불법이래 !
 

원청업체와의 회의

아르바이트를 하기 시작한 지 2주 후, 나는 처음으로 원정업체인 L사와 회의를 하게 되었다. 원청업체와의 회의는 자주 있는 일이 아닌 듯 했다. 나는 외부 회사와 회의를 한다는 말에, 좋은 인상을 줄 수 있도록 회의를 완벽하게 준비하고 싶어졌다.
 
제일 먼저, 나는 회의의 목적이 무엇인지 파악하려고 했다. 사실, 이번 회의는 좀 특별했다. 이때까지는 별다른 원청 업체와의 회의 없이 진행해왔는데, 갑자기 회의를 청해 온 것이다. 나는 팀장님께 회의 목적에 대해서 여쭤 보았지만, 팀장님께서는 그저 업무상황 공유를 위한 회의라고 말씀하셨다. 그 ‘업무상황 공유’를 왜 하는 것일지, 오리무중이었다.
 
좀처럼 왜 회의를 하는지 이해가 되지 않자, 나는 회의의 흐름을 예상해 보았다. 주기적으로 있는 회의를 토대로 예측해 보건데, 아마 나는 모든 프로그래머분들의 보고 마지막에 PT를 하게될 것 같았다. 그렇게 된다면, 테스트 시 재현되지 않는 에러 내용은 이미 내 차례 전에 다른 분들께서 발화해 주실 테니 나는 해당 내용에 대한 피칭은 생략하기로 했다. 그리고... 그리고 ... 모르겠다... 아무리 생각해도 회의를 하는 이유가 무엇인지 파악이 좀처럼 되지 않았다. 정말 '업무 상황을 공유' 받고 싶다니! 마이크로 매니징을 하려고 하는 걸까? 그 이유는 회의를 해 보고 난 후에 알게 되었다.
 
회의는 내 예상대로 흘러갔고, 다른 프로그래머분들이 자신의 이슈에 대해 상세히 보고하는 것을 보면서도 '우리가 처한 상황에 대해 알아 듣기는 할까? 저 분은 프로젝트 매니저이지, 프로그래머가 아닌데.' 하는 생각을 떨칠 수 없었다. 나의 차례가 되었고, 나는 이렇게 말했다.
 
"안녕하세요, 저는 이슈 테스트 지원 업무를 하고 있는 이재은 사원입니다. 저희 측에서는 일단 제가 먼저 최신 SOP버전과 최신 데일리 릴리즈 버전으로 전체 이슈 테스트를 1차, 2차로 진행하고, 재현되지 않는 이슈가 있다면 프로그래머분이 한번 더 3차 테스트를 진행해서 검증하고 있습니다. 이런 과정을 거쳐도 이슈 재현이 어려우면 Comment와 함께 Resolved 처리를 하고 있습니다. 현재 제가 확인한 바로는, 이슈 항목 중에서 1차 테스트 최신 SOP 버전으로 재현되지 않는 항목은 6건, 2차 테스트 최신 데일리 버전으로 재현되지 않는 항목은 3건 확인되고, 프로그래머분들께서 3차 테스트를 진행하고 계십니다."
 
내 이야기를 다 듣고 난 후, 프로젝트 매니저에게 피드백을 듣고, 나는 아주 커다란 충격을 받게 되었다. 그 이유는, 내가 그 동안 내 업무의 우선순위를 완전히 잘못 두고 있었기 때문이었다. 나는 여태껏 우리 팀 프로그래머들의 이슈 재현을 돕는 업무를 진행하고 있었다. 하지만, 원청업체에서 나에게 바라는 업무는 그게 아니었다. 원청업체에서 나에게 바란 업무는 정기 업데이트를 하기 전, 이슈 해결이 되었는지를 확인하는 역할이 필요한 것이었다. 나는 회의 이후 나의 업무 우선순위를 재정비하게 되었다.
 
이때까지 나의 업무 우선순위

1. 오류 검수 : 이슈가 정말 있는지 확인
2. 개발자 도움 : 이슈 재현 지원
3. 데일리 버전 적용 확인

회의 이후 나의 업무 우선순위

1. 데일리 버전 적용 확인
2. 개발자 도움 : 이슈 재현 지원
3. 오류 검수 : 이슈가 정말 있는지 확인

업무 상황을 보고하는 게 무슨 의미가 있나 싶었는데, 그들은 우리의 업무 상황을 경청하고, 혹시 불필요한 일을 하고 있지는 않은지 검토해 주었다. 우리는 회의를 통해 어떤 업무를 어떻게 하고 있음을 공유하여 서로의 업무 방향을 일치시키고 업무 효율을 높일 수 있었다.
 

형상 관리

S사에서는 표준형/경제형은 아예 다른 SW로 취급했으며, 한국형/유럽형/호주형은 같은 SW로 취급하여 하나의 Git Master Branch를 사용하고, 필요한 Commit만 서로 공유하는 cherry-pick 방식으로 형상을 관리했다.
 

cherry-pick의 존재를 알게 된 것은 정말 충격적이었다. 최근 나는 친구들과 한 프로젝트를 작업하며, merge하는 과정에서 코드가 없어지는 이슈 때문에 어려움을 겪고 있었다. 이 때문에 항상 코드를 덜 작성한 쪽의 코드를 희생하는 방향으로 어렵사리 코드 합병을 해 왔었는데, 이 문제를 해결할 만한 마땅한 검색 키워드가 떠오르지 않아 오랫동안 이 방식을 고수해 왔다. 이런 방식은 서로의 인터페이스를 해친다는 문제점도 있었다. 나는 캐릭터를 보고 작업해야 하는데, 다른 프로그래머는 UI를 보고 작업해야 할때, 이런 방식으로 코드를 합치면 서로가 보고 작업하고 있던 환경을 다시 처음부터 설정해야 한다는 문제가 있었다. cherry-pick 기능을 활용한다면 더 효율적으로 작업할 수 있을 것 같다! 후기는 미리내 개발 일지에 적어 보도록 하겠다.
 

QA의 눈물 1️⃣ - 분명 내가 할 때는 안 됐는데 ...

QA를 하며 가장 힘들었던 순간은, 내가 '잘못' 테스트 했을 때였다. 나는 정말 꼼꼼하게 선수행 조건을 확인하고, 이슈 티켓에 적힌 대로 테스트했다. 여러 차례 검사한 끝에도 에러가 발생하지 않으면, 이 에러는 재발생하지 않는다! 라고 도장을 쾅 찍는다. 그런데, 꽤 잦은 빈도로 프로그래머들이 나에게 항의를 했다. '제가 하니까 에러 나는데요?'

그럴 때마다 내 일에 대한 자부심은 뚝뚝 떨어져 갔다. 더 힘든 것은, 나의 억울함은 업무에 하나도 도움이 되지 않는다는 것이었다. 나는 변명할 여지 없이 내 무능력을 받아들여야 했다.

무슨 말이냐면, 이런 경우가 반복되자 나는 에러가 재현되지 않을 때마다 이를 동영상으로 찍어 '저한테는 정말 안 됐어요!' 하는 증거를 마련했다. 하지만 이는 무의미했다. 나는 증거까지 마련해 가며 나의 무능력에 대해 변론했지만, 여전히 문제가 발생한다는 사실은 변하지 않았다. 내가 "이 에러는 아무튼 저한테는 발생하지 않았어요." 하고 말하는 것은 정말 아무 의미 없는, 생산성 없는 몸짓이었다. 내 변명을 들은 결국 프로그래머는 '아 네...'하며 자리로 돌아가 그 에러를 검사해야 했고, 내 무능력 또는 부주의를 들켜버린 나는 자리에 동그마니 남아 혼자 내 영상을 보고 또 보았다. 분주한 마음으로, 나는 생각하고, 또 생각했다. '나는 정말 열심히 일을 했단 말이야! 영상 속 나를 봐! 제대로 하고 있잖아!' 그 시간은 정말이지... 무의미했다. 내가 그 에러를 재현하지 못한 이유를 동영상만으로 찾는 것은 불가능했고, 다시 그 에러를 재현한덜 그저 내 무능력을 확인할 뿐이고, 다시 그 에러가 재현되지 않은들 그 에러를 다시 테스트하지 않아도 어련히 그렇게 진행될 것이었다. 나는 문제가 발생했을 때, 그 문제의 원인을 파악하고 개선 방안을 모색하여 한 층 더 나은 사람이 되고자 하는데, 이런 경우에는 그런 자기 피드백이 불가능했다. 나에게는 조금 더 꼼꼼히 하자는 막연한 다짐만이 허락되었다. 나는 그저 내 부주의로 문제를 찾아내지 못한 것을 받아들이는 것 말고는 할 수 있는게 없었다... 동영상까지 찍어 증거까지 남겼는데... 이렇게 영상 속 내 기기에는 그 문제가 발생하지 않는 게 버젓이 찍혀 있는데 ... 나는 '오류 검수'라는 것이 무의미함을 느꼈다. 오류가 정말 있는지 검수하는 '오류 검수'는 노동력 낭비라는 생각이 들었다. 앞으로는 오류 검수는 그저 현재 어떤 오류가 일어나고 있는지 파악하는 용도로만 하는 것이 좋을 것 같다고 생각했다.
 

QA의 눈물 2️⃣ - 내가 하는 일은, 당신의 잘못을 찾아내는 일

QA 업무를 직업으로 삼으면 안되겠다고 느낀 중요한 이유이다. 나는 프로그래머들이 실수한 것을 찾아 내어 그들에게 그 잘못을 전달해야 했다. 대학생 시절 살던 빌라에는 집 주인과 관리인이 따로 있었다. 집 주인은 세입자에게 요구 사항이 생길 때마다, 늘 직접 말하지 않고 관리인을 통해 전달했다. 그 덕분에 세입자들은 '쓰레기좀 제대로 버려라' '집에서 조용히좀 해라' 등의 안 좋은 말은 늘 관리인에게 듣게 되었고, 나를 비롯한 같은 빌라 친구들은 자연스레 관리인을 '늘 싫은 소리 하는 어렵고 조심해야 하는 사람'으로 생각하게 되었다. 그리고, 집주인은 '넉살 좋은 집주인 아저씨' 칭호를 유지할 수 있었다. 정말이지 감탄이 나오는 너무 좋은 전략이었다! 나는 지금 이 프로그램의 싫은 소리 하는 사람이 된 기분이다. 마음이 너무 무겁고, 팀원들에게 이런 잘못이 있다고 말하는 것이 마음이 무겁다. 나는 미움받고 싶지 않다. 나는 미움을 감당할 수 있는 사람이 아니다. 말하고 보니 관리인 아저씨가 존경스럽다...
 

그 외 나의 경험들

버그를 정확히 분류하지 않아 일어난 일들
팀장님께서는 에러를 팀원들에게 분배하여 할당할 때, 비슷한 에러를 할당하려고 노력하셨다. 그렇게 해야 번거롭게 하드웨어 장비를 바꿔 셋팅해 가며 프로그래밍해야 하는 번거로움도 줄어 들고, 한 분야의 에러를 다루다 보면 다음에 비슷한 에러를 만났을 때 보다 빠르게 대응할 수 있기 때문이었다. 어떤 장비에서 일어나는 일인지 DQA 팀에서 정확히 기입하지 않으면, 에러를 분배할 때 너무 난해한 에러를 분배받기도 했다.
 
어려운 일을 한 명에게 몰아 주자 생긴 일들
어디에도 묶일 수 없거나 너무 번거로운 일은 항상 K님에게 분담하는 경향이 있었다. 그 때문에 K님께서는 회의 중에 '너무 어려운 문제는 저에게만 분배 하는 것 같아 힘들다.'라고 말씀하시기도 했다. 이러한 문제는 일시적으로는 해결될 수 있지만, 장기적으로는 팀에 독이 될 것이라는 생각이 들었다. 만약 K님께서 휴가를 가신 중에 급한 이슈가 발생한다면? 만약 K님께서 회사를 그만두시기라도 하신다면? 이런 문제를 해결하기 위해서는 버그 정보에 대한 형식을 일관되고 정확하게 기입하는 것이 필요해 보였다. 이러한 상황이 어떤 결과를 낳게 될지, 팀장님께서는 이런 문제를 어떻게 해결하실지 궁금하다.
 
나의 천직은 무엇인가
번거로운 반복 작업을 자동화하고 지식을 정리하여 플랫폼 만들기를 좋아하는 내 성격과, 이전 회사에서 DevOps 업무를 맡으며 생긴 직업병이 더해져서 나는 자꾸만 자동화가 하고 싶었다. 공용 데이터가 필요할 때마다 원격 서버에 접속해서 모든 파일을 뒤져 데이터 파일을 받아오다니! 세상에! 누가 실수로 삭제라도 하면 어쩌려고! 심지어 도메인 주소가 있는 것도 아니었다. IP를 알아 와서 WinSCP로 데이터를 받아 오고 ... 더 골때리는 점은 커맨드를 입력하려면 Putty로 접속해야 했다. 원격으로 접속해야 하는 컴퓨터마다 두 개의 세션을 켜고 작업해야 했다는 말이다! OMG! 너무 자동화 하고 싶었다. 나는 정녕 DevOps를 해야 하는 인재인건가 ... 너무 하고 싶은 일이긴 하지만, DevOps의 끝을 모르겠다. 나는 어떤 분야의 전문가가 되고 싶은데, DevOps 업무는 너무 얕고 넓은 지식만 활용하는 분야라 내가 '전문가'가 될 수 있을지는 모르겠어서 망설여진다.
 
ChatGPT의 활용 - 공부 효율 향상
적다 보니 마치 내가 한 번에 이 모든 내용을 친절하게 교육 받은 것처럼 보이지만, 사실은 그렇지 않았다. 질문하지 않은 것에 대한 지식은 거의 얻을 수 없었다. 나는 부족한 부분을 채우기 위해 열심히 질문했다. 질문을 해도 답을 얻지 못하는 것은 구글링을 하고, 그 지식을 얻기 위홰 어떤 질문이 필요한지조차 모르겠는 경우에는 ChatGPT를 활용하여 어떤 질문을 하면 좋을지 확인했다. 

ChatGPT와의 대화 내용

특히 위 대화가 기억에 남는데, FWDN의 역할을 하기 위해 하드웨어의 '어떤 것'을 파티션으로 나누는지 궁금했을 때 GPT와 나눈 대화이다. 나는 GPT에게 '내가 하고 싶은 말'을 제공했고, 그는 살을 덧붙여 주었다. 그 과정에서 내가 원했던 단어를 찾아낼 수 있었다. 바로 '플래시 메모리' 였다. 나는 이와 같은 방식으로 생성 AI를 활용하여 공부 효율을 향상시키는 경험을 했다.
 
그리고, 미처 적지 못한 이 업무를 하며 새로이 알게 된 것들

• 펌웨어
• 임베디드의 정확한 개념
• 체리픽

 
끝!