8월 마지막주가 지나고 9월이 시작된지 11일 째

8월 마지막주에 대한 회고 작성이 늦어졌다. 그동안 너무 바빴다. 지금도 그렇지만

트레바리 마지막 모임이 있었다.

트레바리는 독서모임인데 4개월의 비용을 지불하고 참가하게 되었다. 이전까지는 독서모임이라던가 사교모임과 같은 다양한 사람들을 만날 기회가 있는 모임에 참석해본적은 없다. 6월에 갑자기 경험해보고 싶다는 생각, 또 이왕이면 책에 대한 이야기를 나눌수 있으면 좋겠다는 생각에 독서모임인 트레바리에 참가하게 되었고, 총 4번의 모임 중 1번을 제외하는 참석하였다.

독서모임을 해보고 싶은 사람이라면 또 적극적인 의견을 내고 싶은 사람이라면 트레바리를 해보는것도 나쁘지 않겠다라는 생각을 했다. 비용이 비싸게 느껴지기는 했지만 그만큼 모임에 자진 참석 해야하는 강제성이 생기는게 아닐까하는 생각도 들었다. 조금 더 시간이 여유로웠다면 좋았을 것을....

책을 읽는다는건 생각보다. 여유로운 시간이 필요한 일이라는 것을 이번에 느꼈다. 강제적으로 책을 읽어야 하는 상황에 놓인건 좋았지만, 책을 읽고 공감한다기 보다는 어떤 이야기를 하면 될까라는 생각이 먼저 들었고, 독후감 제출 시간안에 읽어야 했기 때문에 마냥 쉬엄쉬엄 읽기에는 어려움이 있었다.

8월 마지막인 1주일은 긴장이 되는 나날이 연속되었다.

8월 26일 월요일 그동안 준비했던 시스템이 오픈되고 사용자들이 문제 없이 시스템을 사용하고 있는지 모니터링을 해야했다.

역시나 생각치 못한 상황들이 많이 발생을 했고, 처리하면서도 많은 고민과 생각이 드는 것이였다.

1. 실제 결제가 이루어 지기 때문에 결제가 정상적으로 이루어져야 했다.

2. 결제 방식에 따라 사용자의 상태값이 변경 되어야 했다.

3. 결제 방식에 따라 사용자의 실제 결제 상태에 대한 알림을 PG사로 부터 노티 받아야 했다.

4. 특정 방식에서는 3.을 처리하는 동안에 실제 입급이 이루어져야하는 텀이 존재했다.

결제모듈을 연동하는건 이번이 처음이였고, 회사 자체의 결제를 처리하는 것이 아니라 고객사의 요청에 의해서 모듈 연동을 진행하게 되어서 더 떨리는 부분이였다. 

다행이도 결제는 무리 없이 진행되어서 컴플레인에 대한 문제는 한시름 놓은 상태였다.

긴장감이 떨어질때 쯤 집중력도 함께 떨어지는듯 하다.

그러면 그동안은 생각하지 못했던 다른 프로젝트와 일정에 대해서 생각 나게 된다.

잠시 미뤄 두었던 일들

앞으로 예정 되어 있는 일정들

하나씩 처리하다보면 여유 있는 날들이 오지 않을까 한다.

요즘하는 업무는 검증 과정에 대한 데이터를 뿌려주는 cms 프로젝에 투입이 되어 열심히 쿼리를 짜고 있다.

되도록이면 하루에 1개 이상의 작업은 완료를 하려고 하다보니 퇴근이 틎어 질떄도 있지만, 하루에 1개도 못할때가 있다면, 정말 잠을 자기 전까지는 그 부분이 머릿속에서 떠나지 않는다.

일반적인 CRUD라면 빨리 빨리 처리할수있겠는데, 데이터를 비교해서 뿌려주거나, 아이디값만 올려 그대로 다시 insert하거나 하는 경우가 많다.

