Hertlity seeks to provide more personalized testing and services, including diagnostics and egg freezing to women through their reproductive journeys.

Emma Watson invests in reproductive health company Hertility | TechCrunch

엠마 왓슨이 또 한명의 셀럽 투자자가 됐네요. 엠마 왓슨은 여성 건강 및 생산성 스타트업 허틀리티(Hertility)에 투자했는데요. 허틀리티의 공동창업자이자 CEO인 헬렌 오닐 박사는 투자자 중 한 명을 통해 엠마 왓슨을 만났고, 평소에 환경에 대한 관심과 여성이 주도하는 이니셔티브를 지원하는 여배우로서 투자자로 적합하다는 생각을 했다고 합니다. 

허틀리티는 여성 중심의 생식 진단 검사, 난자 냉동, 원격 진료를 포함해 개인화된 서비스를 제공하는, 런던 기반 여성 건강 스타트업입니다. 헬렌 오닐 박사는 "영국에서 60만 명 이상의 여성이 산부인과 진료를 기다리고 있습니다"라며, 딜로이트에 따르면 직장을 가진 여성의 자기부담 의료비가 남성보다 150억 달러 더 많은 것으로 나타났으며 평균적인 남성조차도 연간 1,000파운드 이상을 지출하고 있어 생식 건강이 전반적인 가족 계획과 지출에 큰 영향을 미친다고 합니다.  헬렌 오닐 박사는 허틀리티가 앞으로 "가능한 한 많은 여성이 호르몬과 생식 능력에 대해 이야기하고, 그들이 있는 곳에서 만나 전 세계적으로 행동을 바꾸는 것이 전부입니다”라고 이야기했습니다. 
https://techcrunch.com/2024/10/07/emma-watson-invests-in-reproductive-health-company-hertility/

엠마 왓슨이 또 한명의 셀럽 투자자가 됐네요. 엠마 왓슨은 여성 건강 및 생산성 스타트업 허틀리티(Hertility)에 투자했는데요. 허틀리티의 공동창업자이자 CEO인 헬렌 오닐 박사는 투자자 중 한 명을 통해 엠마 왓슨을 만났고, 평소에 환경에 대한 관심과 여성이 주도하는 이니셔티브를 지원하는 여배우로서 투자자로 적합하다는 생각을 했다고 합니다.&nbsp; 허틀리티는 여성 중심의 생식 진단 검사, 난자 냉동, 원격 진료를 포함해 개인화된 서비스를 제공하는, 런던 기반 여성 건강 스타트업입니다. 헬렌 오닐 박사는 "영국에서 60만 명 이상의 여성이 산부인과 진료를 기다리고 있습니다"라며, 딜로이트에 따르면 직장을 가진 여성의 자기부담 의료비가 남성보다 150억 달러 더 많은 것으로 나타났으며 평균적인 남성조차도 연간 1,000파운드 이상을 지출하고 있어 생식 건강이 전반적인 가족 계획과 지출에 큰 영향을 미친다고 합니다.&nbsp; 헬렌 오닐 박사는 허틀리티가 앞으로 "가능한 한 많은 여성이 호르몬과 생식 능력에 대해 이야기하고, 그들이 있는 곳에서 만나 전 세계적으로 행동을 바꾸는 것이 전부입니다”라고 이야기했습니다.&nbsp;https://techcrunch.com/2024/10/07/emma-watson-invests-in-reproductive-health-company-hertility/

TechCrunch

코틀린에서 웹소켓에 액터모델을 연결시켜  분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다.

 * more : https://wiki.webnori.com/x/dYGZBQ

코틀린에서 웹소켓에 액터모델을 연결시켜&nbsp; 분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다. <ul ><li>more : https://wiki.webnori.com/x/dYGZBQ</li></ul>

코틀린에서 웹소켓을 우아하게 사용하기

My thoughts on license choices for balancing business interests and Open Source software and why the FSL is a better choice than the AGPL.

FSL: A Better Business/Open Source Balance Than AGPL

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다.

Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다.

이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다.

이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다.

AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다.

라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다.

https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다. Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다. 이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다. 이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다. AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다. 라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다. https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Armin Ronacher's Thoughts and Writings

