[260201] Day 172 - 미루고 미뤘던 TIL과 2차 프로젝트의 진행 중 회고

들어가며

텔레칩스 임베디드 스쿨도 어느새 2주밖에 남지 않았다. 세상에나. 이번 8월부터 시작했는데, 가을은 정말 순식간에 지나가버리고 어느새 설날이 다가오고 있다. 이번 겨울은 어찌나 빨리 지나가버리는지, 놀라울 따름이다. 열심히 버텨내고, 살아내는 덕분에 이렇게 시간이 쑉쑉 지나가는 거라고 믿는다. 어찌 매일매일 새로운걸 배우고 새로운 문제를 만나고 또 대가리 박으면서 해결해내는 중이다. TIL을 그동안 계속해서 남겼다면 또 정말 하고싶은 말과 기록들이 많았을 것 같은데, 바쁠때는 거의 일주일 내내 막차타고 집에 오고 주말에도 센터 열리면 나가서 작업하고 오고 하느라 TIL을 적을 여유가 없었다. 어쩌면 같이 교육을 듣는 다른 피어들과 다른 나의 장점은 이렇게 TIL 이나 후기를 적을 공간을 운영하고 있다는 것일텐데, 너무 안일하게 이 장점을 못살렸나 싶기도 하다.

ㅤㅤ

이제 끝날 때까지 2주가 남은 시점에서 또 기록을 안남길 수가 없지.

ㅤㅤ

1차 프로젝트 끝나고 회고 한 번 남겼어야 했는데, 끝나자마자 바로 2차 프로젝트에 들어가면서 바로 또 바쁘게 작업하느라 신경을 쓰질 못했다. ㅠㅠ

2차 프로젝트 중간 회고

재밌어요

확실히 오랜만에 맨날 막차타고 집에 오고, 눈 뜨는대로 바로 센터 출근해서 프로젝트를 하니깐 재미있다. 예전에 공유오피스에 책상 하나 빌려서 개발하던 생각도 나고 뭔가 계속 문제에 박치기를 하면서 해결해나가는 과정이 꽤나 즐겁다. 확실히 “적성에 맞는다”는게 어떤 건지 알 것 같은 느낌.

 

프로젝트를 시작하기 전에는 내가 ISO 규정이며 A-SPICE나 MISRA 같은 내용들을 신경쓰면서 개발을 진행할 것이라고는 생각하지도 못했는데, 지금은 산업 표준들을 찾아보면서 설계를 짜고있다. 지금 단계에서 뒤돌아보면 진짜 많이 배우고 성장하고 있다는 느낌이 든다.

ㅤㅤ

괴로워요

미친듯이 프로젝트를 달리고 있다. 괴롭다. 그래서 만족스럽다.

이전에 애플 개발자 아카데미를 할 때, 그리고 수료했을 때 들었던 감정은 “즐거웠다”, “또 하고싶다” 였다. 근데, 생각해보면 그 때는 막 그렇게 간절하지도 않았고 ‘해내야한다’ 라는 생각도 크지 않았어서 딱 즐거운 정도로 개발을 했었던 것 같다. 돌이켜보면 그 점이 가장 후회되는 부분이였다. 그래서 이번에는 후회되지 않도록 괴롭게 프로젝트를 해야겠다고 생각했고, 지금은 진짜 너무 힘들다. 다행히도 힘들다 ㅋㅋㅋ.

ㅤㅤ

개발 자체는 그렇게 힘든게 없었다. 근데 단순 앱개발이나 다른 소프트웨어랑은 다르게 하드웨어적인 영역이나 OS의 빌드까지 고려해야 하다보니 더 까다로웠다. 소프트웨어 설계 과정에서 결합도는 낮추고 응집도는 올리는 식으로 설계를 다 해두고 이걸 기반으로 클로드나 커서를 활용해서 빠르게 코드 작업을 수행해줬다. 내 이론으로는 완벽한데, 여기에서부터 하드웨어 억까가 시작되더니 더이상 뭐가 문제인지 파악하기 힘든 순간들을 많이 마주쳤다. 전력 문제라거나, 센서값이 잘 안읽힌다거나, 데이터 시트대로 했는데 짭 부품이라는 의심이 드는 로그가 출력된다거나.

ㅤㅤ

그런데 이제 힘든 점은 팀프로젝트라는 점에서 더욱 크게 왔다. 1차 프로젝트, 2차 프로젝트 기간 내내 팀장을 맡아서 진행하면서, 개발보다는 오히려 문서 작업이나 팀 작업 조율에 더 신경을 많이 써야할 때가 많았다. 물론 전체적인 구조에 대한 설계나 팀 협업을 위한 환경 세팅을 경험할 수 있었다는 장점도 있겠지만, 이건 팀장급으로 올라가야 써먹을 수 있는 “개발 외적인 소프트스킬”이지, 신입이 기술력으로 회사에 어필할 수 있는 포인트는 전혀 아니라고 생각이 들었다. 전체 아키텍처에 대한 설계에 대한 경험이 지금 내 수준에서 필요할까? 오히려 드라이버 코드를 뜯어보면서 도큐먼트를 읽으며 복잡한 코드를 이해하고 이를 상세 모듈 설계에 적용해본다거나, 소프트웨어 모듈에 구체적으로 어떻게 섬세하게 구현해낼지를 고민하는게 더 어필이 되지 않을까? 라는 고민이 프로젝트를 시작한 지난 두 달간 계속 들고있다.