그래도 곧 끝나가는 시점에 짧게 나마 기록을 해두고자 한다.

이번 프로젝트를 진행하면서 느낀것은 1. 팀인원 2. 분석 설계 과정의 중요성 3. 커뮤니케이션 이다.

되도록이면 팀인원의 밸런스가 정말 중요하다고 느껴졌다. DBA,Backend,Frontend 등등 뿐만아니라 PM의 역할까지도,

이러한 점은 분석설계과정이 미비할수록 더 잘 느껴지는 것이 아닐까하는 생각을 해보는데, 일정이나 , DB설계, 구조, 개발방법 등등 개발에 들어가기 앞서 진행되어야 하는 것들이 어느정도 (내생각에는 90%)가 완료되어야 개발 단계에는 불편함이나, 힘든 시간을 보내지 않을 수 있지않을까?

이런 분석설계가 잘 이루어져 있지 않다보니, 테이블 정의서 없이 DB 테이블을 수정해야하는 일이 빈번해지고, 테스트를 위한 임의데이터의 결점도 많아져 쿼리를 계속 수정해야하는 일이 잦아 졌다. 물론 내개발 실력의 문제일수도 있지만, 1.팀인원에 대한 문제와 귀결되는 사항인데, 앞단 뒷단 할것 없이 개발을 해야하다보니 한가지에만 집중하기 어려운 점도 있기는 하다. 특히나 어떤 기능에 대한 확정적인 답변이 필요로 해야하는 빈번하게 발생한다는 점이다. 각 화면에 대한 기능 정의나 설계가 부실해 그때그때 마다 구현 방식이 바뀌게 되고 이게 맞는지 아닌지에대한 설명도 애매해질때가 많고, 팀원 중 한명은 개발을 중점으로 하는게 아니라 이러한 문제를 해결하려고 커뮤니케이션에 할애하는 시간이 훨씬 많다. 

코로나 시대에 접어들면서, 또는 비대면 시대에 접어 들면서, 대면으로 하는 미팅이나 대화가 많이 줄어든 상태이다.

비대면으로도 업무가 정말 잘 진행 된다면 좋겠지만,짧은 시간안에 빠르게 진행되어야할  문의사항에 대한 결정이나, 협의사항을 이야기하는데에는 대면이 훨씬 능률이 좋지 않을까?

많은것을 느끼고 배우고있는 프로젝트가 이제 막바지를 향해 달려가는데 끝나면, 제주도로 떠나야지

마음 먹고 출근하는 날

Overview

- 시각화를 위해 사용할 라이브러리로 react-google-chart 와 d3.js 중 택 1

- d3는 좀더 내 입맛에 맞게 변형하기 위해서는 공부가 필요할 듯 하다.

- react-google-chart는 이전에도 사용해 봤기때문에 손쉽게 사용가능하나 변형을 위한 options을 잘 확인해야 한다.

#회고

오늘 하루는 차트와의 싸움이였고, 데이터를 처리에 많은 시간을 사용했다.

좀 더 능숙하게 다루고싶지만, 이것저것 잡생각이 많이 들어서 어려운것 같다.

리액트보다는 vanilla 가 좀더 좋은 것 같기도...

개발환경 세팅은 언제나 재미있지만, 많은 시간을 잡아 먹는 것 같다. 그래도 예전보다는 빨라 진듯 하다.

글을 쓰는데 생각이 많이 든다. 그래도 우선 적어보자.

사용방법에 대한 정리를 해보자!!

다시, 다시, 다시

프로젝트를 진행하다보면 저번에 엎어졌던게 다시금 시작되기도 하고, 다시 엎어지기도 하는 것 같다.
특별하게 어려운 점은 없지만, 지금와서 생각해보면 컨디션이나, 체력 관리 측면 보다는 일에 대한 의지를 유지하는게 중요한것 같다는 생각을 다시금 하게 된다.

오늘 기록

