230718 화요일 업무 TIL

'오늘 나에게 한마디'
오늘은 굉장히 피곤했다. 사실 일을 하면서도 몇번 졸았다. 확실히 체력이 많이 깎였다는 것을 느꼈다. 그래서 오늘은 칼퇴를 하며 집에서 휴식을 하고 나니 그래도 피곤하게 많이 가시는 느낌이었다. 내일을 위해서 오늘을 조금 아껴두는, 그런 자세도 필요한 것 같다. 그리고 오늘 칼퇴한 덕분에 오랜만에 비온 뒤의 맑은 하늘을 볼 수 있어서 감사했다.


'오늘의 고민'
내일 preview 홈페이지가 나가면서 미리 dev 환경에 팝업을 띄워야 했는데, 아직까지도 퍼블작업이 이뤄지지 않아 어떤 데이터를 삽입해야 하는지, 신규 추가 데이터에 대해서 프론트엔드 팀원이 먼저 개발을 하고 > 나는 그것을 토대로 데이터 컬럼을 어떻게 추가해야하는지 파악해야 하는데 아직 퍼블리싱이 넘어오지 않아 dev 환경에 미리 구축을 하지 못하였다. 내 잘못은 아니지만, 업무 담당자 중에 한명으로서 마음이 조급하다. 

---

[잘한점]
상황1) terminal로 블록체인 이벤트를 수신해오는것과, kubernates의 pods를 이용해서 블록체인 이벤트 수신의 차이점은 무엇일까? 둘이 같은 결과를 내는 것 같은데?라는 고민이 들었다. 
액션1) 궁극적으로 같은 결과값을 내는 것 같은데?라고 생각했던 결과에 대해 차이점이 긴가민가하여 곰곰히 생각해보다가 혼자 결론이 안나서 팀원에게 질문하였다. 

칭찬1) 겉으로 봤을때는 큰 차이가 없어보이지만, 알고보면 둘의 경우 상황에 따라 블록체인 이벤트를 언제부터 수신해야 하는지로 갈린다. 이런 차이점을 이제 알게 되었으니 다음번에 블록체인 이벤트를 수신할 때 상황에 맞게 적절하게 이벤트 데이터를 받아올 수 있을 것 같다. 

---

[개선점]

 

개선점이라기보다는, , 앞으로 적용해보면 좋을 것 같은 점 

문제1) 업무 회고 자리가 있었는데,  나와 한 팀원을 제외하고는 모두 자신이 맡았던 업무에 대한 회고를 했었는데 나와 다른 팀원 둘만 자기반성을 했다. 

원인1) 둘다 자아성찰을 잘 하는 사람들이라고 하자 ㅎㅎ 

액션플랜1) 다음번에 회고자리가 있을때는, 내가 맡았던 업무에서 느꼈던 점들과 + 자기반성을 적절히 섞어서 하면 좋을 것 같다. 

 

문제2) 회고자리에서, 백엔드 개발자가 자신이 만든 API의 목적을 모르는 경우가 있는 것 같다는 지적이 있었다. 

원인2) 아무래도 '마켓플레이스'라는 큰 틀의 경우 여러 기능들이 유기적으로 많이 얽혀있다보니, 내가 지금 이 API를 작성하는 목적이 무엇인가?에 대해서 잊을 때가 종종 있었던 것 같다. 이는 업무 집중도가 흐려지는 문제점을 낳기도 하였고, 직접 겪기도 하였다. 

액션플랜2) API 목적에 맞게끔 설계하는 것이 정말 중요하고, 무엇보다도 프론트엔드 팀원과 효율적으로 소통하는 것이 정말 중요하다고 생각했다. (지금도 소통을 안하는건 아니지만, 더 효율적인 소통을 찾아야 할 것 같다) 

 

 

---

[배운점]

배움1) 팀장님의 경우, 자신이 성장했다고 느꼈을 때가 '코드를 보지 않고도 이해가 된다'라고 하셨을때다. 내걸 빨리 만들어야겠다고 생각하셨으며, 나라면 어떻게 했을까?에 대해 끊임없이 고민하셨다고 한다. 

의미1) 나는 현재 이 로직이 단순히 돌아가기만 하면 된다/결과값이 나오면 된다 라는 측면에서만 API 개발을 해왔던 것 같다. 다른 팀원의 코드를 보아도 단번에 이해하기는 쉽지는 않지만, '나라면 어떻게 할까?'에 대해 생각을 한 적이 거의 없는 것 같아 반성하게 되었다. 앞으로 공부할때나 다른 팀원의 코드를 볼 때 '나라면 어떻게 할까?','이 방법 적용해보자'라고 직접 생각하고 실천하는 자세가 중요하다는 생각이 들었다. 

 

배움2) 쿼리가 만능이다 생각하는 개발자 vs 쿼리 조회보다는 어느정도 로직으로 해결해야 한다 

이에 대해 둘 중 어느것도 100% 정답은 아니다. 

의미2) 상황에 맞게 쿼리를 써야하고, 무조건 쿼리를 쓴다고 해서 능사도 아니고, 무조건 로직으로 해결해야지!도 답이 아니다. 그런 상황 판단이 빨리빨리 되는 개발자가 되고 싶다. 

 

배움3) 프론트엔드측에 entity로 응답을 내려줄지, DTO로 응답을 내려줄지에 대해서 아직 큰 차이점을 모르겠다. 일단 DB에 접근하지 않고도 응답을 내릴 수 있다면 DTO로 처리해야겠다고 생각이 들지만, 정확히 어떤 상황에서는 entity로 응답을 내려주고, 어떤 상황에서는 dto로 응답을 내려줘야 하는지에 대한 감이 크게 잡히지 않은 것 같다. 

의미3) 이에 대해 백엔드 팀원들끼리의 논의도 필요할 것 같다.