협업 특강!

하루·2025년 2월 11일

야생학습은 비순차적이다.

Ex) 사이드 프로젝트 개발

  • 필요에 따라 백엔드 / 프론트엔드 개발을 전환
  • 문제 해결 과정에서 새로운 기술 습득
    • RDB에서 데이터를 뽑아서 전달. 그런데 느리다?
    • In-Memory Cache, Redis

야생학습은 자료에 한정이 없다.

  • 신뢰할 수 있는 자료를 선별하는 능력

  • 그리고 이를 잘 전달하는 방법도 고민

  • 공식 문서

  • YouTube의 각종 강좌, 논문, 개발 블로그

  • GitHub Copilot, Stack Overflow 검색

야생학습은 명확한 평가가 없다.

  • 학습 공부처럼 등급으로 나뉘지 않는다.

  • 회사에서 받는 엔진니어 평가 등급(T1, T2등)도 명확한 기준이 없다.

  • 정량적 지표

    • 커밋 목표
    • 오픈소스 기여 횟수
    • TIL 작성 횟수

  • 정성적 지표

    • 트러블 슈팅 문서화
    • 학습 과정에서 깨달음 기록
    • 기술 역량 자기 진단

야생학습은 정답이 없다.

  • 수학처럼 하나의 답을 구하는 여러가지 풀이법이 존재한다

  • 엔지니어링 문제도 마찬가지

  • 또 수학처럼 답이 없기도 하다

  • 가설을 만들고 실험을 반복

    • 다만 실험 과정에서 프로그래밍이 사용되는 것 뿐

  • 다양한 해결책 탐색

  • 트레이드 오프 분석

  • 리소스를 고려한 해결책 도출

정답은 없으니 계속 시도하고 도전해서 실패를 반복하라.. (좋아질것이다.)

야생학습은 목표가 불분명하고 바뀌기도 한다.

  • 시장의 흐름이 지속적으로 변화
  • 빅데이터, 블록체인, 딥러닝, 생성AI
  • VR, 메타버스, AR, MR

시장 흐름은 어떻게 될지모른다.

쉽게 해볼만한 방법

  • 커뮤니티 참여
  • GitHub에서 프로젝트 시작하기
  • 생성AI 도구 활용
    • 기술 블로그, 발표, 세미나, 스터디 등

뭐든 부딪쳐봐라. 사람끼리 하는 커뮤니티면 더욱 좋다

도마뱀뇌

  • 척수 맨 윗부분에 위치

  • 생존을 위해 존재

  • 식량과 안전만을 원한다

  • 싸워야할 때 싸우겠지만 대부분 도망친다.

마감에 쫓기는 사람의 특징

  • 시간을 끌어 다급한 상황을 만든다.
    • 발등이 불타다 못해 튀겨진다.
  • 모든 감정을 압도하는 아드레날린 분출
  • 몰두하여 완수

-> 내가 도마뱀인 것처럼 위급한 상황에 쫓겨서 굴러라...

프로젝트 예시

  • 온라인 우수타를 돕는 우수타 채널 만들기

야생 -> 자신만에 답을 찾는 과정이다.

QNA

학자형인데 억지로 바꿔야한다?
-> 학자형에 대한 성공 경험이 있나 성향이 저거에 맞다 싶으면 굳이 바꿀 필요는 없다. (억지로 바꾸지는 말라)

신입 개발자는 어떤사람을 채용하나요?
-> 저도 잘몰라요 (시장에 관한 경쟁은 아닌데 채용자에 따라 관점이 다르다.. 무엇을 많이 해본것이 아니라 어떤문제를 해결을 잘하는사람?이 좋다고 생각한다.)

트러블 이슈 블로그 작성을 하려고 하는데 단순한 이유여도 작성을 하면 좋을까요?
-> 하세요 글쓰기는 하다보면 실력이 늘어난다.

오픈소스에 단순 오타 기여도 괜찮나요?
-> 자랑만안하면 괜찮다. 기여에 관련은 기능에 대한 기여가 좋다. 단순 오타는 면접관이 좋아하나? (단 시도 자체는좋다.)

프로젝트가 몇개 있는데 시간 관리가 너무 어려워서 시작을 못하고 있다. 일단 시작을 할까요?
-> 망해도 괜찮다. 결국 이런 여러시도를 걸쳐 하나의 프로젝트를 완성이 나온다.

