99CON(99콘) 연봉협상 2019 내년, 나의 연봉은

짧지만 달콤한 이야기 99CON Dec 2019 내년, 나의 연봉은 

99콘 하이라이트

경력자에게도 수습이 필요하다

레이니스트 안성현, '수습평가'편

• 회사에서 안정적으로 다니고 있었음
  
• 다니다보니 이직 생각이 들음
  
• 폐쇄적인 곳에서 작업하니까 aws, github등 다른 기술을 사용하고 싶었음
  
• 이직
  
  • 만능 이력서를 작성하여 뿌림
  • 회사 별로 정리(SI, 스타트업 등등)
  • 면접을 많이 보는것이 좋음
  • 휴가를 내는것이 힘드니 하루에 3시간 간격으로 여러곳을 면접봄
  • 몇군데 합격을 했으니 어디를 갈것인가?
  • 내가 중요하게 생각하는 것은?
  • 항목을 작성하여 가중치를 정함
  • 그래도 비슷하거나 수치화 할 수 없는 느낌이 있음
  • 비슷한 도메인의 실리콘밸리/유니콘 회사를 비교해보기
  • 해당 도메인의 회사가 어느정도의 가치를 지니는가?
• 왜 스타트업을 선택했는가?
  
  • 현역 개발자
  • 성장
  • 기술적인 부분을 수평적으로 토론
  • 기술 조직/개발 문화를 만들고 싶음
• 입사 했는데 경력 수습이 있음
  
  • 예전 회사들
    
    • 수습이 끝났는데 회사가 망함
    • 80%월급
  • 레이니스트
    
    • 과제를 스스로 선정 협의
    • 2개월 동안 진행
    • 진행하는 과정을 피드백 진행
• 입사 초기
  
  • 무엇이든 물어보라고 함
  • 경력자도 모르는 것이 모른다.
  • DM 을 지양하는 문화
  • 공개된 질의에 대한 두려움
• 또 하나의 두려움
  
  • 경력자 != 시니어
  • 시니어의 대한 기대감
  • 나는 시니어라고 생각해 본적이 없음
  • 나는 시니어리티가 있나?
• 물어보기
  
  • 공개 채널에 많이 물어보기
  • 만남의 광장(회의)
• 공유하기
  
  • 어떤 작업을 하고 있는지 공유
  • 작업 내에서의 고민을 공유
  • 어떤 방향으로 하면 좋을지를 공유
• 시니어리티에 대한 고민
  
  • 기술적/경험적으로 알려주기
  • 모르는 것은 모른다
  • 먼저 실천하기
• 수습 피드백
  
  • 세번의 피드백
    
    • 협업하는 분들의 피드백
    • 피드백을 통한 설장, 컬처 핏에 맞추가는 상황
    • 경력자 > 회사/팀/조직에 대한 피드백을 줄 수 있는 기회
    • 그들도 듣고 싶어 한다
• 수습기간이란
  
  • 기술적 트렌드를 따라가고
  • 다른 세대와 일하는 방법을 알아가고
  • 스스로를 검증하고
  • 시니어리티에 대해서 고민해 볼 수 있는 시간
  • 수습을 하지 않았따면 시니어리티에 대한 고민이 없었을꺼 같음
• 벌써 일한지 1년
  
  • 기술적으로 무럭무럭 성장중
    
    • 일하는 방식의 변환(TechSpec + Jira)
      
    • 조직안에서의 개인의 성장
      
    • 역할에 대한 고민
      
      • 개발하는 코드에 대한 고민 > 조직에 필요한 것은 무엇인가?
    • 기술부문, 조직의 문화, 지향하고자 하는 가치에 대한 고민
      
      • 좋은 사람을 어떻게 뽑을 것인가?
      • 어떻게 하면 1시간 안에 좋은점을 알 수 있을까?
    • 시니어가 되고 싶었음
      
      • 그러나 중니어
      • 보고 배울 시니어가 점점 늘어나고 있는 현실에 감사
      • 기술적/비지니스적 의사결정/의견들을 보고 배우는중
  • 건강 관리 실패
    
  • 사업.조직 개펀
    
• 결론
  
  • 성장을 위해서 스타트업에 입사
  • 수습을 통해서 리부트
  • 1년동안 기술적/소통적/인간적 성장
  • 중니어를 넘어 시니어로 무럭무럭 성장하는중

영혼까지 끌어쓰는 자기평가(v2)

우아한형제들 이상한모임 강미경 '인사평가'편

• 이전 버전을 꼭 봐야함
  
• 상반기 평가 버전
  
  • 사업팀에서 개발팀으로 변경됨
    
  • 영혼의 조각모음을 분류해서 가중치
    
    • 스스로 한일
    • 업무
    • 엄무 아님
  • 회사의 매출에 영향도를 줬는지 표로 정리
    
    • 비슷해 보이는 업무는 묶어서 점수 확정
  • 업무이력에서 지난 업무들을 추출
    
  • 추출한 업무들을 분류, 가중치 등을 부여하여 정량화
    
  • 평가자가 바라보는 인재상?
    
    • 제가 뭘 하면 좋을까요?
      
    • 대답하려고 하면 생각이 정리되고 평가기준이 생김
      
    • 바뀌는 인재상 > 조직장이 원하는 역할을 인지함
      
    • 상태체크
      
      • 평가기준의 리마인드, 협상 방향성 체크
  • 채용공고란
    
    • 기본기
      
    • 우대사항(회사에서 벌어지는 일)
      
      • 이게레알 지원자격
      • 없으면 서류 광탈
      • 많을수록 면접합격
      • 입사해도 평가될 역량
    • 나의 포지션에 기대하는 역할과 책임을 명확히 하자
      
    • 채용공고를 분석하자
      
  • 업무를 성과로
    
    • 초안을 작성
    • 버릴것을 찾고 더할 것을 찾는다
    • 셀프 평가를 덧붙이자
    • 숫자를 넣음
    • 팩트는 숫자로 쓰지말고 목표를 명시하기
    • 성과의 크기는 비교대상을 두기
    • 정성적인 것도 정량적으로
    • 3자 객간화
    • 셀프 평가는 뻔뻔하게
  • 정리
    
    • 회사가 원하는 역량 + 내가 중요하게 생각하는 성과기준 = 재료
    • 정량적 수치는 팩트가 아닌 임팩트
• 하반기 평가 버전
  
  • 10월 어느날 개발팀으로 이동 될것 같다고 어느팀으로 갈지 생각해 보라고함
    
  • 앱개발팀으로 마음 먹음
    
  • 안된다고함
    
  • 새로운 팀으로 가야한다고 1시간동안 설득당함
    
  • 올해 나는?
    
    • 아무래도 하반기은 망했는데 일단 새팀에 적응하자
  • 프랜츠차이즈시스템
    
    • 주문 flow중에 중계라는 부분이 들어가 있음
  • 당장 모든 로직을 파악하기 힘듬
    
    • 영업과 개발 사이에 껴서 나한테 말해달라고함
    • 본사와 커뮤니케이션 하겠다
    • 배포를 하면 알려주기로 함
    • 커뮤니케이션으로 말을 전달하자
  • 올해 성과는?
    
    • 상반기에 작업한 내용을 가져올 수 있음
    • 매트릭스 별로 나눔
  • 평가
    
    • 인사평가란?
      
    • 인간성 평가가 아닌 내년 연봉을 결정하기 위함
      
    • 회사가 원하는 인재가 아닌 필요한 인재를 하면 연봉을 미리 더 올려주지 않을까 라고 생각
      
    • 회사가 필요한 역량이란?
      
      • 하나의 문제를 집요하게 하는 헝그리 정신이 필요
      • 여러가진 문제를 빨리 해야함
      • 복잡한 문제도하면서 새로운 도전을 하고 기존 운영도 잘 해야함
    • 회사가 필요한 역량은 그때그떄 다르다
      
      • 연말에 정해진다
    • 회사는 상황에 따라 필요한 인재가 다르다
      
    • 내 성향과 역량이 회사의 현재 상황에 맞는지 고민해본다
      
  • 글쓰기 좋은날
    
    • 매트릭스별로 정리한 주제를 카테고리 별로 나눔
    • 전략적 타이틀 뽑기
    • 타이틀이 다한다
    • 이미지가 생간다
    • 내용보다 타이틀이 다할떄가 많다
    • 하반기 평가는 현재가치 뿐만 아니라 미래가치도 보여줘야 한다
    • 글쓰기를 꾸준히 연습하고 제품을 한 줄의 카피라이트로 팔린다
    • 글을 많이 읽자
  • 회사마다 다른 기준, 나의 다른 여러분 인사평가에 정답은 없다 이제 여러분의 차례
    
• Q & A
  
  • 글쓰기 연마 방법
    
    • 생각나는 대로 써보기
    • 말로 읽어 보기
    • 그게 앞 뒤가 맞는 맥락인지 이해
    • 100 ~ 200(맘에 들때까지) 수정
  • 조직장 평가가 있는 경우
    
    • 우아한형제는 조직장 평가는 없음
    • 생각의 다름을 이해하고 그 사람의 역량이 필요함을 어필
  • 일정을 맞출 수 있는 방법
    
    • 미뤄야 하는 것들은 스펙 아웃해셔 제거하고 일정을 미리 미룬다
    • QA중에 일정을 미루지는 않아야 한다
    • 사전에 이유를 만들어 둔다
  • 티 안나게 일하거나 드랍된 경우나 목표가 미달된 경우
    
    • 목표가 미달된 경우
      
      • 핑계를 만들수 있다
      • 다음 프로젝트가 있을때 먼저 챙기겠다(보완점)
    • 티안나는 경우
      
      • 이게 없었다면 리스크가 생겼을 거라고 가정하여 작성
    • 드롭된 경우
      
      • 잘 마무리 했다고 정리
      • 리소스를 낭비하지 않게 문서로 정리

주니어 개발자의 이력서 쓰기

우아한형제들 이동욱, '이력서'편

• 이 발표는 개인의 의견
  
• 참고용 이력서
  
• SI > 중소 포털서비스 > 스타트업 일했음
  
• 여태까지의 과정 3번의 이력서와 3번의 합격
  
• 주변 개발자 분들이 이야기 했을때 잘된 경우
  
• 대상자
  
  • 대학생 및 3년차 미만의 개발자
    
  • 기술적으로 성장하고 싶은 회사
    
  • 회사에 대한 티어가 있음
    
    • 코드 리뷰 /테스트 코드 / 기술블로그를 하고 있는 회사는 현실적으로 너무 소수고 대부분 유명한 회사
      
    • 최후의 마지노선
      
      • git 사용
      • CI/CD
      • 협업툴 사용
• 워밍업
  
  • 프로젝트는 역순으로 정렬하여 정리
  • PDF로 정리
• 보편적인 이력서
  
  • 기본
    
    • 필수
      
      • 이름
      • 이메일
      • 깃허브
    • 준필수
      
      • 블로그
      • 사이드 프로젝트
    • 선택
      
      • 링크드인
      • 페이스북등 SNS계정
    • 채용자의 입장에서는 서류이외도 볼것이 많은 사람을 선호
      
      • 회사는 좋은사람을 뽑는것보다 안좋은 사람들 뽑는게 두려움
      • 서류 심사관이 도박을 하도록 만들지 마세요(오늘 하고 싶은 말)
      • 나를 증명해야 한다
  • 자기소개
    
    • 일종의 압축된 자기소개서
      
      • 어떤 경험을 해왔고 어떤 가치관을 갖고 있고 평소에 어떤 노력을 하고 있는지 7~8줄로 정리
    • github는 작업활동을 증명 할 수 있다
      
    • 최대한 숫자로 표현할 것
      
      • 대규묘/대용량 말고 RPW/TPS/PV/MAU 등 구체적 숫자
    • 신입이 숫자가 어딨나?
      
      • 신입 개발자의 자세를 강조
        
        • 배우려고 하는 자세
          
          • 본인이 부족한 점을 끊임없이 찾는다
          • 그걸 스스로 부끄러워하고 걱정할 줄 안다
        • 좋은 질문을 하는 자세
          
          • 선임이 A 라고 했을때 바로 수긍하는 사람은 NO
          • 선입이 A 라고 했을때 납득이 안되면 검증하고 다시 질문 하는 사람
  • 기술 스택
    
    • 1~2번 써본 기술을 언급하지 않는다
      
    • 지금 당장 쓸 쑤 있는 주력기술들만 언급한다
      
    • 경력에 비해 너무 많은 기술 스택은 오히려 좋지 않다
      
    • 뭐라고 해본 기술을 적자. hello world만 사용한 것은 별로다
      
    • 다다익선이 좋은것이 아니다
      
    • 자바 개발자로 지원하면서 머신러닝/블록체인 등은 소용 없다
      
    • 그동한 해온 기술과 다른 분야로 지원하면?
      
      • 러닝커브를 강조하는 이력서로 얼마나 빠르고, 올바르게 기술을 배우는 사람인지
        
      • 본인의 스타일을 적자
        
        • 라이브러리를 까서 공부하는지
        • 베스트 프랙티스
    • 신기술 경험이 없는 경우
      
      • 3년간 챗봇을 운영한 경험글 참고하기
        
        • Ajax + Jquery
      • 아주 쉬운/오래된 기술을 쓰더라고 계속해서 운영하고 개선 해본 경험을 우대
        
  • 경력/프로젝트
    
    • 질문하면 답변할 수 있는 프로젝트만
      
    • 담당파트 요약
      
    • 프로젝트에서 특히 강조하고 싶은것
      
    • 성과/실적도 있다면 추가
      
    • 가능하면 증명 가능한 링크
      
    • 근무기간
      
    • 프로젝트가 있으니 요약정리
      
    • 프로젝트 성과 외 언급 할것들
      
    • 경력이나 프로젝트가 부족할 떄?
      
      • 어떤 기준으로 교육을 선택했는지
        
      • 무엇은 배웠는지
        
      • 증거는 필수
        
        • github등 블로그 정리 링크
    • 신입이 해야할 교육/스터디 주제는?
      
      • 테스트코드
        
      • OOP
        
      • 클린코드
        
      • Git
        
      • Linux
        
      • 생각보다 리눅스를 모르는 개발자가 많다
        
        • 리눅스 운영체제에 대한 비교도 모른다
    • 혼자서 MSA 연습은 하지 말자
      
      • 신입 개발자에게 기대하는건 탄탄한 기본기
    • 오픈소스
      
      • start 많은 오픈소스가 효과가 있나?
        
        • 나는 start가 많은 저장소를 이력서로 쓴 적이 없다
        • 이 프로젝트에는 코드가 없다
        • 코드 없는 오픈소스는 이력서에 효과가 없다
        • star가 적어도 코드가 있는 오픈소스가 이력서에 효과가 있다
  • 포트폴리오
    
    • 본인의 기술적으로 구현한 부분이 무엇인가?
      
      • 편리한 UI, 풍부한 자료, 마켓 다운로드 몇회
      • 개발자로서 어떤 역량을 발휘한 작품인가는 의문
    • 작품의 호응도가 본인의 개발 실력이 아니다
      
    • 학교 과제 제출하듯이 기능/UI/기획이 강조된 PPT는 효과가 없다
      
    • 프로젝트는 모두 Github에 올려 내가 어떻게 코드를 작성하는지 공개한다
      
      • 깔끔한 README.md 와 커밋 메세지는 가산점++
        
      • 정리
        
        • 설치 방법
        • 정리
        • 커밋메시지 정리
  • 문제 해결 사례
    
    • 학교프로젝트, 국비교육, 스터디 하면서 만났던 문제를 해결한 사례
      
      • 메일 발송시 간혈적으로 오류
      • 서버 다운 없이 패킷 추적
      • 문제점을 추측
      • 테스트 코드로 문제를 재현하여 해결
