2023 인프콘 후기(별 것 없음)

NANA·2023년 8월 16일
0

그냥일기

목록 보기
3/7

개인적인 후기

  • 개발자 컨퍼런스는 사실 천하제일 굿즈 대회가 아닐지?
    나는 굿즈에 관심 없는 사람이라서 굿즈를 받으러 이 부스 저 부스 다니면서도 '이게 뭔가..'하는 생각이 들었다. 특히 나는 스티커 붙이는데 흥미가 없는 사람인데 스티커만 10조10억개 정도 받은 것 같다. 남의 회사 로고가 떡하니 있는 스티커가 나에게 무슨 귀여움을 줄 수가 있죠..? 나한테는 그냥 예쁜 쓰레기.. 지구야미안해템이지만..!!! 한편으로는 이런 스티커를 덕지덕지 붙여서 나만의 개성을 뽐낼 수 있는 직군에 있다는 것을 실감하고 또 거기에 감사했다. 이번에 받은 스티커들을 여기저기 붙여서 나도 개발자스러움을 뽐내 봐야지.
  • 혼자는 외로워
    스탬프 받으러다니고 부스 돌아다니는 건 즐거웠는데 네트워킹은 도저히... 혼자서.. 할 자신이.. 없었다. 그 이유는 직장 생활을 하며 사회성이 소멸된 내 탓도 있고, 다들 뭔가 어려보여서.. 이모가 껴두 될까..^^ 싶기도 했고, 나는 워낙 기술 스택이 애매하다보니 어디 무리에 껴서 대화를 섞기가 쉽지 않을 것 같았다.
  • 세션 시간 넉넉히 주세요..
    세션은 다 좋았다. 40분 짜리도 있고 20분 짜리도 있었는데 대부분 다 내용이 풍부해서 시간에 쫓기는 느낌이 있었다. 개최측에서 철저히 시간관리를 해서 마무리를 쫓기듯이 했던게 아쉬움. 근데 왕왕 좋았음!

세션 후기 및 정리

친구들이 요약 해줌

1. 지소라 님의 <2곳 중 1곳은 무조건 합격하는 개발자 이력서 만들기>

  • 너무 당연하지만 낙담하지 말기
  • 이력서는 구글 독스를 활용하고 포트폴리오는 노션을 활용. 피그마 같은 디자인 툴 활용하는 것도 방법. 노션은 export가 어렵고 행간 조절이 안돼서 한 장 축소가 어렵다.
  • 이력은 불렛포인트로, 기술 위주(일종의 위키 형식). 한 문장에 why, how, what이 정리 돼야 한다.
  • 문제 - 연구 - 해결 : 어떤 문제를 / 어떤 식으로 구체화 / '기술적으로' 어떻게 해결?'
  • 서사가 있는 것이 중요하다.

일단 소라님은 열정이 매우 넘치셔서 이것저것 경험이 많아 이력서에 쓸 내용이 많은 것부터가 나에게는 큰 도움이 안됐다. 대신에 엄청난 자극을 받았다. 내 자신이 아무 콘텐츠가 없는데 왜 내 이력서는 짱짱하길 바랬던걸까? 작지만 나만의 사이드 프로젝트도 해보고, 회사 업무 회고도 해보고.. 기록을 해두는 것이 좋겠다.

2. 이동훈 님의 <왜 내가 만든 서비스는 아무도 안 쓰지?: 개발자가 알아두면 좋은 사이드 프로젝트 제작 팁>

  • 좋은 문제를 찾고 이해하고 해결하자.
  • 솔루션을 먼저 정의하고 사용자를 끼워 맞추지말고, 시장의 니즈를 이해하자.
  • 당연하게 생각하는 걸 당연하게 여기지 않기. 당연하게 생각했던 프로세스에 반문하기. 왜 이런 문제가 생기는지 고민해보기.
  • 가능한 짧은 시간에 완성 돼야 한다. 완성을 목표로 해야한다. 동기 부여가 중요하기 때문!!!
  • 처음부터 완벽하게 개발하려는 생각을 버리고, 3-6개월 정도로 잡는다. 핵심 기능 하나에 집중한다.
  • 대부분의 사이드 프로젝트는 실패한다. 과정에 집중하자.
  • 기록과 회고 : 어떤 문제를 어떻게 해결했는지, 어떤 기술 스택을 왜 사용했는지, 어떤 결과가 있었고 얻은 점은 무엇인지 여정을 기록하자.
  • 작은 시도, 작은 실패, 작은 성공