Zahan Malkani shares how they built a microblogging service to compete with Twitter with a small team that shipped a new social network in a few months.

0 → 1, Shipping Threads in 5 Months 

https://www.infoq.com/presentations/threads-meta/

메타 엔지니어인 Zahan Malkani가 쓰레드 출시에 대해 설명해준 글을 봐서 공유해보아요
 * 사람들이 Twitter를 포기하고 어울릴 다른 곳을 찾고 있었는데, 이걸 기회로 보고 시작함
 * 빠른 출시를 위해 인스타그램 재활용 : 기존 코드를 재사용 후 기술 부채 해결하는 전략을 사용
 * 페이스북이 아닌 인스타그램을 사용한 이유 : 인스타그램은 팔로우 그래프에서 시작되었고, 인스타나 페이스북을 선택할 수 있었는데 인스타그램이 더 잘 맞았다고 생각해서
 * 기술적인 이야기
   * 사용자 데이터는 다양한 시스템에 저장
   * TAO : 메타에서 개발한 분산 데이터베이스, 그래프 구조의 데이터를 처리
   * UDB : MySQL 기반 DB
   * Haskell : 어뷰징 체크와 관련된 작업은 하스켈 사용
   * ZippyDB : Key Value 스토어
 * App Store의 preorder 기능을 사용했는데, 국가별로 타임존이 달라서 배포일 전에 앱을 다운로드하고 로그인을 시도했음. 글로벌 서비스는 배포할 때 타임존을 항상 고려하는 것이 필요
 * 엔지니어링 팀의 규모 : 1월엔 5~10명, 중반엔 25~30명. 출시 당시엔 30~40명. 50명 이하로 유지되었고, 기여한 엔지니어는 100명 정도
 * 쓰레드는 인스타그램, 페이스북보다 웹으로 나가는 아웃바운드 링크가 많음
그 외에도 흥미로운 내용이 있으니 글 한번 보셔도 좋을 것 같네요

https://www.infoq.com/presentations/threads-meta/ 메타 엔지니어인 Zahan Malkani가 쓰레드 출시에 대해 설명해준 글을 봐서 공유해보아요<ul ><li>사람들이 Twitter를 포기하고 어울릴 다른 곳을 찾고 있었는데, 이걸 기회로 보고 시작함</li><li>빠른 출시를 위해 인스타그램 재활용 : 기존 코드를 재사용 후 기술 부채 해결하는 전략을 사용</li><li>페이스북이 아닌 인스타그램을 사용한 이유 : 인스타그램은 팔로우 그래프에서 시작되었고, 인스타나 페이스북을 선택할 수 있었는데 인스타그램이 더 잘 맞았다고 생각해서</li><li>기술적인 이야기<ul ><li>사용자 데이터는 다양한 시스템에 저장</li><li>TAO : 메타에서 개발한 분산 데이터베이스, 그래프 구조의 데이터를 처리</li><li>UDB : MySQL 기반 DB</li><li>Haskell : 어뷰징 체크와 관련된 작업은 하스켈 사용</li><li>ZippyDB : Key Value 스토어</li></ul></li><li>App Store의 preorder 기능을 사용했는데, 국가별로 타임존이 달라서 배포일 전에 앱을 다운로드하고 로그인을 시도했음. 글로벌 서비스는 배포할 때 타임존을 항상 고려하는 것이 필요</li></ul><ul ><li>엔지니어링 팀의 규모 : 1월엔 5~10명, 중반엔 25~30명. 출시 당시엔 30~40명. 50명 이하로 유지되었고, 기여한 엔지니어는 100명 정도</li><li>쓰레드는 인스타그램, 페이스북보다 웹으로 나가는 아웃바운드 링크가 많음</li></ul>그 외에도 흥미로운 내용이 있으니 글 한번 보셔도 좋을 것 같네요

InfoQ

쓰레드 출시 과정에 대한 생생한 후기

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다. 

테스트 프로세스
테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다. 
테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다. 

테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.
테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다. 

테스트 프로세스: 세부 단계별 활동의 정의와 수행방법
테스트 계획
테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다. 

