'Techniques'에 해당되는 글 17건

  1. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - Governance and Leading from the Center
  2. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - Exception Handling
  3. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - Technical Debt
  4. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - Governance Through Code
  5. 2019/01/12 용비 Chapter 02. The Evolutionary Architect - The Required Standard
◀ 이전페이지 1 2 3 4 다음페이지 ▶

Chapter 02. The Evolutionary Architect - Governance and Leading from the Center

Techniques/Building Microservices 2019/01/12 19:14 용비
Governance and Leading from the Center
(센터에서의 거버넌스와 리딩(리더십))

아키텍트가 처리해야만 하는 부분에는 거버넌스가 있습니다. 거버넌스가 무엇을 의미합니까?
Control Objectives for Information and Related Technology (COBIT) (정보 및 관련 기술에 대한 제어 목표?)는 꽤 좋은 정의를 가지고 있습니다.

거버넌스는 이해관계자(stakeholder)의 요구, 조건, 옵션을 평가하여 기업의 목표(enterprise objective)가 달성될 수 있도록 보장합니다.
우선순위와 의사 결정을 통한 방향 설정, 동의된 방향 및 목표에 대한 성과와 컴플라이언스(법령 준수), 진행 상황을 모니터링합니다.
------ COBIT 5

거버넌스는 IT 포럼에서 여러 가지 사항에 적용될 수 있습니다.
아키텍트의 업무라고 생각하는 기술적인 거버넌스 측면에서만 중점을 두기 원합니다.
만약 아키텍트의 업무 중 하나가 기술적인 비전을 보장하는 것이라면, 거버넌스는 우리가 구축하는 것과 비전을 일치시키고, 필요하면 이 비전을 발전시키는 것입니다.

아키텍트는 많은 것들을 책임지고 있습니다.
아키텍트는 개발을 가이드할 수 있는 일련의 원칙들이 있는지, 이 원칙들이 조직의 전략과 일치하는지를 확인해야 합니다.
아키텍트는 이러한 원칙들이 개발자들을 비참하게 만드는 실무 실행절차들을 요구하지 않도록 확실히 해야 합니다.
아키텍트는 최신 새로운 기술을 파악하고, 언제 올바르게 절충(trade-offs)해야 하는지 알아야 합니다.
이것은 대단한 책임입니다.

또한 이 모든 것과 함께 사람들을 데리고 가야 합니다.
함께 일하는 동료들이 결정을 이해하며 일을 하고, 그것을 수행하게 하기 위해서입니다.

그리고 이미 언급했듯이, 의사 결정과 심지어 코드에 대한 영향을 이해하기 위해서 팀과 함께 약간의 시간을 보내는 것이 필요합니다.

힘든 주문인가요?
전혀 아닙니다.

그러나 이것을 홀로 해서는 안 된다는 견해에 대해서 확고합니다.
제대로 기능을 수행하는 거버넌스 그룹은 함께 작업을 공유하고 비전을 형성할 수 있습니다.
일반적으로, 거버넌스는 그룹 활동입니다.

규모가 작은 팀과의 비공식적인 채팅이거나 더 큰 범위의 정식 그룹 멤버십을 가진 더 구조화된 정규 미팅일 수도 있습니다.
이것이 우리가 앞에서 다룬 원칙들이 필요에 따라 논의되고, 변경되어야 한다는 것에 대해서 내가 생각한 것입니다.
이 그룹은 기술자에 의해 주도되어야 하고, 지배적인 업무를 수행하는 사람들로 주로 구성되어야 합니다.

이 그룹은 또한 기술 위험에 대해 추적하고 관리해야 합니다.

내가 가장 좋아하는 모델은 아키텍트가 그룹의 의장을 맡는 것이지만, 대부분의 그룹은 최소한 각 팀을 리드하는 각 딜리버리 팀(delivery team)의 기술자들로 이루어진 것입니다.
아키텍트는 그룹이 동작하는지 확인할 필요가 있습니다만, 그룹 전체가 거버넌스를 담당해야 합니다.
이것은 부하를 공유하고, 높은 수준의 승인(high level buy-in)을 보장합니다.
또한 팀에서 그룹으로 정보가 자유롭게 흘러가게 하고, 결과적으로 의사 결정이 훨씬 더 현명하게 이루어지고, 많이 알게 됩니다.

