https://zarar.dev/good-software-development-habits/

• 
  이 글은 조언이 아닌, 저자가 현재 적용하고 있는 개발 습관들에 대해 작성한 내용
• 나쁜 습관을 피하고 좋은 습관을 만들기 위해 노력한 경험을 정리한 글로, 생산성 향상과 품질 유지에 도움이 되었던 10가지 습관을 다룸

1. 작은 커밋 유지

• 커밋을 최대한 작게 유지해야 함. 작은 커밋은 버그 발생 시 특정 커밋만 되돌릴 수 있게 하여, 복잡한 병합 충돌을 피할 수 있음
• "소프트웨어가 컴파일될 때 커밋할 수 있어야 한다"는 것을 규칙으로 삼음

2. 지속적인 리팩토링

• Kent Beck의 조언: "변화를 원할 때, 먼저 변화를 쉽게 만들고, 그런 다음 쉽게 변화를 만드세요."
• 최소 절반의 커밋은 리팩토링이 포함되도록 함. 작은 리팩토링이 큰 요구사항이 들어올 때 큰 도움이 됨
• 큰 리팩토링은 피해야 함. 대신 10분 이내의 작은 개선 작업을 지속적으로 수행

3. 코드 배포의 중요성

• 코드 자체는 잠재적 부채이며, 배포되지 않은 코드는 가장 큰 부채임
• 테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미함
• 배포 빈도가 높아질수록 호스팅 비용이 증가할 수 있지만, 최신 작업이 실제로 작동함을 확인하는 것은 중요한 이점임

4. 프레임워크의 기능 테스트하지 않기

• 프레임워크의 기능을 테스트하지 않음. 프레임워크는 이미 충분히 검증되어 있음
• 컴포넌트를 작게 유지하면 프레임워크가 대부분의 작업을 처리하게 되어 테스트가 줄어듦
• 큰 컴포넌트는 복잡성을 추가하고, 이에 따라 많은 테스트가 필요해짐

5. 새로운 모듈 생성

• 특정 기능이 기존 모듈에 맞지 않는다면, 새 모듈을 생성하는 것이 좋음
• 기존 모듈에 억지로 기능을 추가하는 것보다 독립적인 모듈로 남겨두는 것이 나음

6. 테스트 주도 개발(TDD)의 유연한 적용

• API 설계가 명확하지 않을 경우 테스트를 먼저 작성하여 "고객"의 입장에서 생각함
• TDD는 종교적인 원칙으로 따르지 않음. 필요한 경우 더 큰 단위로 작업 후 테스트할 수 있음
• 작은 단위의 코드를 실패 상태로 만들지 않아도 되며, 생산성을 저해하는 교조주의에 얽매이지 않음

7. 복붙은 한 번만 허용

• 한 번의 복사는 괜찮지만, 두 번째 복사부터는 중복이 생김
• 이 시점에서 적절한 추상화를 통해 중복을 제거해야 함. 파라미터화가 약간 이상해 보여도, 여러 구현을 합치는 것보다는 나음

8. 디자인의 변화 수용

• 디자인은 시간이 지나면서 낡아짐. 리팩토링을 통해 노화를 늦출 수 있지만 결국에는 바뀔 수밖에 없음
• 이전의 디자인을 너무 집착하지 말고, 변화를 받아들여야 함
• 완벽한 디자인은 없으며, 변화에 잘 대처하는 능력이 소프트웨어 개발의 핵심임

9. 기술 부채의 세 가지 유형

• 기술 부채는 세 가지 유형으로 분류할 수 있음:
  1. 현재 작업을 방해하는 것
  2. 미래 작업을 방해할 가능성이 있는 것
  3. 방해할 가능성이 있을지도 모르는 것
• 첫 번째 유형의 부채는 최소화하고, 두 번째 유형에 집중하며, 세 번째 유형은 무시해야 함

10. 테스트 가능성과 좋은 설계의 관계

• 테스트하기 어렵다면 설계에 문제가 있을 가능성이 높음
• 테스트 설계 또한 개선의 대상이 될 수 있음. 예를 들어, em.getRepository(User).findOneOrFail({id})의 목(Mock) 작성을 어렵게 느낀다면, 별도의 함수로 분리하거나 테스트 유틸리티를 사용하는 것이 좋음
• 테스트가 작성되지 않는 이유는 테스트하기 어렵기 때문이며, 이는 설계의 문제일 수 있음

