🤔 나에게 23년은?
2022년 갈피를 못 잡고 방황하다가 본격적으로 백엔드에 몰입했던 해였다.
나름 바쁘게 그리고 성실하게 보냈던 한 해였던 것 같다.
단순히 잔디로 무엇을 했는지 어떤 성취가 있었는지 모두 표현하기 어렵다.
기억을 조금 더듬으며 지난 한 해를 돌이켜보겠다.
🏃 23년에는 무엇을 했나요?
23년은 무언가 정말 많이 한 것 같다. 사이드 프로젝트와 스터디로 나눠서 회고해 보겠다.
🗂️ 사이드 프로젝트
많은 토이 프로젝트와 사이드 프로젝트를 진행했는데 그중에서 딱 2가지만 기억에 남는다.
올해 초에 약 2개월의 시간을 투자했었던 Flaground와 올해 말 1개월의 시간을 투자했던 올해도 아좌좌이다.
1️⃣ Flaground
당시 소속되어 있던 학교 동아리 FLAG에서 진행했던 프로젝트이다.
동아리원이 꽤 많아서(약 150명) 우리만의 공간을 만드는 게시판 프로젝트였다.
최초 프로젝트의 목적은 동아리 활성화와 이전 스터디의 연장선으로 일종의 실습이었다.
프로젝트를 진행하다 보니 이전 프로젝트인 SUWIKI의 성공으로 "이 프로젝트도 성공시켜 보자"라는 생각으로 규모를 키웠다.
물론 이 프로젝트는 역시나 실패했다.
여러 가지 요인이 있었는데 요약하면 다음과 같다.
- 미흡한 도메인 분석
- 팀원들의 탈주
여기서 가장 중요한 문제는 미흡한 도메인 분석이었다.
이 세상의 모든 직업은 문제를 해결하기 위해서 존재한다.
의사는 질병이라는 문제를 해결하기 위해서 존재하고 선생은 교육을 위해서 존재한다.
개발자 또한 마찬가지로 어떤 문제를 SW적으로 해결하기 위한 직업이다.
이 프로젝트는 명확한 문제 상황이 없이 단순하게 있으면 쓰겠지?라는 생각으로 규모를 키웠던 게 문제가 되었다.
이전 SUWIKI가 성공할 수 있었던 이유는 정확하게 반대이다. 도메인(문제 상황)이 명확했기 때문이다.
SUWIKI는 학교 측에서 기존에 사용하던 강의 평가 앱으로 더 이상 정보를 제공하지 않아 학생들이 불편함을 느껴 만들었다.
이렇게 도메인이 명확하지 않으니, 다르게 말하면 명확한 목표가 없으니 자연스럽게 2번 문제로 이어진 것 같다.
실패한 프로젝트임에도 불구하고 기억에 남는 이유는 많이 노력했기 때문이다.
회고를 통해 고백하자면 정말 남 모르게 엄청 노력했었다.
당시 나는 동아리에서 부회장을 맡고 있었는데 정말 아무것도 몰랐다. (부회장은 허울이다)
과탑을 몇 번 하다 보니 주변에서 당연히 잘할 것이다 라는 기대(?)가 있었던 것 같다. (물론 아무도 신경 안 썼을 수도 ㅎ;)
그래서 부담을 받았고 주변 사람들에게 모른다는 말을 하고 싶지 않아서 매 순간 더 많이 고민하고 더 공부했다.
내가 자주 하는 말 중 "남들 잘 때 공부하면 경험치 두 배"라는 말을 이 기간에 가장 많이 혼자 되뇐 것 같다.
이런 내 모습을 보면서 언니네 이발관이라는 레전드 락 밴드가 생각났다. 거짓말이 사실이 되게끔하는 것이다.
이 밴드를 모르시는 분들은 링크를 한번 읽어보시기 바란다.
2️⃣ 올해도 아좌좌🔥
데브코스에서 파이널 프로젝트로 진행했던 프로젝트이다.
서비스하기 위해서 이 글을 쓰고 있는 지금도 노력하고 있는 프로젝트이다.
바로 왜 가장 기억에 남는 지로 넘어가면, 끝까지 달려가고 있기 때문이다.
앞서 개발자는 문제를 해결하는 사람이라고 했다.
그래서 우리가 찾은 문제는 왜 사람들은 신년 계획을 끝까지 지키지 못할까? 였다.
팀원들과 머리를 맞대고 한 고민 끝에 우리가 제공할 수 있는 가치는 같이 나아감이다. (지금은 많이 부족하다)
이 가치를 제공하기 위해서 사업자 번호가 필요했다. 그리고 발급받아서 현재 순항 중에 있다.
사실 사업자 발급받는 것이 어려운 것도 아니고, 우리보다 더 나은 프로젝트가 있을 수도 있다.
하지만 우리처럼 끝까지 간 사람들은 별로 없을 것 같다. (물론 아닐 수도 ㅋㅋ)
이렇게 좋은 이야기만 했지만 과연 문제는 없었을까? 당연히 아니다.
프로젝트하면서 가장 무서웠던 점은 사실 나 자체였다.
내가 경험한 것이 옳다 생각하고 팀원들에게 너무 강하게 주장하거나, 내가 팀원들의 주장에 설득되지 않을까 무서웠다.
또한, 내가 팀원들보다 아주 약간의 경험이 있는 것 때문에 팀원들이 내 의견을 따르기만 할까도 무서웠다.
내가 가진 이 약간의 경험은 19살과 20살의 차이와 같다고 생각한다.
어른이 봤을 때는 둘의 차이를 모르지만, 19살은 20살이 어른이라고 생각하고 20살은 19살이 애기라고 생각한다.
따라서, 현직자 관점에서는 정말 알량한 차이지만 팀원들에게는 그리고 나에게는 아닐 수도 있다.
이런 부분을 최대한 조심하면서 프로젝트를 진행했다. (아니라면 편하게 말씀해 주셨으면 좋겠다.)
그다음으로 무서웠던 점은 내 프로젝트는 이전과 동일하지 않을까? 였다.
최대한 이전 프로젝트와 다른 구성의 코드(설계)에서 작업하려고 노력했고, 기술적으로 안 써본 것도 활용해 보려고 노력했다.
이 과정 속에서 빠르게 공부하고 빠르게 도입할 수 있는 힘을 기르고자 했다.
가장 마음에 드는 것은 Jacoco 활용하기인데 이런 식으로 관리하면 장단점이 있겠지만 제법 괜찮다고 생각했다.
지금은 여러모로 부실하지만 훨씬 발전시켜서 꼭 많은 사람들에게 우리 서비스를 제공하겠다. 😁😁
📝 스터디
올해 참여한 스터디가 몇 개인지 셀 수 없을 정도로 많이 했다. 사실 많은 이유는 다 기간이 1달에서 2달 정도라서 그렇다ㅋ
보통 내가 필요한 스터디를 내가 오픈하기 때문에 이렇게 단위가 짧아야 한숨 돌릴 수 있기 때문이다. 😋😋
기간이 짧은 만큼 몰입해서 열심히 진행했다. 그에 따라 괴리도 있었는데 그건 뒤에 작성해 보겠다.
올해 초에 진행한 JPA, 이펙티브 자바 스터디부터 지금 진행 중인 모든 스터디 중에서 기억 남는 것만 적어보겠다.
1️⃣ 사당 패밀리 스터디
나는 리차드와 다이거를 사당 패밀리라고 부른다. 사당에서 주로 모이기 때문이다. (셋 중에서 나만 이렇게 부를 것이다)
사당 팸과의 스터디는 대략 10회 정도로 많지는 않지만 가장 여러 인사이트를 제공해 준 스터디이다.
리차드는 올해 취뽀하고 현직자 관점에서 많은 이야기를 해주고 다이거는 주변에 많은 현직자에게 들은 이야기를 많이 전달해 준다.
리차드는 지금 다른 언어를 다루고 있는데 빨리 근-본있는 자바로 돌아왔으면 좋겠다. (적어도 코틀린)
그리고 다이거는 정말 열정 있는 사람인데 앞으로도 안 꺾였으면 좋겠다.
자주는 못 봐도 모두 잘 되었으면 좋겠다 👍👍
2️⃣ 객체지향의 사실과 오해 스터디
명실상부 객체지향이라는 패러다임을 가장 잘 설명하는 책이다.
나는 이 책을 총 4번 읽었는데, 이 책을 읽으면서 가장 폭발적으로 성장했다고 해도 과언이 아니라고 생각한다.
누군가는 이 책이 재미없다고 한다. 왜 그런가 물어보면 너무 텍스트가 많고 추상적인 표현이 많아서라고 한다.
그리고 다음 책인 오브젝트는 정말 재밌다고 한다. 마찬가지로 왜 그런가 물어보면 코드가 많기 때문이라고 한다.
이렇게 이 책은 코드가 없고 오로지 텍스트로만 객체지향이란 추상적인 개념을 다루는 어려운 책이다.
하지만 나는 4번을 읽으면서 매번 느끼는 것이 있었고 감탄했다.
조금 강하게 이야기하자면 재미없다고 하시는 분들은 책을 제대로 안 읽으신 분들이라고 생각한다.
분명히 코드 없이도 객체지향의 묘리를 잘 드러내는 책이라고 생각하기 때문이다.
누군가 이 글을 읽는다면 꼭 비문학 읽듯 읽어보시기 바란다.
그리고 스스로 객체지향이란 무엇인가, 객체란 무엇인가 고민해 보시기 바란다.
스터디를 운영하면서 가장 힘들었던 점은 역시 사람들과의 마찰이다.
직접적인 마찰은 없었지만 사람들이 참여율이 점점 떨어지거나 집중도가 많이 떨어지면 힘들었다.
보통 외부에서 사람을 구한 스터디에서 이런 현상이 많이 발생한다. (정말 갖가지 변명을 들을 수 있다)
여기서 가장 크게 느꼈던 딜레마는 다 큰 성인들임에도 불구하고 다 확인해야 한다는 것이다. (이게 K-책임감??)
이럴 때마다 고민을 많이 하게 되는 것 같다. '내 진행 방식이 별로인가?' 혹은 '내가 싫은가?' 등등.
열심히 참여하지 않으시는 분들을 욕하고 싶진 않다. 나도 그런 적이 있었을 수 있고 그럴 수도 있으니까.
그렇다고 내가 스트레스받고 싶지 않으니, 앞으로는 시스템적으로 제약을 걸어서 해결할 생각이다.
스터디를 운영하시는 많은 분들, 저만 이런 고민하는 게 아니겠죠?? 정말 리스펙 합니다. 👍👍
🔥 가장 의미 있던 성취는?
올해 이룬 가장 큰 성취는 두 가지를 뽑을 수 있을 것 같다.
각설하고 바로 들어가 보겠다.
😶 나는 어떤 개발자가 되고 싶은가?
올해는 내가 앞으로 어떤 개발자로 살아갈 것인지 많이 고민하는 시간이었다.
성장에 대한 고민도 중요하겠지만, 어떻게 꾸준히 앞으로 나가갈 것인가도 중요하다.
꾸준히 나아가기 위해서는 바다 위에 별자리와 같은 이정표가 필요하다. 이상향은 내 개발 인생의 이정표가 되어줄 것이다.
🧐 좋은 개발자? 뛰어난 개발자?
내가 되고 싶은 개발자는 좋은 개발자이다. 뛰어난(혹은 능력이 출중한) 개발자는 별개라고 생각한다.
그렇다면 좋은 개발자란 무엇이고 뛰어난 개발자는 무엇을 의미하는 것일까?
내가 생각하는 좋은 개발자란 같이 일하고 싶은 사람이다.
또 여기서 같이 일하고 싶은 사람은 소통이 잘되는 사람이다.
그러면 또 누군가 질문할 수 있다. 🗣️ "희조님, 소통이 잘되는 사람은 어떤 사람인가요?"
계속 타고 타고 들어가는 이 질문의 연속은 내가 고민했던 흐름 그 자체이다. (사실 더 많다 😋)
어떤 사람이 소통이 잘되는 사람일까? 에 도달했을 때 나는 비로소 2가지 유형을 찾을 수 있었다.
- '안 돼요' 혹은 '아니요' 등의 부정적인 대답으로 응답하지 않는 사람.
- 나보다 윗사람을 설득할 수 있거나 나보다 아랫사람에게 설득당할 수 있는 사람.
첫 번째 유형은 그렇게 많진 않았지만 간혹 있었던 것 같다. 많은 분들도 끄덕할 것 같아서 넘어가겠다.
중요한 것은 두번째 로 데브코스에서 큰 영향을 받은 부분이다. 어떻게 보면 가장 개발자스럽다고 생각한다.
관습처럼 여겨 넘어가던 부분이 있을 때, 잘못됨을 인지했다면 논리적으로 이유를 정리해서 건의할 줄 알아야 한다고 생각한다.
우리는 더 나은 프로덕트(Product)를 제공하는 존재들이기 때문이다.
반대로, 의견을 제시받은 사람도 해당 이유가 타당하고 충분히 의미가 있다면 받아들일 수 있어야 한다고 생각한다.
그렇지 못한 사람들을 생각보다 많은 것 같다. 물론 나도 그런 사람일 수도 있기 때문에 항상 조심하고 있다. 😋😋
반면 뛰어난 개발자란 무엇일까? 나는 퍼포먼스가 뛰어난 사람이라고 생각한다.
그런데 이 퍼포먼스의 기준을 잡는 것은 어렵다고 생각한다. 왜냐하면 사람에게는 상황이라는 조건이 주어지기 때문이다.
모자란 퍼포먼스는 개인의 노력이나 동료를 통해서 채울 수 있는 부분이 아닐까? 라고 생각한다.
(여기서 주어진 기한 내에 본인 일을 모두 처리하는 것은 당연하다.)
그래서 좋은 개발자란 단순히 말이 잘 통하는 사람일까? 사실 그것도 아닌 것 같다.
잘 이야기하다가 갑자기 다른 소리를 하는 것일 수도 있지만, 뭔가 인간적인 끌림까지도 필요한 것 같다.
내 이성적인 기준은 앞서 이야기한 것들이고, 결국 본인이랑 맞는 사람이 중요한 것 같다 ㅎㅎ... (머쓱 🫣)
😎 제네럴리스트, Generalist
사실 이 이야기가 가장 중요하다.
아직 어떤 분야로 스폐셜리스트가 되어야겠다고 정하지 못한 것 같다. 물론 결정할 수 있을 정도의 경험도 해보지 못했다.
개발이란 분야는 정말 넓고 나는 지금은 백엔드를 걷고 있지만 나중에는 어떤 개발자가 될지 모른다.
개인적으로 출발(분야)은 달라도 개발자의 끝은 동일하다고 생각한다.
이런 이유로 특정 분야에 갇히고 싶지 않은 것 같다. 그래서 나는 SW 엔지니어를 꿈꾼다.
하지만 아직은 잘 모르기 때문에 당장은 제네럴리스트가 되고 싶다. 주어진 어떤 태스크라도 잘 처리해내는 사람이 먼저 되고싶다.
이게 지금 내가 되고싶은 개발자인 것 같다. 두루두루 잘 처리하다보면 나중에는 스폐셜리스트인 내 모습을 볼 수 있지 않을까?
💡 도메인 바라보기
도메인은 참 어려운 용어다. 그리고 정말 다양한 의미를 가지고 있다.
DB, 네트워크 외 다양한 영역에서도 도메인이란 용어가 등장한다.
지금 이야기하고자 하는 도메인의 정의는 '해결해야할 대상'이다.
어떻게 나와 다른 사람과의 차별점을 드러낼 수 있을까를 정말 많이 고민했었다.
풍부한 기술 스택, 멋진 포트폴리오, 엄청난 서비스 그리고 방대한 CS 지식 등 이런 것들 중에서 정답을 찾았었다.
그러다가 문득 현직자들에게는 나는 아주 귀여운 수준일 것이라는 생각이 들었다.
정말 어느날 문득 도메인이 다가왔는데 이때, 이거다 싶었다.
그래서 나는 도메인을 새롭게 정의했다. (추상적인 개념이니까 내 마음대로 정의할거다 😎😎)
👏 도메인이란?
나는 도메인이란 가치라고 정의하고 싶다.
가치는 상대적이라는 속성에 잘 드러내면서 중요한 느낌을 주기 때문이다.
딱딱한 돌빵은 누군가에겐 먹기 싫은 음식일 수 있지만 망치가 없어서 못질을 못하는 분에게는 유용한 도구가 될 수 있다.
이렇게 돌빵의 가치는 상황이라는 대상에 따라 가치가 변화했다.
단순 조건 외에 도메인 자체도 비교 대상이 될 수도 있다.
온라인 상품 판매 시스템(e-commerce)에서는 상품이 가치(도메인)이다.
어떤 상품을 구매하기 위해서 단순히 하나의 시스템만 있을 수 없다.
누가, 어떤 상품을, 어떻게 전달할 것인지 등 여러 가치와 결합이 되어 제공된다. (고객, 주문, 배송 등)
구매자에게 물건을 보낼 때, 배송(도메인) 관점에선 구매자의 정보는 그렇게 중요하지 않다.
회사에겐 소중한 고객님일지라도 배송 할 때는 단순히 배송지로 물건을 잘 전달하는 것만이 중요하기 때문이다.
이렇게 상품(가치)을 어떤 관점(도메인)에서 바라보는지에 따라 달라진다.
고객에겐 상품은 원하는 대상이지만, 배송에겐 내용물이 무엇인지 알 필요가 없이 잘 전달하기만 하면 된다.
🧐 도메인의 의미?
지금까지 도메인은 가치로 표현할 수 있고 조건(관점)에 따라짐을 달라질 수 있다는 점을 설명했다.
그렇다면 도메인은 어떤 의미를 가질 수 있을까?
개발자가 도메인을 바라본다는 것은 대상을 다양한 시각에서 바라볼 수 있음을 의미한다.
도메인을 바라보기 시작함으로 제공할 수 있는 가치(도메인)는 점점 풍부해질 수 있는 것이다.
온라인 상품 판매 시스템에서 상품은 회사와 고객 관점에서 다르게 볼 수 있다.
회사에겐 상품(도메인)은 수익 창출의 대상이고, 유저에겐 상품은 구매하고자하는 대상이다.
이렇게 도메인을 고민하다 보면 다음과 같은 방법이 자연스럽게 떠오른다.
- 유저에게 원하는 물건을 잘 보여준다.
- 유저가 원하는 물건을 잘 찾을 수 있다.
유저에게 1번은 자동적인 방법이다. 자동적인 방법으로 저메추(완전 MZ)마냥 추천이 떠올릴 수 있다.
이걸 보통 알고리즘이라고 많이 부른다. (유튜브 알고리즘 ㅋㅋ)
이런 흐름에서 개발자는 유저가 원하는 물건을 자동적으로 찾을 수 있게끔 추천 알고리즘을 개발하게 되는 것이다.
반면에 2번은 유저에겐 수동적인 방법이다. 원하는 물건을 찾는 것이므로 검색 기능을 의미한다.
처음에는 심플한 검색 기능을 도입하고, 나중에 더 좋은 성능이 필요하게 되면 Elasticsearch 도입을 고려하게 되는 것이다.
여기서 더 도메인을 고민해보면 후기나 추천 기능까지 고려해볼 수 있다.
사람들은 타인에게 쉽게 영향 받기 때문에, 추천이 많은 상품 혹은 좋은 후기 많은 상품이 당연히 높은 구매율을 기대할 수 있다.
나는 이렇게 가치로 설명했지만 혹시라도 글을 읽은 분들은 가치로 받아들이지 않으셔도 무방하다.
도메인 자체가 추상적인 개념이라서 엄청난 단어로 정의할 수 없고 의미를 제대로 전달하는 딱 맞는 단어는 없을 것이다. (아님 말고~)
하지만 본인 스스로 어떤 개념인지 정의하시기 바란다.
이런 도메인을 바라볼 수 있는 힘은 여러 방면에서 가치를 볼 수 있고 그걸 자연스럽게 끄집어낼 수 있는 힘이라고 생각한다.
그리고 우리는 끌어낸 가치를 SW적으로 표현해주면 되는 것이다.
😎 마무리
2023년은 정말 순식간에 지나갔다. 공부도 공부지만 정말 많이 고뇌한 것 같다.
너무 많이 고뇌한 탓일까 9kg나 쪘다 ㅎㅎㅎ...
더 많은 이야기를 적어보고 싶었는데 너무 시간을 오래 투자해서 여기서 마무리 지어야겠다.
최근에 블로그 포스팅이 귀찮았는데 정말 올릴게 너~무 많다.
올해는 스스로 부끄럽지 않은 한 해였으니 돌아오는 해에는 더 열심히 보내야겠다. 😎😎
그리고 살도 빼야지 😁😁
😋 지극히 개인적인 블로그지만 댓글, 조언 그리고 좋아요는 제 성장에 도움이 됩니다 😋
'이모저모' 카테고리의 다른 글
| [후기] 프로그래머스 백엔드 데브코스 4기 합격 후기 (8) | 2023.05.23 |
|---|
댓글