①테스트 수행 계획은 테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.
② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.
③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.
  ▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정 
  ▶ 테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정
  ▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등
고려
④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다. 
▶ 테스트 시작 기준 
Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.
  ▶ 테스트 완료 기준 
제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가
테스트 일정을 조율합니다.
품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단
결과 오픈 가능 여부를 전달합니다.

[테스트 완료 기준 예시]
1. 계획된 품질 보증 활동을 모두 완료
2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함
3. Major 이상 잔존 결함 없음
4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함
5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련
6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 & 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의

⑤ 테스트 수행 환경 구성 및 구현
테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다. 테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다. 

[테스트 환경 예시]
▶ Dev : 개발 환경
▶ QA : QA 테스트 환경
▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)
▶ 각각의 환경과 연동된 테스트 빌드 

⑥ 테스트 수행 역할 선정
⑦ 테스트 단계별 산출물 정의
⑧ 계획된 테스트 전략을 바탕으로 QA Plan 작성 
QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다.

테스트 설계
테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다. 

테스트 케이스를 작성하기 위해 먼저 ①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다.

테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로 ②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다. 

테스트 케이스 작성이 완료되면 테스트 수행을 위한 ③테스트 데이터 및 테스트 도구를 준비합니다.  기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다.

테스트 구현과 실행
①테스트 구현은 선별한 테스트 케이스에 맞게 자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고 코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.
②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다. 

테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다. 등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다.

테스트 수행이 완료되면 ④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다.

테스트 완료 및 평가
계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여 ①테스트 최종 결과 보고서를 작성합니다. 제품의 출시 가능 여부는 테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다. 

산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다. 첫째, 테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다. 둘째, 전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다. 

테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지 ②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다.

마지막으로 ③완료된 품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다. 테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의 참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는 테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다.

테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem 활동을 진행합니다. 회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은 기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다.&nbsp; 테스트 프로세스테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다.&nbsp;테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다.&nbsp; 테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다.&nbsp; 테스트 프로세스:&nbsp;세부 단계별 활동의 정의와 수행방법테스트 계획테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다.&nbsp; ①테스트 수행 계획은&nbsp;테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.&nbsp;&nbsp;▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정&nbsp;&nbsp;&nbsp;▶&nbsp;테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정&nbsp;&nbsp;▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등 고려④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다.&nbsp; ▶ 테스트&nbsp;시작 기준&nbsp; Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.&nbsp; ▶ 테스트&nbsp;완료 기준&nbsp; 제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가 테스트 일정을 조율합니다. 품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단 결과 오픈 가능 여부를 전달합니다. [테스트 완료 기준 예시] 1. 계획된 품질 보증 활동을 모두 완료2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함3. Major 이상 잔존 결함 없음4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 &amp; 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의 ⑤ 테스트 수행 환경 구성 및 구현 테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다.&nbsp;테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다.&nbsp; [테스트 환경 예시]▶ Dev : 개발 환경▶ QA : QA 테스트 환경▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)▶ 각각의 환경과 연동된 테스트 빌드&nbsp; ⑥ 테스트 수행 역할 선정⑦ 테스트 단계별 산출물 정의⑧&nbsp;계획된 테스트 전략을 바탕으로 QA Plan 작성&nbsp;QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다. 테스트 설계테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다.&nbsp; 테스트 케이스를 작성하기 위해 먼저&nbsp;①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다. 테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로&nbsp;②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다.&nbsp; 테스트 케이스 작성이 완료되면 테스트 수행을 위한&nbsp;③테스트 데이터 및 테스트 도구를 준비합니다. &nbsp;기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다. 테스트 구현과 실행①테스트 구현은&nbsp;선별한 테스트 케이스에 맞게&nbsp;자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고&nbsp;코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다.&nbsp; 테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다.&nbsp;등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다. 테스트 수행이 완료되면&nbsp;④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다. 테스트 완료 및 평가계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여&nbsp;①테스트 최종 결과 보고서를 작성합니다.&nbsp;제품의 출시 가능 여부는&nbsp;테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다.&nbsp; 산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다.&nbsp;첫째,&nbsp;테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다.&nbsp;둘째,&nbsp;전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다.&nbsp; 테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지&nbsp;②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다. 마지막으로 ③완료된&nbsp;품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다.&nbsp;테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의&nbsp;참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는&nbsp;테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다. 테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem&nbsp;활동을 진행합니다.&nbsp;회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은&nbsp;기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

