필자는 학부 때는 머신러닝을 배우다가 백엔드 개발자로 전향한 사람이다. 최근에는 나름 인프라 쪽도 공부를 하면서 시스템에 대해서도 배우고 있는데 머신러닝 시스템 설계라는 주제가 꽤 흥미롭게 다가와서 관련 책을 읽어보게 되었다.
머신러닝 시스템 설계
이 책은 머신러닝 + 시스템 설계라는 주제를 가지고 있다. 그리고 머신러닝 기초 -> 머신러닝 실무 관련 지식 -> 인프라 / 시스템 순으로 설명을 하고 있다. 그 중 머신러닝 기초와 인프라 / 시스템 쪽은 필자가 읽을만 했는데 실무 관련 지식들은 자세히 보지 못하였다. 이 책의 구성이 꽤 괜찮다고 느껴지는 건 머신러닝 시스템 설계를 어떻게 해야할지 감이 잘 안 잡히는 사람에게는 어느정도 청사진을 그려줄 수 있다는 점이고, 필자가 거기에 해당되었기 때문이다. 목차는 아래 사진과 같다.
012345
목차
어떻게 보면 이 책의 초반에서 "비즈니스와 머신러닝의 목적"이라는 부분이 있듯이 비즈니스 관점에서도 머신러닝을 다루고 있다. 어떻게 보면 공학 쪽은 결국에는 필수적으로 비즈니스와 연결되는 부분을 고려해야하는 것 같다. 따라서 이 책에서는 이해관계자들의 관점에서도 머신러닝을 바라보고 있으며 그런 부분도 흥미롭게 읽었다.
연구가 계속되면서 크기가 커지기 시작하면 한 사이클을 돌리는데 걸리는 시간이 오래걸리기 마련이고, 그 사이클의 주기를 줄이는 것이 다른 어떤 부분보다도 중요하게 될 때가 있다. 그래서 현대 소프트웨어 개발 분야에서 CI/CD 관련한 논의가 많이 일어나고, 어플리케이션 오케스트레이션 부분도 발전하게 된 걸 것이다. 이러한 관점을 책의 chapter 9에서 연속 학습로 다루고 있으니 한 번 읽어보면 좋을 것 같다.
아마 실무에서 AWS를 관리하는 devops이거나 개인적으로 프로젝트를 진행하면서 AWS를 통해 서버를 사용하고 있다면 비용을 어떻게 절감할 수 있을지 고민을 많이 했을 것입니다. 그래서 대표적으로 비용을 절감하는 saving plan이나 예약 인스턴스를 많이 사용하셨을텐데 이 책에서는 이 뿐만 아니라 ec2 인스턴스 스펙부터 시작해 스토리지, 네트워킹 비용까지 절감할 수 있도록 도와줍니다.
표지
목차를 보면 가장 많은 고려하게 되는 순으로 컴퓨팅서비스, 스토리지, 네트워킹, 이렇게 되어있습니다.
012
목차
근데 저는 이 책에서 네트워킹 서비스 쪽을 추천하고 싶습니다. 왜냐하면 서비스가 커지면 커질 수록 알게 모르게 돈이 새나가는 부분이라고 생각하기 때문입니다. 특히 쿠버네티스 환경을 사용하게 되면 가끔 AWS 내부나 클러스터 내부에서 통신을 할 수 있는 부분을 인터넷망을 통하게 되어서 공짜로 통신할 거를 비용을 지불하게 될 수도 있으니까요.
이 책은 표도 많고, 자기가 필요한 부분을 읽는게 많이 도움이 될 수 있을 것 같아 앞 장부터 제가 흥미롭게 보았던 부분을 뽑자면, 컴퓨팅에서는 스펙별 특장점, 예약인스턴스와 세이빙 플랜에 대한 설명, 컨테이너 서비스 쪽입니다. 스토리지에서는 S3에서 스토리지 클래스 전환(스탠다드에서 글레시어로 변환한다던가) 부분이었습니다. 그리고 마지막으로 네트워킹 부분은 어렵지만 생소했던 부분이라 다 재미있었던 것 같습니다. 특히 아래 그림은 네트워킹에서 우리가 알게모르게 path별로 과금이 상이했다는 것을 보여줍니다.
네트워킹 비용
마지막으로 한줄평을 하자면 "devops라면 집에 한 권씩 챙겨둬서 손해보지 않을 책"입니다.
이 책을 읽고, 첫번째로 들었던 생각은 기대했던 것보다 업무에서 쓸 수 있을만한 좋은 내용들이 곳곳에 있었다는 것이다. 근데 그런 것에 비해서 정말 입문(AWS를 처음 쓰는 사람)하는 사람이라면 별로 안 와닿는 내용이었을 수도 있을 것 같았다. 왜냐하면 중간중간 정말 실무에서 알면 좋을 만한 내용들을 담고 있었던 반면에 실습 부분은 정말 너무 쉬운 내용을 담고 있었기 때문이다. 예를 들어 EC2를 설명하는 장에서 EBS의 스펙들도 알려주고, ALB, NLB도 알려주고, X-Forward-For 과 같은 개념도 알려주는데 실제로 만드는 것은 EC2를 만들고 접속해보는 것까지 해본다...ㅠㅠ
그래서 "나는 정말 AWS를 처음 써본다!" 하는 사람은 이 책의 5장까지만 보고, 정말 이 책을 보면 좋을 만한 사람은 ec2, rds, s3 같은 서비스를 이미 만들어보고, 개발경력이 1년정도 있는 사람같다. 왜나하면 처음 aws를 접할 때는 서비스 스펙 같은 건 신경쓰지 않고, 프리티어에서 공짜로 쓸 수 있는 걸 쓸 거라고 생각하고, 필자 또한 그랬다. 근데 실제로 돈을 내보거나 devops를 하시는 분들은 가격같은 것도 신경을 많이 써야한다. 그러면 이 책에서 설명하는 해당 스펙의 장단점, 그리고 여러 서비스들을 어떻게 조합하는지가 중요해진다.
업무에 바로 쓰는 AWS 입문
특히나 이 장의 처음에는 IAM에 대해 설명하고 있는데, 난 처음 aws 접할 때 IAM이 뭔지도 모르고 ec2를 만들어 쓰곤 했는데 여러 서비스를 조합하고, 회사에 들어가게 되면 그 때부터 IAM이 중요하게 된다. 그래서 IAM을 첫번째 장에 넣은 것도 저자의 의도였을 것이라고 본다. (베스핀 글로벌에서 교육을 받았을 때도 IAM을 배우는 것부터 시작했다.) 또한, 초반에는 (필자가) 주요하게 쓰는 서비스 ec2, rds 등을 설명하고 나중에는 dynamodb, api gateway 같이 자주 쓰지 않는 서비스가 나왔기 때문에 저자가 책의 구성에도 신경을 썼다고 생각한다.
마지막으로 한줄평을 하자면 처음 읽을 때는 너무 쉬운 내용을 다루고 있는게 아닌가 하다가도 가면갈수록 좋은 내용, 꿀팁을 알려줘서 기대 이상이였다.
첫번째는 아주 성장이 빠른 기업이나 조직경험. 아주 성장이 빠른 기업이라는 건 증가하는 인원에서 느껴진다. 내가 들어올 때가 딱 증가하는 순간이였던 것 같다. 그러다보니 조직을 리빌딩하기도 하고, 기존 방식으로는 잘 안 굴러가는 문제가 있었던 것 같다. 그러다 보니 만 2년차가 조금 넘은 나에게는 신선한 경험이었다. 조직이 커짐에 따라 기존의 방식이 잘 적용이 안되고, 새로운 규칙 또는 방식을 찾아야 했나보다. "그 때는 맞고, 지금을 틀리다" 같은 느낌. 솔직히 팀이 리빌딩되면서 (기존 맴버가 이탈하기도 하고, 외부에서 인재를 영입하기도 하고, 신입을 많이 뽑기도 하고... 등) 분위기가 어수선한 느낌은 있었지만 그래도 조금 진정되가고 있는 것 같다. 또, 이번에 들어오신 경험이 많으신 리더 분이 인원이 늘고 성장하는 시기에 팀을 만들어가는지도 옆에서 볼 수 있는 기회인 것 같다.
두번째로는 방법론을 배울 수 있는 조직인 것도 맞는 것 같다. 스타트업이기 때문에 가능한 부분인 것 같은데, 여러 툴들을 적극 활용하려는 분위기 뿐만 아니라 새로운 방법론을 도입해보려는 시도들이 많이 보인다. 기존에서는 노션에서 문서를 정리하면서 프로젝트를 관리하다가 linear라는 툴을 적극 도입해보기도 하고, 서드파티의 데이터 파이프라인, 리포팅 툴을 도입해 여러가지 것들을 자동화하기도 하였다. 무엇보다 동료분들이 대단하다고 느낀 부분은 바뀌는 것에 대한 두려움이 별로 없고, 생각보다 적응하는데 시간이 많이 걸리지도 않았던 부분이다.
세번째 데이터 분석과 AI를 활용하여 업무의 효과, 효율을 높힌 경험은 chatGPT를 써본 경험을 들 수 있을 것 같다. 어떻게 만들지는 아는데 어떤 라이브러리를 써야하나 이런 걸 고민할 때 chatGPT를 쓰면 도움이 된다. 전 직장에서 db에서 데이터를 추출 후 엑셀 파일을 이메일에 첨부하는 코드를 짤 때 chatGPT에게 도움을 받은 적 있다. 이런 식이다. "데이터를 가지고 엑셀 파일을 만드는 python 코드를 짜줘" -> "이메일에 엑셀을 첨부해서 smtp 서버를 통해 보내고 싶은데 코드를 짜줘" 이런 식으로 하면 몇 초만에 짜준다. 근데 중요한 건 돌려보면 안 돌아갈 수도 있다. 저번에 chatGPT가 줬던 코드는 외부 라이브러리에서 method를 하나 잘 못 썼었던 같은데 그런건 에러 보고 바꿔주면 된다. (chatGPT에게 틀렸다고 말해주면 고치는 방법을 알려줄 수도 있다.)
번외로, chatGPT를 쓰면 공부하는데 도움도 많이 된다. 아래 글에서 썼다시피 큰 덩어리를 배울 때 어떤 것부터 배워야하는지 어려울 때가 있는데 선생님에게 질문하듯이 chatGPT에게 질문을 하면 큰 도움을 받을 수 있다.
마지막으로 네번째, 자신의 업무가 고객에게 직접 가치를 부여하는 것을 확인할 수 있는 업무 경험도 감사하게도 있었다. 우리팀 PM님이 고객사를 만나고 오면 product에 대한 피드백이나 이런저런 기능이 있으면 좋겠다는 이야기를 공유해주신다. 그럼 이런 부분이 더 보완되어야하구나, 이런저런 기능은 다음에 만들어야겠구나 하는 생각을 한다. 그리고 이런 이야기를 듣다보면 어떤 기능을 개발할 때 작게 쪼개서 보완해나가는 방법을 배워볼 수도 있다. 채팅 기능을 예로 들자면 처음에는 두 사람이 대화하는 것만을 개발하고, 후에 그룹채팅 방을 만든다던지. 처음에는 텍스트만 보낼 수 있는데 이모티콘까지 지원하는 채팅방을 만든다던지... 이런 경험은 좋은 PM님을 만나서 있을 수 있었던 경험 같다.
단 한 가지, E-to-E로 문제를 정의하고 설계하고 해결해본 경험은 없는 것 같다. 사실 db 모델을 설계하고, 개발 완료하고, 모니터링까지 하는 게 E2E 라면 E2E 겠지만은 그걸 안 해본 백엔드 개발자는 거의 없을 것 같아서 제외하고, 비즈니스적인 관점에서 기획~실행까지는 아직 못해본 것 같다. 특히나 개발팀에 있으면 기획 같은건 거의 PM님이 해주셔서 그런 것 같기도 한데 좋은 PM님과 일하면서 나중에는 기획도 어느정도 할 수 있는 개발자가 될 수 있으면 좋겠다.
PM의 역할은 다른 직무에 비해 꽤 광범위하고, 사람은 강점보다는 약점이 두드러져 보이기 쉽다는 점에서 PM은 참 (좋은 평가받기) 어려운 것 같다. 제품을 같이 만들어 가면서 느꼈던 PM의 역할이 어려운 이유를 적어보려고 한다.
project manager
1. 내부에서의 역할도 다양한데 외부도 신경써야 한다. 내부에서 해내야 할 일도 많은데 타 팀이나 고객들과도 의사소통을 해야한다. 프로젝트 관리를 하다보면 일정이나 인력을 관리해야하는데 그러면 타 팀과 고객들과의 의사소통은 불가피하다. 근데 우리의 팀은 하난데 타 팀이나 고객은 제각각이다. 그래서 케이스 바이 케이스에 갑을 관계에 있으면 더더욱 힘들어 지는 것 같다.
2. B2B와 C2C에서 PM이 고객을 대하는 마인드가 달라져야 하는 것 같다. 위에서 고객들과도 의사소통을 해야한다고 했는데 일반 소비자(C2C에서의 고객)와 회사(B2B에서의 고객)을 대할 때 마인드가 조금 달라져야 하는 것 같다. 예를 들어 일반 소비자와 니즈를 파악하고, 제품에 반영할 때는 고객 한명 한명의 니즈를 다 반영할 수도 없고, 반영해서도 안 되는 것 같다. 그리고 일반 소비자는 자기가 원하는 걸 정확히 모를 수도 있고, 원하는 것을 해결하기 위해서 근본적인 이유를 찾아야할 때도 있다. 근데 회사를 대할 때는 일반 고객보다는 적기도 하고, 갑을 관계에 있을 수도 있고, 제품을 솔루션처럼 팔 수도 있기 때문에 그 회사만을 위한 커스터마이징이 필요할 수도 있다. 그리고 니즈가 꽤 구체적일 수 있고, 가장 중요하게는 그것을 안 맞춰주면 우리 제품을 안 사용하거나 경쟁사 제품을 사용하려고 할 수 있기 때문이다. 그래서 각각 B2B, C2C사업에서의 PM은 약간 다른 면모를 가지고 있어야 하는 것 같다.
3. 잘한다는 건 사람이 평가하는 거라서 주관적이고 상대적인데 단점이 두드러지기 쉬운 것 같다. 사람은 완벽할 수 없고, 어떤 역량은 약간 떨어질 수 밖에 없다. 어떤 PM이 완벽에 가까우려면 모든 역량이 평균 이상이여야할 것 같은데 그럼 엄청 난 것 아닐까..? 그래서 제목에 "PM의 역할이 참 어려운 이유"라고 썼지만 정확하게는 "PM이 좋은 평가 받기 어려운 이유"라고 봐야한다.
결론: 아무튼 PM은 어려운 것 같으니까 좋은 점을 보려고 노력하고, 주변에 힘들어 하는 PM이 있다면 응원해주자 :)