팀원으로 좋아하는 성격이나 성향 있나..?
-> 질문 요지에 따라 맞는 질문을 하는 사람이 있고 요지를 파악하지 못하고 다른 말을 하고 있는사람과 공격적인 사람은 만나고 싶지않다. (팀워크가 망가지는 상황이 발생한다)
요약 : 극혐이다 라고함...

프로젝트형 공부도 중요하지만, 공식문서가 중요하다는 말이 어느 곳에서나 들린다.
-> 공식문서를 작성하였기 떄문

현업자 분들께서는 서류면접에서 무엇을 중요하게 보시나요?
-> 육각형 인재는 허상이다. 부족한 부분을 채우는 것이 아니라 강점을 부각시키는게 좋다. (무엇이 부족해서 채워야한다고 합격하는게아니다, 누가 원하는것 맞춰가려고 하면 한도 끝도없다..)

코딩테스트 면접이 있는데 솔브하는게 중요하겠지만 무엇을 신경써야 하는지
-> 1. 작동 가장 퍼포먼스를 저하하는 그걸 개선하는 방식 (많이 할수록 유리하다)

불확실성이나 걱정을 이겨내는 자신만의 방법
-> 마인드셋 (내가 할수있는 일이있는가? 내가할수있는 일이없으면 걱정하지말라)
내 생각 : T가 되라...

비즈니스 로직과 같은 로직에 대한 이해도를 늘리려면 여러번에 프로젝트 밖에없나요?
-> 많이 경험을 해보는것이 중요하다.

도마뱀 뇌에서 벗어나기 위해서는 어떤마음가짐이 중요하나?
-> 내가 지금 도마뱀뇌에 걸린게 아닌가 하는 자각을하면된다..

습관을 만드는 좋은 방법은 무엇일까요?
-> 목표를 작게 잡아라 (Ex) 주에 3번 ,2번 성공시 나자신을 칭찬하라 완수에 대한 도파민으로 강화가 된다. 작은목표에 대한 달성에 대한 도파민을 느껴라?

마인드 셋에 대한 읽고 있는 책이있나요?
-> 린치핀?읽어보면 좋다. 린인?(셰릴샌드버그)

프로그래밍을 할때 AI도구를 활용하는것에 대해서 어떻게 생각핫시나요?
프로그래밍 및 코딩을 할때는 최대한 AI도구를 배제하고 하는게 좋나요? 아니면 활용하는게 좋을까요?
-> 활용해도 할루시네이션과 같은 경우도 있고 좋은질문을 해야 그에 맞는 답을 알려주기에 활용하는게 좋다고 생각한다.

자바가 중요하나요 스프링이 중요하나요?
-> 둘중 재밌는걸 하세요

페어 프로그래밍 하는방법
-> 한사람은 프로그래밍 다른사람은 길(가이드)을 알려준다. 룰은 정해져있지않다.

개발문화가 좋은 기업의 사람들은 대표를 잘봐야한다..
-> 기부가 박하다.. (나누는 것이 어렵다..) 회사에 나눔이 적다.. 어떻게 해먹으려고한다.
-> SNS에서 대표 써칭을 잘해라.. 독성 말투 확인 필수
-> 면접관이 독성말투를 한다? 플래그다 걸러라..
신뢰 -> 맡은바만 다하면된다

반에서 실력이 낮은 사람과 높은 사람의 격이 너무 크면 낮은사람일때 어떻게 해야하나?
-> 잘하는 사람을 잘 관찰 해서 한가지라도 배우려고 하면 된다. 특징을 흡수해라

팀내에서 분위기 메이커가 있어야 결과가 좋게 나온다고 생각하는데 어떻냐?
-> 부정적인 얘기를 하면 망한다. 분위기 메이커가 되면 좋다.

개발자 시장에 뛰어드려면 최소 기준이 있지 않나요?
-> 다리를 만들어달라고 할때 다리를 만들수 있는 사람인가를 생각해보라.. 만들어 달라했을땐 만들수 있느냐? 잘만드는건 두번째 이야기이다. (만들 수 있는지가 중요하다, 그 다음이 능력이다.)

