“빠르게 해주세요”는 요구사항이 아닙니다 | 품질 목표 제대로 정하는 법

Video: “빠르게 해주세요”는 요구사항이 아닙니다 | 품질 목표 제대로 정하는 법
Channel: 코딩하는기술사
Duration: 17m 17s
Source: subtitle (auto, ko)
Transcript:
자, 개발자 여러분, 어, 이런 요구 사항 어떻습니까? 빠르게 만들어 주세요. 어, 장애가 최대한 안 나게 해 주세요. 어, 보안도 강화해 주세요. 자, 어떻게 고객한테 또는 기획자한테 많이 들어본 요구상 아닌가요? 아니면 여러분들이 바이브 코딩할 때 AI한테 이렇게 시키고 있나요? 빠르게, 안전하게는 기준이 없는 겁니다. 어, 비개발자가 이런 용어를 사용할 수 있어도 우리 같은 개발자는 이렇게 하면 안 되겠죠. 그래서 어 측정 가능하고 검증할 수 있는 소프트의 품질 목표를 세우는 법을 알려 드리겠습니다. 여러분들이 바이브 코딩을 할 때도 정확하게 AI한테 품질 목표 기준을 주고 그 기준을 기반으로 검정하는 체계를 갖추는 것이 중요합니다. 그래서 오늘 주제는 AI 시대에도 더욱 중요한 문제입니다. 자, 이렇게 빠르게 안전하게라고 얘기를 하면 그것을 완료했다는 것은 어떻게 판단할 건가요? 기준이 없으니까 무호하죠. AI한테 이렇게 일을 시켜도 AI도 무호하게 일을 할 겁니다. 자, 이런 요구 사항을 듣고 시스템을 개발했다고 해 보겠습니다.

자, 그러면 고객이 어, 그 시스템을 사용해 보고 이렇게 얘기할 수도 있겠죠. 어, 제가 볼 때 화면이 조금 느린 것 같습니다. 그렇지만 우리 개발 팀의 개발자는 어, 제가 볼 땐이 정도면 빠른 건데요. 자, 둘 다 틀렸다고 말하기는 어렵죠. 왜 그러냐면 이들이 합의한 기준 자체가 없었기 때문입니다. 빠르게 만들어 주세요라는 것은 기준이 없는 거죠. 자, 그래서 이런 모한 기준을 검증 가능한 어 품질 기준으로 바꾸는 방법을 알려 드리겠습니다. 자, 왼쪽을 보시면 자, 성능을 어, 행용사로 이렇게 얘기를 했죠. 빠르게 만들어 주세요. 자, 품질 목표가 있습니까? 기준이 있습니까? 없죠? 자, 그러면 개발자는 어, 빠르게 만들어 달라고 했으니까 캐시 넣어야지. 자, 이렇게 결정을 합니다. 그리고 개발이 완료되고 나서 앞에서와 같은 일이 생기는 거죠. 둘이 합의된 기준이 없었기 때문에 어 이것이 제대로 완료됐는지 판단이 불과하죠. 자, 이것을 어 오른쪽에 있는 검증 가능한 기준으로 말해 보겠습니다. 자, 품질 특성은 성능 효율성.

자, 성능이고요. 자, 성능에는 크게 두 가지 축이 있죠. 레이턴시와 스루프. 응답 시간과 처리량입니다. 그런데이 요구에서는 어 회비를 해보니 응답 시간을 얘기한 거였고요. 그래서이 응답 시간에 대한 목표를 설정합니다. 얼마? 500ms 이하로 응답을 해야 된다. 자 그래서 어 캐시 튜닝 스케일 아웃과 같은 텍틱 즉이 설계 전략을 세우고 적용을 하는 거죠. 이렇게 해서이 목표를 달성했는지 부과 테스트를 해 보고 500ms 이하로 나오면 통과 아니면 실패 정확한 판단 기준이 세워지는 거죠. 자, 그런데 여기서 목표 어 조금 다듬어야 될 필요가 있습니다. 자, 목표를 검증 가능하게 앞서 우리가 어 예시로 간단하게 응답 시간이 500ms 이하라고 했는데요. 이것도 사실은 조금 부족합니다. 어떤 부하 상황에서 어, 어떤 API가 그리고이 응답 시간이라는게 평균 응답 시간인지 아니면 어, 퍼센테이지인지. 자, 그래서이 품질 목표를 조금 더 구체화시켜 보겠습니다. 조건과 목표 그리고 대상 등을 정확하게 지정을 하는 거죠.

