6월 2주차 회고(6/6~6/10)

이번주 점수는? ⭐⭐⭐⭐⭐

😍 좋았던 것(Liked)

팟캐스트 출연

친한 스타트업 대표 형의 초대로 스타트업을 주제로 다루는 팟캐스트에 게스트로 출연했다. 주제는 <스타트업 임직원들의 자기계발>이었다. 평상시 루틴, 리추얼에 대한 소개부터 이전에 창업하면서 있었던 에피소드 등 다양한 이야기를 나눌 수 있어 좋은 시간이었다.

매일 유지하는 루틴은 아래와 같다.

1. 아침에 일어나자마자 이불 개기
2. 모닝 찬물 샤워(처음부터 찬물로 조지는 건 아니고, 따뜻한 물로 하다가 마무리 1분을 찬물로! 하고 나면 정신이 번쩍 들면서 엄청 개운함)
3. 데일리 회고

패널 분들께서 내 루틴 얘기를 듣는데 표정이 질색이시더라(…)ㅋㅋㅋㅋㅋㅋ 왜 그렇게까지 해야 되냐, 그걸 매일 유지하는 게 가능하냐 등 말씀하셨다. 그래서 이렇게 대답했다.

“열심히는 누구나 다 한다고 생각해요. 누가 자기 열심히 안 한다고 생각할까요. 하지만 그걸로는 부족하지 않을까요? 스타트업에 온 이상 정말 잘해야 되거든요. 잘하려면 자신이 지금 어느 방향으로 가고 있는지 끊임없이 체크해야 해요. 특히나 개발자는 더더욱 그런 것 같아요.”

이렇게 말하니 뭐라도 있어보이지만, 사실 전혀 그렇지 않기 때문에 이렇게 불철주야 노력하는 것이다. 뭐라도 있었으면 이렇게까지 했을까 싶다. 그냥 놀 때 놀고, 쉴 때 쉬지 뭐하러 이렇게까지 하나. 하지만 객관적으로 남들보다 늦게 출발한 반면, 그들을 뛰어넘고 싶다는 욕망이 있다. 그럼 뭐 달리 방법이 있나. 남들 하는 거 배로 하는 수밖에. 그나마 한 가지 믿음이 있다면 인풋은 절대 거짓말 안 한다는 것이다.

사수 분들에게 받은 찐한 관리!

이번 주 별점이 다섯 개일 수밖에 없는 이유가 여기에 있다. 이번 주에만 사수 두 분께 찐하게 관리를 받는 귀중한 경험을 했기 때문이다. 하나는 프론트엔드 엔지니어 분과 페어 프로그래밍을 진행하면서, 다른 하나는 백엔드 팀의 사수 분과 긴 시간 공부 방향 상담을 나누면서였다.

이전에도 언급했지만, 처음에 이 회사에 들어올 때 불안한 점이 많았다. 외부에 잘 알려지지 않은 회사였고, 개발팀이 어떤지는 더더욱 알 길이 없었기 때문이다. 하지만 가면 갈수록 정말 이 회사에 들어오길 잘했다는 생각밖에 들지 않는다. 이렇게 뛰어나면서도 겸손한 분들과 함께 이 다이나믹한 여정을 함께 헤쳐나갈 수 있다는 사실이 그저 행운이다.

📚 배운 것(Learned)

공부한 것들

• <스프링 부트와 AWS로 혼자 구현하는 웹서비스>
  • 3장 끝냄
  • 4장: ~4.4장
• <이것이 자바다>
  • 8장 인터페이스 복습
• 디자인 패턴
  • 템플릿 메소드 패턴 정리
• Spring
  • Spring의 설계 철학은?

확장성 있는 코드란 무엇인가?

프론트엔드 엔지니어 Z와 페어 프로그래밍을 하면서 실무 관점에서 코드의 확장성에 대해 깊게 고민해볼 수 있었다. 우리 서비스에는 사용자에게 대출을 제공하기 전에 이 사람의 신원정보를 기입하는 항목이 있다. 기존에는 산업군을 선택하는 항목과 직업을 선택하는 항목 간 dependency가 존재하지 않았다. 즉, 선택할 수 있는 모든 산업군 항목이 나열되고 뒤이어 마찬가지로 선택 가능한 모든 직업군이 전부 보여지는 식이었다. 예를 들면

• 산업군
  1. IT
  2. 자동차 제조업
  3. 금융
• 직업
  • 소프트웨어 개발자
  • 영업
  • 생산기술 제조업자