내 스스로 느끼던 나의 문제점에 대해 정곡을 찔린 것만 같던 세션.. 일단 작은 거라도 실행에 옮겨보자, 제발 마무리 좀 잘해보자.

3. 김영한 님의 <어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들>

  • 팀 기술 -> 업계 메인 기술 -> 주변 최신 기술 순서로 학습 범위를 넓힐 것
  • 팀 기술을 잘 이해하는 개발자가 되는게 우선이다.
  • 기술을 학습한다는 것 : 기술의 원리를 이해하고 깊이 있게 학습, 그 기술이 왜 필요한지 이해, 해당 기술을 사용해서 밑바닥부터 스스로 완성, 문제가 발생했을 때 해당 기술에 대한 해결사 역할
  • 비즈니스 이해가 정말정말 중요하다.
  • 회사마다 있는 admin의 기능 전부 이용해보고, 사용자의 기능을 사용해보기. 기획자, 팀장, 문서 등등 활용해서 비즈니스 이해하기.
  • 데이터(핵심 테이블, 핵심 필드) 정리, 핵심 업무 프로세스 정리
    - 비즈니스 이해는 좋은 시스템 설계의 핵심이다. 애플리케이션 아키텍처의 선택은 변경 가능성의 영향이 큰데, 비즈니스를 제대로 알아야 변화에 대해 올바른 선택을 할 수 있다.
    - 내가 성장하기 좋은 환경이란? 지금 좋다기보다는 일하기 좋은 방향으로 바꾸어 나가려고 노력하는 조직, 내 도전과 고민을 응원해주는 조직
    - 생각과 고민이 너무 많은 개발자들은? 개발구조/최적화/아키텍처 -> 이 셋을 모두 단순화 할 것! 단순한 걸 먼저 개발해본다. 최적화는 웬만하면 안하는 것이 좋고, 필요할 때 필요에 의해 엔진을 늘려라. 마이크로서비스도 그걸 할 가치가 있을 때 시작해라!!!(정말 속이 시원했다.)
    - 인강을.. 2배속으로 들으면서 공부하지말고 한 번에 하나씩, 정리하면서 하나씩!

영한님이 왜 일타강사인지 알 수 있던 세션이었다. 내가 최근에 갖고 있던 고민들에 대해 귀신같이 답변이 돌아오는 세션..! 최근에 업무 압박, 개발자로서 내 미래에 대한 불안감, 상사와의 갈등 등으로 스트레스가 최고조에 달했고 무엇보다 의욕이 너무 떨어진 상태였는데 이 세션을 통해 뭔가 얹힌 것이 쑤욱 내려가고 내가 어떤 태도로 개발 공부에 임해야 하는지 마음을 다잡을 수 있었다. 그리고 지금 내 직장에 대한 판단이 아주 또렷해졌다^^.

4. 이승천 님의 <점진적 추상화>

  • 개방-폐쇄 원칙(OCP, Open-Closed Principle)은 '소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다'는 프로그래밍 원칙이다.
  • 우리는 이 원칙을 지키기 위해 인터페이스를 활용한다. 하지만 확장의 '축'을 고민해두는 것이 좋다.
  • 어떤 타입(원화 입출금, 달러 입출금)을 중심으로 코드가 확장이 될지, 혹은 행위(생성, 승인 등)를 중심으로 코드가 확장이 될지 예측이 어렵다. 현실 비즈니스에는 확장의 다양한 축이 있으므로 처음부터 특정 축을 중심으로 확장 가능성을 예측하고 추상화를 해놓으면 안된다.
  • 너무 넓은 범위를 추상화 하지 말자. 처음부터 인터페이스를 만들지 말고, 함수 분리부터 한 뒤 클래스로 응집을 시키자.
  • 콜백 메소드 패턴... 공부하자.

