1. 개발자의 역할
- 돈을 벌어들이는 것
- 돈을 덜 쓰게 하는 것 (비용 절감)
돈을 벌어들이는 것 ⇒ 조금 특수한 경우
돈을 덜 쓰게 하는 것 ⇒ 약간의 노력만 한다면 누구나 할 수 있음
어떻게 돈을 덜 쓰게 할 수 있을까?
이에 대한 수단이 무엇일까?
- 인건비를 효율적으로? → 개발할 때 수정을 용이하게 한다. 개발에 투자하는 시간을 줄인다.
- 어떻게 수정이 용이한지 알 수 있을까?
- 디자인패턴
- 프레임워크
- 프레임워크
- 리액트를 사용하는 경우, 컴포넌트 단위로 개발을 하게 된다. 관리가 용이해진다.
- “리액트(프레임워크)가 일종의 규칙”
- 공장에서 물품을 찍어내듯이, 개발자가 일종의 기계 부품이 되는 느낌.
- A라는 사람이 퇴사해도, B라는 사람이 프레임워크를 이해하고 있으면, 적응도 빠르고 수정도 빠르고
- 프레임워크에 종속적이지 않은 사람이 되려면?
- “나는 단순한 공장부품이 되고 싶지 않아!” 라는 욕구가 있을때는?
- 코딩 외적인 것 ( = 소프트스킬 )
- 커뮤니케이션 능력을 키우자.
- 리더쉽을 키우자.
- 분위기 메이커가 되어보자.
- 개발을 잘 한다 ≠ 일을 잘 한다
- 하드 스킬(코딩)을 키우는 방향
- 자가체크 ( 내가 배운걸 정말로 잘 활용하고 있는지 확인해보자 )
- 생각보다 사람은 노력하는걸 안 좋아한다 → 시간 투자가 더 필요하다 ( 더 열심히 공부하자 )
- 언어(자바스크립트)를 잘 하자.
- react ≠ javascript
- javascript를 잘 하게 되면, 사실 어떤 프레임워크를 써도 상관 없고
- 다른 언어에 대한 이해도도 높아지고
- 배움이 더 빨라지고
- 더 어려운 문제를 해결할 가능성이 높아짐
- 100개의 일이 있다고 치면, 95개 정도는 누구나 해결할 수 있고 (누구나 할 수 있고) 나머지 5개를 해결하는 사람은 드물다. 여기서 5개를 해결할 수 있는 사람이 고급인력이 된다.
- CS ( 알고리즘, 자료구조, 네트워크, 운영체제, … )
- 10명이서 어떤 프로젝트에 투입했다.
- 한 50%정도 완성되었는데
- 갑자기 5명이 끼어들었을 때, 얼마나 더 빠르게 프로젝트를 완성할 수 있을까?
- 10명에서 15명이 되었으니 1.5배 더 빨라질까?
- 느려질수도 있다 → 5명을 가르쳐야되니까
- 최소한 느려지진 않게 해야하고
- 프로젝트에 적응을 최대한 빨리 해야한다.
- 문서화
- 도메인 모델링을 잘 분석하자 ( DB, 설계 등 )
- 체크하는 사이클 ( 테스트 ) ( 스크럼 ) → 사이드 이펙트를 관리하자
- A라는 기능을 만들었는데, B에서 뭔가 문제가 생기네…? 알고보니까 C에서도 생기고 D에서도 생기네…? → 이걸 방지하려면 어떻게 해야 좋을까? → 테스트
- 코드리뷰
- 코드를 읽기 쉽게 작성하자
- 클린코드
- 코드리뷰
- 버전 관리 (git, github) 를 체계적으로 구성하자.
- git flow
- github flow
- …
- ci/cd → 10주차 - CI/CD 참고 ( 자동화 )
- Continuous Integration
- Continuous Delivery ( deploy )
- 자동화
- 사람이 하는 일을 기계에게 시킨다
- 일을 분업이 아니라 협업을 하자
- 분업은, 다른 일을 나눠서 하는 것
- 협업은, 같은 일을 같이 하는 것
- 분업 + 협업을 같이 할 수 있는 방법