가끔, 그룹은 아키텍트가 동의하지 않는 의사 결정을 내릴 수 있습니다.
이 시점에서 아키텍트는 무엇을 해야 할까요?
전에 이 직책에 있었기 때문에, 이것이야말로 직면할 수 있는 가장 어려운 상황 중 하나라고 말해줄 수 있습니다.

종종, 나는 그룹 결정과 함께 가야하는 접근 방식을 택합니다.
사람들을 확신시키는데 최선을 다했다고 생각하지만, 궁극적으로 충분히 확신을 주지 못했습니다.
그룹은 종종 개인보다 훨씬 현명합니다. 그리고 나는 한번 이상 잘못했습니다.

그룹이 결정을 내리도록 공간이 주어지고 궁극적으로 무시되는 것에 대해서 어떻게 권한을 빼앗을 수 있는지 상상해 보십시오.
그러나 가끔 나는 그룹을 배제했습니다. 왜? 언제 그랬을까요?
라인(line)을 어떻게 선택합니까?
아이들에게 자전거를 타는 법을 가르치는 것에 대해서 생각해 보십시오.
여러분이 그들을 위해서 탈 수는 없습니다.

여러분은 아이들이 흔들리는 것을 보지만, 만약 여러분이 아이들이 떨어질 것처럼 보일 때마다 매번 개입했다면, 아이들은 결코 배우지 못하고, 어떤 경우에는 여러분이 그럴 것이라고 생각하는 것보다 훨씬 덜 넘어집니다.
그러나 만약 차가 다니는 방향으로 방향을 바꾸거나, 근처의 오리 연못으로 향한다면, 여러분이 개입해야 합니다.

마찬가지로 아키텍트로서 비유적으로 여러분의 팀이 오리 연못으로 방향을 잡고 있을 때, 확고한 이해력을 가지고 있어야 합니다.
또한, 심지어 여러분 자신이 옳다는 것을 알고 있고, 팀을 지배하고 있다면, 이것이 여러분의 지위를 손상시키고, 팀이 말을 하지 않는다고 느끼게 만들 수 있음을 깨달아야만 합니다.

때로는 올바른 일은 여러분이 동의하지 않은 결정에 따르는 것입니다.
이것을 언제 해야 하는지, 언제 하지 않아야 하는지를 아는 것은 어려운 일이지만, 때때로 중요합니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/818

Chapter 02. The Evolutionary Architect - Exception Handling

Techniques/Building Microservices 2019/01/12 17:47 용비
Exception Handling
(예외 처리)

원칙과(principle) 실행 절차(사례:practice)는 어떻게 시스템을 구축해야 하는지 가이드합니다.
그러나 시스템이 이것을 벗어날 경우 무슨 일이 발생할까요?
때때로, 규칙에 예외가 되는 결정을 하게 되는 경우도 있습니다.

이러한 경우, 나중에 참조할 수 있도록 로그로 그러한 결정을 캡쳐할 가치가 있을 수도 있습니다.
충분한 예외가 발견된다면, 결국 세계에 대한 새로운 이해를 반영하기 위하여 원칙이나 실행절차를 변경해야 할 수도 있습니다.

예를 들면, 데이터 스토리지로 MySQL을 항상 사용할 것이라는 사례가 있을 수 있습니다.

그러나 "카산드라를 사용하는 경우에, 볼륨이 크게 증가하지 않는다면, 대부분의 스토리지 요구사항에 MySQL을 사용하십시오."라고 말하지만, 실행 절차를 변경하여 확장성이 뛰어난 스토리지를 위해서 카산드라(Cassandra)를 사용해야만 하는 강제적인 이유가 있을 수 있습니다.

그러나, 모든 조직이 다르다는 것을 되풀이할 가치가 있습니다.
나는 개발팀이 높은 신뢰와 자율성을 가지고 원칙이 가벼운 (분명한 예외 처리의 필요성이 제거되지 않으면, 크게 감소합니다.) 몇 개의 회사와 작업을 한 적이 있습니다.