[SW프로세스 III]협업 프로세스 내 테스트 활동

“네가 원하는 걸 만들지 말고 다른 사람들이 원하는 걸 만들어.”

스타트업 세계에서 자주 듣는 말입니다.
내가 만들고 싶은 걸 만들다가 써주는 사람이 없어서 망했다는 이야기.
바보 같고 우스워 보이지 않나요?

하지만… 남들 모두가 원하는 거 만들면 정말 잘 될 수 있을까?
그렇게 쉽지는 않을 겁니다.
거기엔 이미 경쟁자들이 우글우글 할텐데.
정말 그 경쟁자들을 이길 수 있는가? (마음만 앞서는 건 아니고?)

남들이 뭘 좋아하는지 보다 제가 좋아하는 것 중심으로 생각하고 싶습니다.
어차피 이렇게 하나 저렇게 하나 돈 벌기는 어려운 일.
그렇다면 내가 만들고 싶은 걸 만들어야 후회 없지 않을까?
내가 원했던 서비스라면 누군가는 분명 나 같은 사람이 있을 거라는 믿음으로.
커피한잔이 바로 제가 (결혼 전) 꼭 있었으면 했던 서비스였습니다.

물론 나만 원하고 아무도 원하지 않는 걸 만들어서는 안 됩니다.
서비스를 출시해보고 망해보고 하면서 이런 감각이 길러집니다.

자기가 만들고 싶은 걸 만들 때는 장점이 있습니다.
오랫동안 기복 없이 할 수 있다는 것.
쉽게 포기하지 않는다는 것.
내 앱의 최고 사용자가 바로 나라는 것.

서비스 한 번 시작하면 몇 년은 훌쩍 지나갑니다.
내 인생도 소중하다고.
기왕이면 제가 관심 있고 좋아하는 일에서 시작하고 싶습니다.

https://jeho.page/essay/2024/10/14/build-what-i-want-to-build/html

“네가 원하는 걸 만들지 말고 다른 사람들이 원하는 걸 만들어.” 스타트업 세계에서 자주 듣는 말입니다. 내가 만들고 싶은 걸 만들다가 써주는 사람이 없어서 망했다는 이야기. 바보 같고 우스워 보이지 않나요? 하지만… 남들 모두가 원하는 거 만들면 정말 잘 될 수 있을까? 그렇게 쉽지는 않을 겁니다. 거기엔 이미 경쟁자들이 우글우글 할텐데. 정말 그 경쟁자들을 이길 수 있는가? (마음만 앞서는 건 아니고?) 남들이 뭘 좋아하는지 보다 제가 좋아하는 것 중심으로 생각하고 싶습니다. 어차피 이렇게 하나 저렇게 하나 돈 벌기는 어려운 일. 그렇다면 내가 만들고 싶은 걸 만들어야 후회 없지 않을까? 내가 원했던 서비스라면 누군가는 분명 나 같은 사람이 있을 거라는 믿음으로. 커피한잔이 바로 제가 (결혼 전) 꼭 있었으면 했던 서비스였습니다. 물론 나만 원하고 아무도 원하지 않는 걸 만들어서는 안 됩니다. 서비스를 출시해보고 망해보고 하면서 이런 감각이 길러집니다. 자기가 만들고 싶은 걸 만들 때는 장점이 있습니다. 오랫동안 기복 없이 할 수 있다는 것. 쉽게 포기하지 않는다는 것. 내 앱의 최고 사용자가 바로 나라는 것. 서비스 한 번 시작하면 몇 년은 훌쩍 지나갑니다. 내 인생도 소중하다고. 기왕이면 제가 관심 있고 좋아하는 일에서 시작하고 싶습니다. https://jeho.page/essay/2024/10/14/build-what-i-want-to-build/html

K리그 프로그래머

