2024-01-27) K-DevCon 대전 강연 기록

2024-01-27 에 대전에서 열린 "K-DevCon" 기록입니다.

강연 들으면서 기록하느라 다소 이상한 내용이 있을 수 있습니다.

Session 1) Coding test §

• 못들음..

Session 2) Testing §

• 테스트 피라미드
  • unit test: 빠르고 비용이 적음
  • integration test: 느리고 비용이 큼
• 테스트 트로피
  • e2e test: 20
  • integration test: 60
  • unit test: 20
  • 정도의 비중으로 가져가는 것
  • msa 구조의 유행으로 unit test 보다는 microservice 들의 integration 의 중요성이 늘어남
• 테스트 대역
  • 테스트 하고자 하는 부분의 종속성을 가진 부분에 대해서는 대역 (스턴트맨 등) 을 두어서 테스트 과정에서의 종속성을 제거하는 것
  • Dummy: 가짜 데이터?
  • Stub: 종속성을 가진 함수 호출에 대해 “미리 정해진”, “일관된” 답변을 응답하는 놈
  • Fake: Stub 이랑 비슷하지만 일관된 답변이 아닌 실제 구현본의 shortcut? 을 이용해 유사하게 동작하게 하는 것
  • Mock (모의 객체): 예상된 입력에 대해 정해진 답변을 제공? Stub 이랑 뭔차이 인지는 모르겠음
    • Mock 이 실제 구현과 비슷해지면 프로덕션 환경과 비슷해져서 유지보수가 어려워진다
    • 그래서 내가 핸들링하지 못하는, SMTP, 결제, 알람 모듈 등 써드파티를 사용할 때 이용하면 좋다는 듯
• 테스트 코드도 코드이기 때문에 유지보수가 필요하고, 따라서 유지보수의 필요성이 적어지게 작성하는 것이 좋다
  • 깨지기 쉬운 테스트를 지양해라
  • 테스트 코드 간의 종속성이 너무 얽혀 있어서 A 를 테스트하기 위한 테스트코드가 변경되었을 때 B 테스트가 실패하는 경우
  • Tip1) 공개 API 를 활용해 테스트 진행
  • 상태를 테스트해라? 함수의 구현보다는 함수의 입출력 상태에 기반해서 테스트 코드 작성?
• Fixure / Setup / Teardown
  • Fixture: 일관된 테스트를 진행하기 위한 환경
  • Setup: 테스트하기 위한 데이터들을 설정
  • Teardown: 다음 테스트를 진행하기 위해 Setup 에서 설정한 데이터를 다시 원복
• JSON 을 활용해서 테스트 데이터를 정의해 놓자
• 테스트 제목을 잘 지어서 어떤 테스트를 하는 코드인지 한번에 파악 가능하도록 해라
• BDD Pattern
  • DCI
    • Describe: 누가
    • Context: 어떤 상황에서
    • It: 어떻게 작동
• 테스트 코드를 디버깅해야 하는 상황은 피해라
  • 조건, 반복문을 피해라
  • 논리를 넣지 말고 하드코딩을 활용해라
• 특수 케이스를 잘 잡아라
  • 엣지 케이스
  • 코너 케이스: 특수한 조건들이 겹쳐서 발생하는 이슈
• 순수 함수 활용
  • 동일한 입력에 대한 동일한 출력을 반환하는 함수
  • 를 활용하라
  • 변할 수 있는 값 (뭐 현재시간 등) 은 함수 내에 포함하지 않고 입력을 받도록 해라

Session 3: 링크드인 활용하기 §

• 시작하기
  • 프로필 업데이트
  • 인맥 늘리기
  • 인맥의 글 들에 추천 / 좋아요 누르기
  • 인맥들의 글들을 짧은 글과 함께 repost 하여 내 관심사를 퍼트리기
• 적극적인 PR 을 위해서는 프로필 노출 항목 을 전체 공개로 설정하는 것이 좋음
• 인맥 관리하기
  • 1촌의 수를 늘리는 것이 좋음
    1. 1촌의 주변 인물들에게 1촌 추천으로 우선 노출되기 때문
    2. 작성한 글들도 1촌들에게 우선적으로 노출되어 퍼져나가기 때문
  • 1촌은 페이스북 팔로우와는 달리, 질 좋은 인맥만을 선별하여 connect 하기 위한 개념
    • 따라서 1촌 신청/수락은 3만번 정도로 횟수가 제한 되어 있고, 500명 정도의 1촌을 유지하는 것이 권장됨
    • 누군가에게 1촌 신청할때나, 혹은 그 분이 수락했을 시에 간단한 감사인사를 남기는 것이 좋음