개발자들이 덜 자유로운 더 구조화된 조직에서는 예외를 추적하는 것이 사람들이 직면한 과제들을 적절하에 반영하기 위해서 규칙들이 필수적일 수 있습니다.

언급된 이 모든 것들과 함께, 나는 가능한 훨씬 자유롭게 손에 있는 문제를 해결하는, 팀의 자율성을 최적화하기 위한 방법으로 마이크로서비스의 팬입니다.

만약 개발자들이 수행하는 방법에 많은 제약을 가하는 조직에서 일을 한다면, 마이크로서비스가 여러분에게 도움이 되지 않을 수 있습니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/817

Chapter 02. The Evolutionary Architect - Technical Debt

Techniques/Building Microservices 2019/01/12 17:46 용비
Technical Debt
(기술적인 부채)

종종 기술 비전에 대한 레터(letter : 편지)를 통해 따라갈 수 없는 상황에 놓이게 됩니다.
어떤 긴급한 기능을 얻기 위해서 몇 가지 모서리를 자르는 선택을 해야 할 때도 자주 있습니다.
이것은 우리가 알아야 하는 하나 이상의 trade-off(장단점) 입니다.
우리의 기술적 비전은 이유가 있습니다.

만약 우리가 이러한 이유에서 빗나가게 되면, 단기적으로는 이익을 얻을 수 있지만, 장기적으로는 비용이 들게 됩니다.

이러한 trade-off(장단점)을 이해하는데 도움이 되는 개념이 바로 기술적 부채(technical debt)입니다.
기술적인 부채가 생기게 되면, 실제 세상에서의 부채와 마찬가지로 지속적인 비용이 들게 됩니다.
그리고 우리가 지불하고자 하는 어떤 것이 있게 됩니다.

때때로 기술적 부채는 지름길을 취해서 야기되는 어떤 것만 있는 것은 아닙니다.
만약 우리 시스템이 바뀌지만, 시스템의 모든 것이 일치하지 않는다면 무슨 일이 발생할까요?
이러한 상황에서도, 기술적 부채의 새로운 소스가 만들어지게 됩니다.

아키텍트의 임무는 더 큰 그림을 보고 이 균형을 이해하는 것입니다.
부채의 수준에 대한 뷰를 가지고, 어디에 참여하게 되는지가 중요합니다.

조직에 따라 적절한 가이드를 제공할 수는 있지만, 팀 자체적으로 어떻게 채무를 추적하고 지불하는지 결정하게 해야 합니다.

다른 조직의 경우에는 정기적으로 검토되는 채무 기록을 유지하는 것처럼, 더 구조화되어야할 수도 있습니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/816

Chapter 02. The Evolutionary Architect - Governance Through Code

Techniques/Building Microservices 2019/01/12 16:45 용비
Governance Through Code
(코드를 통한 거버넌스)

함께 모여서 어떻게 일을 할지에 대해서 동의하는 것은 좋은 아이디어입니다.

그러나 사람들이 이러한 가이드라인을 따르도록 하는데 시간을 낭비하는 것은 각 서비스에서 기대하는 모든 이러한 표준들을 구현하는 것이 개발자들에게는 부담이 되므로 더 재미가 없습니다.

나는 올바른 일을 더 쉽게 하도록 하는 위대한 신봉자입니다.

내가 여기서 잘 보여주는 2가지 기법은 예제를 사용하고, 서비스 템플릿을 제공하는 것입니다.

Exemplars
(예제)

문서화를 하는 것은 좋고, 유용합니다.
그 가치를 분명하게 보았고, 결국 나는 이 책을 쓰게 되었습니다.
그러나 개발자는 코드, 즉 실행할 수 있고, 탐구할 수 있는 코드를 좋아합니다.

만약 여러분이 장려하고 싶은 표준이나 모범 사례(Best Practice)를 가지고 있다면, 사람들에게 가리킬 수 있는 예제를 갖고 있는 것이 유용합니다.

아이디어는 사람들이 시스템의 더 좋은 부분의 일부를 모방하는 것만으로는 잘못될 수 없다는 것입니다.

이상적으로는, 방금 구현된 격리된 서비스(isolated service)가 아니라 완벽한 예제가 되도록 올바르게 동작하는 실제 서비스(real-world service)를 제공해야만 합니다.
예제가 실제로 사용되고 있음을 보장함으로써, 모든 원칙들이 실제로 의미가 있음을 보장할 수 있습니다.