아니, 난 그냥 내가 만들고 싶은 걸 만들래

Facebook

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다.

퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.
책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다.

그런데 회사에 들어가서 보니
구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.
이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다.
이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다.

이 의견에 대해서 설득하지 못했습니다.
데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다.
하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다.

그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다.
고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다.
먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다.

조금씩 고객 규모는 늘어났지만
너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 & 꾸준히 정진하는 사람 & 능동적으로 텍스트를 읽고 이해하려는 사람 & 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다.

물론 반대되는 생각도 있었습니다.
퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다.

일하면서 강하게 하게 된 생각은
'스타트업은 시장 크기가 거의 전부다' 라는 것입니다.
퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다.

퍼블리에서는 열심히 일했지만 한계가 있었습니다.
충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다.
사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다. 퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다. 그런데 회사에 들어가서 보니구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다. 이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다. 이 의견에 대해서 설득하지 못했습니다.데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다. 하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다. 그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다. 고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다. 먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다. 조금씩 고객 규모는 늘어났지만너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 &amp; 꾸준히 정진하는 사람 &amp; 능동적으로 텍스트를 읽고 이해하려는 사람 &amp; 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다. 물론 반대되는 생각도 있었습니다.퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다. 일하면서 강하게 하게 된 생각은'스타트업은 시장 크기가 거의 전부다' 라는 것입니다. 퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다. 퍼블리에서는 열심히 일했지만 한계가 있었습니다.충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다. 사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

www.facebook.com

결국 시장이 제일 중요하다

제가 지금까지 만든 학습 패키지는 총 8개입니다.

- 데이터 이력서 템플릿
- 생산성 도구 리스트
- 위클리 뉴스레터
- 코호트 데이터 분석 노트
- AARRR 데이터 분석 노트
- 데이터 커리어 스타터팩 BASIC
- 취업 준비 트래커
- ARAR 타임 트래커

학습 패키지를 하나하나씩 만들면서, 실제로 배우는 사람들에게 어떤 도움이 되는지, 그리고 학습자의 미래에 진심으로 도움이 되는지를 매번 다시 한번 생각해보곤 합니다.

물론 제 기준으로 만들기 때문에, 모든 학습자들에게 도움이 된다고 100% 확신할 수 없습니다.

하지만, DATA/AI를 조금 더 재미있게, 조금 더 가치있게 배울 수 있는 교육을 만들고 싶습니다.
그리고 그로 인해 더 많은 사람들이 더 나은 세상을 만들어가는 학습을 꿈꾸고 있습니다.

DATA/AI를 재미있고 가치있게 배울 수 있도록 앞으로도 더 많은 학습들을 만들어가겠습니다.

감사합니다.

#데이터리차드 #학습패키지 #DATA #AI

제가 지금까지 만든 학습 패키지는 총 8개입니다. - 데이터 이력서 템플릿 - 생산성 도구 리스트 - 위클리 뉴스레터 - 코호트 데이터 분석 노트 - AARRR 데이터 분석 노트 - 데이터 커리어 스타터팩 BASIC - 취업 준비 트래커 - ARAR 타임 트래커 학습 패키지를 하나하나씩 만들면서, 실제로 배우는 사람들에게 어떤 도움이 되는지, 그리고 학습자의 미래에 진심으로 도움이 되는지를 매번 다시 한번 생각해보곤 합니다. 물론 제 기준으로 만들기 때문에, 모든 학습자들에게 도움이 된다고 100% 확신할 수 없습니다. 하지만, DATA/AI를 조금 더 재미있게, 조금 더 가치있게 배울 수 있는 교육을 만들고 싶습니다.그리고 그로 인해 더 많은 사람들이 더 나은 세상을 만들어가는 학습을 꿈꾸고 있습니다. DATA/AI를 재미있고 가치있게 배울 수 있도록 앞으로도 더 많은 학습들을 만들어가겠습니다. 감사합니다. #데이터리차드 #학습패키지 #DATA #AI

앞으로 만들고 싶은 학습 프로덕트 리스트

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠.

개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요.

여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요.

매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠. 개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요. 여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요. 매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

흑백요리사, 이모카세가 대단한 이유