• 퍼스널 브랜딩 전략
  • 정체성
    • 나는 어떠한 사람인가?
  • 방향성
    • 그 정체성과 관련있는 활동을 하였는가?
  • 꾸준한 활동
    • 이러한 활동을 얼마나 오랫동안 지속해 왔는가?
• 한줄프로필 (헤드라인) 작성법
  • 직무전문성 - 정체성을 드러낼 수 있는 최대 5개 정도의 키워드 작성
  • 어떻게 적어야 할 지 모르겠다면, 동종 업계의 인원을 검색해서 키워드 참고하기
  • 현재의 직무 외에도 미래에는 어떤 것을 해보고 싶다 등의 미래 지향적인 키워드 들을 넣어놓는 것도 좋음
• 간단프로필 작성법
  • 포트폴리오 + 간단 소개
  • 혹은, 커버레터 (직무 전문성을 나타내는 간단한 자기소개 문구) 를 넣어도 좋음
    • 업무 분야 및 역할
    • 관심 분야
• 경력 및 학력 작성법
  • 회사 간략 소개
  • 나의 역할 / 업무
  • 주요 기술
  • 최신순으로 나열, 그리고 경력 내의 직책이 여러개일 경우 중요도 순대로
• 보유 기술
  • 직무를 대표하는 기술이 먼저 보이게 작성하는 것이 좋음
  • 기술 평가 혹은 동료에게 추천 기능 활용
• 모든 항목을 되도록이면 영어로 작성 (국내에서도 키워드 검색 등에서 영문을 많이 활용)
• 깔끔한 프로필 사진, Full name 기재
• 글 올리기
  • 최근 글들을 보면서 트랜드 및 작성법 파악

Session 4: 연봉협상 §

• 연봉 협상과 통보?
  • 통보: 평가 후 “일방적으로 통보”
  • 협의: 평가 후 “제시 후 협의”
• 정성적 / 정량적 평가?
  • 인사 평가 제도를 숙지?
• 셀프 리뷰
  • 그간의 실적을 회고
  • 실적들을 수치화
  • 추가적인 자기개발 등의 열정 어필?
• 협상에 성공하기
  • 준비가 부족
    • 스스로에 대한 평가를 철저히 하지 못함
    • 어차피 안될 것 같으니까 지래짐작하여 포기
  • 통보를 받았을 때 그냥 accept 하지 말자 -> 이때부터가 협상의 시작이다
  • 기준점 수치화 필요
    • 이런식으로
      • 첫 제안 금액 (최선)
      • 만족 금액 (차선)
      • 결렬 금액 (최악)
    • 이러한 수치를 정해두지 않으면 협상 내내 휘둘리다가 별 소득 없이 끝난다
    • 그리고 이러한 기준점에 대한 데이터에 기반한 근거가 있어야 한다
      • 정당한, 객관적인 이유
    • 또한 이러한 기준점에 대한 제스처도 생각을 해야 한다
  • 감정 컨트롤을 해야 한다
    • 싸우러 가는 것이 아니다 -> 이 협상에 나온 사람도 결정권자가 아닌 중개인의 입장으로 온 것이다
    • 설득력이 없는 개인 사정 등의 근거를 대지 말것
    • 다른 회사랑 비교하지 말 것 -> 회사마다 업무와 사정이 다르기 때문
    • 까내려도 문제의 본질 (희망 연봉의 간격을 줄이는 것) 을 잊지 말고 감정에 휘둘리지 말어라
    • 공통의 적 만들기? 협상자와의 공통의 적을 생각해 내서 서로를 악으로 만드는 것이 아닌 제 3의 악에 대응하는 식
  • 연봉과 성과급을 혼동하지 마라
    • 연봉은 미래의 가치이고
    • 성과급은 과거의 가치이다
    • 따라서 협상 중에 과거의 실적만을 어필할 것이 아니고 이것을 기준으로 미래에는 어떠한 가치를 회사에 안겨줄 것인지를 어필할 것이다
  • 자신감이 반이다
  • 침묵 전략: 먼저 제시하지 마라
    • 얼마 받고 싶냐고 물어보면 얼마 생각하셨냐고 역질문 해보기
  • 시간 끌기: 모호한 워딩? 으로 질질 끌기?
  • 내 이야기는 줄이고 사측의 상황을 들으면서 상황 파악
    • 듣다가 나중에 다시 얘기하자고 미루기 등
• 결정권자도 통보한 연봉에 상향 버퍼가 있다
• 판례를 만들기 싫어서 안된다라고 하면, 대신 보너스로 달라는 식 혹은 복지 향상 등의 협상사례