이런 식이라고 하자. 그러면 금융업에 종사하는 영업직이라고 할 때, 금융업을 눌렀으면 그와 관련된 직업만 화면에 렌더링되어야 하는데 그렇지 않은 직업(ex. 생산기술 제조업자)이 함께 나오는 식이다. 즉, 각 산업군과 그에 따른 직업이 매핑되어 있지 않은 상황. 이는 사용자 경험을 해칠 수 있는 요인이다.

이를 어떻게 수정할 것인가를 생각해보자. 그냥 슥 보면 쉬워 보인다. 가장 간단하게는 각 산업군마다 그에 해당하는 직업을 분류하고 Job 항목에서만 유저가 선택한 Industry 값에 따라서 리턴해주는 방식을 떠올릴 수 있다. 이러면 Job에 의존성이 걸리지만 데이터를 바꾸진 않아도 된다. 하지만 이렇게 해버리면 문제가 발생한다. 사용자의 신원정보는 Industry와 Job만 있지 않다. 다른 항목들도 있는 상황에서 이 케이스만 예외로 디펜던시를 추가하는 것. 일종의 예외 케이스 개념인데, 매번 이런 식으로 예외 항목을 계속 설정하다 보면 유지보수가 점점 어려워지게 된다. 나중에 비즈니스 로직이 바뀌는 상황이 발생한다고 가정했을 때, 각 예외 케이스 역시 일일이 점검해줘야 하기 때문.

아니면 기존 데이터 구조를 static이 아닌 함수 형태로 바꿔서 받아오는 방법이 있을 수 있다. 이는 장기적인 관점에서는 확장성이 열려있지만 당장 손이 많이 가게 된다.

사실 자세하게 해당 문제를 이해한 것은 아니나, Z가 전하고 싶었던 맥락은 아래와 같다.

• 추상화 및 확장성을 고려한 아키텍쳐의 중요성: 뭔가를 만들려고 할 때 나무만 보지 말고 숲을 볼 줄 알아야 한다. 변화에 열려있는 구조로 짜야 한다. 소프트웨어는 급변하는 비즈니스 상황에 맞춰 유연하게 동작해야 한다.
• 보기 쉬운 코드와 확장성을 고려할 줄 아는 개발자가 좋은 개발자이다. 나중을 고려한 아키텍쳐는 처음은 오래 걸리나 그 다음은 쉬워진다. 당장 편한 길은 나중에 부채로 돌아온다. 하지만 때로는 부채도 적절하게 짊어질 줄 알아야 한다. 현재 비즈니스 상황에 맞춰 어디까지 고려할 것인가를 적절하게 판단하는 개발자가 좋은 개발자.

글만 읽으면 잘 와닿지 않을 수 있지만, 실제로 코드를 보면서 Z가 전하려는 메시지를 들으니 새로운 눈이 뜨인 기분이었다. 단순히 만들기만 잘하는 건 무의미하구나. 얼마 전에 얼리 스타트업 대표인 지인이 자기네한테 새로 지원한 신입 개발자 이력서를 한 번 봐달라고 했다. 봤더니 무엇이 이상한지가 대번 보였다. 무늬만 개발자와 진짜 개발자는 보여주고 싶은 게 다르다는 걸 깨닫고 있다.

개발, 어떻게 공부할 것인가?

스프링을 어떻게 공부하면 좋을지 고민이 많았다. 틈틈이 스프링 공부 방법을 찾아보다 백기선님의 스프링 공부 방법 관련 유튜브 영상을 봤다. 거기서 나온 이야기는 “가성비 있게 공부해라"였다. ‘몇 달 내내 토비의 스프링 책 처음부터 끝까지 보고 있으면 효율이 나오지 않는다. 그러니 IoC, DI 같은 핵심 개념 위주로만 이해해라’는 뉘앙스의 영상이었다. 이전까지 스프링부트 책 코드만 따라치다보니 뭐가 뭔지 전혀 감이 없었다. 그런 와중에 이 영상을 보고 “아, 그러면 적어도 핵심 개념은 제대로 짚어야겠다!”로 방향을 잠시 선회했다.

그날 오후 하루종일 스프링의 IoC와 DI에 관련해 책을 보면서 글로 정리했다. ‘제어의 역전’이라는 말이 잘 와닿지는 않았으나 프레임워크와 라이브러리 예시를 보니 뭔가 알 것 같기도 했다. 하루종일 들여다보느라 피곤했지만 그래도 글로 주루룩 써놓고 보니 뭔가 한 듯한 뿌듯함이 들었다.

