본문으로 건너뛰기

2023.06.06

· 약 10분

1. "타이탄의 도구들"을 읽고

지금 읽고 있는 책에 내가 겪은 고민들에 대한 내용이 나오다 보니 매우 공감하며 읽게 된다.

"트랜드는 중요하지 않다. 미래의 삶에 가장 중요한 역할을 하는건 '사명감'이다."

어떤 트랜드가 생겨나면 곧장 엄청난 사람들이 몰려든다. 그리고 많은 사람들이 몰리면 경쟁은 치열해지는 반면 차별화는 약해진다. 따라서 1등을 차지하지 못하면 트렌드는 의미가 없다. 망한다는 건 '특정 트렌드의 n번째 순위'를 기록하면서 사라진다는 뜻이다. 트랜드를 탐색하는 시간을 대신해 우리는 '사명'을 찾아야 한다. 사명이란, 다른 사람들이 해결하지 못한 문제를 찾아내는 것이다. 다른 사람들은 엄두도 내지 못하는 문제를 해결하는 노력이다.

자신의 일과 사업, 아이디어를 시작하고자 하는 사람들이 스스로에게 던져야 할 두 개의 질문은

  • 첫째, 내가 매일 떠올리는 문제들 중 아직 아무도 해결하지 못한 것은 무엇인가?
  • 둘째, '아직 아무도 세우지 않은 멋진 회사에 대한 아이디어는 무엇인가?'

최근에 시작한 프로젝트가 딱 트렌드를 쫓아 만들었던 것 같다. 최근 유행하는 아이디어에 타겟만 살짝 바꿔서 만들고 있다. 그런데 이런 유행이나 트랜드는 언젠가 식기 마련이고 다른 서비스와의 차별성은 점점 모호해질 것이다. 책에서 말했듯 1등이 아니면 사라질 것이 자명했다.

"타이탄의 도구들" 책이 아닌 서점을 둘러보다 잠깐 들어 읽었던 책에 이런 문장이 있었는데 기억에 남는다.(무슨 책인지는 기억이 안난다.)

사업을 할때는 역사적으로 꾸준하게 사랑받아 왔던걸 해야한다. 시간이 지나고 유행이 바껴도 변하지 않는걸 해야한다. 오랜세월 꾸준하게 사랑을 받아온 클래식같은..

사실 윗 문장은 그냥 그 책이 말했던 느낌만 담아 각색했다. 정확한 문장은 기억안나는데 말하고자 했던건 위와 비슷했다

2. fe 개발자가 spring boot를 공부하고 느낀점

요즘 스프링을 공부하고 있다. 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 완강했고 스프링 핵심 원리 - 기본편는 60% 정도 들었다.

스프링을 공부하게된 이유를 말해보자면. 소프트웨어 공학 관련 저서들을 읽어 보면 대부분 백엔드 중심으로 쓰여졌다. 그래서 이를 프론트코드에 적용하려 노력해보지만 힘들기도 했고 참고할 만한 코드도 없다보니 흉내내서 개발하는 느낌이였다. 클린한 것 처럼 보이는 코드, solid를 꾸역꾸역 적용한 코드, 어디서 본 아키텍처를 흉내내어 적용한 코드를 작성했다. 책에서 소개된 개념과 방법들을 사용하기는 어려웠고 그 개념과 철할을 프론트 코드에 녹이려는 노력만 하게 되었던 것 같다. 이런 과정에서 저자가 말하려는 내용들, 그리고 널리 알려진 클린 아키텍처나 방법론들을 더욱 잘 이해하기 위해서 백엔드를 공부하게 되었다. 물론 이런 이유만 있는건 아니다. 혼자서 사이드 프로젝트를 만들고 싶기도 했고 백엔드 직군으로 전향 해보고 싶은 니즈도 조금은 있다.

스프링이 어떤건지는 "스프링 입문" 강의 하나로도 대부분 알게 되었던 것 같다. 스프링 빈과 의존관계 그리고 AOP는 충격이였다. 클래스 위에 annotation을 달아주는 것 만으로 스프링 컨테이너에 빈으로 등록되고 Configuration을 수정하는 것만으로 의존성을 자유롭게 주입하고 조립할 수 있었다. solid를 프론트에서 적용하면서 들었던 의문들... 의존성 역전원칙이 프론트에서 그렇게나 힘들었는데 스프링 사용하면 configuration만 수정하면 되었다. 너무나 쉬웠다. 그냥 스프링이 다해줬다. 프론트는 그런 라이브러리나 프레임워크가 없다. 그런걸 구현하려면 개발자가 코딩해야 했다. 그리고 관례적인 기법도 아니기에 여러 팀원들과 함께 개발하는 프로젝트라면 쉽지 않은 선택일 것이다.

스프링은 코드를 잘 설계할 수 있도록 발전 되었다면 react를 사용하는 프론트엔드 개발자는 dom을 만들고 js로 함수를 만들고 dom과 js를 직접 이어줘야 한다. 프레임워크가 해주는건 알아서 잘 렌더링해주고(변경이 많아도 모아서 한번에 렌더링 시킨다던가) 컴포넌트 라이프 사이클에 따른 훅을 제공해주는 것 뿐이다. 잘 설계하고 좋은 코드를 만들도록 발전한게 아닌 성능적인 부분을 개선시키기 위해 발전되었다. 아직 프론트 기술이 성숙하지 못했기 때문인 것 같기도하고 (관례적인 방식 같은게 없다. - service, controller, repository 같은..) 있어도 빠르게 바뀌고 누군가가 비판하며 새로운 걸 내고, 기존의 라이브러리 혹은 프레임워크가 업그레이드 되는게 아닌 deprecate 되어버리고 새로운게 나와버린다. 그래서 코드레벨에서 유지보수하게 잘 만들 수 있도록 발전되기는 커녕 다른 프레임워크에 먹힐까봐, 자리를 빼앗길 걱정에 성능을 개선하고 조금이라도 많은 기능을 개발하기에 급급한 것 같다는 생각이 든다.

김영한 선생님이 워낙 쉽게 가르쳐주시고 실무 경험 위주고 가르쳐 주셔서 좋았고, 백엔드 취준생의 느낌으로 공부하다 보니 재미도 있었던 것 같다. spring 재밌네.


Meet-Coder-Study/posting-review 에 오늘 올린글인데 긁어왔다 ^^

추가로 백엔드 엔지니어 분께서 코멘트를 남겨주셨는데

자바/스프링 공화국의 문제인거 같긴해요.. ㅋㅋㅋ

Spring Boot가 불편해보인다는건 없었을까요?? ㅋㅋㅋ 좋은점들만 적어주신거 같아서 ㅋㅋㅋ

어쩌면 나는 새로운 프레임워크나 라이브러리가 빠르게 나오고 바뀌는데 조금은 지쳐 spring에 대한 좋은점만 보였던 것 같기도 하다. 최근에 진행하던 프로젝트에서 e2e 라이브러리를 선택할 때 cypress에서 playwright로 바꾸고, css 라이브러리도 stitches를 사용했다가 emotion을 사용했다가 이제는 module css, module scss로 바꾸려고 계획하고 있고 web-client 프로젝트들을 cra (webpack)을 사용하다 vite로 바꿨고 이제는 ssr(next)로 프레임워크를 바꾸려고 준비중이다. 이런거에 조금은 지치지 않았나싶다.