“개발의 목적”
- 단순하게 기술을 익히는게 아니라, 이 기술이 왜 등장 했는지, 어떤 효용성이 있는지 등을 이해하고 공부하자.
- 보통 개발 지식들은 “비용을 줄이는 것”에 초점이 맞춰져 있다.
CSR(Client Side Rendering)
네이버 / 카카오톡 / 라인 / 토스 / 배달의민족 / 당근마켓
→ 여기에 프론트엔드 개발자들이 굉장히 많다
→ 그런데 여기서 무슨 일을 하고 있을까?
→ 웹뷰를 만든다.
→ 근데 왜 하필 웹뷰일까? 네이티브 앱으로만 만들면 비용 2배, 문제가 발생했을 때 즉각 대응 X, 업데이트 어려움
카카오톡 → iOS 개발자 2명, Android 개발자 2명 → 기능이 계속 추가 → iOS 개발자 10명, Android 개발자 10명 → 웹 서비스도 만들고싶어 → 웹 개발자 추가 고용
…
생각해보니까 그냥 웹 뷰로 보여주면 비용을 훨씬 줄일 수 있지 않을까?
iOS 개발자 1명
Android 개발자 1명
웹 개발자(Front) 10명
- 웹이라는 프로그램(클라이언트)이 발전이 해야 가능
- javascript로 만든 UI가 네이티브를 대체할 정도로는 따라와줘야 된다.
- 브라우저 발전
- 방법론, javascript로 만드는 어플리케이션의 형태가 발전 ( CSR )
- 복잡한 화면을 구성하고, 유지하기가 훨씬 수월하다. (SSR에 비해서)
훨씬 더 많은 일을 훨씬 더 빠르게 할 수 있다.
2. 몰입 하는 환경과 상황
- bottom-up 으로 공부하는 사람 (본인)
- 일단 공부를 한다.
- 일단 꾸준히 한다.
- 그것들이 쌓여서 뭔가가 된다.
- 보통 이런 사람들은 삼천포로 잘 빠진다.
- python, php, java, mysql, mssql, oracle, javascript, …
- 그러다가 아! 이러면 안되겠구나 → javascript를 깊게 파자.
- top-down 으로 공부하는 사람
- 목적을 가지고 공부를 한다.
- 공부에 대한 계획이 있다.
- 체계적으로 공부한다.
- 보통 이런 사람들은 공부해야할게 너무 많을 때 혼란을 느낀다. ( 저걸도 해야돼 말아야돼? 같은 고민 )
- 유의미한 무언가를 만들 때 몰입을 하는 사람
- 재밌는 서비스를 만들어야지!
- 지식을 활용할 때 몰입을 하는 사람
- react를 활용해야지!
- 서적으로 공부하는 사람
- 인강으로 공부하는 사람
- 서적과 인강 둘 다 안 보는 사람 → 본인
- 기타 등등
내가 몰입하는 환경이나 상황을 알아야한다. 다른 사람의 피드백을 무조건 수용하기보단, 나에게 맞게 적절하게 흡수하면 더 좋다. ( 제가… 겪고 있습니다…. 무차별 수용 놉! )
3. 우리가 잘하고 있는 것
- 의자에 오래 앉아있는 중이다.
- 공부는 엉덩이로 한다.
- 일단 디스코드에 들어온다 👍👍👍
- 스크럼 매일 하고 있다.
- 아이스브레이킹
- 과제 - 현재 상태 - 뭔가 잘 안 풀린다거나 → 아직은 부족한 것 같다.
- 스크럼의 목적 → 1순위는 친해지는 것, 2순위는 이슈공유 ( 팀원을 잘 활용하자 ) → 인지하고 해보자.
- 돌아가면서 한 가지씩 이야기해보기
- 혜성님: 팀원들이 잘 챙겨준다. 신경써주셔서 감사합니다 🙏
- 지성님: 친화적인 분위기로 만들어진 것. 오프라인으로 첫 번째로 만났다. 아이스브레이킹 실천!
- 지현님: 힘든 팀원이 있으면, 도움이 필요하면 다가와준다.
- 찬욱님: 이 팀이 두 달 동안 이어진다고 생각을 하고, 천천히 친해지면 나중에 아쉬워지고, 빠르게 친해지기 위해선 무엇을 해야 될까 생각을 해봤다 (처음부터!). 그러기 위해서는 한 명이 나서야하고, 기분이 안 나빠지는 선에서 컨트롤을 할 수 있도록 노력했는데 거기에 잘 호응 해주셨다. 어쩌다보니 오랫동안 디스코드에 상주하면서 간간이 대화를 나누는 중. 강제로 소프트 스킬을 키우는 중.
- 세진님: 제일 좋았던 점은 모르는 부분이 있을 때 편하게 이야기 나누는 것. 팀원을 잘 활용 중.
4. 성장
본문 발췌
가장 큰 것은 개인의 커리어 성장과 학습이 팀과 회사의 성과에 기여할 수 있어야 한다는 것입니다. 스타트업 에도 있고 대기업에도 있는 빌런 중 한 유형은 바로 ‘회사와 조직의 성과와는 상관없이 나만 잘 되면 돼.’ 라는 마인드를 가지고 있습니다. 그들의 특징은 ‘회사나 팀이 잘 되건 안 되건 상관없이 자신에게만 피해가 오지 않으면 된다.’ 라는 것이죠. 그런데 우리가 비즈니스를 하는 동안 중요하게 여겨야 할 것은 ‘조직의 성과로 연결되지 않는 개인의 성장은 무의미 하다.’ 는 것입니다. 이유는 내가 다른 조직에서 일을 할 때도 이전 조직에서의 성과 기여가 가장 중요한 레퍼런스가 되기 때문입니다.
두번째로 고민해야 할 것은 ‘혼자서 성장하는 시대는 끝났다.’는 것을 인정하는 것이죠. 제가 성장하던 시대에는 학교와 학원에서 공부하고, 집이나 도서관에서 문제집을 풀며 공부하는 것이 학습의 전부였습니다. 하지만 지금은 혼자서 새롭게 찾아지는 다양한 지식과 경험을 학습할 수는 없는 시대입니다. 너무 빠르게 쌓여가고 있거든요. 그래서 저는 아래 5가지 원칙을 성장과 성공을 위한 방법으로 사용하시길 추천 드리고요.
1) 조직의 목표와 얼라인 하라
내가 하고 있는 일이 팀과 회사의 어디에 기여하는지를 스스로 설명할 수 있어야 합니다. 그리고 내가 만들어 내는 결과물들이 조직의 성과에 어떤 기여를 하는지도 설명할 수 있어야 하죠. 이제는 내 일을 브랜딩하는 시대이거든요.
2) 나의 리더가 나를 서포터 할 수 있게 하라
과거에는 리더가 구성원을 매니징 했지만, 이제는 구성원이 자신의 리더를 매니징할 수 있어야 합니다. 내가 하고 있는 일과 그 기여, 진척도와 장애물을 정기적으로 공유하고, 지원 요청을 받을 수 있는 것들을 찾아 도움을 받아야 하는 것이죠. 리더 또한 구성원이 관리해야 하는 자원이 되는 것입니다. 이때 가장 중요한 방법은 1 ON 1 입니다. 정기적으로 리더와 1 ON 1을 할 수 있는 구조가 된다면 가장 큰 성장은 바로 구성원이 된다는 것을 기억해 주셨으면 좋겠네요.
3) 자신의 문제를 동료들에게 공유하라
과업을 수행하면서 아무런 어려움이 없다면 그것은 내가 성장할 수 있는 과업이 아니라는 의미입니다. 내가 성장하기 위해서는 어려운 과업, 처음 맡아보는 과업, 복잡한 과업들을 정기적으로 수행해 봐야 합니다. 그리고 이때는 내가 가진 지식과 경험으로 문제를 해결할 수 없는 시점이 되겠죠. 이때 내 문제, 내가 모르는 것, 내 장애물을 동료에게 공유해 보세요. 그럼 그들이 가진 지식과 경험을 통해 내 문제를 해결할 수 있게 될 것입니다.
4) 자신의 지식을 공유하고, 다른 사람들의 지식을 공유 받을 수 있는 커뮤니티를 구성하라
내가 다른 사람들에게 지식과 경험을 공유 받기 위해서는 내가 먼저 내가 가진 지식과 경험을 공유할 수 있어야 합니다. 회사 안과 밖에서 편하게 지식과 경험을 공유하고, 학습할 수 있는 커뮤니티를 만들어 보세요. 실제 저는 HRD, 코치 그리고 스타트업 HR 커뮤니티 등을 통해 필요한 정보를 구하고, 공유하고 있거든요.
5) 다른 관점을 공유해 줄 수 있는 멘토와 코치를 둬라
마지막은 나의 성장과 내 고민을 함께 해주는 외부의 멘토와 코치가 있어야 한다는 것입니다. 외부가 꼭 회사 밖을 의미하지는 않습니다. 하지만, 나와 함께 일하는 팀이 아닌 그 외부의 멘토와 코치가 있다면 조금은 다른 관점을 공유 받을 수 있거든요. 그 과정에서 내가 몰랐던 것들을 알게 되기 때문에 추천 드립니다.
기타
→ 잊혀진 그 레포..
5. QnA
Q. 기술블로그를 써보려고 하는데, 단순 기록용으로는 쓰기가 싫은 상태. 내가 이해하고 나만의 논리를 바탕으로 쓰고 싶어서 그렇게 써봤는데, 맞는 논리인지 확인하기가 쉽지 않다. 틀리더라도 나만의 논리를 전개하면서 쓰는게 좋은걸까?
A. 블로그는 논문은 아니다. 틀린 정보가 있으면, 고치면 된다. 단, 공개가 되어야 피드백을 받을 수 있기 때문에 틀리더라도 한 번 써보고 올려보고 피드백을 받고 수정하고 반영해보자. 너무 겁먹지 말기.
단순 기록용 → 스스로에게 도움을 주고 싶은 것. 타겟이 결국 내가 되는게 아닌가.
Q. 조금씩 알고리즘을 공부하고 있는데, 언어가 중요한가?
A.
javascript → 자료구조 제공을 안 함 → 조금 더 신경쓸게 많고 → 문제 해결 과정에 걸림돌이 될 수도 있다.
풀이하는 언어가 평가에 큰 영향을 주진 않는다.