https://www.itworld.co.kr/numbers/82001/338846

아태지역 AI 시장에서 생성형 AI의 비중이 더 커질 것이라는 전망이 나왔다. 중국이 앞서가는 가운데 일본과 인도 시장이 빠르게 성장하리라는 분석이다.

30일 시장조사업체 한국IDC가 ‘전 세계 AI 및 생성형 AI 지출 가이드’ 보고서를 발표했다. 중국과 일본을 포함한 아시아 태평양 지역의 AI 시장을 조사했다. AI 기반 시스템을 위한 소프트웨어, 서비스, 하드웨어를 포함한다. 보고서에 따르면, 아태 지역 생성형 AI 지출은 연 평균 95.4% 성장해 2027년에는 260억 달러 규모가 될 전망이다. 생성형 AI의 비중은 더 커진다. 생성형 AI는 2024년 전체 AI 시장의 15%를 차지하지만, 2027년에는 29%까지 늘어날 것으로 업체는 예상했다.
 

IDC 아태지역에서 빅데이터 및 AI 리서치 헤드 디피카 기리는 "아시아 태평양 지역에서 생성형 AI의 도입이 급증하며 향후 2년 이내에 투자가 정점에 도달한 후 안정화 기간을 거칠 것으로 예상된다. 중국은 생성형 AI 기술 관련 지배 시장 위치를 유지할 것이며, 일본과 인도는 향후 몇 년 동안 가장 빠르게 성장하는 시장이 될 것이다"라고 말했다.

산업별로 보면, 금융, 소프트웨어 및 IT, 정부, 리테일, 내구재 등의 부문에서 성장이 두드러진다. 금융 서비스 산업의 AI 지출은 2027년까지 연평균 96.7%씩 성장해 43억 달러 규모를 형성할 전망이다. 사내 운영 효율성 개선, 반복 작업 자동화, 사기 탐지 및 복잡한 문서 작성과 같은 백오피스 프로세스 최적화에 생성형 AI를 주로 활용하는 추세라고 보고서는 분석했다.
 

소프트웨어 및 IT 산업은 마케팅, 데이터 분석, 소프트웨어 개발 등 다양한 분야에서 생성형 AI를 활용한다. 생성형 AI는 콘텐츠 제작을 간소화하여 마케팅 전략을 최적화하고 오디언스 참여를 극대화하며, 소프트웨어 개발 분야에서는 코딩 작업을 자동화하고 프로토타입을 생성해 개발자의 생산성과 효율성을 높이는 데 기여하는 것으로 나타났다.

정부 부문에서는 생성형 AI 기술 교육과 훈련을 발전시켜 새로운 일자리를 창출하고 기술 혁신 허브의 성장을 촉진하는 데 활용하고, 리테일 산업에서는 개인 맞춤화 경험 제공을 위해 AI 기술을 활용하는 것으로 보고서는 분석했다.

소프트웨어 개발자의 생산성을 측정하는 방법

https://www.itworld.co.kr/news/315198

소프트웨어 개발자의 효율성을 측정하는 것은 수십 년 동안 불가능한 것으로 여겨졌다. 두 명의 맥킨지 컨설턴트는 개발자가 개발자의 생산성을 측정할 수 있는 방법을 소개한다.

우리는 다양한 산업 분야의 많은 기업과 협력한 결과, 소프트웨어 개발자의 생산성을 측정할 수 있는 방법을 찾았다. 3년 전, 맥킨지는 440곳 대기업의 개발자 속도를 분석했다. 그 결과 소프트웨어 개발자의 성과와 회사의 성공 사이에는 분명한 상관관계가 있다는 사실이 밝혀졌다. 이는 IT 기업뿐만 아니라 다른 분야에도 적용된다. 전 세계 소프트웨어 엔지니어의 약 절반이 IT 산업이 아닌 다른 산업군에서 일한다.
 

ⓒ Getty Images Bank
현재 전 세계적으로 약 2,700만 명의 개발자가 있으며, 440만 명이 미국에 있다. 미국 노동통계국은 2021년부터 2031년까지 이 숫자가 25% 더 증가할 것으로 예측하고 있다. 생성형 AI의 급격한 확산을 고려하면, 개발자 수요는 훨씬 더 커질 것이다.
 

성과와 직결되는 개발자 생산성

