23년 회고록을 작성한지 얼마 안된거 같은데,,,사실 아닌거 같다. 기억도 안난다. ㅋㅋ
벌써 24년의 마지막이라고 생각하니,, 1년 마다 모두들 돌아오는 회고 시즌이다.
개발자 적 회고도 하면서 개인적인 회고도 좀 해보려고 한다.
사실 이번 년도 할말 많은건 ㅎ 안비밀
아무튼 좀 길어질듯 하니,,적잘한 짤을 섞으면서 시작하겠습니다.
직무 전환
사실 제일 큰 이벤트는 이게 아닐까 싶다.
본격적으로 소장님이 교체가 되면서, 소장님이 처음으로 진행했던 건 결국 저의 위치 였습니다.
우리 회사에선 더 이상 DevOps라는 업무가 필요가 없다,,그리고 그 업무를 연구소가 들고 있는 건 더더욱 안된다.
사실 구구절절 얘기하기엔 작년도 회고집을 들고와야하기에, 작년꺼에 젹혀 있나..?
무튼 AWS를 사용하는 인프라팀으로 갈건지 혹은 직무를 전환해서 연구소에 남을지,,에 대한 문제였습니다.
사실상 연구소에 남아 있으려면 백엔드든 프론트든 했어야했죠.
그래서 사실은 백엔드를 먼저 지원을 했지만, SQL을 깊게 다뤄보지 않는게 원인이 되어서 프론트로 당첨!
사실 등 떠밀려서 그런건 아닙니다. 제 입장에서는 둘다 그닥..? 이긴 한데, 지금 회사는 당장의 퍼포먼스가 그래서 나오냐? 이게 더 중요 했었습니다.
그래서 제일 익숙했고, 제일 많이 다뤄봤던 FrontEnd 개발자 탄생하게 됐죠...⭐️
처음으로 겪는 협업
사실 제가 회사에 오고 난 이후 부터는 협업 이라는 개념이 없었습니다.
사실 DevOps와 서버를 다루는 일을 혼자 수행했기 때문이죠,
그리고 외주 작업도 했지만, 제가 리드를 했고, 사실상 거의 작업 자체는 혼자했기에, 제대로된 협업을 수행했던건 이번이 처음인 것 같습니다.
처음 수행하는 협업에 많이 attack 당했습니다
히히… 뭐 사실 대부분은 소통의 문제 입니다.
일을 했는가? 언제 햇는가? 거기서 나오는 문제점은 무엇인가? 오류는 없었는가?
일을 하면서 나오는 복합적인 문제들은 무엇인가?
해당 일이 어느정도면 끝나는가?
그래서 이 일을 어떤식으로 구현했는가?
전형적인 SI 형태의 프로젝트라면, 일을 하는데 협업? 그게 중요한가? 기한을 못맞추는게 문제지! 라고 생각을 했을수도 있습니다.
하지만, 우리는 연구소고, 우리가 문화적으로 변화를 만들지 않으면, 아무도 그에 대한 생각을 하지 않을 것이다.
라는 생각으로 저희 만이라도 실험적으로 조금 타이트하게 적용했던거 같습니다.
처음에는 협업도 처음, 이런 방식도 처음이다 보니, 익숙치 않다보니, 적응하는데 오래 걸렸습니다.
차츰 익숙해지고, 하다보니, 보고를 하고 소통을 하는데도 시간을 쏟아야하는 거라는 걸 좀 느꼈습니다.
일하는 시간이 무조건 개발하는데 쏟기 보다는 적절한 시간 배분을 통해서 보고를 깔끔하게 하는 것 까지도 일이라고 치는 걸 이제야 깨닫게 됐습니다. ㅎㅎ
아직도 부족하긴 하지만..조금더 신경을 쓰게 된다면, 나아질거 같다는 생각이 듭니다.
내년도에는 조금 Jira를 배워보면서 자동화에 대한 걸 공부 해볼까 생각을 좀 다방면으로 하고 있습니다.
쓰다보면서 느낀 거지만, 협업과 일하는 방식 요론 책을 좀 읽어 봐야겠군여
개발
이번에는 조금 각잡고 개발에 집중했던거 같습니다.
외주도 하면서, 회사에서도 개발을 동시에 진행하니 자체 하드코어 난이도로 공부를 하고 일을 하다보니,, 어우 실력은 정말 확실히 오른 것 같습니다.
진짜 5년은 늙었다는 기분으로 진행한거 같습니다..
무튼 저희 팀에서는 클린코드 스터디도 진행햇고, 사내에선 유일하게 테스트 코드라는 개념을 도입해서 저희가 처음으로 시도를 해봤습니다.
역시 테스트 코드는 si 처럼 뒤로 미루게 되더라구요 ㅋㅋㅋㅋ
결국 목표가 테스트 코드 작성이라 막판에는 그렇게 진행을 했지만,,,,무튼 올해 개발적으로는 굉장히 많이 성장하면서도, 많이 생각하게 만든 계기가 된거 같습니다.
테스트
테스트에 대한 부분은 지금까지는 사실 로컬에서 띄워 놓고 개발을 했다면,
이제는 테스트 코드를 가지고 화면이 아닌 코드를 통해서 테스트를 할 수 있다는 점이 장점으로 다가왔습니다.
어느정도 기능을 모두 개발을 하고, 테스트 코드를 작성하면서도 오류를 발견했었던 경험이 있습니다. ㅋㅋㅋ
확실히,,,잘만 테스트를 한다면, 오류의 대부분을 잡을 수 있겠구나 라는 생각이 좀 강하게 들면서,,
테스트 커버리지, 테스트 종류 등등을 좀더 심도 있게 본 것 같습니다.
아직까지는 걸음마 단계지만, 추후에는 JS DOM에 대한 부분도 테스트로 어떻게 녹일까..
그리고 저희는 Grid를 라이브러리로 사용 중이라서, 이에 대한 ui 테스트가 전혀 되지 않는데,,,이 부분을 좀 해결하고 싶은 생각이 되게 강렬하네요 ㅎㅎ
내년에는 반드시 이문제는 해결 하리라..
구조, 설계
사실 저의 연차에서는 구조가 어떻고, 설계가 어떻고 하는 그런 얘기는 받아드릴 수는 있지만, 적용은 어렵다고 생각이 듭니다.
그럼에도 불구하고, 부족한 지식으로 얘기를 해보자면, 구조 설계에 대한 얘기가 나올 만한 부분은 아니었습니다.
그렇지만, 제가 맡은 한 부분에 요청사항이 매우 큰 편이었습니다.
업무 시스템에서 Grid 시스템이기에, 각종 원하는 기능과 규칙들이 굉장히 많았고, 데이터 컨트롤 부터 유효성 검사까지 커스텀 해야하는 양이 매우 많았습니다.
그렇다보니, 한 파일 내에 코드의 양이 매우 많아지면서, 클린코드에 의해서 파일을 분리 조치를 취할 수 밖에 없엇습니다.
사실 그냥 보기에도 양이 너무 많기에,,, 어쩔 수 없는 분리 조치,,그리고 이왕 분리 조치를 할거라면 이후에 확장성까지도 고려하면서, 좀더 많은 부분 커버 되도록 많은 고민을 하면서..1차 구조 수정..
그리고 결국 5번 넘게 고침^^
사실 이거 구조를 짜려고 몇 주 동안 머리 싸매면서 고민을 했지만, 결국은 그 때 당시는 이 이상 못하겠네,, 이런식을 구조를 짰다고 생각하지만, 결국 상황이 닥친다면, 결국은 수정해야한다 ^^
그러다 보니 생각이 든건 아래의 구조 처럼 짜게 되게 됐습니다.
사실 Application의 디자인 패턴 마냥 정말 복잡한 구조를 설계한 건 아니지만, 경험이 없는 상황에서 구조를 조금 더 보기 쉽게 짜려고 하다보니, 고민이 생겼던 것 같습니다.
Java가 아닌 JavaScript이이게, Class 사용이 익숙하지 않고, 그리고 사용하고 싶어도 사내에서는 class 도입을 규칙으로 세우지 않았기에, 되도록이면 class를 사용하지 않고, 모듈화를 진행했습니다.
구조 개선을 할 때, 이제라면 어떻게 시작할거냐? 이 부분에 대해서 잠시 얘기를 한다면, 결국은 해당 로직이 위에서 아래로 내려오는 단방향을 그린다고 가정했을 때, 위 그림 처럼 가지를 쳤을 때, 가지를 칠만한 요소들을 정할 것 같습니다.
만약 6개의 공통점이 있다면, 처음부터 1개씩 1개씩 나워서 6개의 가지를 치기 보단 처음부턴 3:3 혹은 4:2 정도로 나눕니다.
그리고 그 이후에 필요에 의하면 하나씩 차례대로 늘려나가는 것이 지금이라면 그렇게 할 것 같네요
위 그림 처럼 처음 부터 1씩 쪼개는 행동을 맨 처음에 했더니, 나중 되면 1끼리의 통신을 해야하는 경우에는 굉장히 애초에 구조적으로 안되는 경우가 너무 많이 생기는 경우가 많았습니다.
사실 초반에 구조를 짤 때는 어떻게 어떻게 나눌 것인가를 너무 세부적으로 나누려고 노력했던거 같습니다.
처음에는 뭉텅뭉텅 나누고 이후부터 세부적으로 나누면 되는 것을 처음부터 MSA 마냥 잘게 쪼갠거 같습니다 히히
그래도 중요한 경험 했다 생각하고 있습니다.
package 화
처음으로 nexus를 설치해보고 본격적으로 nodepacakge를 사용해봤던 해 인거 같습니다.
실제 package화를 하는 방법에 대해서 심도있게 알아보지 못해서 그건 조금 아쉬웠습니다.
회사 사수분이 우아콘에 갔다 오셔서 말한 MSA Front 에 대한 기술에서 package 화가 핵심인듯 해보이는데
프론트 많이 했다고 생각 했지만, 항상 부족하다고 저에게 일러주는 기분이네여 흑흑
내년의 목표로는 프론트의 패키지화에 도전해서 MSA를 조금 도전해보려고 합니다
히히 재미게따
마무리
이번 회고록을 적은 이후는 사실 12월에 저는 잠시 울산에 파견을 갑니다.
히히히히 즐겁다 히히히히히힣
그래서 회고록을 미리 작성하는 것도 있습니다.
사실 이 전에 이미 회사에서 나의 성과에 대한 걸 적어봐라..
이 성과 평가에 대한 얘기가 있어서, 오랜만에 내가 1년 동안 뭘 했는지 곰곰히 생각해보았습니다.
근데 정말 24년은 정말 열심히 살았더군요
회사 계정과 개인 계정과 분리 된 것 치고도, 절반 정도는 거의 개발 커밋도 올렸고,
사실 저희 회사가 24년4월 부터 github 를 쓰기 시작했다는거 감안하면
뭐야 뭐이리 많이 했어 나 개발만 하고 살았나?
https://www.devdubu-note.co.kr/
위 처럼 obisidian에 자료도 많이 작성하고, 사실 올린거보다 안올린게 더 많다는건 안비밀...
나름대로 정말 징글징글 열심히 살았다고 생각이 드네요,,그런데도 좀 아쉽다고 느끼는 건 욕심이겠죠..?
개발도 가고, 다른 타 소모임도 참여하고, 운동도 배드민턴은 다시 시작하고, 헬스도 시작했다보니,, 생각해보니 올 한해 여행을 간적이 저번 강원도 제외하고 본격적으로 간건 없네요 ㅎㅎ
너무 열심히 살았나 싶기도 하고, 조금은 느슨하게 살아도 됐을까나 생각이 드는 한해 이네요
그래도 제일 다행인건 24년도 무탈하게 지나갔다는 거 아닐까요???
다들 24년 연말 잘 보내시고 1년 뒤에 뵙겠습니다!!
다들 24년 고생많으셨습니다
'잡담' 카테고리의 다른 글
| AI 관한 개발자의 고찰 (7) | 2025.06.08 |
|---|---|
| 새 블로그 홍보 (0) | 2024.11.28 |
| 강릉 무작정 여행 (1) | 2024.10.21 |
| 추상적인 가치 (18) | 2024.07.23 |