2024년 6월 회고

 

 

6월에는 본가에 내려가 고양이들도 케어를 하고, 아주 쭈무르고 왔다. 거기에, YOLO 모델을 만들면서 필요한 이미지 데이터를 수집하기 위해 현장에 나가 이미지 데이터 취득을 진행했는데, 개발자 노가다 뛰다.

 

 

5월 회고를 작성한지 아직 얼마 지나지 않았는데 또 6월 회고를 작성해야 한다. 회고록이 반성을 할 수 있는 계기와 내가 지금까지 해왔던 일들을 기록할 수 있는 순기능이 있는 반면, 조금은 회고록을 작성하기 위한 시간을 만들어야 하고, 작성해야 한다는 강박관념이 생겨 조금은 신경쓰이는 스트레스 정도가 생기긴 한다.  그런데도 회고 작성해야 한다라는 생각은 언제나 가지고 있다. 이게 다 나의 경험치고 추억이니 말이다. 이번 6월에도 5월에 이어 해외 여행을 다녀왔던 달이다. 여행이 있는 달은 언제나 몸이 들떠서 일의 능률도 확연하게 올라가므로 회고를 시작한다.

---

회사

2023년 9월부터 시작한 프로젝트는 10개월이 지나 이제 11개월을 달려가고 있다. 현재 가오픈까지 1달도 남지 않았고, 이 1달이라는 기간에 전체적인 준비보다도 일부 오픈만 하기 때문에 특정 기능들만 정상적으로 작동하면 아무런 문제 없는 오픈이 될 수 있다.

---

인터페이스(1차)

이번 6월에는 인터페이스에 대한 생각이 정말 많아졌던 달이었다. 기존에 웹개발을 하면서 인터페이스를 할 경우에는 거의 대부분 restful API 또는 SAP와의 인터페이스(DBCO 또는 RFC, EAI)를 많이 사용했었다. 근데, 하드웨어(기계, 로봇)와의 인터페이스는 처음이었고, 위의 방식이 아닌 TCP/IP 소켓 통신을 통해 진행하는 것으로 설계를 했었다.

 

HTTP 통신의 경우에는 클라이언트가 서버에 요청을 보내면 서버는 데이터를 리턴하는 형태의 단방향 통신이고, 소켓 통신의 경우에는 실시간 채팅처럼 누가 서버가 됐든 간에 서로 요청을 보내서 데이터를 지속적으로 주고받을 수 있는 양방향 통신이라  서로 데이터를 보내고 받는 형태로 인터페이스를 설계했었는데 기존 HTTP 통신처럼 설계를 바꿔버렸다.

 

설계는 기존에 소켓 통신의 특징들을 가지고 진행했지만, 결국 소켓통신을 가지고 HTTP 방식으로 설계가 변경이 되었다. 경력이 있는 분들은 기존에도 이렇게 사용했다고 하니, 하드웨어 와의 인터페이스를 개발하지 못했던 나는 의구심이 정말 많아 물어봤는데 예전부터 그렇게 써왔다고 하니 제대로 설득할 수 없었다.

 

내가 설계 했던 방법은 서버와 클라이언트 간 서로 요청을 보낼 수 있으니, 요청에 전달해야 하는 데이터를 담아 요청을 보내고, 해당 요청에 대한 결과를 response를 받는 것으로 하여 불필요한 체크 및 추가적인 인터페이스 횟수를 줄여 시간을 줄이려고 했지만 아쉽게도 이 방법은 사용되지 못하고 개발이 되고 있다.

 

추가적으로, 인터페이스 협의 및 전체 프로세스가 사전에 컨펌하여 해당 방향으로 개발이 됐는데도 이렇게 변했고, 일정이 빠듯하다고 하소연을 하니 미칠 노릇이다. 애초에 처음부터 서로 협의를 통해 만들어진 것인데 지금와서 프로세스를 바꿔버리고 방식도 바꾸니 어쩔 수가 없나 보다.

 

오픈이 1달도 안남았는데 아직 협의도, 개발도 끝이 나질 못해 관리하는 입장에서는 답답할 노릇이다.

---

인터페이스(2차)

로봇과 AI 서버의 인터페이스에 대한 계획과 일정에 대한 차질이 생겼다. 인터페이스의 경우 설계는 내가 진행을 했고, 설계가 잘 되든 안되든 컨펌을 한 이상 변동이 없었어야 했다. 혼자만 개발하는 것이 아닌 총 3개의 회사가 개발을 진행하기 때문에 전체적인 수정이 있을 경우에는 일정에 영향을 주고, 리스크를 감당하기에는 짧은 시간이기에 수정을 되도록 안하려고 했다.

 