이런 조사 결과를 종합하면, 관리자는 소프트웨어 개발 인재를 가장 잘 활용할 수 있는 방법을 정확히 알아야 한다는 결론에 도달할 수 있다. 오늘날의 소프트웨어 개발은 창의적인 과정일 뿐만 아니라 협업 과정이기도 하므로 이는 쉽지 않은 일이다. 노력과 수익 간의 합리적인 관계를 보장하는 것은 결코 쉬운 일이 아니다. 이미 많은 기업이 시스템, 팀, 개인의 생산성을 측정하는 데 실패했다.

배치 빈도와 같은 알려진 지표는 팀의 생산성을 추적하는 데 도움이 될 수 있지만, 개인의 생산성을 추적하는 데는 도움이 되지 않는다. 하지만 우리는 개발자의 생산성을 측정하는 일이 가능하다고 생각한다. 특히 맥킨지는 이미 이 작업을 수행하고 있는 20여 곳의 IT, 금융 및 제약 회사와 협력하고 있다. 아직 100% 신뢰할 수 있는 결과는 얻은 것은 아니지만, 유망한 결과이다. 맥킨지의 계산에 따르면, 이들 기업은 개발자의 생산성을 측정하고 개선해 오류율을 평균 20~30% 줄이고 고객 만족도를 60%까지 높일 수 있었다.
 

개발자의 생산성을 측정하는 방법

우선, 구글과 마이크로소프트에서 개발한 두 가지 지표, 즉 소프트웨어 배치 처리량과 안정성을 측정하는 DORA(DevOps Research and Assessment)와 개발자의 개별 생산성을 측정, 이해 및 개선하기 위해 설계된 프레임워크인 SPACE(Satisfaction, Performance, Activity, Communication/Collaboration and Efficiency)를 활용한다. 맥킨지는 이들 지표를 다음과 같은 네 가지 '기회 지향 지표'로 보완했다.

내부 루프 및 외부 루프에 소요된 시간. 내부 루프는 코딩, 빌드, 단위 테스트 등 소프트웨어 제품 개발과 직접 관련된 활동을 포함한다. 외부 루프는 코드를 프로덕션 환경으로 이전하는 것과 관련된 활동으로, 통합, 테스트, 릴리스, 배치 등을 말한다. 개발자가 내부 루프에 더 많은 시간을 할애할수록 생산성이 높아지는데, 상위 기업의 경우 이 비율이 70%에 달한다.

개발자 속도 지수(Developer Velocity Index, DVI) 벤치마킹. 사내 프랙티스를 다른 회사 또는 경쟁사의 프랙티스와 비교함으로써 개선해야 할 영역을 파악할 수 있다. 백로그 관리, 테스트 또는 보안 및 규정 준수 등이 이에 해당한다.

개발자 기여도 분석. 팀이 백로그에 어떤 기여를 하고 있는지 평가한다. 백로그 관리를 측정하는 지라(Jira) 같은 툴을 사용해 성과 향상을 방해하는 부정적인 흐름을 파악할 수 있다. 작업 환경을 개선하고 자동화 수준을 높이거나 팀원 개개인의 기술을 최적화할 방법을 보여줄 수도 있다. 예를 들어, 한 회사는 자사의 최고 개발자들이 코딩 이외의 활동에 너무 많은 시간을 소비하고 있다는 사실을 깨달았고, 모든 개발자가 자신이 가장 잘하는 일에 집중할 수 있도록 운영 모델을 변경했다.

인재 관리. 인재 관리의 목표는 직원들이 각자의 재능과 선호도에 따라 배치하는 것이다. 업계 표준 역량 맵을 사용해 조직의 기존 지식, 기술 및 능력을 가시화할 수 있는 점수를 만들 수 있다. 이를 통해 격차와 약점을 파악할 수 있다. 예를 들어, 한 고객사는 경험이 부족한 개발자를 너무 많이 고용하고 있다는 사실을 깨달았다. 이 문제를 해결하기 위해 맞춤형 학습 프로그램을 제공했고, 개발자의 30%가 6개월 이내에 다음 단계의 역량에 도달했다.

이런 접근법은 DORA 및 SPACE와 함께 소프트웨어 생산성에 대한 차별화된 관점을 가능하게 한다. 또한 개발자에게 동기를 부여할 수 있는 방법, 적절한 툴와 전문 지식을 보유하고 있는지, 시간을 어떻게 사용하는지, 팀 구성이 최적화된 상태인지 등을 파악할 수 있다.
 

