[고찰] SSH EP 0: 왕초보가 왕왕왕왕왕초보(과거의 나) 피드백하기
이전의 나...
시험이 끝나고 스스로 진행할 토이프로젝트를 구상중이다.
최근들어서, 단조로운 API설계, 기능 제작만 하는 백엔드 개발자는 껍데기 개발자라는 생각이 머리를 가득 채운다.
나름 스스로 고심해서 코딩해왔지만, 아직 기술의 뎁스가 얕다고 생각했다.
AI가 할 수 없는, 데드라인에 쫒기지 않는, 내가 원해서 하는 개발이 필요했다..!
이때, '채팅개발 시스템 설계 과정'라는 당근 유튜브를 보게된다.
'어? 예전에 혼자 채팅만들어봤는데? 이걸 탐구할 점이 많은걸까?'
[고찰] 당근 채팅 시스템 정리 및 생각
서론위 당근 서비스의 채팅서버에 대한 발표를 정리한 글이다.당근에서 설계된 채팅 아키텍쳐와 전략 등을 살펴보고, 내 생각을 따로 정리하고자 이렇게 작성했다.모든 그림은 발표에서 사용된
tadokang.tistory.com
당근에서는 그룹채팅관점에서 적합하지 않았기에 pub/sub을 채택하지 않았다.
"pub/sub 관점에서 만들기에는 효율이 정말 안좋을까? 근거있는 해결방법을 만들어보자!"
이렇게 프로젝트를 시작하게 되었다. 다른 기술블로그, 테크 세미나 영상 정리하면서 적용할 내용을 추가할 생각이다.
이때, 이전에 혼자 만들었던 채팅 기능이 생각난다.
"한번 이거를 혼자 피드백해봐야겠다!"
⚠️경고: 지금부터 해당 개발은 1년전 만들었던 개발이니, 왕왕왕왕초보 관점에서 봐주길 바란다.⚠️
2024.07 처음으로 소켓을 통한 채팅서버를 만드는 토이 프로젝트를 진행했다. 멘토님이 함께했기에 조금 무모한 주제선택을 수행하기로 한다. 이 시절에는 채팅 앱의 목표로 1) socket 통신, 2) 멀티모듈, 3) CICD로 잡는다."꿈도 크다"는 말이 맞다.
결국 멀티모듈 두 스푼, 채팅 두 스푼 정도 하고, 벽만 잔뜩 느끼게 되었다. (그래도 한 스푼보다는 깊게 공부한 것 같다.)
심지어 멘토님의 추천으로 구글링 자료도 많지않은데 Netty를 쓰게 된다. 멘토님은 공식문서를 따라만 가도 쉽게 socket통신이 가능하기에 추천했지만, 그때는 공식문서를 이해할 수준조차 되지 않았다.
서버 아키텍쳐
나름 서버 내의 모듈 분리 및 기능 정리를 위해, 그림과 같은 아키텍쳐를 그렸다.
이제보니 뭔가 해보려고 아등바등거리는 모습이 보기 좋다고 생각한다. 그리고 참 뭣모르고 시도하는거 하나는 잘하는 것 같다.
지금보니 엉터리 그자체다.
잘한 점
1. '서로 다른 기능'을 기준으로 크게 3가지로 확실한 분리를 수행했다. (DB, API, Socket)
2. 머리 속을 정리하기 위해서 아키텍쳐를 그린 행위 자체를 칭찬한다.
못한 점
1. 일의 실행순서 📈
멀티모듈, socket, cicd 를 수행한다고 하자. 그럼 뭐부터 시작해야할까? 보통 내가 만든 코드를 빠르게 통합 배포하기 위해 cicd를 먼저 구축하고, socket통신과 api를 만들어 서버를 짜고, 쌓여있는 구조를 정리하는 멀티모듈을 수행할 것이다. 그리고 차례대로 진행할 것이다.
-> 이때 난 그날마다 하고싶은 개발을 했다. '음 저번에 멀티모듈 이만큼 햇으니까, 오늘은 소켓 채팅해야지~' 미x놈이다. 체계가 무너지니 이전에 뭘했는지 스스로 망각하고, 어느정도 개발되었는지 전체 진행률 파악이 어려웠다.
📌 마일스톤을 지킬 수 있게, 그리고 잘 지키자.
2. 멀티모듈의 잘못된 이해 📁
모듈을 나누는 이유는 커져가는 프로그램의 크기와, 쌓여가는 폴더 수, 추가되는 코드에 따라 들어갈 기준이 모호해진 파일, 뻣뻣한 결합구조를 해결하기 위함이다.
-> 🥶 이때 난 모듈을 나눈다는 것이, 프로그램을 분할한다는 의미로 이해한다 🥶 실제로, 위의 spring, netty 모두 각각 8080, 8081 포트로 실행된다는 사실... ('멀티모듈'을 '멀티서버'로 이해했다고 봐야한다.ㅋㅋ)
3. gradle 파일의 관리 ⚙️
아무 레퍼런스도 없이 관리도구가 gradle이라는 이유 하나만으로, spring서버와 android의 의존성을 통합 관리한다는 생각을 한다. 무지했기에 용감한 선택이라 생각한다.: 2번과 연결되면서 두 프레임워크의 의존성 통합과 동시에 함께 실행되어야한다고 생각했다...
4. 조급함 😥
사실 위 3가지 못한 점의 가장 근본적인 원인이라고 본다. 숲을 보지 못하고 나무만 본 것이다. 적용하려했던 키워드가 모두 처음 접하는 상태였다. 기술 자체를 이해하지 못한 채, 당장의 에러만 해결하려했던 점이 가장 큰 문제였다. 멀티모듈, socket, cicd 등 시간을 할애해서 이해를 쌓아야하는 키워드인데, 조급한 마음으로 코딩했던 점이 너무 아쉽다.
📌 천천히. 시간이 걸리더라도 확실하게 한발씩.
끝내 아래의 결과물을 만들기 위해 1달 반이라는 시간을 할애했다.
작년의 나는 이해보다는 문제해결만 했고, 결국 남는건 gpt와의 대화를 위해 빨라진 타자실력뿐이다. 머리에 이해했던 내용은 거의 없다고 무방하다. 현재가 되면서 gpt와의 대화만 하기에는 내가 묻는 대화의 수준이 중요하다고 느꼈다. 내가 높은 퀄리티의 질문을 해야 높은 퀄리티의 대답을 해준다. 결국 내가 그만큼 알고 있는 것이 가장 중요하다고 느꼈다.
또 일의 체계적인 부분을 중시하려고 노력했다. ADHD와 맞먹는 내 집중력을 조금이라도 끌어올리기 위해 계획을 지키려 노력했다. 특히 KPT를 수행하면서 실력이 늘어난 나를 볼 수 있었다. 이제는 혼자서 서버구현 정도는 거뜬히 수행할 수 있다.
그래도 저런 무모한 시절이 있었기에 지금의 내가 있다고 생각한다.
관심이 생겼던 소켓통신을 다시 한번 구현하고자, 과거의 나를 통해 지금의 나를 증명하고자 이렇게 프로젝트를 시작하려고 한다.
다음 편에는 계획과 탐구하고자 하는 방향에 대해 작성하겠다.
이 글을 읽는 누군가도 꼭 한번씩 나를 돌아보고 피드백하는 시간을 가지면 좋겠다.
2025.05.04 (글쓰다가 든 생각)
최근 AI가 도래하고 하루가 다르게 발전하는 속도를 보면, 어쩌면 금방이라도 개발자가 사라질지도 모른다.
기존에 알았던 지식량만으로는 개발자를 고용하는것보다는, 차라리 구독료를 지불하고 GPT, Cursor를 사용하는 것이 더 나을지도 모른다.
변화에 민감하게 대응해야하는 직군이니까, 이런 큰 변화에도 유연하게 대처해야한다.
이를 극복하기 위해서는, DevOps + 백엔드 개발자가 살아남을 수 있다. 적어도 난 그렇게 생각한다.
기존에 비즈니스 로직을 처리하고 코드를 중시하던 백엔드 개발자에서, 아키텍쳐적인 지식(DevOps)과 복잡한 구조를 가진 서버 구조를 처리할 수 있는 백엔드 개발자가 앞으로 살아남을 수 있지 않을까?