203th online meetup, 2024-10-05

[jongfeel]

참여 방법

토요일 오전 10시 30분에 아래 google meet 링크를 통해 접속
https://meet.google.com/jyx-mxnq-kpk

이 이슈 assignees에 자신의 github 계정을 추가
약 1시간 30분 분량의 할 내용에 대해 댓글 작성 (최소 모임 시작 전까지)
구글 캘린더 일정 등록 메일 확인을 통해서도 가능 (일정 관리에 도움도 드립니다)
모임 시간에 각자 개발 관련된 공부 진행

• 시작: 10시 30분, 각자 오늘 진행할 것 이야기 5분 ~ 10분 간 진행
  • 자기소개: 새로 오신 분이 있으면 각자 짧은 자기소개가 진행됩니다
• 진행: 2시간, 하지만 쉬는 시간 및 기타 잡일 감안해서 1시간 30분 정도로 진행
• 완료: 12시 30분, 이후 각자 진행한 것 이야기, 12시 40분 전후로 종료.

모임 끝난 후 공부한 내용 정리 & 링크 추가 => 최소 다음 모각코 전까지 확인 가능해야 함.

주의: 회사일 혹은 마감 기한 임박한 일 처리의 경우는 최대한 자제해 주세요. 주말 아침에 일하면 우울하니까요. ㅜㅜ

[yeslee-v]

To do

• jenkins 배포 환경 설정 블로깅

[fkdl0048]

• 2장 인터넷 fkdl0048/BookReview#302

일정이 생겨서.. 다음에 참여하겠읍니다!

[ohdair]

할 일

개발자 원칙 1, 2장 독서

정리

정리 글

[!info] 박성철 저자
Sk 플래닛, 우아한형제들 등에 있었으며, 현재에는 컬리 풀필먼트 프로덕트 본부장
지금까지 40년 가량 컴퓨터를 매개로 탐험
소프트웨어 개발에 대한 인식 및 개발 현장을 개선에 관심이 많음
블로그 링크

프로그래머로 살기로 선택했을 때 결심한 쓸모 있는 일을 하자 라는 원칙을 선택 기준으로 삼았고 이 원칙을 달성할 방법을 모색했습니다. 이 글에서 그 여정을 정리해보았습니다.

p. 55

첫 직장에서 많은 것을 배웠습니다.
오랫동안 컴퓨터를 끼고 살았고, 대학에서 전공 외로 전산과 수업도 듣고 독학도 했기에 자신감이 매우 넘치던 때였습니다. 더닝 크루거 효과¹의 대표적인 예였던 것이죠.

무엇보다 프로그래머라고 해서 프로그래밍만 잘하면 되는 것이 아니라는 것을 알게 되었습니다. 여러 사람에게 설명도 할 줄 알고 협상도 하고 계획도 세울 줄 알아야 하고 무엇보다 진행 중에 닥치게 되는 난관을 해치고 목표를 달성하며 이를 위해 여러 결정도 스스로 내릴 수 있어야 한다는 것도 배웠습니다.

p. 59

가트너 신흥 기술 하이프 사이클을 보면 다수의 기술이 환멸의 깊은 계곡에서 빠져나오지 못하고 사라집니다.
그 당시 기술들이 표방한 꿈은 컸지만, 현실은 아직 시간이 필요했습니다.

선행 기술 자체가 의미가 없다는 뜻은 아닙니다. 기술이 발전하려면 이런 시도는 계속되어야 하고 투자도 이루어져야 합니다. 그런 면에서 과잉 기대가 긍정적인 효과를 낼 수 있습니다. 다만 그런 경향에서 편승해 돈만 보고 따라다니는 사람들을 많이 보았고 그 삶에서 벗어나고 싶었습니다.

p. 62

동기부여 방법이 필요하다고 느껴서 여러 책을 읽었는데, 한책에서 사람은 저마다 자기만의 동기를 가지고 살고 있고 외부에서 부여하거나 제어할 수 없다 라는 문구로 중요한 교훈을 얻었습니다.

그때 이후로 저는 저 자신을 포함해서 저와 같이 일하는 사람들을 수동적인 대상으로서가 아닌 주체로서 바라보게 되었습니다.

p. 64

동기를 관리할 때 신경써야 하는 것은 에너지입니다. 사람은 에너지에 따라 다르게 판단하고 행동합니다.
동기는 단순히 있고 없고 하는 것이 아닌 크기가 있는 양입니다.

에너지 관리는 단순히 에너지를 소진하지 않으려고 걱정하며 조심하는 소극적인 방식이 아닌 회복 탄력성을 키우고 에너지 그릇을 키우는 적극적인 방식이 좋습니다.

p.65