역시 DB를 다루는것은 항상 고민을 하게 만든다.
오랜만에 aggregate를 사용한 query를 짜는데 있어서 시가닝 좀 더 많이 소요되는 것을 느꼈다.
항상 많은 데이터를 다루다 보니, 결측치를 찾지 못하고 DB에 넣는 경우를 많이 보게 된다.
테스트를 하는 것이 좋겠으나, 요즘들어서는 인력이 많이 부족한게 아닌가를 많이 생각하게 된다.

일을 시작하고 나서는 부터는 업무파악이나, 프로젝트를 따라가는 것에 바쁘다보니, 책을 읽을 시간이 많이 없었습니다.

물론 그 전에도 많은 책을 읽지는 않았지만,

요즘들어 여유가 생기고 나서부터는 책을 읽기 위한 시간을 가지고 있습니다.

특히나, 프로젝트를 진행하는데 필요한 지식들이 많이 있기도 하고, 유튜브나 구글링에서 보는 것에 조금은 지친 탓에 프로그래밍에 관력된 서적을 많이 보는 편입니다.

회사에서는 필요로 하는 책을 수입해주기 때문에 편하게 볼 수 있지만, 개인적인 서적도 필요로 함을 느끼고 있습니다.

그런데 아무리 책을 사도 부족함이 없다고들 하지만, 가격도 가격인지라, 도서관을 이용할때가 많습니다.

다행이도 구청이나, 학교가 가까이 있어 책을 빌리는 것에 크게 어려움은 없습니다.

역시나 빌린 책을 반납하는거는 너무나 귀찮은 일

이런저런 고민을 하면서 알게된 것은 서울도서관 전자책 서비스입니다.

의외로 필요로 하는 책들이 많이 있고, 카테고리도 다양해 전문서적이 아니더라고, 재미있는 책들이 많이있습니다.

https://elib.seoul.go.kr/ebooks/main.do

안드로이드 뿐만아니라, ios 앱도 있기때문에 PC , 모바일에서 대출한 전자책들을 볼 수가 있는 점이 너무 좋습니다.

물론 없는 책들은 구입을 하는 편입니다.

책을 읽고 난 후에 후기도 작성해 보면 좋을거 같은데, 쉽지가 않습니다. 하하하

회사에서는 정말 다양한 직군들이 있습니다.

이중 개발자와 함께 협업을 진행할 경우 어떤식으로 대화를 이어나가는지 궁금하기도 합니다.

현업 개발자로 일하고 있지만, 

팀간, 개인간에도 용어통일이라던가, 각자 사용하는 언어가 달라 가끔 그 의미에 대한 질문을 하기도 합니다.

하지만, 대체로 크게 개발자간 이야기에서는 크게 문제 될 것 없이 이야기가 흘러 갑니다.

요즘은 마케터, 데이터 사이언티스트 등과 이야기할 경우도 많고, 개발에 대해 배우고 싶은 분들에서 조금이나마 파이썬에 대한 교육같은걸 하고 있습니다.

특정 데이터를 요구할 경우 개발자에게 어떠한 내용을 전달 하면 좋을지 궁금해 하는 분들도 종종 있었습니다.

이런한 상황에서 가장 크게 느꼈던점은 용어에 대한 혼동이 정말 빈번하다는 점입니다.

"변수에 값을 할당한다."

"변수에 값을 대입한다."

"매개 변수, Parameter, Argument"

비전공자 또는 개발자가 아닌 사람들을 위한 IT 용어들에 대한 책도 많이 나오고 있습니다.

또 어떠한 문제를 냈을 경우 문제에 대한 답을 이끌어 내기위한 정확한 워딩이 필요하다는 점입니다.

예로 

"1 부터 100까지 출력하는 코드를 짜보세요."

라는 이야기를 했을 경우 개인마다 생각하는 코드 작성방법이 다 다르기때문에 문제에 대해 정확한 워딩도 필요하다고 느낍니다.