500TPS 즉 초당 500개의 트랜잭션 환경에서 주문 API 자 대상 API가 주문 API입니다. 주문 API에 95%의 응답 시간이 500ms 이하로 나와야 된다. 자 이렇게 정확하게 조건과 대상 그리고 지표 목표를 설정을 해야 됩니다. 이렇게 해야지 정확하게 기준이 세워지고 정확하게 검증할 수 있고 판단할 수가 있습니다. 자, 그래서 이런 품질 요구 사항과 어 정확한 기준과 평가를 위한 국제 표준을 말씀드리겠습니다. 자, 스퀘어라는 것이 있습니다. 시스템 앤 소프트웨어 quality requirement먼트 앤볼루션의 약자이고요. 소프트웨 품질를 정의하고 요구 사항을 만들고 측정하고 평가하기 위한 ISOIC 25, 계열의 표준 체계이고요. 여기에는 여러 가지 어 품질 기준들이 있습니다. 오늘은 그중에서 세 가지를 소개해 드리겠습니다. 자 첫 번째 ISO210입니다. 자 이것은 퀄리티 모델 품질 특성을 체계화시킨 국제 표준입니다. 즉 무엇을 품질로 볼까? 성능, 보완, 신뢰성 같은 특성을 정의를 하고 각 특성의 세부 부탁을 정의를 해둔 표준이고요.

ISO23은 앞서 정의한이 품질 특성을 무엇으로 측정할까에 대한 표준을 정의한 것입니다. 각 품질 특성에 대한 측정 항목과 측정 함수 매저먼트를 제공하고 있습니다. 자, 그리고 ISO25030은 이런 품질 요구 사항을 어떻게 정의하고 어 관리할까 즉 조건, 목표, 평가 기준과 같은 구체적인 요구상 리먼츠를 구체화하는데 도움을 주는 국제 표준입니다. 어, 제가 항상 강조드리는 얘기가 있죠. 전문가는 네피셜이 아니라 기준, 정확한 기준을 가지고 일을 하고 그 기준 중에서 아주 신뢰할 만한 것이 국제 표준이라고 강조하고 있습니다. 그래서 여러분들도 이런 국제 표준을 기준을 삼고 어 아키텍처 설계할 때 품질의 목표를 정의하고 측정의 기준을 삼으시기 바랍니다. 자 250 어 제품 품질 모델을 간단히 보겠습니다. 자, 소프트웨어 제품에 품질를 아홉 개의 특성으로 나눴습니다. 그리고 각 특성에는 또 세부 특성들이 여러 개 있습니다. 자, 여러분들이이 시스템을 설계할 때이 표준에서 정의하는이 품질 특성을 참고해서 품질 기준을 세우시기 바랍니다.

자, 다음으로 ISO 250 제품 품질을 적정한다. 자, 앞서 봤던 250에 품질 특성, 부탁을 어 정량적으로 평가하기 위한 측정 항목을 정의한 국제 표준입니다. 예를 들어서 어 250에 성능 효율성이라는 품질 특성이 있습니다. 자,이 품질 특성의 여러 가지 부탁 중에서 어 시간 효율성이라는 부득성이 있고요.이 이 시간 회율성을 측정하기 위한 측정 항목 응답 시간 적정성이라는 것이 2503에 정의되어 있습니다. 자,이 응답 시간 적정성에 대한 측정 함수입니다. x는 a 나 b입니다. 자, a는 실제이 시스템의 평균 응답 시간이고요. B는 우리의 목표 어, 응답 시간입니다. 즉 목표 대비 우리 시스템의 실제 응답 시간이 어떤지를 측정하는 함수죠. 목표가 500m세였는데 응답 시간이 400ms면 1보다 작죠. 즉 우리 목표보다 빠르다는 것입니다. 자, 그런데이 ISO25023에서는 이렇게 측정 항목하고이 측정 항목을 측정하기 위한 측정 함수를 제공을 하고 있지만 여기에 있는이 B 있죠? 목표, 응답, 시간이 수치 자체는 정의를 하고 있지는 않습니다.