Tailored Service Template
(맞춤형 서비스 템플릿)

여러분이 매우 적은 업무로 가지고 있는 대부분의 가이드라인을  따르는 것이 모든 개발자가 정말로 쉽게 일하게 할 수 있는 것이라면, 대단하지 않을까요?

만약, 특별히, 개발자들이 각 서비스에서 필요로 하는 핵심 속성들을 구현할 수 있는 대부분의 코드를 가지고 있다면 어떨까요?

Dropwizard와 Karyon은 2개의 JVM 기반 마이크로 컨테이너 오픈소스입니다.

그것들은 Health-Checking, HTTP 제공, 메트릭 노출과 같은 기능을 제공하는 라이브러리 세트를 함께 사용하여 유사한 방식으로 동작합니다.

따라서, 특별히, 명령줄(command line)에서 실행될 수 있는 임베디드 서블릿 컨테이너(embeded servlet container)를 가진 완전한 서비스를 제공할 수 있습니다.

이것은 시작하기 좋은 방법이지만, 거기서 멈추는 이유는 무엇일까요?

하는 김에(while we are at it), 왜 Dropwizard나 Karyon과 같은 어떤 것을 사용하지 않을까요?
그리고 왜 맥락(context)에 적합해지도록 더 많은 기능을 추가하지 않을까요?

예를 들면, Circuit breaker를 필수적으로 사용하도록 할 수 있습니다.
이 경우, Hystrix와 같은 Circuit Breaker 라이브러리를 통합할 수 있습니다.

또는 모든 메트릭을 중앙의 Graphite 서버로 보내야 할 수도 있기 때문에 Dropwizard 메트릭과 같은 오픈소스 라이브러리를 가져와서 설정하여 알려진 위치로 응답 시간과 오류율(error rate)을 자동으로 Push할 수 있습니다.

자신만의 개발 사례 세트에 대한 그러한 맞춤형 서비스 템플릿으로 인해 팀이 더 빠르게 시작할 수 있고, 또한 개발자들이 서비스가 안 좋게 동작하도록 하는 방법에서 떠나도록 할 수 있습니다.

물론, 만약 다른 여러 가지 기술 스택을 포용한다면, 각각의 경우에 맞는 서비스 템플릿이 필요합니다.
이것은 미묘하게도 여러분의 팀에서 언어 선택 제약 사항이 될지도 모릅니다.

만약, 사내(in-house) 서비스 템플릿이 단지 자바만 지원한다면, 사람들은 대체 스택을 선택하면 많은 일을 해야만 하는 경우, 대체 스택을 선택하는 것에 대해서 낙심하게 될지도 모릅니다.

예를 들어, Netflix는 시스템의 한 부분의 작동 중지로 모든 것이 다운되지 않을 수 있도록 보장하기 위해서 내결함성(fault tolerance)와 같은 측면에 특히 관심을 가지고 있습니다.

이것을 처리하기 위해서, JVM 클라이언트 라이브러리가 있는 팀에 서비스가 잘 동작하도록 유지하는데 필요한 도구를 제공하기 위해 엄청난 노력을 하고 있습니다.

새로운 기술 스택을 소개받은 사람은 누구나 이 모든 노력을 재현해야함을 의미합니다.
Netflix의 주요 관심사는 중복된 노력을 덜하는 것보다 잘못되는 것이 너무 쉽다는 사실에 있습니다.

새롭게 구현된 내결함성(fault tolerance) 오류를 가진 서비스의 위험은 그 서비스가 시스템에 더 많은 영향을 줄 수 있을 때 높습니다.

Netflix는 적절한 라이브러리를 사용하는 JVM과 로컬로 통신하는 사이드카 서비스(sidecar service : 효력을 정지하는 서비스)를 사용하여 이 위험을 완화합니다.

여러분은 서비스 템플릿의 생성이 코드를 통해 일을 해야만 하는 방법을 지시하는 중앙 도구나 아키텍처 팀의 일이 되지 않도록 주의를 기울여야 합니다.