성공의 증거는 없지만 명확한 지표

개발자 생산성 측정은 여전히 논란의 여지가 있는 주제이며, 많은 전문가가 우리의 시도를 부정적으로 생각한다는 것도 알고 있다. 하지만 맥킨지와 긴밀하게 협력하는 20개 기업은 이에 동의하지 않는다. 우리는 소프트웨어 개발이 측정이 불가능할 정도로 복잡하고 신비롭다고 생각하지 않는다. 오히려 업데이트를 코딩하고 구현할 때 생성형 AI 도구를 사용하면 얼마나 개선되는지 꽤 잘 예측할 수 있다.

여기서 설명한 개발자 생산성 측정 시스템은 아직 완벽하지 않다. 우리는 개선해야 할 부분에 대한 건설적인 비판을 언제나 환영한다. 하지만 소프트웨어 개발의 중요성이 날로 커지고 인재 확보 경쟁이 치열해지는 상황에서 복잡하다고 미뤄두기에는 너무나 중요한 주제이다.

2022년 적용 SW기술자 평균임금 공표

https://www.sw.or.kr/site/sw/ex/board/View.do?cbIdx=304&bcIdx=51393&searchExt1= 

통계법 제27조(통계의 공표)에 따라 『2022년 적용 SW기술자 임금실태조사 (통계승인 제375001호)』의 SW기술자 평균임금을 공표합니다.

【SW기술자 평균 임금】

                                                                                                                                  (단위: 원)

<본 평균임금을 SW사업대가 활용시 유의사항>

※ 본 조사결과는 SW사업에서 SW기술자 인건비로 참고 활용 가능하며, 수·발주자간 자율적 협의에 의해 
적용할 수 있음

* SW기술자 평균임금은 소프트웨어진흥법 제46조(적정대가지급등) 제4항 ‘소프트웨어기술자의 인건비 기준’을
지칭함

* SW기술자 평균임금은 기본급, 제수당, 상여금, 퇴직급여충당금, 법인부담금을 모두 포함한 결과임

* 일평균임금은 월평균÷근무일수(20.8일), 시간평균임금은 일평균÷8시간으로 각각 산정함

* 월평균 근무일수는 휴일, 법정공휴일 등을 제외한 업체가 응답한 근무일의 평균이며, 이는 개인의 휴가 사용여부와는 무관함

* SW기술자 전체 평균임금은 전년대비 2.6% 증가

   - 2020년 공표된 평균임금을 변경된 임금추정방식(가중평균)으로 환산하여 비교

* IT직무 중 26. IT감사, 29.IT교육강사는 유효응답(30명 이상) 표본이 적어 활용시 유의해야함

[시행일] 2022년 1월 10일부터 2022년 12월 31일까지 적용

2022년 1월 10일

한국소프트웨어산업협회장

12가지 필수적인 소프트웨어 개발 원칙과 개념

업계에 처음 발을 들여놓는 젊은 개발자들은 한꺼번에 많은 원칙과 개념에 대한 이야기를 듣게 된다. 관리자로 올라서는 경력 개발자는 그동안 피해 왔지만, 기술적인 측면에 폭넓은 영향을 미치는 비즈니스 개념에 대한 이야기를 듣게 된다.

다음은 지난 20년 동안 소프트웨어, 그리고 소프트웨어 비즈니스에 있어 가장 중요한 12가지 개념이다.

1. 권한 없는 책임

경력이 어느 정도 된다면 권한 없는 책임을 접해봤을 것이다.

극단적인 사례를 들면 경비원에게 분기별 수익 책임을 지우는 것이다. 경비원이 아무리 노력해도 회사의 수익성을 높일 수는 없다. 경비원이 영업 회의에 참석한다 해도 신참 영업 사원이 전화를 더 많이 걸도록 유도할 수는 없다. 영업 사원을 움직일 영향력이 없기 때문이다. 마케팅 회의에 참석해봤자 마케팅 부서에서 새로운 캠페인을 구상하도록 이끌 수도 없다.

물론 극단적인 예다. 그러나 짊어지는 책임과 실제 행사할 수 있는 영향력 사이의 격차는 그 정도가 얼만큼이든 스트레스의 원천이다. 권한 없는 책임은 조직적인 기능 장애를 나타내는 징후이며(모든 조직에 어느 정도는 있음), 해결책은 권한을 높이거나 책임을 낮추는 것밖에 없다.