ㅤㅤ

나는 임베디드 개발을 더 깊이있게 경험하고 싶은데, 이 부분은 불만이 크다. 심지어 1차 프로젝트 기간 동안에는 내가 코드를 집중해서 개발한건 몇 주간의 프로젝트 기간 중에 하루 이틀밖에 안된다. 심지어 그 코드도 그냥 센서 몇 개 보드에 꽂고 값 잘 들어오는지 확인하는 정도의 너무 간단한 초등학생도 할 수 있는 수준의 개발이였어서 아쉬움이 많이 남았다. 쩝… 지금은 그래도 테스크를 하나 담당해서 진행해보려고 하고있는데, 디스플레이랑 스피커를 보드랑 연결해서 출력을 확인하고, 다른 프로그램과 소켓 기반 통신으로 출력신호를 주는 기능을 개발해뒀다. 근데 이것도 사실 이틀밖에 안걸렸던거기도 하고, 뭔가 기술적으로나 설계적으로 깊이있게 작성한 부분은 아니라서 별로 기술적으로 어필이 될 만한 부분도 아닌 것 같다.

ㅤㅤ

어찌되었든 이 프로젝트 자체가 스펙이나 내 포트폴리오의 한 페이지로 들어가야하는 것도 있지만, 어찌됐든 임베디드 교육 과정의 일부분이니깐 팀원들이 최대한 성장할 수 있는 방향으로 업무 분담을 하기 위해서 내 개발을 포기하고 (진짜 2달 동안 코드 구현한 게 일주일도 안되는게 말이 안되긴 해 ㅋㅋ) 하드웨어를 많이 경험해본 팀원들에게 소프트웨어 개발 업무들을 나눠줬다. 근데 이게 좀 잘못된 판단이였던 것 같다. 다른 팀의 팀장들은 주요한 부분들을 다들 맡아서 작업을 하면서 프로젝트 진도를 쭉쭉 뽑아내고 있는데 우리팀은 항상 거의 1주일 이상 지체가 되고 있고 (나는 개인적으로 팀원들의 작업 속도를 지켜볼 때 팀의 개발 역량 부족이 원인이라고 느껴졌다), 그 상황에서 정작 나는 개발이 빨리 진행되기를 기다리면서 그냥 문서 작업이나 하고 있어야하는 때가 종종 있었다. 소프트웨어를 더 깊이있게 경험할 수 있게 나름 배려해준거였는데, 오히려 하드웨어 쪽을 잘 아는 팀원들은 SW 개발 업무는 일주일 넘게 미뤄두고 하드웨어 쪽 작업만 하는 경우도 있었다. 어쩌면 그냥 부족한 부분을 채우기보다는 각자 잘하는 부분을 더 잘 할 수 있게 키우는 방향으로 업무를 분담하는게 더 좋은 방향성이였을까 하는 생각도 든다. 예쁜 육각형 보다는 T 자형으로 강점을 가져가는게 더 좋지 않았을까. 사실 여기에 대해서 1차 프로젝트 발표를 하고나서 한 번 업무 분담의 방향성을 피벗팅을 해볼까 아젠다를 올렸는데, 모두들 지금 하는대로 하고싶다고 해서 믿고 맡겼는데, 좀 발등 찍힌 감이 없지않아 있는 것 같다. 미뤄두고 안할 것 같으면 나한테 개발 테스크를 넘기지.

ㅤㅤ

앞으로 2주 동안은 어떻게 할거냐

사실 프로젝트 기간이 이제 2주 남았다고 하지만, 발표 자료 제출이 일주일 뒤라서, 2차 기능 확장 개발은 앞으로 월~수 3일 내에 끝나야 하고, 시연 영상 촬영이 최소 금요일에는 진행이 되어야 원활하게 발표 준비와 면접 준비를 할 수 있다. 내가 생각할 때 그냥 지연 발생할 것 같은 파트에 붙어서 무조건 개발 일단 진행해야 할 것 같다. 그래야 발표 준비든 뭐든 하지.

ㅤㅤ

이번 기회에 길게 줄줄 회고 글을 쓰고싶었는데, 프로젝트 마무리를 향해 달려가야 하는 시점이라 시간이 너무 없다. 프로젝트 발표랑 면접까지 종료가 되고나면 한 번 지난 프로젝트 기간과 6개월간의 과정에 대한 리뷰 겸 회고를 길게 한 번 작성해봐야겠다.

ㅤㅤ

이전까지는 그래도 하루에 진행한 것이나 배운 것, 트러블 슈팅한 내용들을 따로 글로 정리하거나 팀원들과 스크럼 시간에 짧게 나누면서 로컬로 기록을 남겨두고 있었다. 이번에 물꼬가 트였으니, 매일매일 TIL 작성을 하면서 하루하루 배운 것들을 남기기를 다시 시작해야겠다.