• 마무리
  
  • 잘 쓰려면 잘 살아야 한다(강원욱의 글쓰기 책)
  • 이력서 잘 쓰려면 좋은 개발자로 잘 살아야 한다
  • 좋은 개발자가 되기 위한 노력이 우선이지 좋은 이력서가 우선 되선 안된다

세션 1&2

나의 연봉협상 오딧세이

ODK Media 권정민

• preface : 어떤 승진
  
  • 아는 분이 승진을 하고 연봉이 올라서 축하함
  • 승진은 했지만 연봉이 안오르면 실속이 없이 책임만 늘어남
• 사내 연봉협상
  
  • 사내에서는 연봉협상을 올리기 어렵다
  • 자기 평가서를 통해 올릴 수 밖에 없음
  • 보통 연봉 통보
  • 맘에 안드는 경우가 많음
  • 맘에 안든다고 말한다는게 쉬운일이 아님
  • 본인이 평가 받은 내용을 통해서 회사에서 판단하에 통보되는것
  • 얘기하는 사람이나 다시 처리하는 사람이 껄끄러워짐
  • 이의를 제기해본 적은 없음
• 여태까지 이직은 8번
  
  • 옮기고 싶어서 옮긴것은 아니고 의도치 않게 이직
    
  • 돈을 벌려고 이직
    
  • 연봉 협상은 중요
    
  • 달라진 업계
    
    • 이직 하는 경우 다른 업계로 이직도 함
      
    • 업계 별로 연봉 평균이 있어서 연봉이 줄어들기도 함
      
    • 연봉이 줄어들면 기분이 안좋음
      
      • 기분은 중요
      • 일이 하기 싫어짐
      • 회사에 대한 애정이 적음
      • 불만이 있다면 불만이 증폭
    • 웬만하면 연봉을 적게 받아서 다니는 것을 추천하지 않음
      
    • 이직할때 연봉을 적게 통보 받았을때 그냥 받았던게 문제
      
• 고정 연봉
  
  • 회사에서 직급별이 연봉이 고정되어 있다고 함
  • 연봉 테이블이 필수로 고정은 아니다
  • 직급을 올려서 가는것이 좋다
  • 연봉이 달라질 수 있다
  • 생각보다 대기업이 연봉이 높지 않는 경우도 많다
• COUNTEROFFER
  
  • 회사를 한 곳만 알아보는게 좋은가?
    
  • 지금 회사에서 연봉을 더 준다는데 다니는게 좋은가?
    
  • 하면 안되는 이유는? 꺼려지는 이유?
    
    • 번거롭다
      
    • 피곤하다
      
    • 구차하다
      
      • 하지만 연봉을 많이 올릴 수 있다
    • 회사에서 이상하게 보지 않을까?
      
      • 이것은 잠깐
      • 보통 HR과 얘기를 나눔
    • 2곳에 COUNTEROFFER를 하는 경우 생각보다 타이밍이 맞지 않음
      
• 연봉 외의 경우
  
  • 강의
    
    • 공공기관
      
      • 시간당 가격
      • 박사 또는 박사가 아닌사람
      • 가격이 정해져 있음
    • 사기업
      
      • 가격이 정해져 있지 않음
      • 가격을 올릴 수 있는지 물어보자
    • 한다고 하기전에 금액을 물어보고 협상하자
      
  • 계약직, 프로젝트
    
    • 회사에서 받는 돈은 쥐꼬리인데 제안서에는 높은 돈으로 측정되어 있다
      
    • 최소 1.5배를 요구
      
      • 회사도 알고 있다
• 연봉은 한번 더 물어보자
  
  • 거절하는 회사는 별로다
  • 거절하는 회사는 많지 않다
  • 회사에도 리소스를 많이 투자해서 뽑는 것
  • 이직시 에는 전 연봉을 기준으로 옮기기 때문에 관리하자
• 어떤 이직
  
  • 아는 사람이 회사를 그만둠
  • 연봉도 낮추고 다른 업계로 간다고 함
  • 지금 잘 살고 있음
  • 커리어 패스가 연봉은 중요하지만 길의 포장지라고 생각
  • 고액 연봉이 꼭 좋은 것일까
  • 본인이 생각해서 맞는 길을 가자
  • 연봉에 너무 끌리지 말고 좋은 길을 가자

연봉협상, 어디까지 튕겨봤니?

카카오 손현태

• 11년차 개발자
  
• 우아한 형제에 있다가 카카오로 옮김
  
• 연봉협상하면서 있던 이야기
  
• 회사
  
  • 청호컴넷 2년 6개월
  • 오픈타이드 2년 3개월
  • 우아한형제들 5년 2개월
• 연봉
  
  • 여러분은 더 높은 연봉을 받을 자격이 있다
  • 오퍼를 받자마자 가고싶은 회사여서 연봉을 그냥 수락하지 말자
• 커리어 스킬
  
  • 커리어 스킬이라는 책
    
    • 15장 연봉과 협상
      
      • 첫직장 연봉이 중요
      • 회사측에서 제시한 연봉을 바로 받아 들이는 개발자가 너무 많다
      • 연봉범위를 알라
      • 유리한 고지를 점령하라
• 처우협의 밀당 ssul
  
  • TIP1 비슷한 회사를 동시에 진행하라
    
    • 하나의 카드만 들고가면 불안하다
      
    • 여러 회사에서 오퍼를 받게 되면 객관적인 연봉을 판단 가능
      
    • 연봉 협상
      
      • 처우를 시작하면 원춴징수영수증, 재직증명서 요규하기도하고 희망연봉을 제시하는 회사도 있었음
        
        • 기존 회사의 연봉 인상율을 반영하여 연봉을 제시
      • 연봉을 제시
        
        • 연봉을 깍아서 옴
      • 연봉 통보를 받음
        
        • 생각보다 낮게 옴
      • 전화를 통해 이유를 듣고 싶었음
        
        • 비슷한 연차가 이 정도 받고 있다고 설명
      • 이직은 리스크가 있기 떄문에 연봉인상으로 보상받아야 한다고 설명
        
        • 사이닝 보너스를 제시를 추가로 받음
        • 1차 제안을 할때 낮게 제시 해서 비슷하게 측정되어 통보 받음
  • TIP2 희망연봉을 명확히 설정하고 시작하라
    
    • 사이닝 보너스
      
    • 내가 희망하는 연봉보다 낮게 요쳥받아서 원하는 연봉을 어렵게 말했다
      
      • 메일로 달라고 한다
      • 하지만 안된다고 거절 당함
  • TIP3 고민하는 시간을 넉넉히 가져라
    
    • 한달정도 고민하고 말해준다고 함
    • COUNTOFFER 를 비슷하게 진행하기 위함
    • 갑자기 연락이 오더니 희망연봉을 맞춰준다고 연락이 옴
    • 면접을 잘 봐야 연봉을 유리하게 할 수 있음
• 정리
  
  • TIP을 지키자
  • 유리한 고지를 점령하라
  • 꼭 필요한 인재 복수지원 연봉은 협상이다
  • 다른곳에 합격한것을 다른 회사에게 통보하면 패스트트랙으로 진행 될 수 있다
  • 야놀자는 배민에 합격하면 데려간다는 소문이 있다.
  • 절대 연봉을 낮춰서 가지말라. 그 피해는 후배 개발자들에게 한마디

스페셜세션 A

당신은 더 높은 연봉을 받을 자격이 있다

커리어 엑셀러레이터 김나이

• 소개
  
  • 커리어 엑셀러레이터
  • 1년에 300명 이상 커리어 상담
  • 스터디파이와 협업
  • 원래 회사원이 있음(금융)
  • 모니터가 12대여서 옆사람이 보이지 않음
• 연봉 협상을 해보셨나요?
  
  • 보통 10~15%
    
  • 연봉 협상이 없는 경우
    
    • 통보
    • 협상이 없어서
    • 주니어라서
• 연봉의 결정타, 무엇일까
  
  • 시장의 수요와 공급이 중요
    
  • 가만히 있으면 가마니가 된다
    
  • 자신의 성과를 이야기 해야 한다
    
    • 숫자로
    • 시장 대비 당신의 성과를
    • 구체적으로
  • 10월에 내년에 원하는 연봉과 일들을 정리하여 보냈지만 1월에 왜 말하지 않았냐고 사장이 대답
    
  • 다른 회사 사람들과의 비교 표 제공
    
• 그런데 1000만원 연봉 인상 제시, 그 회사로 이직, 해야할까?]
  
  • 어떤 업무와 비전을 가지고 있는 회샤인지 판단
  • 왜 1000만원을 더 주는지? 나의 능력에 대한 부분인지
  • 이 포지션에서 사람을 오래 구하지 못해서 연봉을 높여서 구하고 있는지?
  • 현재 회사의 상태를 고민해보자
• 대기업은 스타트업보다 연봉이 높다?
  
  • 회사마다 다르다
    
  • 연차가 쌓인다고 연봉이 높은것은 아니다
    
  • 한 회사를 오래 다닌다고 연봉이 높지 않다
    
  • 본인이 속한 마켓에 따라 다르다
    
  • 마켓에 대한 눈을 기르자
    
  • 회사의 상태와 매출과 이익을 알아야 한다
    
  • 연봉을 높이려면 업황 & 회사의 상태를 알아야만 한다
    
    • 도입기를 지난 회사가 제일 좋다
  • 7년차에서 15년차 분들이 제일 많이 고민
    
  • 회사가 상승되는 상태를 봐야한다
    
• 스타트업 다니는 사람들의 고민
  
  • 고민
    
    • 언제 도망 쳐야 할까?
    • 비지니스 모델
  • 투자자의 시선으로 대표를 보자
    
  • 대표하고 시장의 업사이클을 본다
    
  • 대표가 별로면 블루오션이여도 성공하지 못한 경우가 있다
    
  • 회사를 갈때 투자자의 관점으로 보자
    
• 스톱옵션
  
  • 스톱옵션을 회사가 성공하지 못하면 휴지다
  • 종합적인 판단이 중요
  • 주변에 있는 사람들과 내가 어떤 일을 해야하는지 판단
• 원하는 연봉을 이야기 해보라 하면, 어떻게 대답해야 할까?
  
  • 연봉협상의 타이밍은 언제가 좋을까?
    
    • 마지막 단계까지 미루는게 좋다
    • 상대방과의 신뢰가 생겨야 한다
    • 중간에 연봉을 물어본다면 추후에 협상하자고 말한다
• 표준 & 프레이밍의 활용
  
  • '과거'의 '숫자' 그 자체에 매몰되지 말고 '미래'의 'Value'에 집중해서 Reframing 하자
    
  • 연봉협상 할 때 너무 돈에만 집착하지 말자
    
  • 현재의 연봉을 말하지 않고 내가 회사에 가서 해야할 역할을 중심으로 얘기하면서 회사에서는 어떤 롤을 부여하는지 문의
    
  • 회사의 기준을 물어보고 이야기
    
    • 단지 돈 문제가 아니라 회사가 원하는 것은 무엇인지
    • 회사가 나에게 기대하는 것은 무엇인지 먼저 듣고 싶음
    • 적절합 합의점을 찾을 수 있을수 있을꺼 같음
• 연봉 협상 Win Win을 위해 우리에게 필요한 Mind Set 3가지
  
  • Confident
    
  • Positive
    
  • Relax
    
  • 약간의 금자감과 어느 정도의 개썅마이웨이 정신이 필요하다(김수현 - '나는 나로 살기로 했다' 중)
    
  • 2배 연봉 상승을 이끌어 낸 개발자의 이야기
    
    • 합격해도 안갔을 다른 회사의 최종 통보를 받은 걸로 구글에 협상
  • 얻을 수 있는 장단점을 파악하여 협상할떄 단점을 가지고 말함
    
• 회사에서 제시하는 숫자가, 마음에 들지 않거나, 약간 부족하다고 생각될 때는 어떻게 말해야 할까요?
  
  • 내가 원하는 정도를 받는다면 회사에서 열심히 일 할 수 있을꺼 같다는 부분을 어필
  • 나의 연봉이 낮다면 대표에게 '당신이 나라면 어떻게 할까요? '라고 물어보는 것도 방법
