일주일간 나의 흥미를 끈 인사이트는??
📌목록
-
롱런하는 개발자
https://antstudy.tistory.com/646 -
데이터 변환 계층 (Data Transfer Layer)
https://jojoldu.tistory.com/685 -
작고 아기자기하지만, 개발조직의 문화 만들기(우아한 형제들)
https://techblog.woowahan.com/9766/ -
박정국 CTO가 알려주는 ‘서버 성능 측정 방법’ (포브스 선정, 신입 개발자, API, 백엔드) - YouTube
https://www.youtube.com/watch?v=HSNyJnobBws -
NRTI (Near Real-Time Indexing)
https://dealicious-inc.github.io/2022/11/21/tech-day_NRTI.html?ref=codenary -
더 빠른 인스턴스로 옮겼는데 성능이 안 나오면 어디를 봐야 할까? (netflixtechblog.com)
https://news.hada.io/topic?id=7911&utm_source=slack&utm_medium=bot&utm_campaign=T03DN2VDVFG -
개발자로 살아남는 "진짜" 방법
https://f-lab.kr/blog/how-to-be-good-developer -
모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?
https://yozm.wishket.com/magazine/detail/1813/ -
소프트웨어 원칙 만들기
https://jojoldu.tistory.com/686
📌감상
1. 롱런하는 개발자
https://antstudy.tistory.com/646
나는 롱런하는 개발자 중 하나가 되고 싶다. 이 글과 글 속의 영상 속에서 말하는 바는 그냥 코드를 따라하는 것에 그치지 않고 구현을 하면서 내부 동작 원리를 알아야 진정한 개발자가 되는 것이라 말한다. 나도 대학원 초반에는 아무것도 모르기 때문에 그냥 코드를 복붙하는 사람이었다. 어째뜬 돌아가게 만든것이 중요한 시점이었기 때문이다. 그런 와중, 나를 가장 성장하게 만든 것은 내부 구현 동작 원리를 확인하고 블로그를 통해 정리했을 때였다. 물론 급한 불부터 꺼야하기 때문에 어떻게 돌아가지는 몰랐지만 일단 작동되게 한 후, 어떻게 돌아가는 지 블로그 글을 써가면서 정리했고 내가 설계한 알고리즘 코드에 대해 다시 정리하는 시간을 가졌다. 나는 이게 큰 성장을 이뤘다고 생각한다. 사실 내부 동작을 알아간다는 것이 쉽지 않다. 어렵다. 그런데 그것이 내 성장에 도움준다는 것을 알기 때문에, 앞으로도 이 동작을 꾸준히 유지하려고 노력할 것이다.
2. 데이터 변환 계층 (Data Transfer Layer)
https://jojoldu.tistory.com/685
이 글을 읽음으로써 DTO에 대해 다시 생각해보는 계기가 되었다. 이전까지는 dto를 단지 데이터를 전달해주는 상자같은 개념으로 생각했다면 이 글을 통해, 타입 변환의 책임도 dto에게 가지고 있음을 알게 되었다. api의 응답으로 문자열로 된 날짜값을 전달해야하는 경우에도 dto에서 타입변환이 이루어진다면 비지니스로직에서 타입변환을 해줄 필요가 없기 때문에 비지니스 로직을 훼손하지 않게 된다고 이 글에서 그에 대한 예시로 언급하고 있다. 만약 데이터 변환이 dto에서 이루어지지 않는다면 프로젝트 전체가 변화와 확장에 대응하기 어렵게 된다고 한다.
3. 작고 아기자기하지만, 개발조직의 문화 만들기(우아한 형제들)
https://techblog.woowahan.com/9766/
이 글에서 가장 눈에 띄었던 프로그램은 "우아한티타임"이라 생각한다. 우아한티타임은 월 1회 프론트엔드 개발자 3~4명이 30분 정도 이야기를 나누는 프로그램이라고 한다. 나는 개발자들끼리의 대화의 중요성을 가장 크게 본다. 대화를 함으로써 내가 아는 지식과 몰랐던 지식, 내가 관심없었던 분야에 대해 알게 되기 때문이다. 따라서, 나는 개발자는 컴퓨터로 프로그래밍하는 것도 중요하지만 많은 대화가 필요한 직업이라 생각한다. 나중에 회사에 가서도 주위 개발자들과 많은 대화를 해보고 싶다.
4. 박정국 CTO가 알려주는 ‘서버 성능 측정 방법’ (포브스 선정, 신입 개발자, API, 백엔드) - YouTube
https://www.youtube.com/watch?v=HSNyJnobBws
개발을 처음 시작했을 때는 가장 중요한 것이 돌아가는 프로젝트를 만드는 것이었다. 하지만 이제는 그것보다도 얼마나 잘 돌아가는 가에 대한 것을 측정을 해보고 싶다는 생각을 이 영상을 통해 하게 되었다.
api 서버 성능이 좋다는 것이 어떤 것일까? 처리하는 속도가 빠를 수록?(latency) 아님 많이 사람이 접속했을때 느리더라도 잘 돌아가는 것이 성능이 좋다고 생각해야 할까?(throughput) 결론은 많은 사람이 접속했을때도 엄청 빠르게 처리하는 것이 성능이 좋다고 할 수 있다. 이것을 측정하는 방법으로 wk2를 쓰는 것으로 소개해주었다. 내 프로젝트에도 서버 성능 측정을 해봐야겠다는 생각을 갖게 되었다. ddd 프로젝트에 적용한 ottsharing과 msa구조로 된 momukgi 프로젝트에 적용해보고 싶다. '몇명의 사용자가 어느 정도의 밀도로 api 요청을 할때 서버의 응답 속도 분포는~'이라는 한 줄을 추가해보는 것이 자그마한 목표이다.
5. NRTI (Near Real-Time Indexing)
https://dealicious-inc.github.io/2022/11/21/tech-day_NRTI.html?ref=codenary
딜리셔스의 기술 블로그로 어떻게 하면 검색 속도를 향상시킬 수 있을까에 대한 개선 과정을 다루고 있다. 결론적으로 near real indexing 방법으로 kafka를 통한 메세지 처리와 eleasticsearch를 이용한 검색엔진 운영으로 개선하였다고 언급하고 있다.
6. 더 빠른 인스턴스로 옮겼는데 성능이 안 나오면 어디를 봐야 할까? (netflixtechblog.com)
https://news.hada.io/topic?id=7911&utm_source=slack&utm_medium=bot&utm_campaign=T03DN2VDVFG
조금 어려웠던 글이었다. 해결 방법은 false sharing과 true sharing을 패치함으로써 성능 향상을 이루었다고 한다.
🔔1) false sharing
-
cpu 내부의 코어와 코어간의 메모리 정보가 공유되어 하드웨어 적으로 병목현상이 일하는 것을 뜻한다.
-
멀티 코어 CPU에서는 데이터를 word 단위로 읽어오는 대신 메모리 I/O 효율성을 위해서 cache-line로 읽어오는데, 이때 문제가 생길 수 있다. 두개의 메모리 연산이 동일한 캐쉬라인에서 실행될 경우, CPU<->Memory 버스 사이에서 하드웨어적인 락이 걸리는데, 이때 하드웨어적인 병목현상이 발생한다.
-
멀티 쓰레드 환경과 cpu의 멀티 코어에서 발생한다고 한다.
-
실제로 공유되고 있지 않은 캐시 데이터를 동기화하는 행위
-
2개 이상의 코어가 서로 다른 메모리 주소에 접근하지만, 두 주소가 동일한 캐시 최소 단위에 적제되어 있어(논리적으로는 전혀 영향이 없지만 캐시는 이를 모르기에) 동기화가 이루어져 성능이 하락하는것
🔔2) true sharing : 동일한 변수를 여러 쓰레드/코어에서 읽고 쓰는 것.
7. 개발자로 살아남는 "진짜" 방법
https://f-lab.kr/blog/how-to-be-good-developer
이 글에서 언급한 것들 중 가장 내가 앞으로 가질 수 있도록 해야할 습관은 '기술적 상상을 하자'라는 말이다. '해당 서비스가 본인의 담당이 아니거나 사회적 이슈가 된 문제가 본인에게 발생한 문제가 아니더라도 그것들을 기술로써 어떻게 해결할 수 있을지에 대해 고민해 보는 것만으로도 충분히 좋은 경험이 될 수 있다. '라는 글을 읽으면서, 아직 초보라 단순히 고민에 그치겠지만, 나중에는 이것을 토대로 새로운 토이프로젝트를 하여 내 성장의 밑거름이 되지 않을까 생각하게 되었다.
8. 모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?
https://yozm.wishket.com/magazine/detail/1813/
모놀리식과 마이크로서비스의 각각의 장단점이 언급되어있어 다시 한번 확인할 수 있는 글이었다.
- 모놀리식 (단일 애플리케이션)
장점) 단순성, 간편한 배포, 보편성, 디버깅이 쉬움, 쉬운 테스트, 쉬운 모니터링
단점) 규모가 커지면 유지 보수가 어려움, 유연하지 않은 확장성(특정 부분만 확장할 수 없음), 대규모 팀작업 어려움, 기술 사용 제한(다른 기술로 변경의 어려움) - 마이크로 서비스 (애플리케이션을 작은 서비스로 분할)
장점) 유연한 확장성, 독립적인 배포(일부 서비스만 배포가능), 단일 실패 지점 제거(한 에러가 전체 애플리케이션에 영향을 미치지 않음), 전체 서비스 중단 위험 감소, 다른 데이터베이스 소유, 다양한 기술 수용 가능
단점) 개발 생산성 필요, 디버깅의 어려움, 마이크로 서비스 간 통신의 복잡성, 표준화 부족, 오류 식별의 어려움
9. 소프트웨어 원칙 만들기
https://jojoldu.tistory.com/686
'급한 일정으로 일이 주어져도 항상 80~90점의 소프트웨어를 출시하는 프로그래머'가 될 수 있는 방법을 언급하고 있다. 어떻게 아무리 급해도 항상 80~90점의 퀄리티의 소프트웨어를 개발할 수 있을까? 이 글에서는 기준과 원칙을 통해 빠르게 결정을 내리면서 정말 중요한 설계와 선택이 필요할 때 더 깊게 시간을 사용하기 때문에 가능한 것이라고 언급하고 있다. 사실 이 글이 책을 홍보하기 위해 쓰인 인트로 부분만이 쓰여져서 그 다음 내용이 없어서 아쉬웠다. 이 책을 한 번 사서 읽어 봐야겠다는 생각이 든다.
