현업에서 말하는 좋은 프로젝트 - 자문위원님들

현업 면접관 입장에서 인상적인 프로젝트?

테오님

• 냉정하게 말씀드리자면 사이드 프로젝트가 면접에서 차지하는 비중이 크지 않음
• 이 사람의 태도, 경험 등을 평가
• 그럼에도 인상적인 프로젝트?
  • 기술적 도전이나 난이도를 가진 것들을 어필하는데, 실직적으로 어려운게 아닐 수 있음
  • 자잘자잘한 것들이 쌓여가는 것들
  • 프론트는 손도 많이 타서 신경 쓰는 만큼 좋아짐
  • 얼만큼 노력하고 고민했는가에 대한 고민이 드러나는 프로젝트
  • 이를 위해 투자한 노력이 보이는 것들
  • 내가 어디까지 만들려고 했지? 완성하려고 했지? 사람들에 대한 반응이 중요
• 프론트엔드의 기술적 완성도를 가지고 보게 됨
  • 관심을 보였다 하더라도 기술적 가치를 가지는 프로젝트
  • 기술적 고민, 기술적 역량을 발휘하는 것
  • 이를 위해서 얼마나 신경쓰고 노력했는지 티가 나는 것들

노성균님(BE)

• 이력서를 보고 면접 여부를 결정하면서 그 과정에서 포트폴리오를 봄
• 완성도를 높이기 위해서 무엇을 고민했는지
• 그러면 이 부분을 면접때 파고들면서 어디까지 고민하고 해결하려 했는지를 확인
• 주니어 개발자에게 기대하는 수준 → 기술자끼리 하는 대화
  • 서로간에 같이 일했을 때 좋은 사람
  • 이력서에 이러한 프로젝트의 완성도를 높이기 위해 데모의 소스코드를 보는 편
  • 데모형 로그인 아이디와 비밀번호 제공이 중요. 대부분 안보심
• 포트폴리오가 이력서 검토때는 큰 비중을 차지하지는 않지만 면접까지 했을 떄는 이야기가 달라짐

중요점

• 왜에 대한 질문에 답할 수 있어야 함

프로젝트의 “완성도”란 무엇인가요?

필주님(And)

• 프로젝트를 봤을 때 Readme, 돌려보는 과정을 한눈에 봤을 때 ,프로젝트를 명확히 볼 수 있음
• 이 프로젝트는 무슨 문제를 해결하기 위한 것인가? 에 대한 명확한 답이 되어 있는 것
• 이게 최선일까? 라는 생각을 하면서 기능개선, 사용자 최적화 등에 대해 다양하게 생가게하기
• 내 목표에 대해 계속 생각하면서 완성도 높여가기

성균님(Web - BE)

• 백엔드의 관점
• 눈에 보이는 부분들이 거의 없음 → 어떻게 판단?
• 단순 기능 구현이 아니라, 실제 서비스에서 지원하고, 잘되면 늘리는 확장성이 높을 수 있는지
• 프로젝트 간단한 기능 구현을 위해서는 겉으로 보일땐 똑같지만 나중에 기능이 추가되면서 확장이 안될 때가 많음
• 프로젝트 팀을 이뤄 협업하는 과정에서 api를 만들면 가져다 쓰는 부분이다 보니까 사용을 할 수 없는 부분이 있음
• 배포에도 수동 배포가 아닌 CI/CD
• • 서버가 죽었을 때 원인을 찾을 수 있어야 함

도영님(IOS)

• 코드로 쳤을 때는 코딩을 많이 하는 것이 좋은 포트폴리오(X)
• 커피를 예시로 말한다면 10잔을 만드는 것보다 맛있는 1잔을 만드는지
• 실수가 일어나지 않는 코드
• UI/UX에 어색한 부분이 없는지 확인

테오님

• 개발자에게 완성도가 중요한 이유 → 마감일이 있기 때문
• 제한된 기간 내에 릴리스
• 릴리즈 한 이후 개선
• 릴리즈마다 의미가 있어야 함
• 어디까지를 잘라도 완성도가 있는지 알 수 있는 능력이 중요
• 모든 개발이 업데이트를 하면서 나가기 떄문에 완성도가 중요
• 그럼 어디까지를 해야할까?
  • 평가에 몰입이 깨지면 그만하는 경우가 많음 → 최소한의 단위
  • 정말 써보는건지/테스트하는건지
  • 내가 정말 이 릴리즈만 가지고도 의미를 만들어 낼 수 있나?
  • 한 사이클에 한 릴리즈 단위로
  • 의미로 부여할 수 있는가? 지속적으로 의미를 부여해나가야 함
  • 지금 무엇을 해야 완성도가 높아지는가?에 대한 기능