• 연봉에 대한 다른 관점
  
  • 글로벌 IT -> 벤처
    
  • 글로벌 IB -> 1인 기업가
    
  • 불안
    
    • 이 조직에서 과연 내가 어디까지 올라갈 수 있을까?
    • 무슨 영광을 누리자고 내가 이렇게까지 하면서 살아야만 하나?
    • 자의든 타의든 회사를 나가게 됐을때 할 수 있는 일은 무엇일까?
  • 성장
    
    • 내가 이 조직에서 지금 의미있는 일을 하고 있는 것일까?
    • 역량과 경험이 시간이 지난다고 자동적으로 획득되는 것이 아닌데, 나는 지금 이 조직에서 내가 혼자 Survive 하기 위한 경험들을 쌓아가고 있나?
  • 언젠가는 연봉이 내려 갈 수 있다
    
  • 계속 연봉이 올라가려면 회사도 계속 성장하고 있어야 한다
    
• 나의 일을 돌아보는 6가지 질문
  
  • 성장
  • 돈
  • 워라벨
  • 의미
  • 재미
  • 인간관계
  • 6가지를 맞출 수 있는 회사는 이 세상에 없다
  • 이 중에서 나에게 가장 중요한 2가지는를 뽑고 만족 하고 있는가
  • 나는 무슨 부분을 바꿔야 하는가
• Q & A
  
  • 회사를 판단 하는기준
    
    • 작은 기업같은 경우
      
      • 투자 리포트
      • 대표를 많이 봄
  • 연봉을 알기 위한 방법
    
    • 네트워킹을 톡해 인맥을 쌓는다
  • 원하는 연봉을 한번에 회사가 수락 했을 경우
    
    • 연봉을 변경하기는 어렵고 그 회사에 내가 갔을때에 대한 가치를 생각
  • 현재 회사에서의 연봉을 높이는 방법
    
    • 나하고 같은 연차가 다른데에서 어떻게 하고 있는지 보고 나를 수치화 하여 어필
  • 나를 돌아 보는 6가지 중에 안맞는 부분이 있는 경우
    
    • 스트레스를 많이 받는 경우 안하는게 맞는거 같음
    • 입사하여 내가 하고 있던 일들이 다른 사람과의 마찰이 있는 경우 물어보고 내가 어떤 업무를 했으면 좋겠는지 문의

세션3

연봉협상도 통역이 되나요?

멀티캠퍼스 천성권

• 주의 사항
  
  • 연봉을 무조건 올릴 수 있는 마법은 아니다
  • 발표자의 회사와는 관계 없음
• 오늘의 통역사
  
  • 직장
    
    • 전자책, 출판(2), 기업교육
  • 업무
    
    • 마케팅, 기획(상품/사업/전략), 그리고 인사
  • Full stack recruiter
    
    • 채용 관련된 모든 업무를 담당
    • 6년가 400명 채용
• 미리 보는 결론
  
  • 경력
    
    • 근무한 모든 기간이 경력은 아님, 증빙 가능 여부가 중요함
  • 연봉
    
    • 연봉의 정의는 회사마다 다를 수 있음. 연봉, 월급의 구조를 알아야 함
  • 소득
    
    • 연봉이 소득을 의미하지는 않음
    • (+)뿐만 아니라 (-)도 확인 필요함
• 연봉협상이란
  
  • 회사와 지원자간 금전적 기대수준을 동기화하는 과정
• 경력이란
  
  • 연봉협상의 첫 단추, 시간은 모든 사람에게 동일한가?
  • 사람마다 판단 기준이 다름
• 같은 시간 다른 경력
  
  • 두 사람이 공백없이 일을 했고 다른 업무(프리랜서, 개월수등) 형태로 일을 했을때 같은 직급/연봉으로 일할 수 있나?
    
    • 계약서가 없는 경우
    • 파트타임인 경우 경력증명서 발급 불가
    • 폐업
    • 직무가 다른 업무
  • 실제로 연봉을 협상하는 사람도 증거를 산정하여 품의를 올림
    
  • 증빙가능한 정보가 없으면 도와줄 수 없음
    
  • 회사는 증빙가능한 경력으로 산출
    
    • 경력증명서
    • 재직증명서
    • 외부인력 경력증명서
    • 건강보험자격득실확인서
    • 용역 계약서
    • 입금 내역서(은행)
• 연봉이란
  
  • 연봉협상의 핵심, 연봉은 모든이에게 같은 뜻인가?
    
    • 같은 연봉 다른 구성
      
      • 급여
      • 중식대
      • 직책수당
      • 명절상여
    • 계약 연봉이 어떤 것들이 포함되어 있는지 알아야 한다
      
    • 같은 연봉 다른 월급
      
      • 기본급이 일정한 경우
      • 기본급에 분기마다 상여금이 있는 경우
    • 추하지 않게 숫자를 말하자
      
  • 연봉에 대한 지원자와 회사의 인식차이
    
• 소득이란
  
  • 소득은 높고 지출은 적어야 한다
    
  • 같은 연봉 다른 소득
    
    • +요인
      
      • 원천징수영수증은 모든것들이 들어가 있음
        
        • 급여명세서
        • 연봉계약서
        • 원천징수영수증
        • 항목을 확인하여 말해야함
      • 인센티브
        
        • 변동성 여부
        • 스톡옵션과 비슷하지만 리스크가 적음
        • 인센티브를 못받을 수도 있다고 가정
    • -요인
      
      • 경조사
      • 자녀학비
      • 건강검진
      • 구내식당
      • 휴가비
      • 도서지원
      • 자사제품 할인
  • 소득 = 연봉 + (부가소득 + 생계형 복리후생 + 인센티브)
    