여러분이 사용하는 사례를 정의하는 것은 집합적인 활동이어야 합니다. 따라서, 이상적으로는 여러분의 팀이 이 템플릿을 업데이트하는 책임을 져야 합니다. (내부 오픈소스 접근 방식이 여기에서는 적합함).

또한, 그들이 신뢰하는 필수적인 프레임워크로 인해 많은 팀의 사기와 생산성이 파괴된 것을 보았습니다.

코드 재사용성을 향상시키기 위해서, 압도적인 괴물이 될 때까지 점점 더 많은 작업이 중앙집중화된 프레임워크에 위치하게 됩니다.

만약 여러분이 맞춤형 서비스 템플릿을 사용하기로 결정한다면, 그 일이 무엇인지에 대해서 매우 주의깊게 생각하십시오.

이상적으로, 그 템플릿의 사용은 순전히 선택적이어야 하지만, 만약 여러분이 그것의 취사 선택에서 더 강력하게 되는 경우, 개발자들을 위한 사용 용이성이 주요한 안내력(guiding force)이 되어야 한다는 것을 이해해야만 합니다.

또한, 코드 공유의 위험에 대해서 알고 있어야만 합니다.

재사용 가능한 코드를 만들기 위한 우리의 욕망으로 인해 서비스간 커플링 소스(밀접하게 엮여 있는 소스)를 만들 수 있습니다.

최소한 내가 말했던 조직 중 하나는 실제로 각 서비스에 수동으로 서비스 템플릿 코드를 복사하는 것에 대해 걱정하고 있습니다.

핵심 서비스 템플릿으로 업그레이드하는 것이 시스템 전반에 걸쳐 적용되는데 더 오래 걸리지만, 커플링 위험보다 덜 중요하다는 것을 의미합니다.

