우아한형제들에서 근무한지 벌써 만 1년이 넘었다.
우리 팀에서 벌써 내가 막내를 탈출하기도 했고 (실력은 아직 내가 막내가 맞는듯 ㅜㅜ), 벌써 입사할 때 후덥지근했던 계절이었던 여름이 다가오기도 했다.
배운 것도 정말 많고 해서 후기를 작성해보려 한다.
그리고 근황도 함께.
(깃허브 잔디 접었다는 소문이 많은데, 그렇지 않다. 그 계정을 거의 안쓸뿐... 뒤에 후술하겠다.)
개발 기술적으로 느낀 점들
API 개발은 신중하게. 도메인 책임 위치는 생각보다 매우 중요!
사이드프젝을 개발할 때에는 유즈케이스 추가에 따른 API 개발 및 필드 추가를 아무 생각없이 하곤 했다.
하지만 실무경험이 조금 쌓인 지금은, 필드 추가 및 API 개발을 굉장히 조심스럽게 하고 있다. 규모가 크고 복잡한 곳에서는 API 개발 또는 응답이 필드에 추가됨에 따라 관리포인트, 트래픽이 확연히 달라지기 때문.
1개월 차에는 'API 개발 난이도가 높지 않으니 그냥 개발해도 되는 것 아닐까?' 라는 생각을 가졌다면, 지금은 '이 API에 이 필드를 추가하는 것이 책임이 적절한가?', 'API의 특정성이 너무 짙어져서 활용성이 떨어지진 않을까?', 'API의 성능이 너무 느려지진 않을까?', 'API 범용성이 너무 커져서 트래픽이 몰리진 않을까?' 와 같이 많은 생각이 드는 듯하다.
그래서 그런지, 요즘은 이 부분이 너무 어렵다.
'해당 API를 추가했다가 이 도메인에 맞지 않는 문의가 들어오는 등, 관리포인트가 증가해버리면 어떡하지?', '이정도까지는 용인될까? 하지만 이렇게 어쩔수 없이 조금씩 추가해주는 것을 용납하다가 나중에는 스파게티가 돼버릴 수도 있는데.' 등등.
경험을 앞으로 많이 하면 조금은 나아질까. 어렵다 🥲
또, API 특정성이 짙어지는 것도 위험할 수 있다는 것을 느꼈다.
A 팀을 위해 기존 api에 필드를 추가하려 한 적이 있다. 이 때, '우리는 너네에게 맞게 커스텀한 api를 제공할게~' 가 아닌 '우리는 이런 것들을 가지고 있어. 필요하다면 너네가 가공해서 바꿔서 써~' 의 차이가 생각보다 크다는 것을 느꼈다. 둘 다 우리 DB에 있는 값을 반환해주는 케이스라 하자. 하지만 전자의 경우는 활용성이 매우 낮아지고 의존성이 A팀에게 짙어지게 돼 변경에 유연해지지 못한다. 후자의 경우는 의존성이 비교적 낮아지고, 필요에 따라 B, C, D 등 다른 팀에게도 열어줄 수 있을 가능성이 생기게 된다.
객체지향의 사실과 오해, 오브젝트와 같이 객체지향 관련 책을 읽는 것의 중요성을 느꼈다.
하지만 더 중요한 것은 충분한 경험. 그리고 동료 및 지인분들과 고민을 깊게 해봄으로써 영향범위를 파악하면서 감각을 쌓아올리는 것이라 생각한다.
컨퍼런스, 세미나에서 세션을 들어 간접경험하는 것도 좋다고 생각한다. 하지만 요즘은 이러한 세션이 거의 없는 듯해 아쉽다. 그도 그럴만한 것이, 사내 보안과도 밀접한 연관이 있을 것이라... 결국 지인분들이나 같은 회사 개발자분들과의 소통을 많이 하는 것이 좋은 듯하다. 그리고 경력을 괜히 따지는 것이 아닌 듯하다.
기술 기본기의 중요성 (카프카, 레디스 < 트랜잭션, 스레드 동시성, Java 문법)
제목에 부등호를 써서 전자가 중요하지 않은 것처럼 보일 수 있는데 그렇지 않다.
물론 레디스, 카프카의 동작 원리에 대해 아는 것도 중요하다고 생각한다.
하지만 장애상황을 겪으면서 다중스레드에서의 정합성 (cs와 밀접한 연관이 있는 케이스),
레디스 캐시 정합성 이슈 (레디스의 얘기도 있지만, 캐시에 대한 충분한 이해도가 필요한 케이스),
스프링 빈 에러 (스프링 생명주기, 빈 스캔 원리 등 스프링 이해가 필요한 케이스)
등의 다양한 상황에서 cs 및 기본기의 필요성을 정말 절실하게 느꼈다.
아래 케이스도 실무에서 겪은 경험 중, 기본기가 중요하다고 느낀 케이스이다.
https://kth990303.tistory.com/471
[Spring] @Transactional(readOnly=true)에서 write 시 예외 좀 더 살펴보기
개발하던 도중 아래 에러를 만났다. The MySQL server is running with the --read-only option so it cannot execute this statement 에러 발생 원인은 @Transactional(readOnly=true) 어노테이션이 붙어진 메서드에서 save 로직을
kth990303.tistory.com
요즘은 자바 스레드 동작 원리 및 동시성 이슈를 처리하고 싶은 생각이 들어, 정수원님의 인프런 강의인 자바 동시성 리액티브 강의를 들어보고 있다.
스프링부트 및 배치 공부도 해야되는데,,, 시간이 부족하여 일단 위 강의부터 집중적으로 공부해보려 한다.
(멀티를 못하고 하나에만 집중하는 편..)
특히 우리팀 동료분들을 보면서 위 생각을 많이 했다.
(이 글을 보실진 모르겠지만 impatient0716님 당신도 포함입니다! ㅋㅋㅋ)
우리 팀원분들은 볼때마다 느끼지만, 정말 기본기가 탄탄하셔서 기술부채 티켓들을 정말 많이 처리하시고 의도치않은 버그 상황에서도 문제를 꼼꼼하게 많이 해결하시곤 한다.
내가 제일 막내는 아닌데, 이런 면에서는 내가 진짜 제일 막내같다. 내 실력이 아직 부족해~ 😭
나도 1인분을 하기 위해서 기본기 공부를 더 철저히 해야겠다고 느낀다.
(근데 우리팀은 도메인로직이 복잡해서, 기본기도 기본기지만 도메인 이해도가 더 중요한 것 같다. 이건 팀바팀, 케바케일 듯하다.)
개발 외적으로 느낀 점들
워라밸에 대한 생각이 바꼈다.
우테코에 있을 때만 해도, 워라밸보단 기술적으로 성장하고 하루종일 일하면서 연봉으로 나의 가치도 높일 수 있는 곳이 좋다고 생각했다. 즉, 워라밸을 크게 중요하게 생각하지 않았다.
일한만큼 성장할 수 있다고 생각했다.
하지만 지금은 생각이 완전히 바꼈다.
워라밸은 중요하다.
기술적 성장, 연봉만큼이나 워라밸도 중요한 듯하다.
일한 정도와 성장의 정도가 비례한다고 생각하지 않는다.
(회사에서 돈을 괜히 주는 것이 아니다고 느낀다. 맨 아래에 후술할 `개발 아직도 재밌나요?` 부분을 참고!)
물론 반비례하는 것은 절대 아니다.
실무에서의 경험을 통해 객체지향적인 경험, 기술적인 도전과제를 통해 성장할 수 있다고 느낀다.
실제로 내가 생각할 때, 우리 팀의 개발문화는 정말 웬만한 회사들, 그리고 타 팀들보다도 훨씬 좋은 탑티어라고 느낀다. 지인들과 대화해봤을 때 정말 많이 느낀다.
하지만 그렇다 하더라도 일한 정도와 성장의 정도가 완전히 비례하는 것은 아니라고 생각한다.
밑에서 후술하겠지만, 사업과제가 많을수록 바쁜 일정으로 인해 원하는 기술 도입은 힘들고, 버전업도 쉽지 않다. 이런저런 비즈니스 요구사항으로 인해 원하는 방향으로 api를 개발하기 어렵다. 그 외에도 여러 원인들이 있다고 느낀다.
그렇기 때문에, 성장하기 위해선 워라밸이 중요하다고 느낀다.
퇴근 후에 개인적으로 깊게 경험하고 고민하는 것이 중요하다고 생각한다. 실무에서 겪은 문제점들과 과제해결내역들을 회고해본다든지. 사이드프로젝트를 통해 새로운 기술을 도입하고 경험해본다든지.
(다른 얘기지만) 실제로 최근부터 실무에서 배운점들을 메모장에 써두곤 하는데, 정말 많은 도움이 되는듯하다. 배운 점을 다시 한번 돌아보고 기록하고 나중에 다시 보는 것의 복습효과가 어마어마하다. 보안에 문제가 안되는 내용이라면 블로그에도 기록해볼 예정이다.
성장하기 위해 워라밸이 중요한 것도 맞지만, 워라밸이 좋으면 삶의 질이 확실히 달라진다.
우리 회사는 주32시간 근무제이다.
이게 정말정말 큰게, 정시퇴근하면 약 4시쯤인데 운동을 충분히 해도 시간이 남는다는 점이다.
남는 시간에 자기개발을 하든지, 충분한 휴식을 취함으로써 컨디션을 좋게 유지할 수 있다.
사람들을 만나면서 즐거운 삶도 보내거나, 아직 사람들이 몰리지 않는 시간대인 4~5시에 한적한 카페에 가서 여유를 즐긴다든지.
나의 경우는 일찍 퇴근하고 학교수업을 가는 편이라, 사실 다른사람들보다 바쁜 삶을 보내고 있긴 하다. (4시에 퇴근해도 4시에 학교수업 가야됨 ㅋㅋ)
하지만, 워라밸이 없다면... 학교 자체를 가지 못했을 것이고 휴학 또는 자퇴를 했어야 됐을 것이다.
워라밸이 좋기 때문에 학교수업도 들을 수 있고, 학교 끝나고 클라이밍과 같은 취미활동도 할 수 있다고 생각한다.
워라밸 덕분에 취미에 미칠 수 있었고, 취미활동은 내 삶의 질을 매우매우x100 높여주었다.
결론은 워라밸이 생각보다 훨씬 중요하다는 점을 요즘 많이 느꼈다.
도메인은 생각보다 중요하다. 결제쪽 vs 주문쪽 vs 인프라로 직종 변경
도메인에 따라 어떤 개발을 하는지가 매우 달라지는 듯하다.
검색 쪽은 ElasticSearch 위주. 결제 쪽은 정합성 및 외부결제사와의 연결. 주문 쪽은 대용량 트래픽 처리.
그리고 이러한 도메인은 중간에 바꾸기 쉽지 않은 듯하다고 느낀다. 새로운 도메인으로 변경하는 것은 어떻게 보면 도전이고, 익숙치 않은 환경 속 개발하는 것이다보니.
나는 결제와 주문 쪽의 중간 어딘가에 속하는 도메인이다.
여기서는 정합성, 동시성 이슈, 대용략 트래픽 등을 충분히 겪는다. (주문, 회원 쪽보다는 덜한 트래픽, 하지만 동시성은 충분히 챙겨야 하는 도메인이다.)
내 개인적인 성향으로 인해, 성능개선 및 동시성/정합성 등 기술적인 문제 해결을 할 수 있는 도메인인 점은 좋다!
하지만 도메인 로직 파악 및 아키텍처 설계는 아직 크게 끌린다는 느낌은 없다.
그래서 지금 내 도메인이 매우 좋지만, 나중에 언젠가 많은트래픽을 다루고 문제해결하는 도메인쪽으로 바꿔본다든지, 아예 아키텍처 설계가 아닌 성능개선에만 집중할 수 있는 인프라 (그 중에서도 DBA) 직종 변경하는 것은 어떨까 하는 생각도 존재한다.
물론 DBA든 다른 도메인이든, 지금 겪고 있는 백엔드 능력들은 매우매우 중시되므로 아직은 충분한 경험을 더 쌓고 위 고민을 해보는 것이 좋다고 판단! 일단 이직 및 직종변경 생각은 전혀 없다. 빨라도 3~5년차에 고민하지 않을까 싶다.
그리고 만 2~3년차가 됐을 때 위 생각이 그대로 유지될지도 의문.
내년에 한 번 이 글을 다시 읽어보고, 그 때에도 이런 고민을 하고 있을지 지켜봐야겠다.
근황
github 계정 버렸나요?
잔디를 보면, 개발을 거의 안하고 깃헙을 안하는 것처럼 보일 수 있다.
실제로 예전보다는 덜하긴 하지만, 그래도 위 잔디만큼 안하진 않는다.
내가 사내노트북을 개인노트북처럼 이용하다보니 저 계정이 아닌 다른 계정으로 commit, push가 될 때가 있어서 그렇다.
위 커밋이력은 지난달에 사이드프로젝트에서 내가 commit한 부분들 중 일부이다.
잘 보면 kth990303 계정이 아닌, kth990303-woowahan 계정으로 커밋된 것을 볼 수있다.
kth990303-woowahan 계정은 사내 깃허브 계정인데, 우리는 사내에서 github을 쓰지 않아서 위 계정은 아예 쓰질 않는다.
(가입날짜를 보면 입사일인 2023년 7월보다 한참 이후인 것을 확인할 수 있다.)
그리고 이 계정이 정말 특이한 것은, 다른 곳에 push 및 PR merge가 된다 하더라도 잔디가 쌓이지 않는다!
(어떻게 된건지 신기하다 ㅋㅋ)
사진 속 잔디 하나는 깃허브에 가입하여 생긴 이력이다. 그 외에는 잔디가 하나도 없다.
하지만 실제로 개발을 덜하는 것도 맞다.
현재는 개발이 아닌, 취미활동에서의 레벨업에 좀 더 초점이 맞춰져있기 때문.
결론) kth990303 계정은 버리진 않았지만, 예전보단 덜 쓰는 것도 맞다.
개발 아직도 재밌나요?
솔직히 말하자면 예전보단 덜 재밌다.
정확히 말하자면 사이드프로젝트 개발하는 것의 재미는 예전과 같으나, 회사에서 개발하는 것은 재밌다고 느끼진 않는 듯하다.
그렇다고 재미없어서 미치겠다든지, 적성에 안맞는다든지의 느낌은 아니다.
사이드프로젝트는 우리가 원하는 때에, 부담없이 이것저것 원하는 기능을 넣을 수 있다.
원하는 기술도 도입 가능하고, 버전에 구애받지 않고 필요하다 싶으면 버전을 자유롭게 올릴 수도 있다.
하지만 실무에서는 원하는 기술을 도입하기에 조심스럽다.
버전업을 하려면 엄청나게 많은 코드를 수정해야 하고 충분한 QA를 거쳐야 하는데, 사업과제는 끝없이 들어온다.
많은 사업과제로 인해 원하는 기능을 넣기보단, 필요한 기능을 개발해야 한다.
그리고 그 기능을 개발할 때에도 위에서 말한 API 관리포인트 고민 등으로 인해 매우 조심스럽게, 천천히 개발된다.
이로 인해 사이드프젝에 비해선 확실히 개발의 재미는 줄어드는 듯하다. (회사가 괜히 돈을 주는 게 아니다 라는 지인의 말이 떠오른다. 매우 공감 ㅋㅋㅋ)
하지만!
사이드프젝에서 느끼지 못하는 트래픽 변화, 개발한 기능에 대한 즉각적인 피드백에서 얻는 성취감은 확실히 크다.
또, 많은 트래픽 덕분에 새로운 기술적 도전과제나 성장하는 느낌은 여전하다.
이것마저 없었으면 진짜 일이 힘들지 않았을까 싶다.
이런 점들로 인해 개발자는 적성에 맞는 사람들이 해야 한다고 느낀다.
다행히 나는 적성에 어느정도 맞는 편이지만, 사이드프로젝트를 하면서 적성에 맞지 않다고 느꼈다면 빨리 개발판을 탈출하는 것도 현명한 선택이라 생각든다. (꼰대같은 발언같지만, 느낀점을 그대로 써봤다 ㅜㅜ)
적성에 맞지 않는 상태로 개발자가 됐을 때, 위 점들 때문에 엄청 힘들 것 같다는 생각이 들었기 때문이다.
추가로, 예전에는 ps 및 개발에 관심이 많았지만 요즘의 나는 클라이밍 및 방탈출과 같이 취미가 생겨버린 것도 한몫할 듯하다.
나는 하나에 미치면 광적으로 그것만 파는 DFS 적인 성격을 가져서, 지금은 칼퇴하고 클라이밍하는 것을 매우매우 중요하게 생각한다. 이런 것 때문에 재미를 덜 느끼는 것도 충분한 원인이 될 듯하다. (그렇다고 클라이밍하는 것을 후회하냐 묻는다면 절대 그렇지 않다. 오히려 하길 잘했단 생각이다.)
적고 보니 1년 사이에 많은 성장을 했다고 느껴진다.
하지만, 아직 갈길이 멀다는 생각도 든다.
그리고 또 1년사이에 정말 많이 변했다는 생각도 든다. (개발을 좀 내려두고 클라이밍에 몰두하는 사람이 될줄이야.)
나중에 만 2년, 3년이 됐을 때 더 성장하고 많은 것을 배운 상태이길 바라며!
그리고 그 때에는 우아콘이든 어디든, 더 큰 컨퍼런스에서 발표도 해본 상태였음 좋겠다.
그리고 팀에서 1인분할 수 있는 인력이 되었음 좋겠다.
그리고 클라이밍 더 잘하는 상태였음 좋겠으며, 클라이밍을 접지 않았음 좋겠다. (클라이밍이라는 취미를 가진 것이 너무 행복하다.)