• 오늘 확인해야 할 자료
  
  • 경력
    
    • 자신의 모든 경력에 대한 확인
      
      • 건강보험자격득실확인서 FAX 발급
    • 증빙 확보
      
      • 분실서류 재발급, 우너본한 보관시 Scan저장
  • 연봉
    
    • 연봉 구조 및 월급 구성 확인
      
    • 연봉
      
      • 연봉계약서 내용/구성 확인
    • 월급
      
      • 최근 6개월 급여명세서 확인
  • 소득
    
    • 연봉외 소득(+과 복리후생(-) 확인
      
    • 소득
      
      • 원천징수영수증 확인
    • 복리후생
      
      • 회사에서 복리후생 안내서 확인
• 지금 or 곧 연봉협상을 하고 있다면?
  
  • 자신감있는 태도 유지
    
  • 단계별 진행상황 확인
    
    • 이것이 연봉협상인지?
  • 다각적/거시적 관점으로 충분한 정보 확인
    
• Q & A
  
  • 연봉협상중인데 회사에서 빨리 대답을 할 경우?
    
    • 회사에게 왜 빠르게 대답을 원하는지 문의
    • 오퍼레이션을 승낙 한 후에 안가도 불법은 아니다

스페셜세션 B

내 역량에 맞는 연봉은?

우아한형제들 변연배

• 당신의 몸값을 어떻게 높일 수 있는가?
  
• 서로 주고 받는 것이 있음
  
• 우아한형제들 인사총괄 임원
  
  • 쿠팡등 인사 쪽 재직
• 최고가 되서 떠나라
  
  • 최고가 된다는 것은 일하고 있는 회사에서 얼마나 가치가 있는 사람인가
• 연봉이 본인에게 얼마나 중요한 부분인가 생각해보기
  
• 개인의 경제활동영역
  
  • 봉급 생활자
  • 사업가
  • 투자가
  • 자영업자
• 사람들이 평생 소비하는 시간 중
  
  • 실제 일하는 시간은 총 12년
• 나이에 따른 임금 vs 생산성
  
  • 임금이 오를수록 40세 부터 생산성이 낮아져서 구조조정이 대상이됨
  • 일하는 시간동안 무엇을 하느냐에 따라 40세에 결과가 나옴
• 인재의 유형
  
  • 부지런함
  • 게으름
  • 똑똑함
  • 우둔함
• 조직장이 되었을때 어떻게 할 것인가?
  
• 구성원들은 어떤 조직장과 일하고 싶은가?
  
  • 조직장은 똑똑한데 게으른게 좋다
• 조직에서의 Employability & Marketability
  
  • 외부 이동 가능 인력(Employability)
    
    • 여기에 해당하는 사람이 되어야 한다
  • 내부 이동 가능 인력(Marketability)
    
  • 내/외부 이동 제한 인력(?)
    
• 현실은 냉혹
  
  • 5만 6천개
  • 반경 평균 100m에 1개
  • 하나 260원 이익, 월 수입 55만원
  • 한 해 평균 7400 Open/5,000 Close
  • 이것은 치킨, 커피집
• 직장인의 무덤
  
  • 자영업 비율 27.4%
  • 창업 949만개 / 폐업 793만개(2004~2013)
  • 5년 생존율 16.4%
• 질문
  
  • 만일 내가 고용주라면 나를 고용하겠는가?
    
  • 6개월 마다 이력서를 업데이트하자
    
    • 역량을 체크
• 간단한 공식
  
  • 어떤 일에 대가를 받는다는 것은 엄청한 책임이 따른다
    
  • 받는 보수 < 주는 가치
    
  • 공식
    
    • 몰입
    • 역량
    • 전문성
    • 끊임없는 학습
• 인재란?
  
  • 탁월한 성과는 인재가 달성하는 것이 아니라 탁월한 성과를 지속적으로 달성하는 사람이 인재이다
• 어떤 것이 탁월한 성과인가?
  
  • 다른 사람들이 평균적으로 달성하는 것보다 확연히 구분되는 우수한 성과
• 인재는 어떻게 알아 보는가?
  
• 한 사람의 인재가 세상을 바꾼다
  
  • 최고 수준의 소프트웨어 개발자 한 사람의 보통 수준의 소프트웨어 개발자에 비해 그 기여도가 10배, 혹은 100배, 심지어 1,000배를 넘어 10,000배 보다도 더 높다
• 인재가 가지고 있는 역량의 구조
  
• 인재는 어떻게 만들어 지는가?
  
  • 체계적, 심층적, 반복적 학습
  • 올바른 마음 가짐
  • 강점파악 -> 체계적 공부 -> 전문분야 경험
  • 10년, 1만시간의 법칙
• 4차 혁명 시대에 요구되는 글로벌역량
  
  • 창의성
  • 문제해결능력
  • 민첩한 학습능력
  • 통섭력
  • 변화에 대한 유연성
  • 회복탄력성
  • 조직적합성
  • 외국어 + 문화적응력
• 그리고 직장 내 인간관계
  
  • 상사
    
  • 동료
    
    • 같은부서
    • 다른부서
  • 후임
    
• 나뭇가지에 있는 새는 무엇을 믿을까?
  
  • 나뭇가지를 믿는게 아니라 내가 가지고 있는 날개를 믿자
• 직업적인 자존심
  
  • 나를 위해 일한다
• 당신의 선택에 대해 불평 하지 마라
  
• 향후 노동시장 및 업무환경 변화
  
• 경력의 시작 및 경력변경의 유형
  
  • 새로운 사업분야로 가는 경우 한번에 전직은 어렵다
• 필요한 직무에 따라 연봉이 결정이 된다
  
• 입사 결정 시 주요 고려 사항
  
  • 총체적 급여 수준
    
  • 기타 추가 지원받을 항목
    
  • 대상 회사 및 그 회사가 속한 산업의 발전 가능성
    
  • 기업 문화 및 경영 철학(중요)
    
  • 같이 일할 상사의 품성 및 리더십
    
  • 시간적 여유
    
  • 나쁜상사라도 좋은 회사로 가라
    
    • 좋은 회사라면 나쁜 상사가 오래 있지 못할 것
• 당신이 다이아몬드 라면 팅겨도 된다
  
• 연봉협상의 시점은 당신을 꼭 뽑아야 한다라고 했을때가 Best Time
  
• 자신의 몸값을 높일 가장 확실한 방법
  
  • 실력과 성과
  • 프로가 되는것

기타

• 우아한형제들 작은집 투어로 인한 구경
  
• 조리 가능하고 식사가 가능한 방이 있음
• 면접 대기실은 잔잔한 음악이 나옴

이상한 모임 이전 세미나 발표자료

Read More

AHEA 2019 상반기 세미나 발표 후기

2019.06.01에 상반기 2019 AHEA 상반기 세미나에서 처음으로 발표자로 서게 되었다.

2019 상반기에 AHEA 스터디에 참여하게 되었다.

내부적으로 세미나 준비가 이미 진행 중이어서 나도 주제를 하나 선택하여 참여해야 했다. 기간이 많이 남아 있지 않아서 주제를 고민 하던 중 JAVA8버전 이후 버전에 고민하던 중에 많이 사용하지 않고 있는 자바 버전 중 개발 관련 내용을 많이 담고 싶어서 자바 9버전을 발표하기로 했다.

발표 1달 전쯤에 다 같이 모여 피드백을 진행하는 자리가 있었다. 자료를 공유하며 피드백을 받는 자리가 있었다. 부족한 부분과 내용에 대해 피드백을 받고 나서 발표자료를 준비하였다.

모인 이후에 onoffmix에서 세미나 모집을 했는데 제한 인원이 100명이 되었는데 빠르게 마감이 되어서 그때부터 매우 긴장되었다.

실제 발표가 있기 2주 전쯤 모여서 한 번 더 피드백을 하는 자리를 마련했다. 이때는 발표자료가 서로 어느 정도 완성되어서 발표자료에 대한 보완점에 대해 서로 피드백을 해주었다.

발표자료를 계속 다듬으며 연습을 하다 보니 실제 발표일이 다가왔다. 발표는 1시부터 시작이었지만 리허설을 위해 9시부터 모여서 발표준비를 하였다. 실제 발표할 공간에 오니 더욱더 긴장되었고 첫 세션 발표를 하게 되어서 리허설 후에 발표할 보며 계속 연습을 하였다.

드디어 첫 세션이 시작되었고 30~40분 정도 발표를 하였다. 발표하면서 청중과 호흡하면서 진행하지 못해서 아쉬움이 많았다. 다음에 발표할 때 개선해야 할 점이라고 생각한다.

발표 이후에 세미나에 관련된 경험을 마이크로소프트웨어에 기고할 기회가 생겨서 세미나를 통해 경험하였던 내용을 기고하였다.

Read More

모두의 TOY STORY 참석 후기

모두의 TOY STORY : Side Project 어디까지 가봤니? - by GDG Campus Korea

GDG

각 지역을 중심으로 다양한 주제로 다양한 사람들이 참여하는 오픈 커뮤니티

#1 최고의 이벤트 플랫폼을 향하여 , and beyond - 진겸

• Festa 프로젝트
  
  • 이벤트를 만나는 가장 쉬운 방법
    
  • 우리 서비스를 쓰는 자에게 최고의 경험을 주기 위함
    
  • 2017년도 개발
    
  • 처음에는 협업용 도구를 개발 하기로 했었음
    
  • 컨퍼런스를 위한 Jira를 만들어보자 라고 시작함
    
  • 써보고 싶은 기술을 마음껏 써보자
    
  • GDG에서 이벤트를 여는데 이벤트를 접수 받는 곳이 없었다
    
  • Pivot을 하기 위함
    
  • Ticketing Platform
    
  • 데드라인 1달
    
  • EDD
    
    • Event Drven Development
  • 파이콘/아임포트에 결제 시스템 문의
    
  • 잘 진행되고 있는듯 했으나 기쁨도 잠시
    
  • 여행중에도 코딩을 진행
    
  • 오픈전에 많은 버그가 존재
    
  • 코드의 피드백을 받을수 없었음
    
  • 마지막 1주일은 밤샘 작업
    
  • 하루전에 오픈 알림이 와서 놀랐다
    
  • 결제를 완료한 화면을 보니 기분이 좋았다
    
  • 하지만 오류 화면도 보임
    
  • 회고.. 그리고 느낀점
    
    • 더이상 못하겠다
    • 회사를 열심히 다니자
  • 기술적 인사이트
    
    • 남들이 많이 쓰는 이유
    • 버전이 정해져 있으면 좋다
  • 스스로의 부족함
    
  • 협업의 어려움
    
    • 최고의 인재들을 모았지만.. 납득시켜야 한다
  • 지킬수 밖에 없는 데드라인 = 발전
    
    • 나는 나태하기 때문에
  • 제 2부 새로운 본격적인 시작 그리고 새로운 문제점들
    
    • 강의를 하려고 했으나 다른 곳에서 Festa를 사용하고 싶다고 요청이 들어옴
      
    • 다시 사람들을 모음
      
    • 처음부터 다시 만들자
      
    • MVP
      
      • 기간이 정해져 있지 않으면 안하게 된다
    • Slak + Jira + Github + Gsuite
      
    • 현실적 문제
      
      • 사업자 문제
      • 보증보험
      • 정산을 위한 기초 자본금
      • 비지니스 모델
    • 프로젝트 매니징의 어려움
      
      • 각종 슬럼프 + 빠른 번아웃
        
      • 프로젝트 접어야할 위기들
        
        • 책임감이 없어지는 순간 위기가 찾아온다
    • 계속되는 EDD
      
    • 사이드 프로젝트의 한계
      
      • 규모를 넘어가면 사이드프로젝트가 아니게 된다
        
      • 엄청난 인력/시간 부족
        
      • 나도 한번 해볼까?
        
      • 가볍게 시작한 프로젝트는 가볍게 끝난다
        
        • 지속성이 중요
        • 원동력이 있어야 한다
      • 프로젝트 축소
        
      • 시간을 무진장 더 쏟는다
        
    • 개발과 서비스는 다른 차원
      
  • 제 3부
    
    • The best way to find Events
      
    • 커뮤니티
      
    • 우리 서비스를 쓰는 자에게 최고의 경험을하기 위함
      
      • 이런거 까지 가능하네? 라는 감탄사가 나오게
    • 수익은?
      
      • 카드사가 많이 가지고감
      • 새로운 비지니스 모델을 찾는중
      • offline event coordinaion
    • Cutting Edge Tech
      
    • 사람을 뽑고 있는중
      
      • 최고의 경험을 주는 서비스를 만들고 싶은사람
        
      • 프로젝트 하나에 진득하게 투자 해보고 싶은 사람
        
      • 책임감이 있는 사람
        
      • 주체적인 사함
        
      • 로케트 탑승권 얻고싶은분
        
      • 모든 직군을 뽑고 있는중
        
      • 급한 인력
        
        • 문서화 좋아하는 PM
        • 서버와 데브옵스 잘하는분
    • 조금더 나은 프로젝트를 만들기 위해 노력
      

#2 기술에 공유를 더하다: 기술블로그 구독서비스 - 권태관

• 오늘 7월 14일이 기술 구독서비스를 오픈한 날
  
• 네이버 백엔드 개발자
  
• VLIVE에서 채용
  
  • 트래픽이 많음
  • 연예인을 볼 수 있음
• 사이드 프로젝트
  
  • 회사에서 하는 업무와 별도로 진행
    
  • 개인 또는 팀으로 구성
    
  • 주제, 목표, 일정에 제한이 없음
    
  • 왜할까?
    
    • 내가 필요해서
    • 번뜩이는 아이디어가 있어서
    • 새로운 지식을 습득하기 위해서
  • 왜 만들었나?
    
    • SNS 챙겨보기 힘들어서 + 보다가 자꾸 딴짓해서
    • 다른 것에 집중하다 보면 중요한 정보나 좋은 글들을 놓쳐서
    • 다른 사람들의 글들을 보며 자극 받고 싶어서
    • 내 블로그를 홍보하고 싶어서
    • RSS리더 서비스를 직접 만들어보자!
• 기술블로그 구독서비스 소개
  
  • 메일을 등록하고 인증절차를 거치고 DB에 저장한 내용을 파싱하여 메일로 발송
    
  • awesome-devblog에서 정보를 가지고 옴
    
  • 개발을 뭘로 하지?
    
    • Java + Spring를 사용했지만 Python + Flask 를 사용
  • 서버는 뭘로 하지?
    
    • AWS
  • 개발을 1주일안에 완성후 SNS에 홍보
    
• 운영
  
  • 너무 느린 메일링
    
    • 수집후 발송하니까 느려서 수집을 미리 하고 발송을 하게 변경
  • 메모리 1G, CPU 1개.. 가난한 개발자?
    
    • 주어진 환경에서 최대의 성능을 만들어보자
      
      • threading
      • multiprocessing
  • 메일 본문 에는 CSS, JS가 적용이 안된다
    
    • Emogrifer
  • 열심히 만들어 보넀는데 스팸?
    
    • 구글 SMTP : 하루에 500개 발송 제한
    • SMTP 서버를 구성하여 보내봤더니 스팸
    • 가장 깔끔하고 발송관련 모니터링이 가능했던 AWS SES를 사용
    • 피드백 기능으로 유효하지 않은 메일이나 수신거부 된 사용자 처리
  • 서비스를 만들었으면 모니터링을 해야지
    
    • 엘라스틱 서치를 사용중이 였지만 비용을 내야해서 따로 로깅시스템을 구축
  • 필터링, 카테고라이징, 태그
    
    • 본문의 형태소 분석을 해서 태그를 설정
  • 구독자 1000명 기념 새로운 기능 만들기
    
    • 양질의 글을 찾기 위해 주간 인기글 적용
    • 아카이브 페이지
  • 한살이 된 나의 프로젝트, 얼마나 컸니?
    
    • 운영기간: 만 1년
    • 크롤링 포스팅 수 : 약 9,000개
    • 구독자수: 약 1600명
  • 앞으로의 방향성?
    
    • 농부의 마음으로
      
      • 후원이 필요
    • 서비스 유지를 위한 후원
      
    • 기술블로그 홍보 및 포스팅을 장려하는 하나의 플랫폼으로
      
  • 하면서 무엇을 느꼈는가?
    
    • 강제 학습
      
    • 회사와는 별도 진행 서비스에 대한 책임감
      
      • 오전 10시만 되면 이제는 몸이 먼저 반응(메일이 잘 왔나..)
      • 경험으로 부터 나온 인사이트를 팀에서도 적용
  • 여러분의 토이스토리는 무엇입니까?
    
    • 넌 그냥 자신을 믿고 시작해보자

#3 어느 전직 리눅스 오타쿠의 이야기 - 권순선

• KLDP
  
  • 96년 10월에 처음 만듬
    
  • ./ + sf.net 또는 SO + GitHub + Wikipedia
    
  • 계기
    
    • 여자친구랑 깨졌다
    • 뭔가에 집중해보고 싶다
  • 1999년도 야후를 배껴서 디자인
    
  • 2000년도 다음을 배껴서 디자인
    
  • 2001년도 디자인 개편
    
  • 2003년도 개편
    
    • 제일 잘 나가던때
  • 2004년도개편
    
    • 행사 진행
    • 해커톤 진행
  • 2005년도 개편
    
  • 2014년~ Now 개편
    
    • php cms 솔루션으로 갈아탐
  • 2016년 10월 20주년 모임
    
• 경력
  
  • 결혼 + 아이
    
  • 회사
    
    • 삼성(1999 ~ 2007)
      
      • 2연속 진급 실패
      • 프로젝트 하느라 일을 못함
    • 네이버(2008 ~ Aug 22, 2011)
      
      • 네이버 개발자센터
      • nForge
      • 버닝데이/Deview
    • 구글(Sep 26, 2011 ~)
      
      • Korea
      • KR/JP/SEA/ANZ
      • KR/JP/CN/TW/HK/AMZ + Global
• 회고
  
  • 행운
    
    • Linux vs Delphi
      
      • 리눅스를 고른것이 행운
    • Developer Relations
      
  • 열심히
    
    • 4 * 365 * 8 - 4 * 30 * 2 = 11440
      
      • 하루에 4시간 이상 작업
      • 병특과 회사 합숙 빼고
    • 기숙사 전화선
      
    • 터미널
      
    • ADSL
      
    • PC방
      
    • 처가집
      
• 기술
  
  • 이것저것 하다 보면 문제가 많이 생김
  • 문제를 해결하다 보면 삽질을 함
  • 삽질을 하다 보면 깊이 파고 들어감
  • 파다 보면 스스로 해결이 안되는 문제가 생김
  • 기술 뉴스를 구독하여 읽음
  • 원서 책을 읽음
• 인연 & Credists
  
  • 많은 사람들과 작업

#4 비처럼 강물처럼 BeckAnd API - 신정규

• Lablup
  
  • 왜 딥러닝 모델 구현이 어려운가?
    
    • 오픈소스 + 클라우딩 컴퓨팅 = 다 된건가?
      
      • 안됨
    • GPU 관리의 어려움
      
      • 표준화된 인터페이스를 제공하지 않음
    • 소프트웨어 관리의 복잡성
      
  • Beckend. AI 만드는 중
    
    • 엔터프라이즈 제품으로 수익
• 목차
  
  • 목이 나온 사람들
    
    • 거북목 증후군
      
      • 그게 플랜 B였습니다. 언제나 플랜 B를 만드세요. 언젠간 그게 플랜 A보다 낫다는걸 발견할 때가 있을겁니다.
        
      • 곰돌이 가족회의
        
        • 생활비 / 저축 관련
          
        • 전자기기 백업 및 보관, 판매
          
        • 방 관련 정돈
          
        • 어느 가족 회의 때..
          
          • 결혼 2.0
            
          • 그럼 목표는?
            
            • 연구와 창업을 위한 오피스 + 집
          • 후회를 남기지 맙시다
            
            • 애기도
            • 서비스 만들기도
            • 연구도
          • 동의를 얻었는데 이걸 진짜 해야 될까
            
      • TEXTCUBE
        
        • 좋은 많은 사람을 만나게 됨
        • 같이 창업 하자
      • 기술에 대한 이해
        
        • 알고 있는 분야
        • 경험이 풍부한가
        • 경험이나 연구에서 나온 강점이 있는가
      • 산업의 발전 과정 역사를 보자
        
      • 만들것
        
        • 거대 샌드박스 기반의 프로그램 코드 + 데이터 실행 서비스
        • 클라우드 기반 아키텍터
      • 안 지르면 영영 못 지를 것 같았다
        
      • 팀
        
        • 같이 계속 의견을 공유하던 텍스트 큐브 프로젝트 + 포스텍 동기
      • 창업
        
        • 첫 피치
          
          • 흑역사
            
            • 피치하는 자리인 줄 몰랐음
            • 왜냐면 IR을 하라고 해서 갔기 때문
          • 준비 없이 갔지만 소득이 있었다
            
            • 백 번 절을 해야 하는 자리 였음
        • 첫 공개
          
          • 파이콘 KR
  • 살이 하얀 사람들
    
    • 가치 평가
      
      • 우리의 시장 가치 목표 1140억(이 수치를 믿으면 안된다)
    • 첫 워크샵
      
      • PC방
    • 첫 공식 출시
      
      • 15년 11월 4일
    • 하지 말아야 했던 것들
      
      • 하드웨어를 만들어 2대 팔았는데 안하기로 함
        
        • A/S문제
      • 컨설팅
        
        • 딥러닝 모델 컨설팅
        • 챗봇 시스템 설계 컨설팅
        • 뇌데이터 연구 과제
        • 돈은 되지만 회사의 가치를 올려주지 않았다
      • 공통점
        
        • 할 수 있는것 + 수익이 나는 것
      • 문제점
        
        • 그게 창업의 목표는 아니 였다
    • 기술 스타트업의 기회들
      
    • 래블업의 시장 예측
      
    • 결정의 순간
      
      • 학교 /연구소
        
        • 편한 도구를 주면 실력이 늘지 않는다
      • 기업
        
        • 똑같은거 만들고 있음
    • 정식 IR
      
      • 첫 IR 자리에서: 모든 일에는 처음이 있다
        
        • 1시간 동안 설명을 들음
      • 네 번째 IR 자리에서 : 모르면 바로바로 물어보기
        
        • SI
          
          • 시스템 통합
          • 전략적 투자자
    • 없음의 미학
      
      • CI도구 : 창업 시작때 자체 개발
        
      • 시드 머니가 바닥나 갈때
        
        • 개인 시놀로지에 Docker 시놀로지 올림
        • 클라우드로 비싸다 -> 시놀로지 Drive로 이동
      • 회사에 돈이 떨어지면 알게 되는 것들
        
        • 엄청난 유혹들과
        • 동료들의 확신의 정도와
        • 딸각발이 정신
  • 눈 밑이 검은 사람들
    
    • 진작 해야 했던 것들
      
      • GUI가 있었어야 함
      • 해외 컨퍼런스 홍보 및 발표
      • 대규모 클러스터 설치 도구 개발
      • 클라우느 SasS 런칭
    • GUI
      
      • 아는 만큼만 보인다
        
        • 설치 방법도 다양하게 지원
      • UI 개선
        
        • CLI에 정보를 더 많이
      • 2019년 2월에 개발 시작
        
    • 해외 컨퍼런스
      
      • 기술 발표는 몇번 나갔음
        
      • 우리 위치가 어느 정도인지 제대로 한 번 알아보자
        
      • 발표 신청 / 부스 신청
        
      • 결론
        
        • GUI를 대충이라도 만들어서 들고 오길 잘했다
        • 기술적으로 우리가 최전선에 있더라
        • 가치 판단 기준의 국내와 국외가 완전히 다르더라
    • 설치 프로그램
      
      • 메뉴얼 있으니까 다들 설치 잘 하겠지?
      • 현실은 설치하기 어려움
      • 개발자용 install 스크립트 만들기
      • Ansible 대응
      • 가상머신 이미지 제공(해야함)
    • 끝마치며
      
      • 현재의 행동은 외외로 미래의 나에게 영향을 미칩니다
        
        • 무엇을 하게 될 지 모르더군요
        • 계획대로 가는 삶은 없는듯 합니다
      • 만드는 시간 만큼 사용하는 사람을 만나봅시다
        
        • 개밥 먹는걸로 같은 개들만 좋아하더랍니다
        • 고양이도 만나고 돌고래도 만나야
      • 시작한 후에 끝날 걱정을 미리 하지 맙시다
        
        • 기술을 멀리 예측하듯이 살도 길게 관조하시면 눈 앞에 집중할 수 있습니다
        • 시작도 안 했으면 끝 걱정도 못 해봤을 거에요

#5 눈누의 노란 사춘기 - 윤민지, 이찬하

• 무료의 한글 폰트를 모아 놓은 서비스
  
  • 라이센스
• PM
  
  • 초보 PM
    
  • 원래 디자니어 및 프론트 개발자
    
  • 원래 하려고 한건 아닌데..
    
  • 프로젝트가 성장하면서 생기는 문제
    
    • 오류 대응 미숙
      
      • 갑작스런 성장
        
        • 시작부터 열광적인 반응
        • 다양한 채널에 노출
        • 갑작스러운 이용자수 증가
      • 작년 3월에 오픈
        
      • 실수로 생긴 오류에 대응하지 못하는팀
        
        • 외부에 도움 요청
        • 반복되는 오류
        • 반복되는 대응 미숙
        • 반나절 동안 사이트가 다운
        • 아, 뭔가 잘못 됐다!
      • 어떻게 해결
        
        • 능력 있는 팀원을 들이자
        • 크루 모집 공고
        • 새로운 팀원 합류 후 외부의 도움 없이 내부에서 문제를 잘 해결되는 듯 했으나..
    • 운영비
      
      • 시작할때 멋쟁이사자처럼에서 받은 1000 creditd을 1년만에 다 써버림
        
      • 1년 후 30만원 남음
        
      • 3개월 시한부
        
      • 돈을 충당
        
        • 비정기적으로 돌아오는 이용자의 소소한 후원금
          
          • 3천원 ~ 11만원 사이에서 들어오는 불안정함
        • 비정기적으로 하는 크라우드 펀딩
          
          • 펀딩에 실패하면 샘플 제작비만 날리고 수익 0원
      • 후원사를 유치
        
        • 두 곳의 후원사 유치 성공
      • 지출 관리
        
        • 아낄 수 있는 건 아끼고
          
          • 과다하게 설정된 용량 줄여서 월 25$ 서버비 절감
          • 불분명한 지줄처 확인해서 불필요하면 없애기
        • 쓰면 좋은 데엔 투자하고
          
          • Jenkins 사용
          • 홍보용 굿즈 제작
        • 비용 문제는 미리미리 생각 해야한다
          
      • 다음 단계 준비
        
        • 타이포 디자이너를 위한 폰트 마켓(예정)
          
        • 온라인 명한 제작 서비스 눈카드
          
          • 눈누에 있는 폰트를 이용해서 명함제작
        • 눈누 폰트를 이용한 메시지 카드 앱(예정)
          
    • 정리
      
      • 팀이 서비스를 감당 못한다고 판단되면
        
        • 신중하고 빠르게 팀원을 충원하도록 하자
      • 자금 문제는 미리미리 준비하자
        
        • 안일하게 생각했다간 밑도 끝도 없는 마이너스
• 개발
  
  • 부채
    
    • 기술 부채
      
      • 기술적인 문제를 뒤로 미루고, 비즈니스 문제 해결을 앞당김
      • 땡겨쓸 떈 편하지만, 부채에는 이자가 붙습니다
    • 원인
      
      • 개발자의 숙련도 부족
        
        • 코드가 불러올 결과를 예상하지 못함
      • 사이드 프로젝트의 한계
        
        • 문제에 대해 진지하게 오래 고민하지 못하고 본업으로
      • 항상 급박한 상황
        
        • 우선 빨간 화면은 안보이게 고치고 생각하자
    • 결과
      
      • 개발자의 의욕 저하
        
        • 해결되지 않는 오류의 늪에 빠짐
      • 서비스가 더 상장하지 못함
        
        • 기능이 추가되지 않으면 귀신같이 정체되는 MAU
      • 더이상 해결되지 않는 문제
        
        • 여기를 고치니까 이제는 저기가 터지기 시작
    • 해결 방법
      
      • 2.0 개발
        
        • 각자 잘하는 or 하고 싶은 부분을 주도해서 만들어보자
    • 역할 분담
      
      • 본업에서 쓰는 스택 위주로 담당
    • 일정 관리
      
      • 구글 시트
    • 느낀 점
      
      • 사실 빛을 안지고 살 수는 없다
      • 적절한 상환 계획이 매우 중요
    • 2.0은 9월에 완공 예정
      

#6 지속 가능한 사이드 프로젝트를 위한 시행착오 - 옥찬호

• 사이드 프로젝트 소개
  
  • RosettaStone
  • C++
  • 팀원이 안뽑힘
  • 하스스톤 개발자를 만나기도 함
• 새로운 팀원을 맞이하기
  
  • 프로젝트의 규모가 커지면 혼자서 감당하기 어렵다. 그래서 프로젝트를 같이할 새로운 팀원을 찾게 됩니다
    
  • 그런데 사이드 프로젝트란..
    
  • 많은 기술을 사용할꺼 같지만 아니다
    
  • 열정이 있어 프로젝트에 참여하려고 들어온 팀원들이 막상 개발을 하려고 하니 구조를 이해하는데 어려움을 겪어 포기하는 경우를 많이 봤었습니다
    
  • 문서화가 필요
    
  • 새로운 팀원이 프로젝트의 구조를 이해하고 기여할 수 있도록 도와줘야 한다. 팀원들이 스스로 무언가를 할 수 잇는 궤도에 오를 떄 까지
    
  • 그러기 위해서는 다음 사항을 준비
    
    • 듀토리얼 문서
    • 예제 코드
    • API 문서화
    • 프로젝트에 기여하는 방법
  • 문서화를 영어로 만드니 팀원이 생김
    
• 각자의 마음속은 동상이몽
  
  • 프로젝트를 더 좋게 만들고 싶은 마음은 팀원들 모두 똑같습니다. 문제는 '어떻게 좋게 만들 것인가'에 대해 갖고 있는 생각이 다르다는 것이죠
    
  • Master 브랜치의 핵심 구조를 바꿈
    
    • 서로 구조가 꼬임
      
    • 서로 생각하는게 다르다 보니 어떤 팀원이 다른 브랜치에서 작업하고 나서 master 브랜치에 머지하고 나면 코드 구조가 달라짐
      
    • 그러다 보니 충돌이 자주 발생/ 작업하던 코드를 전부 다시 작성
      
    • 이런 일이 몇번 일어나고 나니, 작업 인원들이 서로 지치게 되고 급기야 팀원 간에 오해가 생겨 프로젝트에 위기가 찾아오 게 된다
      
    • 이 문제를 해결하기 위해 우리가 한 일
      
      • 온라인 4시간, 오프라인 4기안 얘기후 한가지로 통합
        
      • 적어도 1달에 1번은 오프라인으로 모여서 프로젝트 진행 상황을 공유하고 앞으로 할 인을 논의하자. 그래야 앞으로 이런 일이 발생하지 않을 것이다
        
      • 질문이 있거나 논의하고 싶은 내용이 있을 때마다 언제라도 이야기할 수 있는 공간을 마련하자
        
        • 채팅방 마련
      • 대화를 많이 하자
        
• 프로젝트 관리의 기준선
  
  • 사이드 프로젝트를 유지하기 위해서는 프로젝트 관리에 최선을 다해야 한다
    
  • 사이드 프로젝트가 잘 유지되고 있는지 어떻게 판단
    
    • 프로젝트가 잘 빌드되고 있는가?
    • 꾸준히 커밋이 되고 있는가?
    • 프로젝트의 코드 스타일에 일관성이 있는가?
    • 프로젝트의 코드 품질은 잘 관리되고 있는가?
    • 프로젝트를 사용하기 위한 문서가 있는가?
  • 빌드가 잘 안되는 경우가 많다
    
    • 빌드가 안되면 안쓴다
  • 프로젝트의 코드 스타일에 일관성이 있어야 하는 이유
    
    • 통일성 있게 사용할 수 있게 장치가 있으면 좋다
  • 정한 방침 : 누구나 관심이 있으면 팀에 들어올 수 있게 하자. 하지만 프로젝트의 관리의 기준선을 아주 높게 만들자
    
    • Windows/Linux/macOS에서 빌드가 안되면 머지 불가능
    • 코드 품질이 일정 수준을 만족하지 않으면 머지 불가능
    • 테스트 커버리지를 충족하지 못하면 머지 불가능
    • 코드 리뷰를 거치지 않으면 머지 불가능
• 정리
  
  • 사이드 프로젝트에서 지속성은 가장 중요한 요소
    
  • 새로운 팀원이 궤도에 잘 오를 수 있도록 든든한 조력자가 되어주세요. 더불어서 처음 시작하는 사람을 위한 가이드를 만들어주세요
    
  • 팀원들이 서로 논의할 수 있는 공간/시간을 만들어주세요. 같은 방향을 바라볼 수 있게요. 온라인, 오프라인 둘다 좋습니다
    
  • 프로젝트 관리의 기준선을 세우세요. 이 기준선은 정하기 나름
    
    • (기준선이 매우 높은게 좋다고 생각)

#7 모두의 연구소 : 경쟁이 아닌 상생의 사회를 꿈꾸며 - 김승일

• 어릴 때는 하고 싶었던게 많았다
  
• 하지만 나중에는..
  
• 어릴때 공룡을 좋아했지만 나중에 공룡박사가 되지 않는다
  
• 입시교육에서 필연적으로 등장하게 되는 사교육
  
• 우리나라의 교육은 본인이 하고 싶은것을 고르지 못한다
  
• 하고 싶은 게 있는 아이들이 효자/효녀다
  
• 대학 입학
  
• 취업
  
  • 안짤리고 다닐려면 아무것도 안하면 된다
  • 하지만 퇴사할 때 할 줄 아는게 없다
• 모두의 연구소
  
  • 누구나 연구소를 만들수 있다
    
  • 누구나 참여할 수 있다
    
  • 어떻게 시작
    
    • 친구가 '개발자 카페를 만들어 보고 싶어'
      
    • 하고 싶은 프로젝트를 함께 하는 곳이 을 만들자
      
    • 그런데 진짜로 하고 싶은 걸 할 수 있을까?
      
    • 그걸 우리가 서포트 할 수 있을까?
      
    • 우리가 해보자
      
      • 드론
        
        • 만드는 방법을 블로그에 올림
        • 구글 검색하면 1페이지에
        • 수많은 강연 요청
        • 책을 한권 쓰고
        • 쇼핑몰도 하나 만들어봄
    • 주변의 반대
      
      • 요즘 세상에 무슨 오프라인 서비스냐
      • 왜 거기까지 와서 연구를 하겠냐
      • 처음에 모인다고 한들, 그 다음부터는 밖에서 따로 만나지 않겠냐
      • 어차피 망할거 빨리 해보고, 빨리 망해서, 빨리 다른거 하렴
    • 부인
      
      • 딱 1년만 해보고 안되면 다른 거 할께
        
      • 자본금 다 날리면 그 순간 그만할께
        
      • 긍적적인 피드백
        
        • 어 재밌을 거 같은데 한번 해봐
    • 2015.08.10 공간대여점에서 시작
      
  • 처음에 3개의 연구실 15명의 연구원
    
    • DeepLAB
    • 나 혼자 난다
    • VRTooN
  • 시련
    
    • 첫번째 시련
      
      • 2015.11월 공간대여점에서 쫓겨남
      • D.CAMP 무료로 한달 사용
    • 두번쨰 시련
      
      • 하고싶댜 != 할줄안다
        
      • 하고싶어하는 사람과 함께할 것인가?
        
      • 할줄아는 사람과 함계한 것인가?
        
      • 상생하는 문화가 생김
        
        • 본인이 잘하는 분야를 공유
    • 세번째 시련
      
      • 할 줄을 모르다 보니 자꾸 스터디 모임을..
        
      • 그래서 풀잎School
        
        • 모두 공부를 하고와서 스터디
  • 이제는 50여개 연구모임 400여명의 멤버쉽 연구원들이
    
  • 어느덧 스타트업이 두개나..
    
  • 여러 대회에 참가
    
    • 지문 인식
  • 여러가지 프로젝트가 나옴
    
    • 비접촉식 호흡 측정기
  • 9권의 책
    
  • 다양한 전시활동
    
  • 감사의 말씀
    
  • 이러한 사랑을 어떻게 나눠줄까
    
    • 돈을 쓰면서가 아닌, 돈을 벌면서 취업을 준비하는 Meani.mo 프로젝트
      
    • 교육을 미래의 꿈꾸기 위한 노력
      
      • 해외 교육 기관 탐방

#8 [Saas] Service as a Side project - 김석준

• 프로젝트
  
  • MINIMO
    
    • 메모
  • PixelBracelet
    
    • LED 팔찌
  • Raspilight
    
    • 인터렉티브 조명
  • 다이어트 다이어리
    
    • 운동 저널
  • 이웃
    
    • 동네 소식 앱
  • 트릿
    
    • 동물병원 레이팅 앱
  • 등등
    
• 왜?
  
  • 애초에 개발자를 하고 싶은 마음이 없었음
  • 앱 열풍과 함께 스타트업에 뛰어 들었으나.. 망함
  • 비 개발자 출신의 한계
  • 정부 지원 사업 -> 외주 -> 정부 지원 사업 -> 외주
  • 그래 내가 만들자
  • 만들고 싶은걸 만들 수 있다는 것이 개발자의 가장 큰 장점
• 인사이트
  
  • 하드웨어는 하지 말자
    
    • 부품 구매/배송/관리 비용이 큼
    • 프로토타입과 제품의 거리가 멈
  • 앱은 하지 말자
    
    • 개발은 하겠는데 배포가 지옥
      
      • 그리고 나는 웹 개발자인데
    • 더큰 문제는 천신만고 끝에 배포를 해도 다운로드를 안받음
      
  • 내가 좋아하고 필요한 걸 하자
    
    • 의미있는 걸 찾다보면 현자타임이 심하게 옴
    • 돈 될거 같아서 해 봐야 아무도 안옴
• 짤봇
  
  • /짤 - 기본 기능
    
  • /짤추가 - 팀에서만 쓰고 싶은게 있을때
    
  • /짤봇 -도움말이 필요하더라
    
  • 어떻게
    
    • 짤 크롤링
      
      • API를 그대로 오픈해놓은 곳이 태반
      • 확장성이 없어 그때 제대로 만들걸 하고 후회
    • UI
      
      • 슬랙 Slash Command 가 잘 되어 있음
      • 배포는 개발한지 2년만에. 앱 등록이 귀찮음
    • 기타
      
      • 설계고 뭐고 일단 되게 하자
      • 비용이 얼마나 나오겠어
  • 빌드
    
    • 빌드를 자동화 하고 싶은 -> 젠킨스
    • 사량이 낮으면 느리고, 계속 켜놓으면 돈나감 -> 고사양으로 쓸때만 켜 놓음
    • 설치하고 세팅하는거 귀찮음 -> Bitnamit로 사용
  • 사용자
    
    • 11번가, 아프리캈V, PUBG, 샌드박스 네트워크등 150여개팀에서 사용
    • 뭐하는데인지 모르는데가 태반
• 런칭
  
  • 2018년 2~3개 서비스를 만들었는데 런칭을 못했음
  • 다 만들고 본의 아니게 접게 됨
• QWER.GG
  
  • 왜?
    
    • LCK 개막이 다가오는데 best.gg 가 운영을 안함
    • LoL 공식 웹사이트 거의 사용할 수 없는 수준임
    • 어디서 중계하는지도 모르겠고, 언제 하는지도 모르겠음
    • 만들어야겠다
  • 무엇을
    
    • 일정을 볼 곳이 없으니까 저장해놓자
    • 경기 할때가 되면 알려줬으면
    • 트위치나 유툽 라이브도 볼 수 있게 해야지
    • 경기 결과도 넣어서 랭킹도 변하게 봐야지
  • 개발자는 반복을 싫어함
    
    • 크롤링을 해야 겠다고 생각함
    • API를 찾아봤는데 없음
    • 뒤져서 소스를 확보함
  • 홍보
    
    • 입네에 지인이 공유해 줌
      
      • 그 사람이 이제 제 PM
    • 유툽으로 해설자에게 (빛돌) 연락을 함
      
      • 직접 만나서, 여러가지 피드백을 받음
    • 여러가지서 연락옴
      
  • 요청
    
    • 내 니즈는 다 실행헀는데 뭐하지?
      
    • 경기 데이터를 사람들이 보고싶어함
      
      • 아이템, 빌드, 룬 같은 것들
    • 국제 리그에 나오는 팀들 뭐하는 애들인데?
      
      • 전세계 리그를 다 긁어버리자
  • 우리는 어떤 사람인가
    
    • 손으로 매치/빌드 데이터를 넣다가 이것도 크롤링
    • 공짜 트래픽을 위한 SSR, SEO
    • 운영/테스트 해 줄 사람이 없으니 데이터라도 쌓자 sentry, ga
    • log를 slack 에 쌓으면 언젠가 보겠지
    • 로그를 slack으로 보내기를 추천
  • 현재
    
    • 유저 10~12k / 1개월
    • 데이터 분석을 통한 지표 생성 및 승률 예측 개발중
    • 키보드/마우스 스폰서
    • RiotGames API를 받음 (잘 안줌) - 선수 그리고 나
    • LCK 상위권 팀과 데이터 관련 파트너쉽 (매출?)
• CI/CD
  
  • 짤봇을 방치했다가 1년반만에 다시 잡았는데
  • 큰 무리없이 다시 시작할 수 있었음
• 디자인
  
  • 디자인이 없으면 서비스는 불가
    
    • 못하는건 아닌데 뭔가 힘이 안나고 지속이 안됨
  • 디자인이 필요없는 UI를 선택하던가
    
    • 슬랙이나
    • 요즘엔 트위치 앱도 재밌을거 같음
  • 디자이너와 협업하자
    
    • 커뮤니케이션을 못하는게 자랑이 아님
    • 이건 언젠가 말할 기회가 있었으면
• 주제
  
  • 내가 좋아하고 내가 필요하면
  • 남들도 좋아하고 남들도 필요하다
  • 가급적이면 크롤링이 가능한 주제로
• 팀
  
  • 친한 사람들을 꼬시되 큰 기대는 하지 말자
  • 내가 못하는 걸 채워줄 수 있는 사람이 좋음
  • 느슨하게 오래가는 팀이 좋음
  • 서로에게 모티베이션을 줄 수 있는 방향을 찾고 있음
  • 재밌게 지내도록
• 기술
  
  • 부트업 시간이 짧은 기술을 선택
    
  • 피처 개발이 쉬운 기술을 선택
    
    • 기능 하나 개발하는데 디펜더시가 많으면 안됨
    • RDBMS는 가급적이면 피하자
    • 원래 개발하고 설계는 나중에 하는 거임
  • 단순한 구조를 최대한 유지
    
  • 데이터 >>>>> 개발시간 >>>>> 성능
    
  • 새로운 기술은 적어도 파운더는 고르면 안됨
    
    • 아는 것만 하고 모르는 건 최대한 뒤로 미루기
    • 배움이 끝나면 모티베이션이 급격하게 하락할 수 있음
• 워크 / 사이드프로젝트 밸런스
  
  • 하루 4-7시간 정도 하다보니 잠이 부족
    
    • 리모트라 가능했음
  • 쉴땐 쉬자
    
  • 자동화가 핵심
    
  
  
  

Read More

OKKY Conference 2018 The Real TDD 세미나 후기

OKKY Conference 2018 The Real TDD - TDD 제대로 알기 -

#1 테스트하기 쉬운 코드로 개발하기

정진욱 / PUBLYTO CPO

• 테스트하기 쉬운 코드란?
  
  • 항상 같은 결과 반환
  • 외부상태를 변경하지 않음
• 테스트하기 쉬운 코드로 개발하기
  
  • 방법1: 테스트하기 쉬운코드와 어려운 코드 분리
    
    • 요청한 좌석 수가 확보 가능한지 판단하기 위한 코드를 테스트 하기 위해서는 DB에 테스트 데이터를 설정해야한다.
  • 방법2 : 두 분류의 코드는 어디서 만나야 하나?
    
    • 두 분류의 코드는 최대한 가장 자리에 위치(에외 : 로깅, 퍼사드)
    • 테스트 하는 메소드에서 테스트 하기 어려운 코드가 제일 안쪽에 있으면 어려움이 전파되서 전체적으로 테스트하기 어려운 메소드가 된다.
  • 방법3 : 두 부류 코드가 만나는 가장자리는 어떻게 테스트 해야 하나?
    
    • 가장 자리를 테스트하는 방법을 익히자
      
    • 수동테스트
      
      • postman 사용
      • DB의 경우 query
    • 자동테스트
      
      • 작성된 프로덕션 코드의 사용 강제
        
      • 현 상태의 코드로는 할 수 없다
        
      • 실제 클래스 대신 목 사용을 위해 이음새가 있어야 한다.
        
      • 목 사용
        
        • 작성된 코드 사용을 강제할 수 있다.
          
        • 목 사용이 큰 장점으로 보이지만, 생각해 볼 점이 있다.
          
          • 행위 검증
            
            • 행위가 호출되었는가
            • Mockist
            • 불필요한 추상화 유발 가능성
          • 상태검증
            
            • 결과 값이 무엇인가
            • Classcist
            • 불필요한 추상화 필요 없음
      • 문제점
        
        • 목을 남발할 가능성이 크다.
          
          • 대부분 목 사용 예제는 간단하다. 그래서 장점이 크게 보인다.
          • 실제 프로젝트에 적용하면 한꺼번에 많은 수의 목을 다루면서 곤란을 겪는다.
        • 적당 수의 목 사용에 대한 답을 찾기 어렵다.
          
        • 상태 검증으로 돌아가보자
          
      • 상태 검증 - 문제 극복 방안
        
        • TDD를 통한 사전이 아니라 사후 테스트를 하자
        • 두 부류의 코드가 맞물려 잘 돌아가는 로직이다
        • 난해한 코드가 아니다
        • 구현된 코드를 사용하지 않고 굳이 어려운 길을 택할 이유가 없다
        • 완벽을 추구하면서 목을 사용하는 비용을 들일 필요가 있는가?
• 끝으로
  
  • 요즘 저는
    
    • 두 분류 코드를 분리해서 각각 테스트하고,
    • 가장자리에서 맞물려 돌아가는 코드는 주로 수동테스트
  • 두 부류 코드 섞어 놓고 테스트가 어렵다고 포기하지 마세요
    
  • 위 내용과 관련된 제 블로그 참조
    
    • http://jwchung.github.io/testing-oh-my
• 테스트를 만족하는 만큼만 코드를 작성하라
  
• TDD는 점진적인 접근방법을 사용하고 있다.
  
• 테스트하기 어렵다는 거는 테스트 할때 값이 필요하다는 뜻이다.
  
• Q & A
  
  • private 코드 테스트 하는 방법?
    
    • 같은 기능을 테스트해도 적은 메소드를 건드리는 메소드가 좋다
  • 레거시 코드 테스트 하는 방법?
    
    • 최대한 레거시 코드와 결합도를 낮추자
    • 목업을 할수 있는 seam을 만든다
    • 최대한 새로 생성된 코드에 최대한 테스트를 가한다
    • 기존 레거시 코드에 대한 값을 정의해 놓고 테스트

#2 의식적인 연습으로 TDD, 리팩토링 연습하기

박재성 / SW 교육 전문가 전 NEXT 교수
TDD와 리팩토링을 왜 해야 하는지 알고 있다. 는 가정 하에 진행한다.
TDD와 리팩토링을 비슷한 비중으로 다룬다. 어쩌면 TDD < 리팩토링 일지도 모른다.
개발 현장을 떠난지 오래 되어서 틀린 부분이 있을 수도 있다

• 의식적인 연습으로 TDD, 리팩토링 연습 과정
  
• TDD, 리팩토링을 잘 하려면??
  
  • 연습..연습..
    
  • 연습을 많이 한다고 잘할 수 있을까?
    
  • 6년한 후에 알게된 점
    
    • 테스트하기 쉬운 코드와 테스트하기 어려운 코드를 보는 눈
    • 테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감
• 의식적인 연습의 7가지 원칙
  
  • 첫째, 효과적인 훈련 기법이 수립되어 있는 기술 연마
  • 둘째, 개인의 컴포트 존을 벗어난 지점에서 진행, 자신의 형재 능력을 살짝 넘어가는 작업을 지속적으로 시도
  • 셋째, 명확하고 구체적인 목표를 가지고 진행
  • 넷째, 신중하고 계획적이다. 즉, 개인이 온전히 집중하고 '의식적'으로 행동할 것을 요구
  • 다섯째, 피드백과 피드백에 따른 행동 변경을 수반
  • 여섯째, 효과적인 심적 표상을 만들어내는 한편으로 심적 표상에 의존
  • 일곱째, 기존에 습득한 기술의 특정 부분을 집중적으로 개선함으로써 발전시키고, 수정하는 과정을 수반
• 연습하는 과정
  
  • 1단계 - 단위 테스트 연습
    
    • 내가 사용하는 API 사용법을 익히기 위한 학습 테스트에서 시작
      
      • JAVA API 테스트(split, subString, ArrayLisy ...)
    • 내가 구현하는 메소드중 Input과 Output이 명확한 클래스 메소드(보통Util 메소드)에 대한 단위 테스트 연습
      
    • 알고리즘을 학습한다면 알고리즘 구현에 대한 검증을 단위 테스트로 한다.
      
    • 지켜야 할 원칙
      
      • 회사 프로젝트에 연습하지 말고 장난감 프로젝트를 활용해 연습하자.
      • 실패하는 테스트 소스 -> 성공하는 테스트 소스 - > 리팩토링을 반복
      • 테스트 코드를 먼저 만들고 코드를 만든다.
      • 어려운 문제를 해결하는 것이 아니라 TDD 연습이 목적 난이도가 낮거나 자신에게 익숙한 문제로 시작하는 것을 추천
  • 2단계 - TDD연습
    
    
    • 회사 프로젝트 말고 장난감 프로젝트를 활용하자.
      
    • 의존관계를 가지지 않는 장난감 프로젝트를 활용하자.
      
    • TDD 사이클
      
      
      • 처음에는 1단계, 2단계만 하고 3단게 Refactoring은 안해도 된다.
    • 리팩토링 연습
      
      • 한 메서드에 오직 한 단계의 들여쓰기만 한다.(메서드로 분리)
        
      • else 예약어를 쓰지 않는다.
        
        • return을 중간에 하면 하단 코드를 안봐도 된다.
        • 가독성 증가
      • 메소드가 한 가지 일만 하도록 구현하기
        
      • 로컬 변수가 정말 필요한가?
        
      • compose method 패턴 적용
        
      • 모든 원시값과 문자열을 포장한다.
        
      • 일급 콜렉션을 쓴다.
        
      • 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.(힘들다)
        
    • 테스트 코드는 변경하지 말고 테스트 대상 코드를 개선하는 연습을 한다.
      
    • 읽기 좋게 코드를 변경한다.
      
    • 추상적인 피드백을 받으면 어느 부분을 작업 해야할지 알기 어렵다.
      
  • 3단계 - 연습을 과하게 한다
    
    • 연습을 할때는 극단적으로 해야 느끼는 점이 있다
    • 처음 읽는 사람에게 어느 코드가 더 읽기 좋을까? 리팩토링 전, 후
    • 한번에 모든 원칙을 지키면서 리팩토링하려고 연습하지 마라. 한번에 한 가지 명확하고 구체적인 목표를 가지고 연습하라.
    • 연습을 극단적인 방법으로 연습하는 것도 좋다. 예를 들어 한 메소드의 라인 수 제한을 15라인 -> 10라인으로 줄여가면서 연습하는 것도 좋은 방법이다.
    • 테스트 코드가 있으니 리팩토링 연습이 가능하다.
  • 4단계 - 장난감 프로젝트 난이도 높이기
    
    • 점진적으로 요구사항이 복잡한 프로그램을 구현한다. 앞에서 지켰던 기준을 지키면서 프로그래밍 연습을 한다.
      
    • TDD하기 좋은
      
      • 게임과 같이 요구사항이 명확한 프로그램으로 연습
      • 의존관계가 없이 연습
      • 약간은 복잡한 로직이 있는 프로그램
    • 연습하기 좋은 예
      
      • 로또
      • 사다리 타기
      • 볼링 게임 점수판
      • 체스 게임
      • 지뢰 찾기 게임
  • 5단계 - 의존관계 추가를 통한 난이도 높이기
    
    • 웹, 모바일 UI, 데이터베이스의 의존관계를 테스트
      
    • 필요한 역량
      
      • 테스트하기 쉬운 코드와 테스트하기 어려운 코드를 보는 눈
      • 테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감
    • 앞 단계 연습을 잘 소솨했다면 테스트하기 쉬운 코드와 어려운 코드를 분리하는 역량이 쌓였을 것이다.
      
    • 한 단계 더 나아간 연습을 하고 싶다면
      
      • 컴파일 에러를 최소화하면서 리팩토링하기
      • ATDD 기반으로 응용 애플리케이션 개발하기
      • 레거시 애플리케이션에 테스트 코드 추가해 리팩토링하기
    • 유지보수를 잘하는 SW개발자가 몸값이 더 올라갈 것이다
      
    • 책
      
      • 소트웍스 앤솔러지
      • 클린코드
  • TDD, 리팩토링 연습을 위해 필요한 것은?
    
    • 조급한 대신 마음의 여유
    • 나만의 장난감 프로젝트
    • 같은 과제를 반복적으로 구현할 수 있는 인내력
  • 가장 필요한 것은 가보지 않는 길에 꾸준히 도전할 수 있는 용기
    
• Q & A
  
  • 컴포트존을 극복하는 방법?
    
    • 삶에 여유와 에너지가 있어야 한다.
    • 회사 말고 집에서 혼자 연습을 하자.
  • 기존 테스트 코드가 있는데 요구사항이 추가, 변경 됐을때 기존 테스트 코드가 에러 났을때 대처
    
    • 내가 테스트 코드를 잘못 짠 경우가 많다.
    • 나중에 하지 말고 현재에 최대한 테스트 코드를 작성하자.

#3 코드 품질을 위한 테스트 주도 개발

삼성SDS 한성곤 Principal Engineer

• TDD Cycle
  
  • Red -> Green -> Refactor 반복
  • 짧은 개발 주기의 반복에 의존하는 개발 프로세스
  • XP의 Test-First 개념을 기반으로, 단순한 설계를 중요시 하는 Pratice
• TDD 장점
  
  • FROM Test
    
    • 동작하는 코드에 대한 자신감
    • 회귀테스트를 통한 자유로은 리팩토링
    • 코드에 대한 지식이 증가
    • 개발 생산성 향상
  • FROM Test-first
    
    • 과도한 설계를 피하고, 간결한 interface를 가짐
    • 불필요한 기능을 줄임
    • 실행 가능한 문서를 가짐
    • 코드 품질을 높임
    • 테스트 코드가 있으면 디버깅에 대한 시간이 줄어든다.
• SonarCloud
  
  • 프로젝트의 코드 퀄리티를 분석
• 사례
  
  • Microsoft 사례
    
    • TDD / Non TDD 팀
      
      • TDD가 하는 팀이 15% 더 많은 시간 소요
• 불필요한 주석은 나쁘다. 버그성에 대한 내용을 주석에 담는 경우
  
• 코드 퀄리티 매트릭스
  
  • 복잡도
  • 결합도
  • 응집도
• MCC 측정 평가
  
  • 마이크로소프트는 McCabe 수치를 임계치 15, 10이상은 refactoring 교려 대상

#4 테알못 신입은 어떻게 테스트를 시작했을까?

이혜승 / 오마이호텔 Front-End Engineer

• 방법에 대한 이야기
  
  • 테스트
    
    • 1-1 기존 코드에 테스트 추가하기
      
      • 이미 테스트 하기 쉽게 만들어져 있는 코드로 시작한다(순수함수, 외부 의존성 있는것은 말고)
        
      • 프로덕션 코드는 수정하지 않고 테스트 한다.
        
      • 테스트코드는 수정하지 않고 리팩토링을 진행한다.(리팩토링은 테스트가 깨지지 않는 범위 내에서만)
        
      • 테스트 하기 어렵게 만들어져 있는 코드에서 테스트 하기 쉬운 것만 분리한다.
        
        • 선택 기준
          
          • 중요도가 높은 비즈니스 로직이 포함된 부분
          • 버그가 발견된 부분 (과거X)
          • 결합이 낮고 논리는 복잡한 부분(외부 의존도가 낮거나 없고(독립적인 환경을 가지고 있고) 비즈니스 로직은 복잡한)
      • 테스트 가능한 코드를 찾아서 -> 분리하고 -> 테스트 코드를 추가하고 -> 리팩토링
        
      • 코드가 테스트 하기 어려운 이유(API 요청,응답 결과에 따라 다른 UI)는 테스트 가능한 부분만 분리한다.
        
        • 외부에 영향을 받지 않는 독립적인 함수로 만들어 준다.
        • 반환 값에 대한 스펙을 추가한다.
  • TDD
    
    • 1-2 새로운 코드는 TDD로 개발하기
      
      • 비즈니스 요구 사항 추가
  • 정리
    
    • 어떻게
      
      • 기존 코드에 테스트만 추가(+리팩토링)
      • 새롭게 추가 되는 요구 사항은 TDD
    • 무엇을
      
      • 이미 테스트 하기 쉬운 코드를 만들어서
• 경험에 대한 이야기
  
  • 좋은점
    
    • 새로운 비즈니스가 추가 됐을때 코드를 수정 후 문제 점이 있을때 기존에 있는 오류를 테스트코드가 잡아준다.
      
    • 진짜로 느낀 것들
      
      • 스펙 문서 기능
        
      • 디자인 개선 효과
        
      • 학습 동기부여
        
        • 내가 얼마나 디자인을 못하는 지 알게 된다.
        • 안정성과 설계 관심을 가지게 된다.
      • 개발 생산성 향상
        
        • 버그를 추적하는 시간이 현저하게 줄어든다.
      • 프로젝트 생산성 향상
        
        • 비즈니스 로직의 허점을 사전(본격적으로 코딩을 시작하기 전에)에 발견하기도 한다.
      • 집중력 향상
        
        • TDD는 동시에 한 가지 이상의 일을 하지 않도록 통제해준다.
  • 실수
    
    • 테스트 대상 오류
      
      • 불필요한 테스트
        
        • 불필요하다의 기준 : 비즈니스와 관련된 버그를 낼 가능성이 낮거나 없고 테스트를 유지함으로써 얻는 이익 < 테스트 유지와 관리에 드는 비용 일 때, 테스트가 단언하고 있는 내용이 사용자에게 중요한 가치를 주는 것이 아닐때
      • 필요하지만 검증 방식이 잘못된 테스트
        
        • 특정 위치에 대한 테스트는 변경될 소지가 많다.
        • 검증식을 개선한다.
      • 검증력이 떨어지는 테스트
        
        • 하나 이상의 가능성을 열어 두고 있다.
      • 테스트 제목과 검증의 불일치
        
      • 테스트를 앞서가는 프로덕션 코드
        
        • 프로덕션 코드에서 미리 모든 요소를 만든다.
        • 테스트가 성공할 만큼의 최소한의 프로덕션 코드를 만든다의 원칙을 어긴다.
  • 고민
    
    • 테스트 관련 코드들의 관리
      
      • 테스트를 위해 만들어진 데이터(Fixture)
    • 이런방식으로 하다보니 함수가 곳곳에 퍼지게 된다
      
      • 왠지 모르겠지만 불안하다.
        
      • 계속 이렇게 함수로 분리하기만 하는 게 맞는 건가?
        
      • 오히려 전부 분리하는 게 가독성을 더 해치고
        
      • 추상화 수준이 낮다
        
        • 아주 구체적인 작은 단위의 함수들로만 분리되어 있고 그들이 조합되어 만들어지는 큰 수준의 기능은 설계되지 않았다. 그래서 추상화 수준이 낮아졌고 클라이언트에서 구체적인 내용을 알아야만 사용될 수 있다.
      • 높은 응집, 낮은 결합
        

#5 테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과

양완수 / 쿠팡 Principal, Software Engineer

테스트 코드의 가독성

• 질문
  
  • TDD를 실무에서 많이 하느냐? 아니다.
  • Unit Test를 작성을 하고 있느냐? 할 때도 있고 안 할 떄도 있다.
• 발표 내용
  
  • TDD에 대해서 이야기하지 않습니다.
  • 테스트하기 좋은 설계에 대해서 이야기하지 않습니다.
  • 제어할 수 없는 것에 대해서 이야기하지 않습니다.
• 테스트 코드는 프로젝트 코드가 사용되는 최초의 장소이며 고객이다.
  
• 모든 역사는 테스트 코드부터 시작된다.
  
• 추상이란?
  
  • 문맥 위에서 오직 관심 있는 것들에 대해서만 집중하여 명확하게 하는 것
• 당신이 테스트를 거들떠 보려 하지 않는 이유
  
  • 귀찮다.
    
  • 고통스럽게 하는것
    
    • 숨겨진 본질
      
      • 낮은 추상화
      • 들쭉날쭉한 추상화
      • 끊어진 논리
      • 알 수 없는 의도
    • 욕심쟁이
      
      • 테스트가 실패하는 이유는 단 하나
      • 하나의 테스트는 오직 한 가지만 똑바로 검사해야 한다.
    • 인지능력의 과부화
      
      • 흩어진 코드와 데이터
      • 매직 넘버
    • 꺠지기 쉬운 것들
      
      • 높은 결합
      • 낮은 응집
• 백문이 불여 일코
  
  • 좋은 설계를 가진 코드는 아니다.
    
  • 다양한 가느성을 가진 코드
    
  • 실제 팀 내 코드에서 발췌하여 발표에 맞게 수정
    
  • 불필요한 것에 집착하지 않습니다.(네이밍)
    
  • 테스트 코드를 위한 프로덕트 코드
    
  • url작성하기 Git
    
  • 코드 커밋 순서 설명
    
    • 무슨 테스트인지 알 수 없는 코드
    • setUp메소드를 통해 응집력이 다른 코드를 분리하고 추상화 레벨을 맞추려고 한다.
    • 객체를 새로 만들어 2가지 객체의 관계를 가깝게 만든다.
    • 테스트 대상을 명확하게 표현한다.(네임변경)
    • 한가지만 확실하게 테스트를 대칭성 있게 하자
    • 응답에는 성공과, 실패가 있다. 의존을 제거하고 불필요한 것을 격리 한다.
    • 테스트명을 처음부터 스트레스 받지 말고 안의 내용을 명확하게 만든 후 수정하자.
    • 하나의 것만 테스트 해라.
• 테스트 코드를 잘 작성하려고 노력하다보면 좋은 설계를 가진 코드(높은 응집도 낮은 결합도를 가진 코드)를 가지게 된다.
  
• 테스트가 쉽도록 코드를 만들어야 한다.
  
• 테스트는 과정, 수련, 스승, 거울, 제품이다. 억지로 먼저 하지마라. 건강하게 하라. 두려워 하지마라. 즐거워 해라.
  
• 테스트는 우리를 가르쳐준다. 우리를 가이드하고 발전 시켜준다. 프로덕션 코드를 좋게 만들어 준다.
  

#6 당신들의 TDD가 실패하는 이유(Live Coding)

이규원 / 오마이호텔 CTO

• TDD가 실패 하는 이유
  
  • 준비가 되지 않아서
    
  • 개인
    
    • 모든 것에 TDD를 하지 않는다.
      
    • 우리가 보호해야 하는 것
      
      • 도메인
    • 우리가 제어할 수 없는 것
      
      • 외부 세상
        
        • 실 세계
        • 인프라
        • 외부 서비스
        • 레거시
    • 설계
      
      • 낮은 결합
      • 높은 응집
      • 도메인 모델 보호
    • 설계를 테스트 하라
      
    • 문제점
      
      • 정보 숨김(Information Hiding)
        
        • 어려운 설계 결정과 변경될 가능성이 높은 설계 결정들을 다른 모듈로부터 숨기는 것
      • 구현을 테스트
        
        • 내부의 코드를 수정하면 테스트가 깨진다.
      • 설계 테스트
        
        • 내부의 코드를 수정해도 테스트가 깨지지 않는다.
    • 레거시와 함께 살기
      
      • 새로 작성한 코드를 위해 Adapter로 감싸고 테스트 한다.(System Under Test)
  • 팀
    
    • 프로세스
      
      • 점진
      • 반복
      • Fail-Fast
    • 반복 주기
      
      • 주로 실행만 한다.(코드만 작성)
      • 계획
      • 실행
      • 평가
    • 문화
      
      • 공유
        
        • 목표
        • 지식
    • 아키텍처
      
      • 낮은 결합
      • 높은 응집
      • 도메인 모델 보호
    • 도메인 모델과 플랫폼
      
      • 도메인 모델과 플랫폼이 강하게 연결되어 있지 말고 서로 분리 해야 한다.
    • 아키텍처 사례(크기가 큰 순서로 나열)
      
      • 비즈니스로직 - 서비스 -모듈 - 애플리케이션 플랫폼
    • MVVM 아키텍처 패턴
      
• 비즈니스에 대한 목적을 정확하고 정리하고 그림을 그리고 얘기를 해야 서로 이해에 대한 오해가 없다
  
• ATDD(Acceptance Test) + TDD(Unit Test)로도 테스트 할 수 있다.
  
• 코드 설계
  
  • 작업에는 어떤 코드 변경이 필요한가?
• 피드백
  

#7 패널 토의 Q & A

• 왜 많은 방법론 중에서 TDD인가?
  
  • 코드에 대한 신중함이 생긴다.
  • 가장 빠른 피드백을 준다.
  • 피드백을 통해 직무 탈진을 하지 않게 된다.
• 주위 사람들에게 TDD를 어떻게 설득할 수 있을까?
  
  • TDD를 하는 개발자는 많지 않다. 외롭다.
    
  • 어떻게 같이 TDD를?
    
    • 주니어 개발자고 영향력이 크지 않다면 전파하는데 집착하지 말자
      
    • 나의 만족을 위해서 하자
      
    • 코드에 대한 자신감이 생긴다.
      
    • 주위 사람이 리팩토링한 코드에 대해 물어보면 그떄 전파 하자
      
    • 나중에 영향력이 있을떄 전파 하자
      
      • 하지만 과연 성공할까?
      • 팀에 대한 문제점을 개인이 인식하게 만든다.
      • 팀원들이 페어링과 TDD를 하자는 환경을 만들어야 한다.
      • 팀원들이 주도적으로 하게 만들어야 한다.
      • 먼저 TDD를 하는게 아니라 필요한 부분에 먼저 작은 변화를 적용한다.
    • 초보일때 남들과 같이 TDD를 하기에 수월할 수도 있다.
      
  • TDD에서는 테스트의 순서가 중요 하다. 첫 테스트는 작지만 핵심인 부분을 하자
    
  • TDD를 도입할 때도 핵심을 찾아야 한다.
    
• 코드 커버리지의 기준은 어떠한 지표로써 이해를 해야 좋을까?
  
  • 테스트 커버리지에 집착 하지 말자
  • 프로덕션 코드에 집중 하자
• 신입의 TDD공부방법 및 도서
  
  • 페어프로그래밍
  • 테스트 주도 개발(도서)
  • 테스트 및 리팩토링 책을 많이 보자
  • 책만 보지 말고 꾸준히 수련 하
• 도메인 모델과 스프링의 접점을 줄여야 하는 이유
  
  • 여러 플랫폼에 종속적이지 않기 위해서
  • 스프링으로 개발하지 말고 순수 코드로 개발 완료 후 스프링에 옮겨 본다.

Read More

DEVIEW 2018 컨퍼런스 후기

COEX Grand Ballroom에서 10.11 ~12일 이틀 동안 열린 네이버에 주최하는 세미나에 DAY2날 참여했다. 전체적으로 인공지능 관련된 주제의 발표가 많았다.

Read More

NHN 엔터테이먼트 안정적인 서비스 운영 - 설계에서 모니터링 까지

NHN에서 주관한 세미나에 참석했다
서비스를 운영하면서 설계하는 여러가지 방법과 운영하면서 신경써야 할 부분에대해 들을 수 있었다.
발표자료는 슬라이드쉐어에서 볼 수 있다.
세미나 정보도 올라오는 페이스북도 있다

Read More

패스트캠퍼스 개발자 커리어 컨퍼런스

이직을 꿈꾸는 개발자들에게 선배 개발자들이 진솔하게 전하는 개발자 이야기
# 인사 담당자가 말하는 개발자 채용
# 개발자로서의 성장
# 한국 개발 커리어의 현실
에 대한 내용을 얘기해보는 컨퍼런스다.

Session 1. 인사담당자가 말하는 개발자 채용

1.1 개발인력의 공통특징/특성 및 채용관점에서 본 개발인력에 대하 요구역량/성장경로

• 시간이 지날 수록 아래로 가서 역량을 펼쳐라
• 본인이 가치창출, 희소성, 모방의 어려움, 비 대체성이 있는지 확인하라(by 제임스반)
• 30대 중반부터 생산성이 하락
• 요즘은 역량기반으로 채용
• 우수 S/W
• 프로그래밍 능력, 도메인지식, 커뮤니케이션
• 문제가 주어지는 순간 머리속에 그려짐
• 직무간(도메인) 전환도 빠르게 적용
• 의사 소통이 중요(안좋으면 좋은 인사고과, 좋은 급여를 받기 힘듬)
• 개발 업무 수행시 요구 사항 분석에 많은 시간을 투자
• 채용 면접 평가 기준
• 신입 : 기본기 위주 skill
• 박사 : 지식+스킬 기반으로 프로젝트 등 새로운 문제해결 시도 및 어떤결과를 냈는지 평가
• 경력 : 현재 사용 가능한 skill
• 리더 역량
• 기술+인간관계+관리능력
• 스택을 넓히고 도메인을 깊이
• 개발자에게 동기부여
• 레벨 테스트
• 주축 개발자가 20~30%정도의 시간을 투자해 교육 및 보상
• 관련없는 분야 이직시
• 트렌드를 보자
• 기존에 가지고 있던 도메인에 대한 개인공부
• 내역량을 드러내는 방법
• 다른사람과 다른 나의 고유한 내적 특성
• 오픈소스기여(재밌어서 하는게 좋다)
• 기업별 보는 스킬
• 대기업: 한개의 도메인의 깊이
• 중견기업 : 한개를 잘하지만 다른것도
• 회사의 성향을 보자

Session 2. 개발자, 직장인? 직업인?

개발자로서 실력을 키워 성장하는 법과, 개발팀 직원으로서 좋은 인사고과를 받고 살아남아 승진하는 법은 다릅니다.

개발 실력과 회사 생활 양쪽을 모두 신경써야하는 직장인 개발자를 위한 성장 꿀팁을 공개합니다.

2.1 개발과 업무의 환경에서 - 레이니스트 안드로이드 개발자 김범준

• 개발에 빠진 이유?
• 개발이 즐거운가?
• 일이 즐겁나요? 반복적인 일, 쉬운일

2.2 어떻게 하면 추천받는 개발자가 될 수 있을까? - 카카오 이경일

• 경력공채, 수시채용 -> 사내추천
• 추천해준 사람을 통해 면접관의 관심사를 알 수 있다.
• 같은조직에 한해 서류전형이 통과될 수 있다.
• 리스크가 적다.
• 추천받는법(2가지이상)
• 현 동료와 좋은 고나계를 유지하라(커뮤니케이션, 협엽)
• 본인의 업무에 최선을 다하라(전문성, 도메인)
• 했던일을 적극적으로 표현(깃허브 세미나, 블로그)
• 컨퍼런스 참석
• 4가지를 충족해도 인성이 나쁘면? 별로다
• 이사람에게 일을 맡기면 해결할 수 있는 인식이 중요

2.3 관리자와 개발자 - 리멤버 CTO 임세준

• 시간이 지나면 관리자?
• API 개발이 즐거웠다
• 메소드 시그니처
• 클래스 나누기
• 라이브러리
• 성능
• 기술리더 : 코딩할 시간이 없다
• 조직관리
• 문화 프로세스
• 업무프로세스 : 스크럼, pp, 코드리뷰
• 품질관리 : 단위테스트, QA
• Risk Taking : 신기술 도입장려
• 채용
• 채용기준
• 채용프로세스
• 다양한 리쿠르팅 활동

QnA

• 같이 일하기 싫은사람?
• 독단적인 사람
• 방어적인 태도
• 근거와 공감능력이 필요하다
• 생각에 대한 논리적인 근거가 필요하다
• 개발성장과 도움
• 문제해결능력(논리적 상황에서 관련된 사항 보는 능력)
• 내가한 행동을 동료에게 넘기고 피드백 요청
• 다른분야로 이직
• 토이프로젝트가 필요
• 빠른 습득력 필요
• 연봉과 역량 그리고 업무,
• 서비스를 빨리 끝내면 그것은 인센티브
• 역량은 윗분들에게 리뷰요청등 피드백 요청해서 알리자 연봉협상에 좋다
• 나의 관심사를 적용해 개발

Session 3. 내가 보는 한국 개발 커리어의 현실

내가 개발자로서 언제까지 살아남을 수 있을까?

핫한 기술 스택 열심히 배우면 이직/승진이 쉬워질까?

3.1 17년을 돌이켜보며 - 네이버 조은

• 언어를 잘하는 것이 아니라 프로그래밍을 잘해야 한다
• 내가 잘하는것 못하는것, 어디에 초점을 맞출까?
• 면접을 보면 나를 알 수 있다
• 레퍼런스 번역을 하며 공부하는것도 방법
• 회사도 중요하시만 팀에서 하는일도 중요

3.2 야생에서 살아남는법 프리로 사는법 하이퍼커넥트 - 최완복

• 짧은 프로젝트 위주의 경력
• 야생 생종법
• 기간, 공백
• 계약해지
• 평판이 중요하다
• 커뮤니티 활동
• 일감확보(기존 거래처 오퍼 및 커뮤니티에서 검색)
• 기술력 확보
• 공격적인 기술셋
• 짧게 여러 프로젝트에 적용
• 커뮤니티로 배우기
• 열정을 충전
• 어려운 문제 해결
• 오픈소스 기여
• 가르키는것이 최고 학습법
• 관계 맺기/유지
• 커뮤니티 : 신기술, 행사
• 해커톤 : 골라서 잘가자
• 새로운 시도 지속하기

3.3 20년차 개발자로 살아남는법 - CTO 굿닥 신현묵

• 벤처 -> SI -> 의료 -> 헬스케어 전문가
• 27년차 개발자
• 20년차 개발자 볼수있나?
• 고참 테크니션이 필요한 곳
• 고참 경력자를 인정하는 곳
• 20년차
• 분석, 설계
• 기술적 로드맵 결정 참여
• 기술적인 이슈 결정 참여
• 비즈니스에 대한 이해도 상승
• How?
• 다양한 경험
• 초기 5년이 중요
• 대기업 별로(4~7년은 까지만)
• 커뮤니티 오픈소스 활동
• 리뷰 활동
• 뛰어난 아키텍처 동료
• 운도 중요
• 10년이상개발자는 인건비내리자 
• 망해보자
• 살아남는법? 직장인? 개발자?
• 사장님
• 개발팀장
• CTO
• 솔루션 or 프레임워크 주요커미터
• 변신
• IT출판사 직원
• 컨설턴트 기술 영업직
• 직장인
• 대화가 잘되고 조언주는 사람

QnA

• 연 8~10억정도 솔루션이면 혼자해도 된다
• 문제에 대한 솔루션은 없는데 고민이 있을때 이직한다
• 이직
• 경영자가 삽질할때
• 내가 필요 없을때
• 주니어/시니어, A/B급
• 업무이외 개발을 하는가? 즐기면서 하고있는가?
• 잘만드나? 가독성 Test, 성능, 설계
• 개발자에게 서포트?
• 개발자가 뭘 원하는가? 맥북..
• 연봉
• 자율출퇴근
• 시간적인 자유로움
• 철학, 비전 공감이 필요하다
• 삽질안하고 동일한 행동 반복 안하게하고 CTO가 좋은 결정하면 된다.

Read More