내가 말한 다른 팀들은 지나치게 결합된 시스템에서 DRY(스스로 반복하지 않음 : don't repeat yourself) 결과에 대한 경향이 되지 않도록 매우 부지런해야함에도 불구하고, 서비스 템플릿을 공유 바이너리 종속성(shared binary dependency)처럼 간단하게 취급합니다.
(DRY 결과로 인한 경향이 지나치게 결합된 시스템이 되지 않도록 매우 부지런해야함에도 불구하고, 단순히 서비스 템플릿을 공유 바이너리 종속성으로 취급합니다.)

이것은 미묘한 주제이므로, 4장에서 더 자세히 살펴보겠습니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/815

Chapter 02. The Evolutionary Architect - The Required Standard

Techniques/Building Microservices 2019/01/12 15:08 용비
The Required Standard
(필수 표준)

사례를 통해 작업하고 trade-pffs(장단점)에 대해서 생각할 때, 발견해야할 핵심 균형 중 하나는 시스템에 얼마나 많은 가변성을 허용할 것인가입니다. 서비스에서 서비스까지 일정해야 하는 것이 무엇인지를 식별하는 핵심 방법 중 하나는 잘 동작하고, 좋은 서비스가 어떻게 보일지를 정의하는 것입니다.

시스템에서 "훌륭한 시민" 서비스는 무엇일까요?

시스템이 관리 가능하고, 하나의 나쁜 서비스가 전체 시스템을 중단시키지 않도록 하기 위해 필요한 기능은 무엇입니까?

그리고 사람들과 마찬가지로, 하나의 맥락에서 훌륭한 시민이 다른 곳에서 좋게 보이는 것이 무엇인지를 반영하지는 않습니다.

그럼에도 불구하고, 잘 동작하는 서비스는 관찰하는 것이 매우 중요하다고 생각하는 공통적인 특징을 가지고 있습니다.
이것은 너무 많은 발산을 허용하게 되면, 꽤나 심각한 시간을 야기시킬 수 있는 몇 안 되는 주요 핵심 영역입니다.

Netflix의 Ben Christensen은 더 큰 그림을 생각할 때, "자율적인 수명주기(lifecycle)을 가지고 있지만, 모든 것이 함께 잘 어울리는  많은 작은 부분으로 이루어진 응집력 있는 시스템이 되어야 한다"고 말했습니다.

따라서, 큰 크림에 대한 시각을 잃어버리지 않고, 개별적인 마이크로서비스의 자율성을 최적화하는 것의 균형을 찾아야만 합니다.

각 서비스가 가져야 하는 명확한 속성(attribute)을 정의하는 것은 균형이 어디에 있는지를 분명하게 하는 한 가지 방법입니다.

Monitoring
(모니터링)

시스템의 건강에 대한일관성 있는 서비스 전반에 걸친 뷰(Cross-Service View)를 작성할 수 있어야 합니다.

이것은 서비스별 관점이 아닌, 시스템 전체적인 관점이어야 합니다.
8장에서 논의하겠지만, 개별 서비스의 상태를 아는 것은 유용하지만, 종종 더 낣은 문제를 진단하거나 더 커다란 트렌드를 이해하려고 하는 경우에만 유용합니다.

가능한 한 이것을 쉽게 하기 위해서 모든 서비스가 동일한 방식으로 상태(health)와 일반적인 모니터링 관련 메트릭을 내보내도록 하는 것이 좋습니다.

각 서비스가 중앙 위치로 이러한 데이터를 Push해야 하는 Push 메커니즘을 채택할 수 있습니다.
메트릭의 경우에는 Graphite를, Health를 위해서는 Nagios를 사용할 수 있습니다.

또는 노드 자체에서 데이터를 긁어서 보내는(Scrape) 폴링 시스템(Polling System)을 사용하도록 결정할 수도 있습니다.

박스 내부를 불투명하게 하고, 모니터링 시스템이 그것을 지원하기 위해 변경되지 않도록 하십시오.
로깅(logging)도 같은 범주에 속합니다. 모두 한 곳에서 필요합니다.

Interfaces
(인터페이스)

작은 수의 정의된 인터페이스 기술을 도입하는 것은 새로운 인터페이스 호출 서비스(Consumer)를 통합하는데 도움이 됩니다.
하나의 표준을 가지는 것이 좋습니다. 2개도 나쁘지 않습니다.
20개의 다른 스타일의 통합은 나쁩니다.

이것은 단지 기술과 프로토콜 선택에 대한 것이 아닙니다.

예를 들면, 만약 HTTP/REST를 선택한다면, 동사나 명사를 사용합니까?
자원에 대한 페이지화(pagenation)는 어떻게 처리합니까?
End-point의 버전관리는 어떻게 하나요?

Architectural Safety
(아키텍처적인 안전성)

나쁘게 동작하는 하나의 서비스가 파티의 모든 사람에게 손해를 끼치게 할 수 없습니다.

우리는 우리 서비스가 건강하지 않은(unhealthy) 다운스트림 호출(downstream call:외부에서 내려오는 호출)로부터 스스로를 보호할 수 있도록 보장해야 합니다.
다운스트림 호출의 잠재적인 실패를 적절하게 처리하지 못하는 서비스가 더 많을 수록, 시스템은 더 취약해질 것입니다.

적어도 각 다운스트림 서비스가 자체 Connection Pool을 가지도록 요구하고, 또한, 각 서비스가 Circuit Breaker를 사용하도록 말할 수 있을지도 모릅니다.

11장에서 마이크로서비스 확장(Microservices at scale)에 대해서 논의할 때, 더 깊이 있게 다룰 것입니다.

응답 코드에 대해서도 또한 규칙을 적용하는 것이 중요합니다.
만약 Circuit Breaker가 HTTP 코드를 사용하고, 하나의 서비스가 에러에 대해서 2XX 코드를 보내거나 4XX 코드를 5XX 코드로 혼동하여 보내는 경우에는 이러한 안전 조치가 분리될 수 있습니다.

유사한 문제가 HTTP를 사용하지 않는 경우에도 발생할 수 있습니다.
OK 및 올바르게 처리된 요청과 나쁘고 서비스가 수행되지 못하게 하는 요청, OK이지만 서버가 다운되어 확인할 수 없는 요청 사이의 차이를 아는 것은 빠르게 실패하고 이슈를 추적할 수 있는 것을 보장하는 핵심입니다.

만약 우리 서비스가 이러한 규칙에 대해 불성실하게 되면, 결국 더 취약한 시스템을 가지게 됩니다.
TAG , , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/814

◀ 이전페이지 1 2 3 4 다음페이지 ▶