The 2024 Tidelift state of the open source maintainer report

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다.

1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.
2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.
3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.
4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.
5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.
6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.
7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.
8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.
9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.
10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.
11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.
12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다.

전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다.

https://explore.tidelift.com/2024-survey

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다. 1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다. 전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다. https://explore.tidelift.com/2024-survey

Tidelift

GitHub 에서 자주보던 브랜드인데 구체적으로 뭘하는지믄 몰랐어요. 소개해주셔서 감사합니다.

🙅‍♂️ 내가 하지 않는 생각
- 이걸로 무조건 성공해서 돈 벌어야지
- 많은 기능 넣으면 사용자들이 좋아하겠지?
- 이왕 만드는 거 완벽하게 만들어야지

🙆‍♀️ 내가 하는 생각
- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자
- 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자
- 필요한 기능 1개만 추려서 빠르게 만들어 보자
- 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

🙅‍♂️ 내가 하지 않는 생각- 이걸로 무조건 성공해서 돈 벌어야지 - 많은 기능 넣으면 사용자들이 좋아하겠지? - 이왕 만드는 거 완벽하게 만들어야지 🙆‍♀️ 내가 하는 생각- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자 - 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자 - 필요한 기능 1개만 추려서 빠르게 만들어 보자 - 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

사이드 프로젝트 만들 때

Online JSON view, format, minify, validate and compare. It also provides graph view to preview JSON data, semantic comparing two JSON diffs, convert JSON to CSV or CSV to JSON and support jq online.

JSON For You | The best online JSON tool

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요!
구조 비교 & 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요!

https://json4u.com/editor

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요! 구조 비교 &amp; 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요! https://json4u.com/editor

JSON For You

파워풀한 json 시각화툴

알고리즘 입문자를 위한 달레의 친절한 안내서

알고리즘 | 알고달레

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java)
📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗)
📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유

개발자 달레님이 만드신 사이트인데요,
무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요!

https://www.algodale.com/algorithms/

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java) 📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗) 📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유 개발자 달레님이 만드신 사이트인데요, 무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요! https://www.algodale.com/algorithms/

알고달레

코딩테스트 공부를 위한 추천 사이트

“아니, 도대체 왜 조회 쿼리 메서드에서 데드락이 생기는거야?”  

왜 조회 쿼리에서 데드락이 발생했을까?

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.
https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

"아니, 도대체 왜?"'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

현구막 기술 블로그

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다.

📕 YES24: https://www.yes24.com/Product/Goods/134021042
📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265
📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550

사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다.

이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다.

"헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다. 📕 YES24: https://www.yes24.com/Product/Goods/134021042 📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265 📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550 사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다. 이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다. "헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

👋 헬로 Bun 🥟 출간 소식 📚

원문 : How to make your web page faster before it even loads How to make your web page faster before it even loads…

(번역) 웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다.

웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다.

만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :)

글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다. 웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다. 만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :) 글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

ykss.netlify.app

웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

Arthur's place

저자는 try-catch 블록 없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.
const [error, response] = try await fetch("https://arthur.place")

위 코드는 기존 try-catch 코드 블록을 간소화하고
error
를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다.
let response;
try {
  response = await fetch("https://arthur.place");
} catch (error) {
  // blah blah
}

아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.
참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과
try
표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다.

https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

저자는 try-catch 블록&nbsp;없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.<pre ><code class="language-js">const [error, response] = try await fetch("https://arthur.place")</code></pre>위 코드는 기존 try-catch 코드 블록을 간소화하고 <code >error</code>를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다. <pre ><code class="language-js">let response;
try {
 response = await fetch("https://arthur.place");
} catch (error) {
 // blah blah
}</code></pre>아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과 <code >try</code> 표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다. https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

ECMAScript try-expressions 제안

You are being redirected...

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다.

# 소프트웨어 침식의 원인과 문제
 * 지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.
 * 불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.
 * 중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.

# 소프트웨어 침식을 방지하는 방법
 * 지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.
 * 품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.
 * 설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.

소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요?