피터 드러커의 프로페셔널의 조건 이라는 책에서 많은 내용을 다루지만 성과를 내는 주체로서 이를 위해 노력해야 하고 목표에 집중할 수 있어야 한다는 점에서 큰 감명을 받았습니다. 무엇보다 개인이 스스로 목표를 설정하고 이 목표를 달성하려면 자신을 경영해야 한다는 가르침을 깊이 받아들였습니다.

[!note] 피터 드러커는 이렇게 말했다.
전문 지식은 과업과 연결되어야만 생산적인 것일 수 있고 조직은 끊임없이 자기 혁신을 추구하며 불안전해야 한다. 지식 근로자는 스스로 성과의 방향을 설정해야 하기 때문에, 자신에게 어떤 성과가 기대되고 있는지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안 된다.

이때부터 동기를 스칼라가 아닌 벡터로 생각하기 시작했습니다.
나에게 기대된 성과와 직교 방향의 성과를 냈다면 그 성과가 아무리 큰 것이라도 인정받을 수 있는 성과는 아무것도 없습니다. 심지어 마이너스 성과를 낼 수도 있는 겁니다.

p. 68

가트너의 기술 성숙도 모델인 기술 수용 생애 주기 라는 모델이 있습니다.
초기 확산 단계를 기대치 관점에서 표현한 것을 가트너의 하이프 사이클이라고 흔하는 말합니다.

선각 수용자에서 전기 다수로 넘어가지 못하는 기술이 많다고 말하고 이를 좁고 싶은 협곡이란 의미의 캐즘이라고 부릅니다. 캐즘을 못넘고 사라질 수 있는 기술을 실무에서 사용하지 않기로 했습니다. 새 기술을 맛보거나 학습하기는 해도 실무로 사용할 때는 엄격하게 이 기준을 적용합니다.

p. 72

본질상 소프트웨어는 팀 작업입니다. 많은 회사가 단위 조직을 팀이라고 부르지만 사실 팀워크가 올바로 동작하는 팀은 많지 않습니다. 좋은 분위기도 중요하지만 팀워크는 그 이상입니다. 1+1이 2 이상이 되도록 만드는 것이 팀워크입니다.

팀워크가 좋은 팀은 의미 있는 성과를 지속적으로 내며 늘 더 높은 목표에 도전합니다. 공동의 목표를 위해 협력할 줄 알고, 서로 배우고 가르치며, 개인과 팀 모두 성장합니다.

p. 74

개발자를 양성하는 교육 과정과 개발이라는 행위는 여전히 흑마법 같습니다.
애초에 개발자가 누구인지 분명하게 말하지도 못하는 거 같습니다.

스티브 맥코넬은 우리 업계에서 주기적으로 골드 러시가 일어난다고 말합니다. 이런 호황기에는 그냥 아무렇게나 일을 해도 돈을 벌 수 있습니다. 하지만 골드 러시가 끝나고 나면, 그래서 진짜 실력으로 평가되고 경쟁해야 하는 때가 오면 엔지니어링 전문성이 중요해질 것이라고 말합니다.

저는 그의 책에서 말하는 형태의 전문 소프트웨어 개발이 정답이라고 생각하지는 않습니다. 하지만 그의 전망대로 언젠가는 호황기가 끝나고 진짜 실력으로 만들어내는 성과에 따라서 평가되는 때가 올 것입니다.

p.76

출간 후 2년, 원칙이 변화되었기 보다는 새로운 환경에 또 어떻게 적용되는지 지켜볼 문제입니다.
한 발짝 멀리서 바라보면 재미있게도 컴퓨터는 처음부터 생각하는 기계 로 만들어졌습니다.

단순하게 어떤 일을 자동으로 반복하는 기계가 아닌, 생각하는 기계로서 컴퓨터를 활용하라는 뜻입니다. 단순히 프로그래밍 언어와 API를 익힐 뿐 아니라 자료구조나 알고리즘 같은 문제 해결법을 알아야 하는 이유입니다.

이런 관점에서 기계학습이나 신경망 기반 기술의 발전은 좋은 기회입니다.
운영 시스템에는 디지털화, 자동화, 최적화, 지능화, 자율화라는 다섯 가지 성숙도가 있다고 생각합니다. 작업의 상당수가 시스템에 의해서 처리되고 사람은 특이상황만 대처하면 됩니다.

적지 않은 사람이 AI 기술의 발달로 개발자 입지가 줄어들 것이라고 말합니다.
이런 전망은 1960년대에도 있었습니다. 개발자는 다 정해진 무엇을 단순히 코드로 바꾸어 표현하는 사람이 아닙니다. 개발자가 하는 일이 단순한 작업이 맞다고 쉽게 대체되겠지만 하는 일은 그렇게 정형화되기 어렵습니다.

[!note] 원칙 준수에 도움이 되는 정보