좋은 협업은 무엇인가요? 팀으로 일하기 위해 중요한 게 무엇인지

성균님(Web-BE)

• 팀단위로 이루어짐
• 협업을 할 때 중요한 것은 팀끼리 거리감을 좁힌 상태에서 시작
• 자유롭게 의견을 나누기
• 모르는 것을 말할 수 있는 분위기
• 분업을 한 상태에서 열심히 하면 되는 것이 아니라, 팀으로 봤을 때 전체적으로 최적화
• 클라이언트 개발자를 위한 API 만들기
• 문서화하기
• 스케줄을 잡아 일을 하면서 책임감이 없다라고 말할 때 일정이 딜레이 되는 경우 발생 → 바로 말하기

테오님

• 목적을 이루는데 있어서 타협을 하거나 도전할 필요 없이 개인의 목적, 팀의 목적을 맞추는 방법이 얼마든지 있음
  • 최대한 펼쳐두고 모든 것들을 만족할 수 있는 방법을 찾는 것
• 공평하게 하는 것이 협업이 아님.
  • 잘하는 사람에게 일을 더 많이 줄 수 있는 것이 좋은 팀
  • 업무의 총량가지고 평가하지 않아야 함
  • 팀으로써 생각했을 때 팀을 잘되게 하는 방법에 대해 생각
• 막판에 결정을 해야 하는 순간이 올 때 합의하지 말 것.
  • 합의할 경우 서로의 마음 상처가 이루어질 수밖에 없음
  • 결정을 합의하려고 하지 않고, 결정하는 방법을 합의하자
  • 결정권자가 합의하면 신속하고 빠르고 강직하게 갈 것.
  • 고민하단 것은 고만고만하기 때문에 빠르게 하는 것이 오히려 좋음
  • 1명의 리드보다는 여러분야의 결정권을 확실하게 위임해주어야 함
  • 수평은 상호작용의 횟수가 많아지는 것이지 결정권이 공평해야 하는 건 아니라는거 기억하기
  • 좋은팀의 측정 기준 = 상호작용의 횟수!
  • 슈퍼패스? 가져가는 그라운드 룰도 괜찮을듯

도영님(Be)

• 내가 잘하고 싶은 것, 동료가 하고 싶은 것을 판단해서 잘 분배하기
• 은근히 한명이 마두를 잡고 가고 나머지는 따라가게 되는 경우가 많음. 그러다 보면 자기주도권을 잃게 됨
• 어느 팀에 가서 각자의 역할을 해야 하는데, 각자의 역할을 분명하게 가지는 것이 중요함
• 난이도가 낮은 것을 하더라도 확실히 하고, 도움을 필요로 해도 결국 책임은 나라는 것을 계속 기억할 것

필주님(And)

• 협업할 때는 커뮤니케이션을 강조
• 그 전에 각자의 분야에 대해서 확실히 가져가기
• 각자 분야를 정하더라도 너무 거기에 매몰되지 않기
• 내 분야의 코드를 올리고 내가 봤을 떄 이 부분을 고치면 좋지 않을까? 하는 부분에 대해서는 자유롭게 할 수 있는 분위기가 되어야 함
• 문서화를 담당한다 하더라도 다른 사람들도 할 수 있어야 함
• 이가 바탕이 되기 위해서는 커뮤니케이션이 중요
  • 팀 스크럼이나 회고를 의무감에 진행하는 경우가 있었는데, 이럴 때 레드플래그라고 생각하고 돌아보기
  • 스크럼 시간을 기대되는 시간으로 만들기
  • 내 문제 해결 방식을 해결하기
  • 막혀서 답이 없어 보이는데 이걸 오픈하면 해결할 수 있지 않을까? 하고 오픈한 뒤 다른 사람들의 의견도 들어보기

멘토링 시간을 어떻게 보내는 것이 중요할까요?

테오님

• 멘토링을 하게 되면 멘토링을 팀별, 개개인별로 받는 경우가 있음
• 팀의 경우
  • 프로젝트가 좋은 방향으로 가고 있는지
  • 이야기를 들으려고 하기 보다는 설명을 하려고 하기
  • 면접 보듯이 해야 도움이 되고 어떻게 진행되고 있는지 알아야 멘토가 제대로 된 조언을 해줄 수 있음
  • 우리의 맥락을 공유하고 얘기하기!
• 개개인
  • 개인적으로 가지고 있는 문제에 대해 딥하게 코드 스타일, 내용, 방법이 맞는지를 확인받기
  • 실질적으로 어떻게 하는 것이 제일 좋은지 해결 방법 찾기
  • 나의 맥락을 설명함으로써 해결하려고 하기