당연하겠죠. 자, B는 우리가 정의를 해야죠. 우리 시스템의 목표는 우리가 정하는 거죠. 자, 다시 말해서 ISO는 응답 시간을 어떻게 측정할지는 정의하고 있지만이 목표 응답 시간은 우리가 구축해야 될 시스템의 요구 사항입니다. 자, 표준에서 정의하고 있는 측정 항목과 측정 함수 예시 몇 가지 더 보여 드리겠습니다. 성능 효율성이라는이 품질 특성의 측정 항목은 앞서 보셨던이 응답 시간의 적정성 있고요. 그리고 평균 응답 시간도 있고요. 또 평균 처리량도 있습니다. 그리고 신뢰성이라는 품질 특성의 측정 항목으로는 시스템 가용성이라는이 측정 항목이 있고요. 가용성은 명시된 운영 시간 대비해서 실제로이 시스템이 제대로 장애 없이 운영된 시간의 비율입니다. 자, 표준에서는 이것 말고도 각 품질 특성에 해당되는 많은 특정 항목을 제시하고 있습니다. 자, 앞에서이 목표값 B 이것은 우리 시스템의 요구 사항이니까 어 우리가 정의해야 된다고 말씀을 드렸죠. 자, 예를 들어서 정권 주문 시스템이 있고 산 게시판이 있다고 해 보겠습니다.

자, 여기서 측정 항목과 측정 함수는이 표준에서 동일하게 제공하고 있고 두 시스템에서도이 표준의 내용을 사용하면 되는 거죠. 그렇지만이 목표 응답 시간은 시스템의 특징에 따라 다르겠죠. 정권 주문 시스템은 굉장히 실시간을 보장하는 즉 아주 빨라야 되겠죠. 하지만 산내 개시판은 그렇게 빠를 필요는 없겠죠. 자,이 수치는 예시입니다. 그래서 표준을 기반으로 해서 동의한 적정 항목과 측정 방법을 사용을 하지만 어 다른 목표값으로 검정을 해야 되고 그 목표값을 설정을 해야 된다는 것입니다. 자, 표준에서도 이렇게 얘기하고 있습니다. 목표값은 우리 시스템 요구 사항에 일부러 우리가 정의해야 된다. 자, 그러면 어, 실무에서 어떻게 적용할지 한번 보겠습니다. 자, 앞서 빠르게 해 주세요라는 요청이 있었습니다. 자, 우리 아키텍터들은이 빠르게를 품질 특성 즉 성능 효율성이라는 품질 특성으로 변경을 하고요.이 품질 특성을이 어떻게 측정할지 기준을 정합니다. 자, 평균 응답 시간과 응답 시간의 적정성이 있었죠. 표준에서.이 이 표준의 측정 항목을 참고를 하고 어 그리고 우리의 합격선을 정의를 합니다.이 측정 항복을 달성하기 위한 조건과 목표를 구체화시킵니다.

자 정상부화 500TPS 트래픽 환경에서 주문 API의 95%의 응답 시간을 500ms 이하로 해야 된다. 이때 오류율은 0.1% 1% 이하가 되어야 된다. 자, 이게 우리 시스템의 성능에 대한 품질 목표이고 판단 기준이고 검정 통과 기준이 되는 거죠. 자, 이것을 검정하기 위해서 부하 테스트를 500 TPS로 일으키고이 결과들을 보는 거죠. 그리고 합격, 불합격을 판단을 하는 거죠. 자, 이때이 성능을 달성하기 위한 여러 가지 아키텍처 전략, 캐시, 뭐 코리, 튜닝, 스케일, 아웃 같은이 설계 전략들을 적용을 해야 되겠죠. 자, 실무 적용 두 번째 사례입니다. 자, 장애가 안 나게 해 주세요. 자, 아키텍터 여러분, 이것은 가용성이라는 품질 특성으로 기준을 세워야 되겠죠. 그리고이 가용성의 측정 항목을 찾아보면이 시스템 가용성 그리고 평균 복구 시간 같은 것들이 있습니다. 자,이 측정 항목을 기반으로 해서 구체적인 조건과 목표를 설정을 하는 거죠. 예를 들어서 월 가용성을 99.95% 95% 이상으로 한다.

그리고 어 복구 시간에 대한 목표는 핵심 주문이 10분 내에 복구되어야 한다. 또는 평균 복구 시간이 10분 이하여야 한다. 이렇게 구체적인 목표 조건 대상을 지정을 하고요. 그리고 나서이 목표를 달성하기 위한 아키텍처 전략들 텍틱들이죠. 이중화 페일오버 백업 모니터링 같은이 아키텍처 전략을 적용을 합니다. 그리고 나서 어 검정을 하는 거죠. 실제 검정은 우리가 합격선을 이미 정했죠. 그래서 가동 시간을 집게해 보고 장애 복구에 대한이 훈련을 해보면 우리가 목표로 세운 이것을 달성할 수 있는지 확인할 수가 있겠죠. 어 참고로이 가용성 99.95%를 5%를 시간으로 환산해 보면 22분입니다. 30일 24시간 * 7 기준으로 단순 계산을 한 것이고요. 30일 동안 22분 이하의 장애만 허용한다는 거죠. 자, 실무 적용 세 번째. 자, 보안을 강화해 주세요. 자, 이제 잘 아시겠죠? 품질 특성 보안이죠. 자, 보안에 대한 측정 항목을 찾아보면 사용자 감사 추적 완전성이라는 측정 항목이 있습니다. 자, 이것 말고도 여러 가지가 있습니다.