기존 인터페이스의 구조는 기존에 우리가 알고 있는 서버와 클라이언트의 관계가 아닌 서버와 클라이언트의 개념을 무시하고, 오로지 인터페이스 통신 속도에 초점을 맞춰 설계를 했었다. 서버와 클라이언트가 있으면, 항상 클라이언트가 서버에 request를 보내고, 서버는 데이터를 담아 클라이언트에게 response를 보낸다. 근데, 이렇게 할 경우, 우리가 총 900번의 인터페이스를 진행해야 하는 경우에는 딱 2배인 1,800번을 수행해야하기 때문에 불필요한 인터페이스 통신이 증가하여 서버와 클라이언트 개념을 무시하고 3월~4월 사이에 설계를 진행하여 컨펌까지 완료하였다.

 

근데, 6월 중순을 넘은 말이 되던 날에 한 협력사(Z 사)에서 잘못 이해를 했다고 인터페이스를 전격 수정을 하자는 말에 이게 프로젝트 이슈에 올라가게 되었다. 3사에서 1개 회사를 제외한 나머지(X, Y 사)는 인터페이스 개발을 95%이상 완료를 하였고, Z사는 인터페이스 개발을 30%도 하지 않는 상황에 그렇게 뒤집어 버리니 X, Y사에서는 반발이 크게 생겼다. 인터페이스는 스탠다드가 있을 뿐이고, 언제든 상황에 맞게 변경하여 개발을 할 수 있는 것인데 그건 모르겠고 자꾸만 스탠다드만 고집을 하는 터이니 미칠 노릇이었다.

 

그렇게, X사에 양해를 구하고 다시 인터페이스를 어느 정도 수정을 하였는데 자꾸만 Z사에서 수정 요청을 하는 바람에 명세서 버전이 1.XX 버전에서 단숨에 3.XX 버전까지 올라갔고, 결국엔 Z사 자기들 입맛에 맞게 바뀌는 상황까지 완료되었다. 이제는 인터페이스 통신에 따른 시간에 대한 이슈나 효율성 및 성능 테스트 때 발생하는 이슈에 대한 책임은 Z사에 넘어가 버렸고, 기존 설계와는 완전히 다르게 되었다.

 

지금 6월 회고를 작성하는 7월 9일 시점에 이제는 Z사에 대한 의도로 다 바뀌었고, 아무런 테스트를 진행하지 않고 반영된 탓에 이슈가 발생할까봐 초조할 따름이다. 지금은 가오픈에 대한 대응을 진행해야 하니, 어떻게든 흘러가게만 만들어 놓고 다시 1차 시연 종료 후 2차 시연 진행 때 다 뜯어고칠 계획이다.

 

물론, 그렇다고 나한테 잘못은 없는 것은 아니다. 1차 설계를 진행할 때 Z사가 이해할 수 있도록 더 자세히 설명해야 했었는데 그러지 못해 Z사가 제대로 이해하지 못한 점이 가장 크다. 나같은 경우에는 프로젝트를 진행할 때, 스탠다드 개발도 진행을 해보고, 스탠다드를 더욱 더 복잡하게 커스터마이징을 진행하면서 복잡한 인터페이스까지 개발을 해본 경험에서 공유를 하지 못한 점이었다.

 

그리고, 해당 속도에 대한 논리적인 근거를 만들기 위한 문서도 만들어서 배포를 진행했어야 했는데 이 문제에 대해서는 조금 벅찬감이 있었다. 인터페이스 담당하는 것 뿐만 아니라 데이터 수집 및 추출, 분석, 전처리와 함께 소스코드 및 클라우드 관리, 타분야 개발까지 하고 있던 터라 문서 만드는 시간도 정말 부족했다.

 

그렇기에, 일단 7월은 조금은 유하게 인터페이스를 진행하고 8월부터는 다시 설계부터 완벽히 하여 진행할 예정이다.

---

Depth Camera 테스트

이번 6월에는 정말 다양한 Depth Camera를 사용해봤다. Intel 사의 D455, StereoLabs의 ZED2i, luxonis oak D pro W까지 총 3개의 Depth Camera를 다뤄봤다. 지금하는 프로젝트에서는 뎁스 카메라의 역할이 정말 컸는데, 카메라 특성 요소 중 FOV가 정말 중요했다. 처음에는 기존 설정에 따라 D455를 통해서 FOV 체크를 제대로 했었는데 커뮤니케이션 미스로 FOV에 대한 기준이 변동되었다. 그렇다 보니, FOV를 맞출 수 있는 카메라가 거의 없었고, 마지막 희망으로 Luxonis 사의 OAK D PRO W를 세로로 세워서 사용하게 되었다.

 

그래서, 직접적으로 관여하여 다뤄봤던 카메라는 OAK 카메라여서 해당 카메라 테스트를 진행했다.

2024.07.01 - [AI/Depth Camera] - [Depth Camera] Luxonis OAK-D Pro W 뎁스AI카메라 FOV 테스트 결과(Depthai Viewer)

[Depth Camera] Luxonis OAK-D Pro W 뎁스AI카메라 FOV 테스트 결과(Depthai Viewer)

 

테스트와 함께 촬영 방법과 Python으로 제어하는 방법들을 정리하면서 카메라 운용법과 기능들을 알게 되었고 어느 정도 가이드를 내릴 수 있어 괜찮은 시간이었다.

