올해부터는 매월 회고를 해보기로 했다. 이유는 양이 너무 많아져 작년 회고를 아직도 쓰지 못했다. 시작할 엄두가 잘 나지 않았던 것 같다.
작년 결산에도 쓰게 되겠지만, TIL을 작년 1월 4일부터 쓰기 시작해서 1년 하고도 1개월이 지났다. 이렇게 꾸준히 뭔가를 작성 해본적이 없었던 것 같은데 해가 바뀌어도 잘 하고 있는 나에게 칭찬을 해줬다 ㅎㅎ
1월은 대부분 인턴에 관한 얘기일 것이다. 마침 스쿱과 was 프로젝트를 일시정지하게 되기도 했고, 일정이 촉박하게 느껴져서 인턴에 최대한 집중했다.
면접때도 느꼈지만, 회사의 첫인상이 너무 좋았다. 빠르게 성장하는 큰 회사에 있는 것 보다 더딜 수도 있지만, 안정적으로 성장할 수 있을 것 같은 느낌이 많이 들었다. 내가 생각했던 것보다 많이 체계적이멶서도 최대한 유연하게 운영하려 노력하는 것 같았기 때문이다. 물론 이미 다니고 있는 분들의 의견은 다를 수도 있겠다. 그리고 이전 직장과 완전 정 반대라 그럴 수도 있겠다. 회사가 큰 발돋움을 하기 직전이라 그런 것 같기도 하다. 이 부분은 운이 좋은 것일 수 있겠다.
처음 1~2주는 맥에 적응하느라 애를 먹었다. iOS를 쓰면서도 많이 느꼈지만, 나는 애플과 궁합이 별로다(그러면서 아이폰에 에어팟 프로를 쓴다. 거기에 아이패드 미니까지 고려하고 있다..ㅋㅋ).
어찌됐건 커스텀할 수 있는 옵션들과 앱들을 최대한 깔아서 활용했다. 이제 꽤나 적응이 돼서 윈도우와 키가 헷갈리는 시점이 왔다. 그리고 개발할때는 사실 큰 차이를 모르겠다. 많은 사람이 반발을 할 수도 있겠지만 개인적으로는 개발 자체만 두고 봤을때 윈도우가 특별히 편한 부분은 없지만, 반대로 맥으로 한다고 좋은 것도 아니었다. 단축키만 헷갈릴 뿐... ㅋㅋㅋ.
결론적으로 대부분의 회사에서 맥을 사용하니 시즈모드용 맥북 프로 + 휴대용 윈도우 노트북 + 게임기 데스크탑이 최고의 조합이 아닐까 하는 생각한다. 아니면 개발해야할때는 노트북에 리눅스를 넣어도 괜찮을 것 같다. zshell을 쓰면 어차피 다 똑같을테니까.
재택할때가 좀 문제인데 여러 방법을 강구해봤지만 일단 독을 좋은걸 사야 뭔가 해결이 될 것 같다. 그런데 조만간 100와트가 넘는 규격이 나올 것 같은데... 일단 인턴 합격 뒤에 새걸로 받게되면 다시 생각해봐야겠다.
첫 주는 애드테크에 대한 공부를 하고 발표를 했다. 면접 후 딜리언즈 톡에서도 그랬지만, 어떤 광고를 할 수 있을지 궁금했는데 배민 앱처럼 생각해보라는 말을 들으니 바로 이해가 됐다.
하지만 그럼에도 생태계 자체가 어떻게 되어있는지는 생각하지 못했는데, 아예 도메인과 산업이 크게 존재하고 있었다. DSP와 SSP 그리고 DMP와 CDP가 현재의 핵심 쟁점인 것으로 생각된다. 발표 후 CDP에 대한 설명이 좀 빈약해서 이해하기가 어렵다는 피드백을 받았는데, CDP를 다 알고 있을 것이라 생각했지만 직접 사용하는게 아니고 여전히 DMP가 중심이니 모두가 자세하게 알고 있는 것은 아닌 눈치였다. 이럴 줄 알았으면 조금 더 자세하게 설명을 할 걸 그랬다.
다시 찬찬히 살펴보니 정말 열심히 조사하긴 했다 ㅋㅋ. 내용을 바탕으로 좀 더 다듬어서 포스팅을 해봐도 좋을 것 같은데.. 일단 인턴이 끝나면 생각해보자.
인턴 과제는 작은 애드테크 플랫폼을 만드는 것이다. 현재 회사에서 구성되있는 것과 유사한 구조를 요구사항으로 제시해주셨다.
여러 매채와 연결시키는 것이 아닌 회사가 직접 보유하는 매체를 판매하는 것이기 때문에 DSP를 중심으로 돌아가고 중간에 RTB가 이루어진다. 사내 SSP가 있지 않을까 했는데, 그렇지는 않은가보다.
첫 주는 설계에 시간을 쏟았다. 클래스 설계에 꽤 신경을 썼는데, 데이터 구조가 간단하기도 했고 여러 컨벤션을 지켜가면서 어려울 것이라 생각해 전체적인 큰 그림을 최대한 공유할 수 있도록 하고 싶었다. 아직까지는 유효했던 것 같고, 놓치는 부분도 계속 체크하면서 진행하기 좋았다. 피드백을 받았던 것 처럼 문서가 계속해서 최신화 되지는 않았지만, 서로 같은 큰 그림과 마인드셋을 가지고 간다는 부분에서는 큰 성과가 있었다고 본다. 서로 생각하는 방향이 달라도 일정 범위를 넘어가진 않았다.
설계에서는 상태 다이어그램이 엄청 어려웠는데, 그 동안 행동이 중심이고 상태는 따라오는 것이라 생각을 해서 그랬던 것 같다. 그런데 시스템이 복잡해지고 상태에 영향을 주는 부분이 여러개가 된다면 특정 행동과 프로퍼티들의 조합만으로 정확한 상태를 검증하기 힘들어진다. 검증할 수 있다해도 한 눈에 흐름을 파악하기는 힘들다. 그래서 특정 상태로 갈 수 있는지 없는지 판단을 해줄 뭔가가 있으면 생각이 편해진다.
특정 상태로 넘어갈 수 있는 제약이 여러개가 있으면 그걸 각각의 상황에서 구현하는게 아니라 해당 상테가 다른 상태로 넘어갈 수 있는지 확인할 수 있도록 역할을 상태에 위임시킨다. 일종의 상태패턴인데, 나는 이넘을 이용해 구현을 했다. 복잡도가 높아져 객체를 분리했는데, 너무 과한게 아니었나 하는 생각이 들기도 했다. 덤으로 상태 패턴과 전략 패턴의 차이를 좀 더 명확하게 알게 됐는데, 상태 패턴은 계속해서 상태를 변화시켜야 하는 경우 적합하다. 그래서 직접 상태를 변경시킬 수 있다. 반면 전략은 처음에 정해지면 바뀔 일이 드물다. 그래서 보통 외부에서만 변경할 수 있도록 한다. 스스로 전략을 바꾸지 못 하도록.
추가적인 고민은 특정 상태 관리를 여러 시스템에서 동일하게 사용하는 경우다. 상태만 전문적으로 관리하는 시스템을 따로 만드는게 좋을지. 아니면 메세지로 불러올 수 있도록 처리하는게 좋은건지. MSA 이제는 시작해보자ㅏ.
프로젝트 요구사항으로 몽고DB와 엘라스틱 서치 사용이 있었다. 요구사항이 간단해 구현 자체가 어렵거나 하지는 않았는데, 어떤게 좋은것일지 판단하는게 많이 어려웠던 것 같다. 처음에는 RDB처럼 여러개의 도큐먼트를 참조해서 연결시키려고 했는데, 안티패턴이었다. 조회를 여러번 해야 되면 한 번에 할 수 있도록 하는게 좋다. 어차피 완전한 무결성을 위한 기술이 아니다. 빠르게 읽고 쓰기 위한 기술이다. 이 점을 인지하고 가는게 좋은 것 같다.
아쉬운 점은 구현을 빠르게 해야하니 훑기만 하고 넘어갔다는 것인데, 각 잡고 공부를 해봐야겠다.
DDD 스타트를 읽어봤다. 작은 책도 하나 읽었는데, 그건 너무 설계 관점이라 나중에 읽어보면 도움이 될 것 같다. 지금은 너무 어렵다.
그 간 어그리거트를 반드시 루트에서만 들어가도록 설계하고 맞추는게 좋은게 아닐까 하는 생각을 했었다. 이유는 예전 Spring Data JDBC 때문이었다. 하지만 아니라고 한다. 어그리거트는 엔티티와 1:1로 대응되는게 보편적이라고 한다. 다시 말하면 도메인을 잘 쪼개면 그런 고민을 덜 하게 되고, 그렇지 않다면 도메인이 너무 큰 것이 아닌지 점검해봐야 할 것이다.
서로 다른 어그리거트를 엮어야 하는 경우도 생기는데, 이런 경우는 결과적 일관성을 사용하도록 하는게 좋다고 한다. 결국 도메인은 각자 할 일을 잘하게 하고 이 것들을 조합해서 큰 서비스 단위를 만드는 게 목적인 것 같다.
책을 읽다가 이벤트를 이용해서 객체의 책임을 보다 명확하게 만들어주는 방법을 봤는데, 생각을 못 하고 있던 방법이. 이벤트는 프런트의 전유물로 생각하고 있었던걸 많이 반성해야한다. 기술은 모두 이어진다. 언어와 플랫폼은 도구다.
가장 궁금했던 것 중 하나는 MSA환경에서 나오는 코드 중복을 어떻게 처리하는게 좋을지에 관한 것이었다. 공통 라이브러리로 배포하는 방법도 있고 메세징을 이용할 수도 있을 것인데, 그냥 각각 구현하고 있다고 한다. 이유는 결국 달라지게 되고 정확히 중복이 된다면 설계에 뭔가 문제가 있을 가능성이 크다고 한다. MSA를 따로 공부해야 좀 더 직관이 생길 것 같다.
데이터 전체의 최소값과 최대값 처리를 생각해야 하는 부분이 있었다. DB에서 가져오면 유지보수성이 떨어질 것이고, 서버에서 처리하면 속도가 비효율적일 것이다.
결론적으로는 빨라야 하는 부분과 빠르지 않아도 되는 부분을 구분하는게 중요한데, 해당 부분은 서버에서 처리해도 문제 없을 정도의 양이라 다른 문제를 해결하는게 더 좋은 방향이었던 것 같다.
물론 부하가 심해지는 때가 오면 다른 방법을 강구해야겠지만 가장 효과가 좋은 것 부터 적용시켜가는게 중요한 것 같다.
자연스럽게 샤딩과 파티셔닝도 훑어보게 됐는데, 샤딩은 분산환경에서 이루어지는 파티셔닝이라는 것 정도로 이해했다. MSA를 공부하면서 좀 더 깊이 알아봐야겠다.
이번달 부터 한 달간 휴식하고 시작하기로 했다. 휴식 전에 요구사항을 정리해두고 휴식을 시작했다. 인턴을 한달 간 하면서 속도가 조금 붙은 것 같아 다음 달에 재개하면 빠르게 구현을 할 수 있을 것 같은 느낌. 물론 느낌만 그렇다.
새로운 사람을 들이는 것에 대한 고민도 있었는데, 고민을 많이 하다가 우리가 케어할 상황이 아니니 받지 않기로 했다. 이런 관점에서 사람을 들이는 입장을 다시 한 번 생각해보게 됐는데, 이전의 내 생각과 비슷하긴 하지만 직접 받아야 하는 상황이 되니 고민이 많이 됐다. 분명 손이 부족하긴한데, 그걸 우리가 케어하면서 갈 수 있을까? 혹은 우리가 쌓아둔 문화(이제 백엔드 두 명이라 문화라기에는 너무 거창하긴 하지만...)에 잘 적응을 할 수 있을까? 이런 고민들이었다.
결론적으로는 우리한테 잘 맞지 않을 것 같으면 받지 않는 것이 좋을 것이다. 손이 모자라도 잘 맞지 않는 사람이 들어오면 팀 자체에 영향이 갈 수 있을 것이기 때문이다. 역설적이긴 하지만 바쁠때 그런 상황이 나오는걸 막아주는 것도 중요한 것 같다. 회사도 마찬가지일 것이다. 아무리 사람이 모자라도 들어가기 힘든 회사가 있는 이유는 이런게 아닐까... 특히나 팀에서 받을지 말지 결정을 해야할테니
1차를 붙고 나서 2차에서 떨어지는게 특별한 이유가 있는 것일 수도 있지만, 진짜 핏이 맞지 않아 그런거라면 크게 상심하지 않아도 될 것 같다. 들어가도 서로 많이 힘들테니까. 앞으로도 이런식으로 생각해봐야겠다. 인턴에 떨어지게 되더라도 이렇게 생각할 수 있을지 궁금하긴하다. 알게되지 않았으면 좋겠다.
12월 말 부터 코틀린 스터디를 하고 있다. 내가 평가할 깜냥이 있는건 아니지만, 확실히 발표할때 각자의 스타일이 많이 보이는 느낌이다. 나는 자바코드로 변환되면 어떻게 되는건지를 위주로 살펴봤었고, 파이로는 람다를 주제로 명 강의를 해줬다.. ㅋㅋ. 첫 발표에서는 책의 원 내용을 너무 등한시한게 아닌가 하는 느낌이 살짝 들었는데, 좀 더 잘 정리해서 다른 사람들도 볼 수 있도록 공유도 해야겠다.
코틀린 자체에 대한 인상은 나쁘지 않다. 전체적으로 편의성에 초점을 맞추고 풀어줄건 그냥 풀어준다. 특히 프로퍼티들의 게터와 세터를 열어놓는게 기본이다. 이게 불만이라고 하는 사람들이 많다고 하는데 개인적인 생각은 꼭 세터를 감춰야겠으면 인터페이스를 쓰면 되는게 아닌가? 하는 생각이다. 직접 써보지 않아서 하는 생각일 수도 있다. 직접 써보면 왜 그랬는지 알 수 있을텐데.. 최근에 지하철 알람이 부족해서 작은 토이 프로젝트를 할까 생각 중인데 거기서 코틀린을 써보는 것도 괜찮을 것 같다.
그런데 이런 변화들이 생산성에 크게 영향을 줄 수 있을까? 써본 사람들은 그렇다고 하는데.. 궁금하다. 어쩌면 너무 스프링을 스탠다드로 생각하고 있어 그런걸지도 모르겠다. 나도 게비스콘 짤 같은 편안함을 느껴보고 싶다.
객체지향의 사실과 오해를 읽으며 내 생각과 함께 다시 정리해보고 있다. 생각보다 진도가 잘 안나가는데, 얼른 끝내고 오브젝트도 봐야겠다.
재밌는 이야기를 들었는데, 회사의 문화를 바꾸기 위해 고군분투하고 있는 분이 계신다.
압축파일과 USB를 사용하는 환경에서 깃을 도입하고, 코드 리뷰 시스템을 정착시키고 있다.
그걸 하기 위해서 구성원들의 학습 흥미를 위해 성경 스터디까지 같이 하고 있다고 한다.
작은 조직이라 가능한 것일수도 있지만, 저런 식으로 생각하는 것 자체가 놀라웠다.
두고두고 생각해볼만한 것이라 따로 적어보기로 했다.
1월은 좀 길면서 빠르게 지나간 것 같다. 스쿱을 중단할때만 해도 시간이 한참 걸릴 것 같았는데 1월이 훌쩍 가버렸다.
인턴을 하면서 내 자신에 대한 검증을 하게 된 것 같은데, 좋은 결과를 얻었으면 좋겠다.
올 해는 책도 많이 읽어보자
Powered with by Gatsby 2.0