2. 반복하지 말 것

 “반복하지 말 것” 원칙은 시스템에서 표현은 명확하게, 한 번만 해야 한다는 것이다. 코드 한 블록을 잘라내서 여러 곳에 붙여 넣을 경우 그 설계에는 결함이 발생한다. 그 결함을 가장 먼저 수정해야 한다.

이 원칙을 위반할 경우 시간을 낭비할 뿐만 아니라 유지보수 문제도 발생한다. 여러 지점에서 잘라내서 붙여넣기한 버그를 모두 찾아 수정해야 한다. 또한 보안 결함이 복제되는 경우를 상상해 보라.

이 문제를 수정하는 방법은 전체 아키텍처를 수정하는 것부터 코드 생성기, 종속성 주입에 이르기까지 많지만 어떤 방법을 사용하든 일단 수정해야 한다!

3. 필요할 일이 없다

앞으로 필요할 것 같아서가 아니라, 지금 필요한 기능을 구현하라. 앞으로 필요할 것 같다면 십중팔구 필요할 일이 없다. 나중에 정말 필요해지면 그때 가서 넣으면 된다.

모듈을 설계하면서 그 모듈이 이번 릴리스와 앞으로의 릴리스에서 해야 할 모든 작업을 미리 생각하고 반영하려 한다면 앞으로 일어나지 않을지도 모르는 기능까지 지원하는 쓸데없이 복잡한 소프트웨어를 만들게 된다.

미래를 예측하는 것보다 현실을 이해하는 편이 훨씬 더 정확하다. 현재에 집중하라.

4. 최소 실행 가능 제품

새로운 무언가를 만들 때 최선은 *할 수 있는* 모든 일을 시원찮게 하는 것보다 정말 잘 할 수 있는 최소한의 일을 하도록 하는 것이다. 이것을 최소 실행 가능 제품(Minimum Viable Product, MVP)이라고 한다.

MVP를 하면 사용자나 고객에게 유용성을 시연하기가 더 쉬워진다. 또한 잘못될 경우 고쳐야 할 부분도 더 적고 실패할 경우 잃을 투자도 더 적다.

5. 좁고 깊게

이 개념은 MVP와 관련된다. 모든 사람에게 모든 것을 줄 수는 없다.

제품이나 기업이 더 많은 일을 하려고 노력할수록 잘 할 수 있는 가능성은 낮아지고 비용과 복잡성은 높아진다. 넓고 얕은 것은 바람직하지 않다.

집중의 문제다. 규모가 큰 조직이나 성숙한 소프트웨어는 “플랫폼”과 사업부를 만들어 더 많은 리소스를 적용할 수 있지만 작은 회사는 한꺼번에 너무 많은 것을 하면 안 된다.

그러나 대규모 조직에도 “좁고 깊게” 원칙은 필요하다. 조직 또는 플랫폼의 각 부분에 대한 원칙으로 두어야 한다. 개별적인 폭이 모여 넓게 될 수는 있지만 각각의 요소는 깊어야 한다.

6a. 최소 비용(운영의 탁월성)

6b. 최고의 제품(제품 리더십)

6c. 최고의 토털 솔루션(고객 친밀성)

 “최고의” 또는 가장 효과적인 조직은 이 세 가지 전략 중 하나를 추구하는 조직이다. 결과적으로 이러한 조직은 가장 비용이 낮은 조직, 최고의 조직, 또는 최고의 서비스를 제공하는 조직이다.

가장 낮은 비용에 초점을 맞출 경우 그 분야에서 최고의 제품이 될 수 있는 최신 기능 일부를 구현하지 못하게 된다.

최고의 서비스(고객 친밀)를 제공하는 데 초점을 맞출 경우 일반적으로 제품이 여러 방향으로 분산되어 각 고객에 따라 대폭 맞춤 제작된다. 이 경우 혁신과 사용 편의성 측면에서 대가를 치르게 된다.

이 목표 중 규모의 확장이 용이한 것은 두 개뿐이다. 가장 낮은 비용 또는 최고의 제품이다. 원하는 검색 결과를 얻지 못할 때 구글 고객 서비스에 전화를 걸 수 없는 이유가 여기에 있다.

