그냥 국비같은데서 스프링 어떻게 깔짝 배워가지고 백엔드 만드는 건 아무나 다 함
어려울게 어딧냐 그냥 컨트롤러 서비스 레포지터리 엔트리 레벨에서는 짜는 코드 다 거기서 거기임
근데 처음으로 이 기초 차이가 나게되는 영역은 데이터 모델링임. 다른 말로 테이블 설계.
깊게 고민 안하고 대충 테이블 만들어놓으면 나중에 진짜 헬된다.
가뜩이나 디비단은 나중에 마이그하기도 개빡센데
애초에 설계자가 충분히 고려해서 짰으면 기획에서 온갖 요구사항 다 튀어나와도 기존 코드에서 간단하게 기능 추가만 해주면 되는거
테이블 개판되어있으면 애초에 기획을 못받거나 받아도 쿼리 무슨 시발 조인에 유니온까지 걸고 임시 테이블까지 만들어서 짜야되고
성능 개판되고 버그 여기저기서 마구 튀어나옴
제대로 기초가 되어 있으면 내가 어떻게 설계를 해야 쿼리가 어떻게 나오고 이 쿼리가 실제로 이런 식으로 돌아서 시스템 부하를 덜 주겠구나 하는게 머리에 그려짐
두번째 차이가 나게 되는 영역은 직접 백엔드를 설계해야 될 때
예전이야 그냥 백엔드 코드 짜서 WAS 위에 올리고 뒤에 오라클 DB 붙여두면 끝났지만
요즘 시스템들은 마냥 그렇게 심플하지 않음
스타텁에서 MVP 만들어내는 거 아닌 이상에야 nosql 하나 이상은 꼭 붙고 MSA 무조건 고려하게 됨
애초에 공부 안하는 빡대가리들은 여기서도 어떻게든 RDB 로 쇼부보려고 억지로 잘 맞지도 않는 기능 우겨넣음
mysql 에다가 job queue 용 테이블 만들고 헛짓거리 하는거 같은 거
근데 이런것도 사실 새로 공부하기가 귀찮은거지 완전 빡대가리는 아님
mysql 테이블 상에서 job queue 구현하려면 어쨌던 지 대가리 속에서 동시성 상황 시뮬레이션 돌려보고 여의치 않으면 어떻게든 야매로 lock 같은거 구현해놓고 하거든
진짜 빡대가리들은 job queue 라는게 있는지도 모르겠지
암튼 kafka 붙이고 mongodb 에 비정형데이터 내려보내고 캐시 레이어 하나 만들어야 자연스러운 상황인데
애초에 빡대가리들은 이걸 못함
kafka 에 producer, consumer 코드들은 짜내겠지
근데 어떤 상황에 kafka 를 붙이고 어떤 메시지들을 어떤 구조에서 주고받게할지 설계랑 의사결정을 못함
거기다가 IDC 혹은 클라우드 이중화 시켜야 된다? 이건 절대 못하지
MSA 상에서 서로 다른 서비스 상에 데이터 동기화시켜야 된다? 이것도 못해
어떻게 kafka 는 붙여놨는데 한쪽에 오버헤드 존나 걸려서 lag 생기고 동기화 텀 길어지기 시작한다?
그럼 그냥 기초없는 애들은 "했는데 안되던데요. kafka 존나 구리네요" 이러고 끝남
kafka 끼워넣어서 제대로된 설계란걸 할려면 최소한 kafka 공식 document 한번씩 정독하고 와서 전체가 숙지되어 있어야 하는데 그걸 안하거든, 아니 못하거든
그러니 아키텍쳐 튜닝이 필요한 시점에도 이걸 못함
내가 위에서 이야기한거 다 존나 시니어 개발자가 어디서 뿅 나와서 해야되는 거라고 생각하지?
이거 최소한 빠르면 3년차 늦어도 5년차 전에는 다 할 수 있어야 되는거임
이거 못하는 애들은 그냥 연차 쌓여도 신입들도 다 할 수 있는 스프링 코드나 존나 짜고있는거야.
남들 연봉 5천 7천 찍어나갈때 아직도 신입이랑 엇비슷한 연봉 받으면서
Msa랑 설계 빠는애들치고 잘하는애를못봄
그런거 필요없는 코딱지만한 시스템 만들땐 필요없긴해. 근데 그거만 하는 애들은 그 세상이 끝인줄 암.
MSA는 최근에나온기술이고 그전에도 네이버랑 페이스북 있었음 니가 니세상이 끝인줄알겠지 ㅋㅋ
MSA 라는 키워드가 만들어진게 최근인거지 네이버는 그전부터 비슷하게 다 하고 있었음. 설계 중요한지도 모르는 뉴비가 뭘 알겠냐. - dc App
설마 MSA 단어 없었다고 회사들이 다 모놀리틱하게 짜고있었을꺼라 생각하는건 아니지?ㅋㅋㅋ - dc App
그전에 모놀리식이었지 모놀리식이면 서버 무조건 1개떠야하는줄아는 좆밥인가보네 ㅋㅋ
그전엔 다 모놀리틱이었댄다 븅신ㅋㅋㅋ 야 msa 나오고나서 야 다같이 msa 하자! 한게 아니고 사람들이 이미 하고있는걸 엮어서 msa 란 키워드가 나온거여. 키워드가 나오기전에 이미 있었겠지 등신아 - dc App
구글도 모놀리틱이었겠네? 이미 그 시절에 kubernetes 전신 만들고 있던 애들이? - dc App
국비 웹 때문에 인식이 낮아진건가 프로그래머는 진짜 공부 조빠지게 해야하네 ㅅㅂ
애초에 설계자가 충분히 고려해서 짰으면 기획에서 온갖 요구사항 다 튀어나와도 기존 코드에서 간단하게 기능 추가만 해주면 되는거 테이블 개판되어있으면 애초에 기획을 못받거나 받아도 쿼리 무슨 시발 조인에 유니온까지 걸고 임시 테이블까지 만들어서 짜야되고 성능 개판되고 버그 여기저기서 마구 튀어나옴 <== 지금 내가 있는 고객사 db 쿼리들이 죄다 저모양임 ㅠㅠ... 근데 그거 써서 새로 시스템 고도화 하느라 머리 빠개지는 중 ㅠㅠ
야, 이걸로 대본 짜서 제목 어그로 잘 끌면 유튜브 영상 하나 나오겠는데.
join 은 밥먹듯 하는건데 뭔 ㅋ
조인은 당연히 많이 쓰는데 본문에서 언급한건 설계만 잘했음 안해도 될 조인을 몇단씩 걸어서 쓰는 사례를 이야기한거임 - dc App
애초에 관계형 db는 정규화가 핵심이라 대부분 정보는 최소한의 정보만 가지는게 맞음 그리고 그걸 조인해서 유기적으로 원하는 정보형태로 가공하는거고 인덱스 잘걸린 테이블끼리 수억번 조인해도 성능에 아무런 영향없다 오히러 한뭉탱이에 이것저것 껴넣은 테이블이 병신인거지
조인 못하고 조인 몇개만 걸리면 머리 쥐나는 애들이나 한테이블에 다 쑤셔박음
너말대로 조인 자체가 나쁜건 아닌데 그건 이상일 뿐이고 실제로는 데이터의 성격상 인덱스가 제대로 걸릴 수 없거나 혹은 특정 테이블만 너무 비대하다던가 이런저런 이유로 적절하게 비정규화를 해줘야 됨. 너말대로 하나도 비정규화 안하고 다 정석대로 가면 디비 리소스 사용량 난리남. - dc App
가뜩이나 웹서비스는 읽기쓰기 비율이 읽기가 압도적으로 높고 도메인이 복잡할수록 디비 의존도가 높아지는 경향이 있는데 이런 상황에서 데이터 올 정규화? 이건 경험없는 초짜들이나 짜는거 - dc App
대학교 1학년인데 뭔말하는지 하나도모르겠음