# 인프콘 2023 기회가 생겨 인프콘 2023년에 다녀왔습니다. 정말로 많은 사람들뿐만 아니라 여러 기업도 참여 했었습니다. 각 부스에 가보니 회원가입을 유도하는 기업도 보였으며, 회사 관련된 설명 및 채용 관련 정보들을 볼 수 있었습니다. (기념품도 줍줍..) 각 발표 세션을 보고 배운 점을 정리해보려고 합니다. ### 인프랩의 미래 - 교육을 넘어 라이프타임 커리어 플랫폼으로 - 가장 인상 깊었던 부분은 키워드별 유입 관련된 수치였습니다. 인프런하면 당연히 기술 스택을 검색해서 유입이 될 것이라고 생각했는데, “사이드 프로젝트”를 통해서 유입되었다는 사실이 신기했습니다. - 이러한 데이터를 바탕으로 이틀 동안 기존 게시판을 복사해서 팀 프로젝트를 모집하는 페이지를 만들었습니다. 이후로 사용자의 유입도 증가하였다는 것을 확인할 수 있었다고 합니다. - 인프랩에서 팀 프로젝트로 유입되는 사실을 보아, 그만큼 인프런 강의를 듣는 사람들은 어느 정도 팀 프로젝트를 하기에 적합하다고 생각하여 유입되었다고 추정했습니다. - 더 나아가서 동영상 강의로만 그치는 것이 아니라 채용과도 연계해서 커리어 플랫폼까지 확장하려고 시도하고 있습니다. - 단순한 가설이 아닌 데이터를 바탕으로 MVP로 만들어 발전시키려는 모습이 보였습니다. ### 소프트웨어 설계를 위한 추상적, 구조적 사고 - 이선협 님 - 개발자가 하는 일은 프로그램을 만드는 일입니다. - 프로그램을 만드는 이유는 문제를 해결하기 위해 만들어집니다. - 문제 해결을 위한 프로세스 : 문제 해결 → 설계 → 구현 → 평가 - 어떤 시니어가 되어야 할까요? - 시니어 개발자는 풍부한 경험과 직관입니다. - 하지만 경험과 직관에 의존하면 분명한 한계가 있습니다. - 어떠한 문제를 발견하더라도 유연하게 해결할 수 있는 방법론을 익히는 것이 중요합니다. - 현상 / 물체 → 분석 / 해체 → 결합 - 패러다임은 사람을 위한 것입니다. - 모든 프로그램은 순차, 분기, 반복, 참조로 구성되며, 내가 만드는 소프트웨어는 어떤 패러다임이 적합한지를 고민해봐야 합니다. ### 2곳 중 1곳은 무조건 합격하는 개발자 이력서 만들기 - 지소라 님 - 가져야하는 마음 가짐은 낙담하지 않기 입니다. - 이력서에는 “WHY”, “HOW”, “WHAT’이 필요합니다. - 이력서는 노션으로 작성하기 보다는 구글 독스 또는 피그마로 작성하는 것이 좋습니다. (자간 조정, 정렬 등..) - “이걸 해본적이 있어요…” 라고 나열하는 것은 뱃지 모으기나 다름이 없습니다. - 개발자는 기획 능력을 보는 것이 아니라 기술적으로 어떤 식으로 해결했는지 푸는 것이 중요합니다. - 작업물을 모아볼 수 있는 모음집 부재는 포트폴리오로 풀어나갔습니다. - “AS-IS” : 문제 상황 인지, 해결하려고 하는 문제, 만들고 싶은 기능 - “Challenge” : 문제해결을 위해 고민한 내용, 어떻게 기술적으로 해결했는지 - “To-BE”: 아웃풋(결과) ### 왜 내가 만든 서비스는 아무도 안 쓰지?: 개발자가 알아두면 좋은 사이드 프로젝트 제작 팁 - 이동훈 님 - 좋은 문제를 찾고, 이해하고, 해결하는 것이 중요합니다. - 작가의 생각으로 만들어지는 것 + 시장의 니즈로 만들어지는 것 - 솔루션을 먼저 정의하고 고객을 끼워 맞추는 경우는, 내가 만들고 싶은 서비스를 만들고 싶었던 것이며, 고객을 고려한 것이 아니라는 것을 알아야 합니다. - 좋은 문제를 찾는 방법은 “반문하기”, “관찰하기”, “펼쳐보기” 입니다. - 주변에 문제를 찾기 어렵다면 나 자신이 고객인 문제를 찾아보는 것도 방법이 될 수 있습니다. - 가능한 짧은 시간에 배포하는 것이 좋습니다. 동기 부여를 지속해서 얻는 것이 사이드 프로젝트의 의의이기 때문입니다. (3개월 or 6개월) - 오래 개발한다고 완성도가 있는 서비스가 되는것은 아닙니다. - 핵심 기능 하나에 집중하는것이 좋습니다. ### 어느날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들 - 김영한 님 - 기술 공부를 안 하는 개발자 - “저는 따로 기술 공부를 하지 않아도 팀에서 필요한 업무를 모두 처리 할 수 있어요” - 1년차 경험을 10번 반복하는 10년차가 됩니다. - 기술 트렌드 찍먹 개발자 - “기술 공부를 하기는 하는데…” - 팀에서 사용하는 기술도 제대로 이해하지 못한 상태입니다. - 새로운 기술을 도입하자고 한다면? - 기술의 깊이가 만들어지기 어렵습니다. - 팀 기술을 잘 이해하는 개발자 - 팀에서 사용하는 기술 역량을 잘 알아둡니다. - 기술을 잘 이해해서 팀 업무를 원활하게 진행합니다. - 팀에 기술 문제가 발생했을 때 원인을 정확히 파악해서 해결합니다. - 팀 기술 학습의 장점 - 동기부여 - 사람은 당장 본인에게 필요한 것을 더 빨리 학습합니다. - 학습 사이클 - 학습 → 업무에 학습한 내용을 활용 → 활용하면서 고민되는 부분 학습 → … - “팀의 기술 → 업계 메인 기술 → 주변, 최신 기술” 순으로 학습해야 합니다. - 기술을 업무에 사용할 줄 안다고 그 기술을 잘 아는 것은 아닙니다. - 비즈니스 이해가 약한 개발자 - 큰 그림에서 전체 상황을 이해하지 못합니다. - 지도가 없으므로 어디까지 질문해야 할지를 잘 모릅니다. - 작업의 영향 범위가 어디까지 영향을 미치는지 파악이 어렵습니다. - 요구사항을 제대로 처리하지 못합니다. - 중요한 메인 업무가 있을 때, 영향 범위를 잘 모르기 때문에 실패할 가능성이 높습니다. - 더 큰 업무를 맡기기는 어렵습니다. (팀의 서브 업무) - 비즈니스를 잘 이해한 개발자 - 지도가 있으므로 어디까지 질문해야 할지를 잘 이해합니다. - 시간이 지날수록 전체 그림에 살을 붙여서 비즈니스와 아키텍처에 대한 이해도가 높아집니다. - 큰 변경사항이 있어도 영향 범위가 어디까지 미치는지 이해합니다. - 좋은 시스템을 설계하려면? - 개발을 잘하기 위해서는 비즈니스 이해가 필수입니다. - 비즈니스를 이해해야 좋은 아키텍처 설계 가능해야 합니다. - 애플리케이션 아키텍처의 선택은 변경 가능성의 영향이 큽니다. - 이게 변할지 안 변할지 선택이 필요합니다. <- 비즈니스를 알아야 가능합니다. - Why - 내가 리더라면? - 리더는 100번 질문해도 100번 대답할 준비가 되어 있어야 합니다. - 왜 이 일을 해야 하는지 잘 풀어서 설명해야 합니다. - 팀장만 리더가 아닙니다. 모두가 리더입니다. - 지금이 좋다기보다는 일하기 좋은 방향으로 바꾸어 나가려고 노력하는 조직이 성장하기 좋은 환경입니다. ### 그 많던 코드는 누가 다 먹었을까 : Kotlin multiplatform을 활용한 서비스 런칭기 - 최근호 님 - 도입하게된 배경은 서버가 90% 가 되었는데, 플루터로 완성도 0%를 해놓고 도망을 쳤기 때문입니다.. - 도입 할 때 두 가지를 고려했습니다. - 안드로이드 개발에 영향이 없어야 합니다. - iOS 개발자 합류 시 생산성을 극대화할 수 있어야 합니다. - Shared 모듈에 state를 통해 viewState를 코틀린으로 정의하고 android 및 iOS에서 옵저빙하는 방식으로 구현했습니다. - iOS 개발자 합류 이후 원하는 기간에 맞춰 android, iOS 앱을 개발했습니다. - shared module을 cocoapod 에다가 배포함으로써 빌드 속도를 최적화 할 수 있었습니다. ### 우리는 이렇게 모듈을 나눴어요: 멀티 모듈을 설계하는 또 다른 관점 - 조민규 님 - 멀티 모듈의 필요성 - 앱을 만드는 사람들 - 만든 앱을 검수하는 사람들 - 앱을 사용하는 사람들 - 플랫폼을 운영하는 사람들 - 기타 등등.. - 결합을 분리하되 서비스가 되기 직전에 멈추는 방식을 선호합니다. - SRP = 변경의 이유가 하나여야 합니다. = 하나의 엑터야야 합니다. - Common 모듈을 수정하면 다른 모듈까지 영향을 주게 됩니다. - 멀티모듈 설계하기 - 시스템에 독립적인 공통 코드 EX) StringUtils - 시스템에 종속적인 모듈 - 핵심 비즈니스 로직 : 시스템의 유/무와 상관없이 존재하는 비즈니스 로직이어야 합니다. - 유스케이스 : 시스템이 있어야 유효한 비즈니스 로직이어야 합니다. - 엄격하게 공통 모듈을 관리하기 위해서 - 공통 모듈의 세분화 > 우선 패키지로, 지나치게 복잡해지면 세분화를 해야합니다. ### 시니어 개발자 너머의 성장: 대규모 조직을 위한 스태프 엔지니어 - 남상수 님 - 고정 마인드 셋 - 누구나 정해진 만큼의 재능과 능력을 지닌채 태어나고 이러한 자질이 고정되어 있다고 생각합니다. - 성장 마인드 셋 - 우리의 능력은 가변적, 노력할 수록 발전할 수 있다고 생각합니다. - 성장 그래프 - 새로운 경험과 능숙 그리고 새로운 경험의 반복입니다. - 성장 방향 - 익숙함을 넘어 새로운 경험을 위해 내가 원한 성장의 방향은 무엇인지 고민해봐야 합니다. - 포지션을 바꾸거나, 팀을 바꾸거나, 리딩을 하는 방법등이 있습니다. - 개인의 방향과 업무의 방향이 일치시켜야합니다. - 채용공고를 통해서 더 객관적으로 알 수 있습니다.
로그인 후 모든 글을 볼 수 있습니다.