코드를 보면서 함께 문제를 해결해나가는 세션이라 재밌었다. 물론 내 개발 지식이 얕아서 중간부턴 잘 못따라갔지만 예전부터 개인적으로 가지고 있던 의문.. '인터페이스를 대체 왜쓰노..?'에 대해 대답이 충분히 되었던 세션이다. 내가 인터페이스를 제대로 활용하지 못했던 것은 이미 내가 특정 축을 중심으로 인터페이스를 만들어 놓았던 탓이었다. 비즈니스의 특정 부분에만 확장 가능성이 열려있고 다른 부분에서는 그렇지 못하니 새로운 요구조건이 들어올 때마다 인터페이스까지 손을 대며 수정을 해야했고, 그렇기 때문에 인터페이스의 유용함에 의문을 가질 수밖에 없던 것이었다!

5. 이일민(토비) 님의 <스프링과 함께 더 나은 개발자 되기>

  • mvc step-by-step / Pet Clinic : 스프링 초창기부터 스프링을 활용한 코드를 잘 보여주는 샘플들
  • 스프링 javadoc 문서 아주 좋음
  • webMVC in the spring framework
  • 이 기술은 왜 이렇게 만들어졌나, 나는 왜 이 기술대로 코드를 짜야하나
  • IoC/DI는 뭐고, 내 코드에 무슨 도움이 되나
  • 스프링의 목표는? POJO, 선언적, 비침략적
  • 스프링의 원칙을 내 코드에도 적용 가능해야 한다.
  • 튜토리얼 예제 반복 작성, 새 기능 추가하고 설꼐 구조 변경 해보고.. 이래야 실력이 늡니다.
  • tdd는 내 코드말고 남이 만든 코드를 익히기 위해서도 활용 가능합니다.
  • 개인 위키와 문서도구를 활용하세요, 단순 정리에 시간 많이 들이면 안됩니다.

나는 어쨌든 스스로를 자바/스프링 개발자라고 정체화(?) 했기 때문에 토비 님의 세션을 가장 기대했다. 세션을 듣고 나서 나는 처참히 부서졌고.. 내가 정말로 아무것도 모른다는 사실을 깨달았다. 하지만 스프링의 역사와 토비 님이 어떻게 스프링을 학습했는지 그 과정을 들으며 오히려 흥미가 생기기도 했다. 스프링 책들을 보며 코드만 따라칠 때는 계속 '이게 뭐가 좋은데..?'하는 의문이 들었는데, 아주 먼 옛날 옛적 스프링의 탄생기를 알고 나면 스프링이 왜 좋은지를 더 잘 알 수 있을 것 같은 느낌적인 느낌..!!! 비단 스프링 뿐 아니라 어떤 기술이든 마찬가지일 것이다. 나는 늘 새로운 기술을 배울 때 남들보다 이해가 느리고 배움이 와닿지 않는다는 기분이 들었는데 그 이유가 이 세션에 있었다. 나는 뭔가를 배울 때 '왜?'가 꼬리에 꼬리를 무는 사람이다... 어떤 기술을 배울 때도 '이게 왜 필요한데', '왜 좋은데', '내가 왜 이걸 써야하는데'에 대한 대답을 스스로 내놓지 못해서 학습이 어려웠던 것이다. 물론 이것들을 다 알려면 많은 시간을 들려서 기술의 오랜 기원을 찾아야한다. 이건 내 열정에 달린 일이다..

인프콘은 자취생에게 도움이 된다

인프콘 다녀와서 얻은 것 : 스티커 한사바리, 귀여운 키캡, 티셔츠 두 장, 수건 두 장, 비누 하나, 칫솔 하나, 물 하나, 서머캐리백 하나, 인프런 수강 할인권, 지금 회사에 대한 현타, 이직한다 반드시.

profile
기술블로그 그런 거창한 거 아닙니다. 일기에요 일기

0개의 댓글