성균님

• 개발자는 I가 많아 대부분 말을 안하려고 함
• 오프라인으로 만날 수 있으면 최대한 만나기
• 1대1로 얘기하면서 많이 알아갈 수 있는 시간 가지기
• 주변 사람들에게도 게스트로 초대해서 문제에 대한 해결을 다양한 사람들에게 많이 받기

필주님

• 팀 멘토링
  • 모든 것을 물어보는 팀? 기초적인 것을 찾지도 않고 물어보지 않기
  • 너무 세세하게 (여기에 엔터를 넣을까요.. 등) 하는 질문들도 지양
  • 멘토가 대신 결정해주길 바라는 질문을 지양하기
  • 만약 지금 팀에서 어떤 해결 방안에 대해서 좋은 방안이 있는지, 깊게 학습 할 수 있는 방식 듣기
  • 내 해결방식의 장단점을 분석하고 더 있을까요?라는 식으로 물어보기
• 개인 멘토링
  • 어떤 문제를 해결할 건지 정리를 해서 들어가기
  • 코드리뷰 멘토링에서 긴 시간 상담 지양
  • 시간을 정하고 문제를 해결하여 효율적으로 하기
  • 나의 감정상태를 객관적으로 살펴보고 스트레스 관리 방법 찾은 후에 개인 멘토링 시간을 보다 효율적으로 사용하기

도영님

• 질문을 하루 전에 준비하기
• 시간에 임박해서 준비해서 이야기하면 좋은 질문이 되기 쉽지 않음
• 맥락을 이해시키기 위해 질문을 먼저 주기
• 멘토님도 미리 준비할 수 있음
• 정말로 커뮤니케이션을 하면서 좋은 것을 다져 나가는 시간으로 활용하기

분야별로 프로젝트 주제를 기획할 때 고려해야 할 점

필주님

• 영상 컨텐츠, 미디어 컨텐츠, 게시판, 이커머스 등의 프로젝트
• 모든 프로젝트를 할 때 이 API를 제대로 사용했는가? 에 대한 고민을 게속 해야함
• 내가 진짜 필요해서 만드는 프로젝트인지를 생각해보기(중요)
• 해결하고자 하는 문제가 가장 명확해야 함
• 기획은 어차피 바뀌기 때문에 세세한 것까지 하지 않기
  • 현업 가도 맨날 바뀌기 때문에 큰 의미 두지 않기
• 내가 과연 처음 코드를 확장성 있게 썼는가를 고민하기
• ai 많이 활용하기
  • 고려해야 할 점들
    • 복잡한 과정을 거쳐야 결과물이 나오는 스텝을 가지고 있는데 AI를 통해 프로젝트가 단순해질 때 적용하는 것을 생각해보기
    • 내가 ai를 활용한다면 생산성을 높일 수 있을 때

도영님

• 무조건 주제에만 구애받지 않기
• 큰 주제에서 생각해보기
• 실현 가능한 주제를 생각해보기
• 서비스의 범위를 너무 넓게 만들지 않기
  • 할 수 있는 정도의 범위

성균님

• 백엔드 기획할 때 확장성을 고려하면서 하기
• 완성도를 높이기 위해 안정성을 높이기
• 나중에 구현할 때 기획 단계에서 세부적인 고려사항들도 어느정도 생각해보면서 설계하기
• 어떤 식으로 할지 고민 많이 해보기

테오님

• 내가 만드는 가치는 기획이 결정함
• 프로젝트 자체의 가치, 목표가 명확해야 함
• 6주정도의 작은 프로젝트인 만큼 고려해서 만들기
• 저게어도 내가 필요하거나 우리 팀이 필요하거나 관심사를 만들어야 함
• 부스트캠퍼들에게 공감을 받을 만한 것들
• 잘되면 많이 쓸 수 있는 것들이 아니라, 응당 쓸 수 있는 것들
• 엣지 포인트, 당장 쓸 수 있는지의 여부
• 프론트엔드로 가치를 만들기
  • 나의 기술적 가치로 가치를 만들기
  • 사용자가 화면을 통해 데이터 조작, 내용을 받아보기
  • 기술적 가치로 해결할 수 있는 것들(나의 불편함을 해결할 수 있는 것들)
• 목표가 의미 있을 때

사용성에 대한 고민함

• UI/UX에 대한 고민하기
  • 클릭 이벤트 뿐만이 아니라 다양한 이벤트등을 다뤄보면서 사용성을 높여보기
  • • 확장성을 높이게 만들기