7. 테스트 먼저

현대 IDE에서는 테스트를 가장 먼저 해야 한다. 이는 단위 테스트를 먼저 작성한 다음 여기서 클래스 등을 생성해야 함을 의미한다. 결과적으로 테스트가 용이한 소프트웨어가 되므로 더 높은 품질의 소프트웨어가 만들어진다. 또한 계약에 의한 설계와 같은 다른 설계 원칙을 따르도록 유도하는 효과도 있다.

8. 계약에 의한 설계

각 루틴에 대해 그 루틴이 어떤 작업을 하고 그 작업을 위해 무엇이 필요한지를 알아야 한다. 방법은 계약에 의한 설계(Design by Contract)다. 여기서 계약은 소프트웨어의 각 요소를 위한 형식적이고 간결하며 확인 가능한 인터페이스 사양을 말한다. 이 접근 방법을 사용하면 부작용, 전역 변수 및 기타 여러 가지 잘못된 것들을 피할 수 있다.

9. 경합 조건에 주의

일반적으로 경합 조건은 계약에 의한 설계의 다중 쓰레드 위반을 의미한다.

가장 단순한 형태로 보자. 두 개의 쓰레드가 동일한 변수를 변경할 때 한 쓰레드가 먼저 한다면 문제 없다. 그러나 두 번째 쓰레드가 변수를 먼저 변경하는 경우 오류가 발생하고 이것이 경합 조건이다.

이러한 종류의 설계 결함을 탐지하는 것이 불가능할 때도 있다. 간헐적이며 부하가 큰 경우에만 발생하는 경우가 많으므로 단위 테스트로 포착할 수 없다. 고도의 방어적 설계와 쓰레드 간 협업을 피하는 것이 경합 조건을 방지하기 위한 좋은 방법이다. 그러나 메시징 및 이벤트 지향 소프트웨어에서도 다른 버전의 경합 조건이 발생할 가능성은 있다(다만 확률이 낮을 뿐임). 동시성은 어렵다.

10. 콘웨이의 법칙

콘웨이의 법칙(Conway's Law)이란 팀의 커뮤니케이션 구조를 반영하는 소프트웨어를 개발할 수밖에 없다는 법칙이다. 바꿔 말하면 팀의 근본적인 구조를 바꾸지 않고서는(바꾸기는 무척 어려움) 소프트웨어의 근본적인 구조를 바꿀 수 없다.

11. 빠른 실패

 “빠른 실패(Fail Fast)” 원칙은 실리콘 밸리에서 인기 있지만 어디에 적용해도 좋다. 기본적인 개념은 오류가 발생할 경우 소프트웨어는 대놓고, 거침없이 그 오류를 드러내야 한다는 것이다.

아마추어 프로그래머는 모든 변수에서 null을 확인하고, null이 될 수 없는 경우에도 이를 0이나 빈 문자열 등으로 대체한다. 그런 다음 불가능하고 잘못된 상황이 발생했는데도 코드를 계속 실행시킨다. 최고의 개발자는 소프트웨어가 null 포인터 예외를 뱉거나 실제 오류 자체를 내뱉도록 한다.

프로젝트 관리에서 빠른 실패란 존재할 수 있는 정치적 또는 기술적 장벽을 최대한 조기에 찾아내는 것을 의미한다.

비즈니스에서 빠른 실패란 궁극적인 실패를 향해 또는 이른바 ‘라면 수익’을 향해 천천히 투자하기보다 상품이나 비즈니스를 입증하거나 반증하는 대담한 계획을 추진하는 것을 의미한다.

12. 맨먼스 미신

프로젝트 종반에 인력을 추가하면 프로젝트는 더 늦어진다. 고전 ‘맨먼스 미신(The Mythical Man-Month)’은 40년도 넘은 과거의 책임에도 오늘날 소프트웨어 엔지니어링의 많은 오류를 설명한다.

이 용어는 “언제 끝나요?”라는 질문에 냉소적으로 답하는 데도 사용된다. 내 일정은 나도 모른다. 다른 일이 없었다면 신비한 3인일(man-days) 내에 이미 마쳤겠지만, 회의가 6번 더 남았고 그 회의에서도 누군가는 똑 같은 질문을 던질 것이다.

원문보기: 

https://www.infoworld.com/article/3233866/application-development/12-essential-software-development-principles-and-concepts.html

...