https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다. # 소프트웨어 침식의 원인과 문제<ul ><li>지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.</li><li>불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.</li><li>중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.</li></ul> # 소프트웨어 침식을 방지하는 방법<ul ><li>지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.</li><li>품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.</li><li>설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.</li></ul> 소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요? https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

www.softwaretestingnews.co.uk

내 눈 앞에서 소프트웨어가 침식되고 있다

음.. 어떻게 얘길 시작해야 하나 

끗과 시작, 그 사이 어딘가

'최고가 되어 떠나라'
회사에 붙어있는 메시지 중 하나인데요.
퇴사부검을 보고나니 다들 멋지네요
앞으로 더 좋은 소식 기대하고 있을께요

https://www.brainbackdoor.com/retrospective/2019-2024

'최고가 되어 떠나라'회사에 붙어있는 메시지 중 하나인데요.퇴사부검을 보고나니 다들 멋지네요앞으로 더 좋은 소식 기대하고 있을께요 https://www.brainbackdoor.com/retrospective/2019-2024

동규님의 우아한형제들 퇴사부검

어제 심오한 고민을 하다가 헤라의 글로우 래스팅 파운데이션을 구매했다. 솔직히 양에 비해 가격이 저렴하...

[극대노주의] 올리브영 일반배송 은근슬쩍 오늘드림 변환 수법

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 <리서치 하는데요> 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다)

요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠.

사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠.

문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다.

[ 큐레이터의 문장 🎒 ]

1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다"

2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다."

3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며"

https://m.blog.naver.com/boksle1127/223420780140

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 &lt;리서치 하는데요&gt; 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다) 요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠. 사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠. 문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다. [ 큐레이터의 문장 🎒 ] 1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다" 2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다." 3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며" https://m.blog.naver.com/boksle1127/223420780140

네이버 블로그 | 계절의 기록

《올리브영 다크 패턴에 돌아선 사용자》

법무부 온라인민원서비스의 민원신청 메뉴의 교도소, 구치소 대상자 및 수감자 관리 메뉴로 들어가면 수용자등록하기 메뉴에서 수용기관, 수용번호(4자리) 그리고 수용자 성명을 입력하면 교도소 수감자 조회 및 등록이 가능합니다. 다만 확인을 위해서는 반드시 수용기관과 수용번호를 먼저

교도소 수감자 조회방법 - 수용번호 및 기관 1분 확인하기 - Micro Business In Asia

법무부 온라인 민원 서비스에서 수감자를 조회하거나 등록하려면, 해당 수용기관과 수용자의 4자리 번호, 수용자의 성명을 입력해야 합니다. 이 정보는 온라인으로 접근할 수 없어, 관련 데이터를 얻기 위해서는 교정시설에 직접 방문해 수감자와의 관계를 등록하는 절차를 밟아야 합니다. 등록 과정에서는 신분증 제출이 요구되며, 등록 완료 후에는 웹사이트를 통해 수감자 정보 조회, 영치금 입금, 접견 예약, 서신 작성 등을 할 수 있습니다. 개인정보 보호법에 따라, 수형기간이나 출소 예정일 등의 세부 정보는 제한적으로만 제공됩니다. 더욱 자세한 내용은 뉴스채널을 참고하세요.

https://microbia.co.kr/jail-inmate-lookup

법무부 온라인 민원 서비스에서 수감자를 조회하거나 등록하려면, 해당 수용기관과 수용자의 4자리 번호, 수용자의 성명을 입력해야 합니다. 이 정보는 온라인으로 접근할 수 없어, 관련 데이터를 얻기 위해서는 교정시설에 직접 방문해 수감자와의 관계를 등록하는 절차를 밟아야 합니다. 등록 과정에서는 신분증 제출이 요구되며, 등록 완료 후에는 웹사이트를 통해 수감자 정보 조회, 영치금 입금, 접견 예약, 서신 작성 등을 할 수 있습니다. 개인정보 보호법에 따라, 수형기간이나 출소 예정일 등의 세부 정보는 제한적으로만 제공됩니다. 더욱 자세한 내용은 뉴스채널을 참고하세요. https://microbia.co.kr/jail-inmate-lookup

교도소 수감자 조회방법 - 수용번호 확인 절차

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필