신입 개발자로서 java/Spring을 깊이 있게 할까? 아니면 기본적인 수준을 익히고 다른 언어를 활용할까요?
-> 재밌는걸 우선으로 해라 그래야 다른 길이 보인다. 재미있는 경험이 있어야한다.

대표 SNS가 중요하다고 하셔서 일론머스크는 어떻게 생각하냐?
-> 우리나라에 없어서 행운이다. 해악을 생각해보면 다행이다.. 이런 사람이 있다면 안간다.

프로젝트는 재밌는데 코테는 재미없다..
-> 의무적으로 해봐라 계속 도망치면 영원히 못한다.

2부

성공하는 팀은 심리적안정감이 있어야한다.

  • 자신의 생각과 아이디어를 표현하는데 편안함을 느낄수 있는 환경

  • 생산적 토론과 혁신적인 솔루션이 나온다.

  • 8개 병원의 51개 의료팀 대상

  • 팀 성과와 의료 실수 보고율의 관계 조사

  • 팀 내에서 대인관계의 위험을 감수해도 안전하다는 공유된 믿음

  • 실수를 인정해도 괜찮다는 믿음

성공적인 팀?

  • 고성과자로 구성
  • 숙련된 관리자
  • 무한한 자원 지원
    -> 안될것이다.

(실수는 성공의 기회가 된다)

밍글링

  • 서로 편안한 분위기에서 교류
  • 하루 혹은 일주일n회
    • 정해진 시간
    • 모든 구성원 참여
  • 스몰 토크
    • 최근 산 꿀템
    • 좋게된 이야기
  • 아무 질문 가능

킥오프 미팅

  • 개인 스토리 공유
    • 상대에 관한 관심이 필요
  • 최소한의 팀 작업 규칙 합의
    • 룰은 복잡하면 지키기 어렵다
    • 적은 규칙을 만들고, 필요에 따라 추가한다.
  • 소통 채널 확립

일일 체크인

  • 개인 당 최소 1분 이내의 상황 공유
  • 작업을 가로막는게 무엇인지 공유
  • 도움 요청 장려

주간 회고

완벽한팀은 없다

  • KPI등 유명 프레임워크 중 쉬운 방법을 선택
  • 개선점을 찾아서 실행하고, 다시 피드백하는게 중요
  • 필요하다면 익명의 피드백 채널 운영

코드리뷰 & 페어 프로그래밍

  • 좋은 코드를 볼 몇 안되는 기회
  • 관찰을 통해 상대의 장점을 흡수 가능
  • 작은 룰로 적용
    • 점차 필요한 부분과 불필요한 부분을 수정

너그러운 마음

  • 누구나 실수한다.
  • 관대하게 실수를 덮어주자..

잘하는사람도 실수한다.

기버(Giver)

그런데 이제 호구는 아닌

  • 선물을 준다는 마음
    • 선물은 보답을 기대하지 않는다.
  • 눈앞의 이익에 집중하면 장사치가 된다.
  • 긴 호흡으로 선물하자
  • 누가 어려움을 겪는지 살펴보자

API First Development

  • API계약 설계 후 작업
    • API 계약 변경을 쉽게 알려줄 수 있는 수단이 필요
    • 단, 이를 마련할 시간이 없다면 적극적인 콜 플레이
  • 빠른 개발 주기에서 동시 작업을 가능하게 한다.
  • API 변경의 추적과 관리가 용이
  • BE,FE가 쉽게 코드를 생산할 수 있는 도구까지 마련되면 더 좋음.

-> 멱살잡이를 최소화 하라

  • FE에서도 DTO를 써야할까요?
  • 경우에 따라 다르다
  • 그러나, 선호하지 않음
    • 2벌의 인터페이스를 관리하게됨
    • 생각보다 기능 변경이 빈번함
    • 사용자의 선택을 받지 못하고 버려지는 기능이 더 많음

부품 조립은 정확치 않다

  • 잘 설계했어도
  • 맞춰보면 틀어지기 마련

-> 잘안될 것이다.

오너십

역할이 아닌 문제해결을 먼저 생각하는 자세

  • 프로젝트를 만들며 학습하는게 중요하다
  • 누가 무슨 일을 하느냐는 문제가 아니다

profile
하루
이전 포스트

중간 회고

다음 포스트

AWS 강의

0개의 댓글