인프콘에 다녀왔다.
사진을 좀 못찍었는데 오후에 슬렁슬렁가서 4개의 세션을 들었다. 들은 내용을 바탕으로 간단한 인사이트를 정리해보려고 한다.
1. 김영한님의 <어느날 고민 많은 개발자가 찾아왔다 2탄 : 주니어 시절의 성장과 고민들>
김영한님은 인프런에서 자바 스프링분야 1타 강사로 유명하시다고 알고있다. 한 번도 강의를 들어보진 않았으나…
이번 세션을 한 줄로 요약하면 ‘기술에 대한 학습과 비즈니스에 대한 이해를 동시에 가져가야 한다.’ 임.
사실 어떻게보면 당연하고 기본적인 내용이긴 한데, 기술에 대한 열정이 너무 큰 나머지 비즈니스를 등한시하는 개발자가 있다고 함. 내 경우에 빗대어 보았을 때 나도 좀 그런 경향이 있는 것 같기도 하다. 물론 회사에서 진행하는 여러 사업들이 있기에 현재 하고 있는 것에 더 집중하려고 노력한 것도 있지만.. 아무튼.
비즈니스의 이해가 왜 중요하나면, 큰 그림을 그리는 능력이기 때문이다. 전체 비즈니스를 조망하는 능력이 있어야 신규 기능을 개발할 때 어느정도까지 영향을 줄 수 있는지 파악 가능하다. 비즈니스에 대해 잘 알고 있기 때문에 더 영향 범위가 넓은 메인 업무도 할 수 있고 그렇기에 더 도전적인 업무도 가능해지는 이점이 있다.
여기서 영한님은 실무에서 이 비즈니스에 대한 이해를 높이는 실천 방법을 알려주셨다.
1. 유관부서의 담당자들(기획자, 디자이너, 개발자 …) 과의 인터뷰 혹은 질의응답 혹은 대화
2. 어드민 기능 하나씩 다 사용해보기, 사용자들이 쓰는 기능 다 써보기
위 과정을 통해 흐릿하지만 약간의 청사진을 그릴 수 있음.
그 뒤에.. 실제 구현이 어떻게 이루어졌는지, 업무의 프로세스가 어떻게 진행되는지 파악하면 좋다.
예시로 핵심 엔티티, 필드에 대해서 정리해보고 문서화를 하는것도 도움이 될 수 있겠다는 내용이었음.
여기서 회사 일을 할 때 어떻게 적용해볼수 있을까 생각을 좀 해봤는데, 전체 앱을 다 써보고 어떤 플로우로 움직이는지 어디에서 어떤 이벤트가 생기고 상태는 어떻게 관리되는지 문서화를 해보는 것도 좋을 것 같다는 생각이 듬. 언젠간 그 앱을 담당하게 될 수도 있으니깐… 틈날 때 해봐야겠다.
스타트업에 다니면서 느끼는 점은 업무의 주도성을 확실히 가져야 한다는 점이다. 주도성을 가지려면 적극성도 있어야하고.. 정말 정해진 업무 프로세스라는게 없고 매일매일 바뀌는게 많다보니 스스로 내가 이 업무의 주인이다(?) 라는 의식이 없으면 아무도 챙겨주지 않는다. 하지만 그러면서도 그런 투명성과 자율성이 완벽하게 보장된 분위기가 아니라면 참… 😥누가 그러지 말라고 방해하는 것은 아니지만.. 팀의 사기, 또 유관 팀의 사기(?) 도 중요한 것 같다는 그런 생각이 요즘 많이 든다..
암튼 이런 주도성과 적극성을 가지려면 업무의 본질, 이 일을 함으로써 어떻게 돈을 벌것인가(?) 를 생각해야하고 그걸 알려면 기존의 서비스를 비즈니스 그리고 기술적인 측면에서 잘 이해해야 하는 것 같다.
김영한님의 세션이 내가 들은 첫 세션이라 그런지, 아니면 남다른 강의력을 갖춘 1타 강사이셔서 그런지는 모르겠으나 짧은 시간동안 압축된 내용으로 많은 인사이트를 느끼게 해주신 것 같다. 주니어 개발자들에게 많이 들은 질문에 대해 답변을 해주셨는데 나 역시 주니어 개발자다 보니... 특히 생각이 너무 많아서 구현에 시간이 걸리는 개발자는 어떻게 해야하냐는 내용에서는 '가장 단순화된 버전으로 만들어봐라' 라는 답이 있었는데 이게 요즘 참여중인 넥스트스텝 과정에서 나왔던 TDD 개념과도 일맥상통하는 부분이 있어서 무릎을 탁! 쳤다.
2. 토스증권 이승천님의 <점진적 추상화>
추상화에도 비용이 든다, 그래서 무조건적인 추상화는 좋지 않다는 말을 요즘 많이 듣는다. 그래서 그럼 어떻게 추상화를 하는데? 라는 궁금증이 생겨서 들어본 세션. 예시는 은행 송금 api 를 만든다는 가정으로 들어주셨는데, 내가 서버 개발자는 아니지만 '추상화'라는 측면에서 충분히 적용가능한 인사이트를 얻을 수 있었음.
지금 기억나는 것은 크게 추상화를 하는 범위 그리고 시기로 나누어서 설명을 해주셨는데. 소프트웨어가 어떤 방향으로 발전하게 될지 알 수 없기 때문에.. 예를 들면 어떤 기능이, 타입이 늘어나는 방향으로 발전할지 혹은 행위가 늘어나는 방향으로 발전할지 모르기 때문에, 너무 넓은 범위를 대상으로 추상화를 하기 보다는 좁게 가져가는게 추후 변경사항에 대응하기 쉽다는 내용이었다. 예시에서는 코어 로직에 대한 추상화 그러니까 아주 작은 범위에 대한 추상화를 진행해 이후 요구사항에 좀 더 쉽게 대응할 수 있게끔 했다.
또한 추상화 시기는... 좋은 추상화는 더 많은 맥락속에서 이루어진다는 말을 해주셨다. 그러니 더 많은 맥락이 쌓일 수 있도록 개발 초기단계의 섣부른 추상화는 피하는게 좋다는 것.
요즘 나도 섣불리 많은 상황에 유연하게 대처 가능한 코드를 먼저 만들지 않으려고 노력한다. 좀 if문이 많고 구체적인 코드라고 하더라도 여기서 추상화를 했을 때 누릴 수 있는 이득이 당장 많지 않다면, 그 추상화를 하기 위해 들이는 비용이 낭비일수도 있다는 생각이 조금 들었음. 특히 앞서 말한 것처럼 나같이 생각이 많아서 구현에 시간이 걸리는 개발자는 아직 주어지지 않은 여러 상황에 대비하기 위해 생각하는 시간 또한 비용이 많이 들기 때문에 이건 맞는 말 같음.
3. 배휘동님의 <주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드>
이 세션은 프론트 엔지니어를 위한다고 적혀있었지만 실제 내용은 막 밀접한 연관이 있진 않았던 것 같음. 어떤 엔지니어에게나 적용될 수 있을법한 내용이었고, 사실 넓게 보면 엔지니어가 아닌 다른 직군에도 적용될 수 있는 '개인의 성장을 위한 가이드' 정도로 볼 수 있을 것 같다.
세션 참여 전에는 몰랐는데, 이분은 예전에 인상깊게 읽었던 프론트엔드 엔지니어 커리어 로드맵:3가지 전문성 트랙의 저자셨다. 그리고 몰랐는데 내가 구독중인 삶의 밀도를 높이는 여정 이라는 뉴스레터 발행자셨구만... 이건 찐으로 지금 알았다. 뭔가 이분의 가치관이나 지향점이 개인적으로 맞닿는 지점이 있어보여서 재밌다.
암튼,
주어진 시간이 40분이었는데, 시간 내에 다 전달하기 힘든 아주 방대한 내용을 정말 빠르게 소개해주셨다. 너무 좋은 실천 방법이 많아서 나중에 따로 시간을 내서 더 찾아보고 싶다.
세션 초반에 '탁월한 개발자' 에 대한 정의를 했다. 개발자 집단 설문 조사 결과, 아래 5가지 정도로 추릴 수 있다고 함.
- 훌륭한 코드를 짠다.
- 근거를 기반으로 의사결정을 한다.
- 동료의 효과적인 의사결정을 돕는다.
- 작업의 현재 가치를 극대화한다.
- 효과적으로 꾸준히 학습한다.
그냥 이렇게보면 그래서 뭐..? 이런 느낌이 들어서, 세션에서 설명해주셨던 + 내 나름의 이해를 덧붙인 부연설명을 추가해보겠음.
1. 훌륭한 코드를 짠다.
- 잘 돌아가면서 디테일까지 신경쓰는 코드를 작성할 수 있어야 한다. (에러핸들링이라던지, 성능, 메모리, 보안, 스타일 등등)
- 그러려면 기술에 대한 기본기와 이해도 그리고 활용 능력이 뛰어나야겠지.
- 그러나 주니어에게 이 '훌륭함'의 기준이 그렇~게 높진 않다고 함.
2. 근거를 기반으로 의사결정을 한다.
- 그러니까 요즘 핫한(?) 데이터 기반 의사결정을 말하는 것임.
- 만약에 내 의사결정에 대해 새롭지만 약간 불편한 - 반대되는 근거라던지 - 개념을 알게 되었다면, 불편하더라도 다시 재고해야.
- 내가 다 맞고!!! 너네가 다 틀려!!! 라고 하지 말라는 것.
- 정말 은연중에 나 이외에 다른 원인때문에 어떤 문제가 발생했을 것이라고 생각하는 경향이 있는데, 그러지 말아야 함.
- 그래서 고여있지 말고 새로운 정보를 계속해서 습득하고, 받아들여야 한다.
- 이를 실천하는 방법으로는, 의사결정 프로세스를 가져갈 때
문제를 정의하고 -> 가설을 세우고 -> 그에 필요한 지식을 습득하고 -> 실천,행동으로 옮기고 -> 결과를 관찰하고 -> 피드백 얻기
와 같이 시도해볼 수 있겠음. 몰랐는데 큰 범위에서 목표를 실천할 때 이런 방식을 사용하고 있는듯 함. 아직 결과 관찰과 피드백은 못해봤지만...
3. 동료의 효과적인 의사결정을 돕기.
- 이건 커뮤니케이션 스킬에 대한 내용임.
- 동료의 의사결정을 도울 때 효과적이려면, 주니어의 입장에서는 질문을 할 때 고맥락으로 질문을 하고 부탁을 해야함.
- 그러니까 ABC 에 대해서 질문할 때 C 말고 AB도 같이 질문하라는 것임. 이 AB가 맥락이다.
- 이건 '질문 잘하는 법' 과 같은 키워드로 검색하면 많이 나오는 팁이기도 함.
- 여기서 인상깊었던 점은 '취약성을 드러내야 신뢰를 쌓을 수 있다' 라는 내용이었다. 업무적인 인간관계 뿐 아니라 일상적인 관계에서도 적용되는 말인듯... 이 말을 업무에 적용하면 모르는 것을 부끄러워하지 말라는 셈이 됨.
- 내가 모르는 것을 부끄러워하지 않고, 충분한 맥락으로 질문을 했을 때 다른 동료 개발자들, 내 상사 개발자에게도 도움이 되는 방향이라는 것으로 결론내릴 수 있겠다.
4. 작업의 현재 가치 극대화
- 현재 코드가 미래의 기술 부채가 되지 않도록, 현재의 작업을 잘 해둬서 나중에 있을 유지보수 비용을 줄일 수 있어야 한다.
- 이것은 어느정도 기술적인 역량과 경험적인 측면이 뒷받침 되어야 할 듯. 내가 할 수 있는건 멀리 내다보려고 노력하는 것임.
5. 꾸준히 '효과적으로' 학습하기
- 원래는 꾸준한 학습이었는데, 휘동님이 '효과적으로' 라는 부사를 덧붙이셨다고 함.
- 이 효과적인 학습을 위한 여러 방법들이 있겠지만... 세션을 듣고 느낀 내 개인적인 경험에 대해서도 덧붙여보고 싶다.
개발자가 되기로 결심하고부터 넘어야 했던 산은 (누구나 그랬겠지만) 방대한 정보 습득과 체득이었다. 지금도 많은 도움이 되는 것은 내가 무엇을 알고 무엇을 모르는지 정리하는 것부터 시작하는 것임. 그리고 처음부터 너무 어려운 책 막 자바스크립트 딥다이브 이런거 읽으면 이해가 1도 되지 않기 때문에, 진짜 간단한 것부터 시작해서 점점 범위를 넓혀가는게 개인적으로 느낀 효과적인 학습법이었음. 이걸 할 수 있으려면 메타인지를 잘 발휘해야한다.
처음 보는 지식과 개념을 접할 때 크게 세 가지 느낌이 드는데, 이에 따른 나름의 학습 액션(?)이 있다.
1. 아 이거 좀 쉬운데 - 왠지 다른 사람한테 가르쳐 줄 수 있을 것 같아! 그러면 블로깅을 하면서 심화 자료를 찾아보고 내 언어로 정리해 체득
2. 아 이거 좀 어려운데 - 왠지 차근차근 하면 이해할 수 있을 것 같아! 그러면 진행 과정을 스스로 메모하고 거기서 파생되는 궁금한 점들을 위주로 추가 학습을 진행함
3. 아 이거 아무리 봐도 이해가 안돼 - 아직 경험치가 부족하므로 나중에 다시 돌아온다. (어차피 돌아오게 되어있음)
특히 2번의 경우는 회사 일을 할 때 많이 느끼고 있음. 사실 요즘 블로그에 쓰는게 대부분 2번에 대한 내용이긴 하다. 아무튼 세션을 듣고 여기서 추가하고 싶은 단계는 '피드백' 이다. 피드백은 셀프 피드백일수도 있고 동료 피드백일 수도 있는데 가장 쉬운건 스스로 해보는거니까. 이 지식과 행위가 어떤 임팩트를 끼쳤는지 평가해보는 것도 좋은 시도가 될 수 있을 것 같다.
추가적으로 휘동님의 세션은 다른 그 어느 세션보다 속도가 빠르게 진행되었다. 나중에 녹화 영상이 올라오는지는 모르겠지만... 마치 너무 똑똑하셔서 하고 싶으신 말이 넘쳐서 흘러내리는 느낌이었달까?
분명 짧은 후기라고 했는데, 개인적인 인사이트를 추가하다보니 내용이 점점 길어지고 있다..
늘 글을 두서없이 쓰는 스타일이기 때문에 어쩔 수 없음...
4. 김태희(로토)님의 <SSR의 기쁨과 슬픔 : 렌더링의 변화의 흐름을 통해 알아보는 SSR과 Streaming SSR>
요약하자면 여러 상황으로 인해 Next.js, remix 같은 프레임워크를 쓰지 않고 직접 SSR 로 웹뷰를 구현했다는 내용. 여기서 SSR이 가진 문제점이 API prefetch 시 오래걸리면 화면이 뜨는 시간도 오래걸리는데 이를 해결하기 위해 Streaming SSR 을 도입했다는 내용이다.
요즘 이제 다시 트렌드가 SSR 로 넘어가고 있는데, 프론트개발자라고 하지만 서버와 인프라에 대한 지식도 어느정도 갖추어야겠다는 생각이 많이 들었던 세션이다. 그리고 최근에 회사에서 배포 관련 이슈가 있었는데 이게 인프라쪽 문제인지 인프라 문제라면 거기서도 뭐땜에 이러는건지 알 수가 없어서 답답한 적이 있어서... 그 맥락을 잘 알기 위해서라도 학습할 필요가 있겠다는 생각이 들었음.
후기
이미 내용안에 후기를 다 같이 작성해버리긴 했지만.
개인적으로 재미있었던 점은, 개발자들 솔직히 IT 관상이라면서 다 똑같다고들 하지만 사람인지라 다들 성향이 다 다르다. 이번 세션 발표자분들이 어떤 분들인지 더 알고싶어서 검색을 좀 해봤는데, 모두 삶의 지향점도 다르고 가치관도 다르고 글 쓰는 스타일도 달랐다. 개발 업계의 좋은 점은 공유 정신이 넘치다 보니 이런 삶의 가치관이나 지향점까지도 함께 공유하고 성장하는 분위기가 있다는 점인듯... 이번에 들었던 세션이 기술 위주보다는 성장에 초점을 맞추었기 때문에 더 그런 느낌을 받았는지도 모르겠다.
그리고 나도 나만의 지향점과 가치관을 가지고, 그리고 거기에 자신감을 가지고 이 일을 계속해나가야겠다.. 는 생각도 하게 되었다.
'회고' 카테고리의 다른 글
2023년 회고 (4) | 2024.01.01 |
---|---|
[회고] 2023년 상반기 회고 (feat. 취업 회고) (3) | 2023.06.13 |
[Project] 🪙데일리 옥션 최종 회고🪙 (2) | 2023.03.17 |
[회고] 부트캠프 수료 후 1개월이 지났다. (1) | 2023.01.14 |
[프로젝트 기술 회고] 데이터 가져오기, 업데이트를 위한 SWR 적용기 (1) | 2022.12.26 |