• 드라이브
• 티크니컬 리더
• 프로페셔널의 조건
• 성공하는 사람들의 7가지 습관
• 만화로 보는 댄 애리얼리 최고의 선택

Footnotes

1. 자신의 능력이나 지식을 실제보다 과대평가하거나 과소평가하는 인지 편향, 자신이 무엇을 모르는지 조차 모르는 상태에서 오는 자신감의 문제를 지적합니다. 간단히 말해, 모를수록 오히려 더 자신만만해진다 라는 현상 ↩

[aquamagic9]

할 일

개발자로 살아남기 part2 83p~111p 읽고 정리
노션 링크

[nonoaa]

할 일

A Tour of C++ 1~2장 읽기

한 일

읽은 내용 정리
https://github.com/nonoaa/books/tree/main/A%20Tour%20of%20C%2B%2B

[chichoon]

할 일

자바스크립트 딥다이브 17장 읽고 정리

12시 10분쯤 먼저,, 나가보겠습니다 🤤

한 일

• Object 생성자함수

  • new Object() 로 빈객체를 추가할 수 있다
  • 여기에 프로퍼티, 메서드 추가
  • 객체리터럴이 더 편함. 굳이?

• 생성자 함수를 사용해서 객체 만들기

  • 객체리터럴의 단점: 동일한 프로퍼티를 갖는 객체를 여러개 생성하고 싶을 때 매번 프로퍼티를 기술해야 해서 비효울적임
  • 이럴때 생성자함수를 하나 만들어서 사용하면 좋다
  • 생성자 함수 내부에서 this 는 생성할 인스턴스를 가리킨다
  • 따라서 this 를 통해 프로퍼티 넣어줄 수 있음
  • 참고로 생성자함수를 일반함수나 메서드로 호출할 경우 this 가 가리키는 값이 달라지므로 주의
  • new 함수명() 을 통해 생성자 함수로서 호출할 수 있다 (엔진에서 암묵적으로 처리)
    • 생성자 함수로서 호출하게 되면, 내부에서 빈 객체를 추가하고 this 를 해당 빈 객체에 바인딩
    • 이후 추가되는 프로퍼티가 빈 객체에 들어가도록 함 (인스턴스가 초기화됨)
    • 초기화가 완료되면 이때 만들어진 빈객체 (this에 바인딩된 그것) 가 반환된다
    • 만약 객체 return문이 함수 마지막에 따로 작성되었을 경우, this 를 반환하지 않고 해당 리턴문을 따른다
    • 원시값을 반환하는 return 문일 경우 이를 무시하고 this 를 반환한다

• 내부 메서드 Call

  • 함수가 일반 함수로서 호출될 경우 Call 메서드가 호출된다
  • 내부 메서드 Call 을 가진 함수를 Callable 함수라고 함
  • 모든 함수객체는 Callable 하다

• 내부 메서드 Construct

  • 함수가 생성자 함수로서 호출될 경우 Construct 메서드가 호출된다
  • Construct 메서드를 가진 함수를 Constructor 라고 함
  • 반대로 Construct 메서드가 없을 경우 non-Constructor 라고 함

• Constructor 와 non-Constructor 의 차이

  • 메서드와 화살표함수는 non-constructor 이다
  • 이때 말하는 메서드는 ES6 사양에서의 축약표현을 의미 (x() {})
  • non-constructor 함수를 강제로 new 붙여서 호출하면 오류가 난다
  • 생성자로 구현하지 않은 일반 함수 (non-constructor 가 아닌 경우 전부) 를 new 븥여서 호출하면 강제로 생성자 함수로 동작한다
  • 그외 외견상 차이점은 없어서 왠만하면 생성자함수는 파스칼케이스, 일반함수는 카멜케이스로 작명하여 구분한다

• new 연산자

  • 함수 내부의 Constructor 메서드를 호출하는 역할
  • non-constructor 일 경우 오류발생
  • new 없이 함수를 호출하면 Constructor 메서드 대신 Call 메서드가 호출되며 일반함수로 동작

• new.target

  • 이 함수가 생성자 함수로서 호출되었는지 여부를 판별할 수 있다
  • 반환값이 undefined 이면 생성자 함수가 아니라는 것

[jongfeel]

도메인 주도 설계 읽고 정리하기

• 14장 모델의 무결성 유지 jongfeel/BookReview#896
  • SEPARATE WAYS(각자의 길) jongfeel/BookReview#941
  • OPEN HOST SERVICE(공개 호스트 서비스) jongfeel/BookReview#942
  • PUBLISHED LANGUAGE(공표된 언어) jongfeel/BookReview#943

14장 모델의 무결성 유지
SEPARATE WAYS(각자의 길)
OPEN HOST SERVICE(공개 호스트 서비스)
PUBLISHED LANGUAGE(공표된 언어)
부분 읽고 정리