하지만 사단이 일어났다. 저녁에 사수 분과 같이 남아 각자 일을 하던 와중이었다. 공부 잘 되어가고 있냐는 사수 분의 물음에 오늘 IoC와 DI에 대해 공부한 내용을 설명드렸다. 그러자 갑자기 이렇게 말씀하셨다.

제어의 역전이라.. 뭐가 제어고 뭐가 역전일까요?^^

순간 당황했다. 하지만 숨을 들이마시고는 책에서 배운 프레임워크와 라이브러리 예시를 어찌저찌 장황하게 설명드렸다. 그러자 다시

프레임워크는 뭐고 라이브러리는 뭐예요?^^(

갑자기 분위기 기술면접

)

그때부터 수난의 연속이었다. 아니, 정확히 말하면 배움의 연속이었다 ㅎㅎ 사수 분과 함께 어떻게 공부해야할지 깊게 이야기를 나눌 수 있었다. 핵심은 아래와 같았다.

1. 기본기와 실전의 균형을 맞추자
   • 첫 달: 자바 & OOP 공부
   • 둘째 달: 스프링부트 공부 & 웹 게시판 구현
   • 셋째 달: 실무 투입 → 대출 심사 관련 인터널 툴 수정
   이런 식이었으니, 첫 달에 해야 할 것을 제대로 하지 않고 바로 둘째 달에 할 것으로 뛰어넘어간 셈. 나름 빠르게 한다고 생각했지만, 사실상 후루룩 넘긴 것이나 다름없다. 사수 분께서는 이걸 지적하셨다.물론 그렇다고 실전기 없이 백날 기본만 할 수는 없는 것이니 <스프링부트> 책과 자바 공부를 함께 하는 식으로 진행하면 좋겠다고 말씀해주셨다. 즉, 베이스를 다지는 기초 학습과 주어진 과제 해결을 위한 실전 학습을 병행하는 것.
2. “지금 스프링의 핵심 철학인 IoC, DI 백날 글로 공부해봤자 의미없어요. 자바의 기본기가 탄탄하지 않으면 이해할 수 없는 내용이예요. 빨리 넘어가는 건 좋은데, 급하게 가면 체해요. 저희가 괜히 기다려주겠다고 한 게 아니니, 충분히 기본기도 챙기면서 가도 괜찮습니다.”
3. 지금 내 방향성은 실전에 빠르게 투입되고 싶은 나머지, 기본기를 후루룩 뛰어넘어가는 모양새였다. 가장 기본이 되는 <이것이 자바다> 책을 인터페이스 파트까지만 빠르게 훑고 3주차부터 스프링을 시작했으니 말이다. 원래 3개월 수습 기간 동안 세웠던 계획에서는
4. 코드로 공부하자“요리사가 처음에 뭘 할까요? 맨 처음에는 요리를 하지 않을까요? 수영선수는 처음에 수영부터 하지 않을까요? 일단 칼질 먼저 해보고, 일단 물 먼저 들어가봐야 하는 것 같아요. 글은 그 다음 순서라고 생각해요.” 그렇다. 개발자는 결국 코드로 말하는 사람이다.
5. 위에서 말했던 IoC, DI와 관련된 내용은 결국 코드 상에서 어떻게 구현되는지에 대한 이해가 중요하다고 하셨다. 직접 코드를 짜보지 않으면 이게 왜 편하고 이전에는 왜 불편했는지 그 맥락을 파악할 수 없다는 것. 그랬다. 토비의 스프링 백날 읽은들 IoC가 코드 상에서 왜 필요한지는 전혀 감을 잡을 수 없었던 것도 이런 이유에서였다. 이렇게 비유를 들어주셨다.

아주 중요한 걸 배웠던 한 주였다.

💦 부족했던 것(Lacked)

• 순수 개발 공부에 들이는 시간이 부족했다. 근데 이건 늘 부족한 것처럼 느껴지는데, 이렇게 말로만 부족하다고 하는 거 별 의미 없다. 방법론을 개선할 필요가 있겠다. 실제로 부족한 게 맞는지도 체크해봐야 하고, 얼만큼을 채워야 부족하지 않은 건지에 대한 기준도 필요하다. 측정 없이는 개선할 수 없다. 진도가 느리게 나가는 것 같아 이렇게 말하는데, 실제로 하루에 책 몇 장을 보는지 체크해볼 것.

🕯 바라는 것(Longed for)

• 이번주는 실제 진도 체크를 좀 더 디테일하게 해볼 예정이다. 하루에 과목별로 몇 장 진도가 나가는지 파악해보자. 측정하고 나서 그 다음주에는 얼마나 속도를 올릴 수 있을지도 체크해보자.