여기서 우리는이 감사 추적에 대한 보안 기준을 세우고 있고요. 우리의 합격서는 어, 관리자 개인 정보 조회을 대상으로 정하고 목표는 감사로 기록률 100%라고 기준을 명확하게 정합니다. 그리고 나서이 전략들을 세우죠. 감사 로그를 설계하고 중앙에 로그 수집기를 만들고 어 로그가 위조되거나 변조되지 않도록 하고 그리고 보관 정책을 설정을 하는 거죠. 그리고 나서 검증을 하는 거죠.이 시스템에 이런 감사 로그가 잘 쌓이고 있는지 그 행위와 로그를 일대일로 대조해 봐서 어 100% 로그로 남겨지고 있는지를 보는 것이고 100% 남겨지고 있으면 합격인 거죠. 자, 여러분, 빠르게 안전하게가 아니라 목표가 정확해야 설계가 결정이 됩니다. 그리고 이렇게 정확한 기준으로 목표를 세워야 또 검증이 가능하겠죠. 성능 조를 어떤 품질 특성과 측정 항모 그리고 구체적인 품질 목표인지를 정하고요.이 품질 목표가 아키텍처에 큰 영향을 준다면 그것이 바로 아키텍처 드라이버가 될 테고요.이 드라이브를 만족시키기 위한 설계 전략 결정을 해야 되겠죠.

그리고 나서 설계한 대로 구현을 하고 테스트를 하고 앞서 세웠던이 기준을 통과하는지 판단을 해 보면 되겠죠. 어, 만일 통과하지 못하면 설계를 재금토하고 다시이 루프를 거치면 되겠죠. 자, 그래서 우리이 아키텍트 그리고 아키텍처 설계에 중요한 역할 중 하나가 막연한이 품질 목표 성능 좋게 있죠.이 이 막연한 품질 목표를 구체적인 설계 결정으로 바꾸는 것입니다. 중요합니다. 자, 이것은 AI에게 일을 맡길 때도 똑같습니다. 자, AI한테 성능 좋게 만들어 줘. 이렇게 하면 어떻게 될까요? AI는 자기 기준으로 해석을 하겠죠. 뭐 물론 질문도 뭐 하겠죠. 자, 근데 우리가 기준이 없으면 합격인지 아닌지를 판단할 수가 없겠죠. 그래서 측정 가능한 기준 검증 기준을 세워서 아래와 같이 이렇게 요청을 하거나 컨텍스트를 제공하거나 검증 기준을 제공을 해야 됩니다. 성능 좋게 만들어 줘가 아니라 500TPS에서 주문 API가 P95ms 이하를 만족할 것 이걸 위한 설계 전략과 어 보화 테스트 기준 검증 기준을 세우고 결과를 보고해 줘.

그래서 A한테도 측정 가능한 기준으로 일을 시키고 그 기준으로 검증할 수 있도록 일을 시켜야 합니다. 자, 정리하겠습니다. 빠르게 장애에 강하게 보완을 좋게가 아니라 품질 특성 식별하고이 특성에 맞는 측정 항목 도출하고 구체적인 조건과 목표를 세우고 이에 맞는 설계를 하고 우리가 기준을 세운 대로 측정하고 검증을 하는 것이죠. 수치화를 할 수 있다면 수치화하는 것이 가장 좋고요. 또 어떤 경우는 수치화를 못 하는 경우도 있습니다. 그럴 때는 최소한 검증 가능한 기준을 세우는 것이 좋고요. 그 기준을 정할 때 이런 표준을 참고하라는 말씀입니다. 자, 측정할 수 없으면 관리할 수 없고 관리할 수 없으면 개선할 수 없다는 말이 있습니다. 우리가 시스템을 개발할 때 측정 가능하게 기준을 세우고 그것을 관리하고 그렇게 해서 개선해 나가는 것이 중요합니다. 제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다.

AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다. 그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. [음악] 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.