---

나고야 여행

6월에 일본 나고야 여행을 다녀왔다. 회사에서 프로젝트를 진행하면서 업무의 어려움보다는 다른 스트레스를 정말 많이 받았다. A라는 주제로 석박사 이상의 분들도 시간적 여유를 가지고 인사이트를 발견하는 것을, 우리는 시간적 여유도 없고 짧은 시간 안에 인사이트를 발견하려고 하니 정말 많은 방법을 통해 인사이트 도출하는 그 과정이 나에게는 큰 부담감으로 왔다. 제대로 된 정답이 아닌 "~하지 않을까?"라는 애매모호한 결론만 도출하게 되어 다시 인사이트를 발굴하는 도돌이표 프로젝트에 조금은 많이 지쳐가고 있어서 어느 정도 회고 여행 기간이 필요하여 여행을 다녀왔다.

나고야 나가시마 스파랜드 씽씽보트

 

 

나고야 여행도 관광도 관광이지만, 놀이동산을 주로 다녔었고 거기에 쇼핑과 모닝 런닝을 하면서 건강과 먹을 것, 즐길 것, 쇼핑까지 제대로 즐기고 왔다. 맛집 블로그에도 나고야에서 먹었던 것들을 정리해야 하는데, 지금까지 쌓여 왔던 글감들이 너무 많이 밀려 있고 시간이 많이 없어 많이 작성은 못하고 있지만 그래도 끝까지 정리를 할 것이다.

---

운동

이번 6월에는 운동을 다른 달보다 정말 많이 했는데 먹는 것도 정말 많이 먹었다. 84kg까지 감량을 했는데 먹기도 잘 먹고 운동도 잘해서 근육량도 올라 갔는데 체지방량도 올라갔다. 6월에는 몸무게 감량보다는 건강한 몸을 만드는데 많이 힘을 썼던 한 달이었다. 근데, 체력도 좋아지고, 살도 찌고, 근육량도 늘었는데 이게 건강하다고는 할 수 없다. 아직도 체지방량이 많으니 말이다.

 

6월에 런데이를 통해 런닝 크루를 만들었다. 월요일부터 일요일까지 일주일동안 10KM 런닝을 뛰면 된다. 총 3명이서 참가하는데, 공지사항은 아래와 같았다.

 

1. A - 일주일에 3번 (10분 이상)
2. B - 일주일에 10km 이상
3. C - 일주일에 10km 이상
--------------------------------------------
A - 60 → 55
B - 86 → 83
C - 92 → 87
※ 7월 31일까지
----------------------------------------------
- 런닝 목표 못 지킬 시 인당 ★5만원★ 벌금
- 벌금은 구질구질하게 변명없이 쿨하고 깔끔하게 납입요망
- 일주일에 뛸 시간은 많으니 구질구질하게 변명x 쇼츠 볼 시간 줄이고 뜁시다
- 몸무게는 개인 목표 설정 - 모든 기록은 런데이로만 확인
- 매주 월~일 정산
- 대체운동 -> 런닝머신 / 계단 오르기 / 싸이클 -> 모든 기록은 본인 기록 대비 거리&시간 절반만 인정
ex) 계단 오르기 10분 -> 5분으로 인정
ex) 런닝머신 20km -> 10km로 인정
- 스쿼트 or 버피테스트 -> 100회에 횟수 1번 / 1km로 인정
- 스쿼트와 버피테스트는 영상 촬영본만 인정-> 기록은 야외 코스 대비 1/2만 인정할 것 (영상찍기가 힘들면 뛰십시오 회원님)
- 예외적으로 스쿼트의 경우 카운팅 해줄 수 있는 어플이 있다면 인정
- 일주일에 4일 이상 비가 올 경우 기준 완화
- 진료 기록서 제출 시 기준 완화
- 경조사는 장례식 이외에 해당 X
- 적응기간 한달 가진 후 개인별 능력에 따라 기준 상향할 것
- 회원님들 적응 후 노들섬&여의도 런닝 / 인왕산&관악산 등산 예정 

 

그냥 일주일에 10km를 뛰면 된다. 비가 오면, 스쿼트나 버피, 런닝머신 뛰면 된다. 이렇게 해서 지금까지 3주동안 진행을 하고 있고, 이제는 날이 지날 때마다 운동할 시간이 얼마 남지 않았다는 강박 관념에 강제로 운동하고 있다. 벌금 5만원 내기 너무 아깝다. 5만원이면 주식산다.

 

 

무튼, 이번 6월에도 잘 달렸고, 7월에도 10키로 잘 채우려고 한다. 7월에는 태국 여행이 있는데, 모닝러닝을 할 것이다.

---

7월 목표

1. 인프런 AWS Certified Solutions Architect - Associate 자격증 준비하기 강의 완강
2. github 다시 시작하기
3. 몸무게 감량 83kg 달성
 
끝.

---