186th online meetup, 2024-06-08

[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]

할 일

• 리눅스 마스터 2급 2차 기출 요약 정리 1독
• 이동 중에 참여할거라 채팅으로 이야기하겠습니다.

[ohdair]

할 일

• "구글 엔지니어는 이렇게 일한다" 1장 및 2장 독서

1장 소프트웨어 엔지니어링이란?

프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이는 세 가지로 `시간`, `확장`, `트레이드오프`입니다.

소프트웨어 엔지니어링 프로젝트에서 엔지니어는 이렇게 행동해야 합니다.
시간의 흐름과 언젠가 변경될 가능성에 더 신경 써야 합니다. 또한, 확장과 효율에 더 집중해야 합니다.
결과에 더 큰 영향을 주는 보다 복잡한 결정을 내려야 합니다.

시간

시간이라는 요소가 더해지면서 프로그래밍에는 중요한 차원이 하나 늘어서 더 입체적으로 바뀝니다.
위에서 말한 부분에서 소프트웨어의 지속 가능성이 핵심입니다.

현재 상태를 안정되게 유지(지속 가능)할 수 있도록 변경들의 영향을 계획하고 관리해야 합니다.
작성한 코드는 유지보수 수명. 즉, 코드가 언제까지 개발 구동, 유지보수 될 것인지, 혹은 가치가 언제까지 유용할지 생각해야 합니다.

하이럼의 법칙은 공표한 계약이나 모법 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한 말입니다.
API 사용자가 명세에는 없는 기능을 찾아 활용하기도 하며, 그 기능이 유용해 널리 쓰이면 추후 변경하지 어렵게 됩니다.

기발한이 칭찬으로 느껴진다면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라 말합니다.
모범 사례를 따르고 미래에 대비한 코드는 클린하고 유지보수 가능한 코드입니다.

프로젝트가 의존하는 모든 기술에는 사용하기 시작한 후에야 발견될 심각한 버그와 보안 구멍이 존재할 위험이 도사립니다.
소프트웨어 설계도 제때 변경해주지 않으면 최신 하드웨어를 도입하는 효과가 퇴색되기도 합니다.

언젠가는 바뀌어야 한다면 변경 시 비용이 적게 들도록 하는데 미리 투자할지도 고민해야 합니다.

확장

협업은 그 자체로 새로운 문제를 유발하지만, 한 명이 개발하는 것보다 가치 있는 시스템을 만들어낼 잠재력 또한 지닙니다.
프로젝트의 팀 조직, 프로젝트 구성, 정책과 관례는 소프트웨어 엔지니어링의 복잡성을 좌우합니다.

확장될 수록 생산 효율적인지, 비용이 증가되는지 성장도 맞춰서 개선되는지를 논의 해야 합니다.

소프트웨어 자체는 연산, 메모리, 스토리지, 대역폭 같은 전통적인 자원을 더 추가할수록 비례하여 속도나 처리량이 확장되어야 합니다.
코드베이스 자체도 확장 가능해야 합니다.
코드가 많아지고 변경 이력이 쌓이는 등의 이유로 빌드 시스템이나 버전 관리 시스템이 점점 느려진다면 더는 정상 운영할 수 없는 시점이 옵니다.

코드베이스의 유연성을 주는 여러 요인이 있습니다.

• 전문성: 여러 방법에 대한 충분한 지식
• 안전성: 규칙적으로 릴리스하여 릴리스 사이의 변경량을 줄이기
• 순응: 규칙적인 업그레이드
• 익숙함: 정기적인 업그레이드를 수행하기 위해 중복되는 작업을 찾고 자동화하려고 노력
• 정책: 비욘세 규칙¹ 과 같은 정책과 절차로 미지의 사용 방법까지 걱정할 필요없이 업그레이드 진행

트레이드오프

불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야만 합니다.
지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로의 규모를 확장하는 비용을 관리해야 합니다.
사실을 주지하고 트레이드 오프를 평가하여 합리적인 결정을 해야 합니다.

비용은 금액만을 지칭하는 게 아니라 투입된 리소스, 인적, 거래, 기회 등의 요소들까지 포함됩니다.
조직 내 구성원들의 스스로 행복을 느끼게 만들고 일에 집중하고 참여할 수 있게 해주면 생산성에 영향을 미치게 됩니다.

엔지니어링 조직의 선택을 결정짓는 요인에서 '내가 시켰으니까'는 되어서 안 됩니다.

• 반드시 해야 하는 일(법적 요구사항, 고객 요구사항)
• 근거에 기반하여 당시 내릴 수 있는 최선의 선택(적절한 결정권자가 확정)

태만한 프로그래머를 위한 최고의 합법적인 핑계: "컴파일 중이에요"

컴파일의 시간이 길어지게 되면서 일할 시간이 줄어들어 우회적으로 인건비를 상승시키는 효과가 발생합니다.
구글은 자체 분산 빌드 시스템을 개발하여 생산성을 크게 올렸지만, 시간이 흐르면서 불필요한 의존성이 커져 문제가 발생합니다.

효율이 좋아지면 자원 소비가 늘어난다 - Jevons Paradox

데이터에 기초한 의사결정을 하더라도 시간이 지나면 변하고 새로운 데이터가 나타날 수 있습니다.
과거에 내린 결정도 수시로 재고해봐야 합니다.
근거에 기초해 결정하되 측정할 수 없는 요인들에도 가치가 있을 수 있음을 명시해야 합니다.

프로그래밍 vs 소프트웨어 엔지니어링

시간 흐름에 따른 코드 관리, 시간 흐름에 따른 규모 확장의 영향, 이런 관점에서의 의사 결정방식에 있습니다.
프로그래밍은 코드를 생산하는 즉각적인 행위입니다.
소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례, 모두 모두를 아우르는 종합적인 개념입니다.

Footnotes

1. 인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라도, 같은 문제가 지속적 통합^CI 시스템의 자동 테스트에서 발견되지 않는다면 인프라 팀의 책임이 아니다 ↩

[chichoon]

할 일

• React 프로젝트 Grid 컴포넌트 개선하기, 페이지 2개 정도 추가

Jun-08-2024.12-38-08.mp4

[jongfeel]

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

• 10장 유연한 설계 jongfeel/BookReview#743

CONCEPTUAL CONTOUR
STANDALONE CLASS
두 부분 읽고 정리

---

지난 주에 돌발 상황이 너무 많아서 많이 진행을 못했습니다.
오늘은 모각코 시간 이외의 시간을 내서라도 진행을 할 예정입니다.

돌발 상황

• 딸 미술학원 등하원
• 딸 발레 수업 등하원
• 딸 보드게임 하자는 거 달래주기 등