Internet Information Services: Scaling ASP.NET Applications: Lessons Learned

아티클
08/24/2016

인터넷 정보 서비스

ASP.NET 응용 프로그램 확장: 교훈

Richard Campbell

한 눈에 보기:

개발자/IT 협력의 중요성
주 확장 전략 이해
여러 팀 간의 지식 공유
핵심적인 지식에 대한 합의

제가 컨설턴트 자격으로 참여하여 성공을 거둔 모든 ASP.NET 응용 프로그램 확장 프로젝트는 응용 프로그램 개발자와 실제로 응용 프로그램을 실행하는 네트워크 관리자 간에 긴밀한 협력이 이루어진 결과였습니다. 응용 프로그램 수명 주기의 처음부터

이러한 협력의 필요성이 항상 명확하게 드러나는 것은 아닙니다. 따라서 응용 프로그램 수명 주기의 시작 단계부터 참여한 적은 없었습니다. 문제가 발생하는 끝 단계에 와서야 그러한 기회가 주어질 뿐입니다.

어떤 응용 프로그램 확장도 처음부터 효과를 발휘할 수 없다는 것은 당연한 사실입니다. 완벽한 상태로 첫 선을 보이는 것은 불가능하기 때문입니다. 응용 프로그램을 성공적으로 확장하기 위해서는 응용 프로그램이 어떻게 구축되었는지 그리고 그 응용 프로그램이 실행되는 운영 환경이 어떻게 작동하는지 파악해야 합니다. 다시 말해서 개발 담당자와 네트워크 담당자의 의견을 모두 수렴해야 합니다. 이러한 지식 공유가 이루어지지 않는다면 성공할 수 없습니다.

확장의 기초

본론으로 들어가기에 앞서, ASP.NET 응용 프로그램을 확장하기 위한 준비가 필요합니다. 일반적으로 사용되는 두 가지 기본 전략은 전문성(specialization)과 배포(distribution)이며, 대개 ASP.NET 응용 프로그램 확장에서는 두 전략을 모두 적용합니다. 또한 ASP.NET 응용 프로그램 확장에 도움이 되는 모든 방법은 두 전략 중 하나로 분류됩니다.

전문성은 응용 프로그램의 요소를 분리하여 독립적으로 확장할 수 있게 합니다. 예를 들어, ASP.NET 페이지를 렌더링하는 서버를 그대로 사용하지 않고 전용 이미지 서버를 구축할 수도 있습니다. 이미지 서버의 최적의 구성은 ASP.NET 서버와는 크게 다릅니다. 또한 이미지 요청을 응용 프로그램의 나머지 부분과 분리하면 타사 리소스를 이미지 서비스에 사용하는 것이 가능해집니다. 이와 동일한 방식을 다른 리소스 파일에도 적용할 수 있습니다.

한편 배포는 웹 팜(web farm)이라고 하는 여러 서버에 응용 프로그램을 대칭적으로 분산시키는 것입니다. ASP.NET 응용 프로그램은 특히 배포에 적합합니다. 각각의 개별 페이지 요청은 작은 편이고, 대개 사용자마다 상호 작용이 독립적이기 때문입니다. 배포는 하나의 대형 서버가 모든 작업을 수행하는 "수직 확장(scale up)"보다는 중급 성능의 서버 여러 대가 함께 사용자의 요청을 수행하는 "수평 확장(scale out)"이라 할 수 있습니다.

전문성과 배포를 연계하면 효율성이 향상됩니다. 응용 프로그램 중 추가적인 성능이 필요한 요소만 배포할 수 있기 때문입니다. 예를 들어, 전문 이미지 서버를 구축했으나 아직 이미지 서비스가 적합한 수준이 아닌 경우 응용 프로그램 전체에 서버를 추가하지 않고 이미지 서버를 추가할 수 있습니다. ASP.NET 응용 프로그램의 성능과 확장성을 높이고자 할 때 이 전략을 염두에 두어야 합니다.

정보 및 의견 나누기

모든 ASP.NET 응용 프로그램의 수명 주기 중 어느 시점에서 개발자와 네트워크/IT 담당자는 미팅을 갖게 됩니다. 응용 프로그램이 배포되기 전에 이런 자리가 마련되는 다행스러운 경우도 있으나, 응용 프로그램이 테스트 환경에서는 제대로 실행되었으나 사용자에게 공급된 후 속도가 크게 저하되는 경우처럼 문제가 발생한 후에야 미팅을 하게 될 때도 있습니다. 이 시점에서 바로 저와 같은 컨설턴트가 투입되기도 합니다.

개발자와 네트워크 담당자가 만나면 정보를 교환하는 것이 일차적인 목표입니다. 개발자는 응용 프로그램에 대해, 네트워크 담당자는 운영 환경에 대해 핵심적인 지식을 갖고 있습니다. 각 그룹은 상대편 그룹이 보유한 자료를 이해해야 하며, 응용 프로그램의 수명 주기에서 이러한 기회가 일찍 마련될수록 더 효과적입니다.

문제가 발생하고 나서야 처음으로 이러한 미팅이 열려서는 안 됩니다. 두 팀 간에 핵심적인 이해 기반이 조성되지 않은 상태에서는 응용 프로그램이 요구 사항에 미치지 못하는 이유를 밝혀내기가 결코 쉽지 않습니다. 게다가 오로지 상대방에게 문제가 있다는 방어적인 자세로 판단하기가 쉬우며, 그러한 판단은 결코 바람직하지 않습니다. 매우 복잡한 문제를 해결하려면 양측 모두의 노력이 필요합니다.

그러나 순조로운 상황에서도 그러한 미팅은 쉽지 않은 자리가 될 수 있습니다. 지금까지 제가 진행했던 미팅에서는 일반적으로 네트워크 담당자가 테이블의 한쪽에 앉고, 개발 담당자가 반대편에 앉는 상황이 전개되었습니다. 상대편을 응시하면서 시간이 흘러갑니다. 대화가 원활하게 진행되도록 하기 위해 회의의 목표, 즉 정보의 교환을 주지시킵니다. 누가 먼저 말하느냐는 중요하지 않습니다. 여기서는 네트워킹 팀이 개발 팀으로부터 어떤 정보를 얻어야 하는지에 대해 먼저 알아보겠습니다.

네트워킹 팀이 개발 팀에 확인해야 할 정보

ASP.NET 응용 프로그램마다 특이한 점이 있겠지만, 모든 경우에 공통적으로 적용되는 핵심적인 요소도 있습니다. web.config 파일도 그 중 하나입니다(그림 1 참조). Web.config는 개발 영역과 네트워킹 영역이 만나는 교차점입니다. 경우에 따라 개발자가 이를 구성하기도 하고 네트워킹 담당자가 구성하기도 합니다. 어떤 경우에서든 web.config의 내용은 하드웨어 및 네트워크 구성을 제한하며, 응용 프로그램의 작동 방법에 직접적인 영향을 줍니다. web.config 파일의 사소한 점까지 모두 살펴본다면 책 한 권을 채우고도 남을 것입니다. 여기서는 강조하고 싶은 점은 두 그룹 모두 web.config 파일을 연구하여 이 파일이 나타내는 구성의 의미와 다양한 설정이 응용 프로그램과 환경에 미치는 영향에 대해 합의해야 한다는 것입니다.

그림 1 응용 프로그램 설정과 사용자 지정 오류 구성을 보여 주는 기본적인 web.config(크게 보려면 이미지 클릭)

예를 들어, web.config의 <authorization> 섹션은 응용 프로그램에서 사용자를 인증하는 방법을 지정하고 종속성을 정의합니다. 응용 프로그램에서 Windows® 인증을 사용하는 경우 Active Directory®가 필요합니다. 폼 기반의 인증을 사용할 경우에는 사용자 계정의 데이터 저장소가 필요합니다. 이는 분명 의견을 나눌 만한 주제입니다.

<customErrors> 섹션은 오류가 사용자에게 어떻게 나타나는가에 관한 항목이므로 중요하지 않습니다. 복잡한 설정은 아니지만 어떤 오류 페이지가 표시될 것인가에 대한 이해를 돕고자 논의할 만한 가치는 있습니다. 협력 단계의 초기에는 사용자 지정 오류 페이지가 없을 것입니다. 이 점에 관해 의견을 나누는 것도 좋습니다.

web.config의 <appSettings> 섹션은 특히 중요한 의미를 가질 수 있습니다. 이 섹션은 일반적으로 개발자가 전역 변수(예: 데이터베이스 연결 문자열)를 저장하는 곳입니다. 중요한 종속성 소스이며 장애 조치, 마이그레이션 등을 계획할 때 핵심적인 부분을 차지합니다. 그러나 <appSettings>는 완전한 사용자 지정 섹션이므로, 무엇이든 포함할 수 있고 그 내용을 이해하려면 많은 설명이 필요할 수 있습니다. 이 섹션에는 실제로 응용 프로그램의 어느 곳에서도 쓰이지 않는 값이 남아 있는 경우도 많습니다.

개발자가 <appSettings>를 사용하지 않더라도 네트워크/운영 담당자가 원할 수도 있습니다. 모든 데이터베이스 연결 문자열을 여기에 저장하는 것은 간단한 장애 조치 전략을 수립할 수 있는 효과적인 방법 중 하나입니다. 데이터베이스 서버가 중단되면 대체 문자열을 삽입하여 다른 데이터베이스 서버로 연결할 수 있습니다. 개발 주기의 초기에 이러한 기회를 잘 활용한다면 응용 프로그램의 안정성과 유지 관리 편의성을 높일 수 있습니다.

마지막으로, 확장의 관점에서 볼 때 web.config에서 절대적으로 중요한 값 중 하나는 <sessionState> 태그입니다. 이 태그는 응용 프로그램의 세션 데이터가 저장될 위치를 결정합니다. 기본적으로, 세션 데이터는 "InProc", 즉 ASP.NET 응용 프로그램의 프로세스 영역에 저장됩니다. 세션 데이터가 in-process로 구성되는 경우, "Sticky" 부하 분산을 설정해야 합니다. 즉, 특정 사용자의 요청을 세션 데이터가 상주하는 동일한 서버에서 처리해야 한다는 것입니다. 이는 확장 및 장애 조치 방법에 직접적으로 영향을 주기 때문에 개발자와 네트워크 담당자 간에 중요한 대화 주제입니다. 이 사항을 일찍 협의하면 응용 프로그램 디버깅 단계에서 발생할 수 있는 많은 문제를 예방할 수 있습니다.

세션 상태에 관한 대화로 진행되면 응용 프로그램 전반의 부하 분산 요구 사항에 관해 얘기할 수 있습니다. 환경에 따라 특정 기능을 갖춘 부하 분산 전용 하드웨어가 있을 수 있지만, 응용 프로그램에서 이 기능을 제공하지 않더라도 큰 문제는 생기지는 않습니다. 이전에 in-process 세션 데이터가 있는 ASP.NET 응용 프로그램과 함께 하드웨어 부하 분산을 사용한 경우가 있었습니다. 그 결과, 이따금씩 어떠한 설명도 없이 세션 손실이 발생하곤 했습니다. 응용 프로그램의 버그처럼 보였으나 사실은 그렇지 않았습니다. 구성상의 실수였던 것입니다.

네트워크 팀은 해당 응용 프로그램에 어떤 부하 분산 체계가 사용될 것인지에 대해 개발 팀으로부터 정확하게 정보를 받아야 합니다. 사용 가능한 부하 분산 체계와 응용 프로그램의 허용 범위 등에 관해 의견을 나눔으로써 그러한 정보를 확인할 수 있습니다. 응용 프로그램 수명 주기에서 초반에 이러한 대화가 이루어질 경우 가장 큰 이점 중 하나는 out-of-process 방식의 비선호도(non-affinity) 부하 분산 체계로의 진행을 미리 계획할 수 있다는 것입니다.

ASP.NET 응용 프로그램의 배포 준비가 끝나거나 이미 초기 배포 단계에 들어 갔을 경우 개발 팀은 응용 프로그램의 빠른 영역과 느린 영역을 어느 정도 정확히 파악하게 됩니다. 무엇보다도, 시스템의 병목 현상과 잠재적 위험 지점을 알 수 있습니다. 네트워크/운영 팀이 이 병목 현상을 알게 되면 미리 문제에 대비하고 예방할 수도 있을 것입니다.

응용 프로그램 서비스가 중단되는 매일 밤, 대량의 데이터 로드 프로세스를 수행하는 응용 프로그램의 경우를 예로 들어 보겠습니다. 개발자는 데이터 로드 메커니즘을 작성하여 테스트했고 그 작동 방식을 파악했습니다. 이것은 데이터베이스에 상당한 부담이 되기는 하겠지만, 효과적이고 우수한 문제 해결 방법임을 알고 있었던 것입니다.

그러나 그들은 이 프로세스가 실행된다는 사실, 즉 데이터베이스 백업이 실행되는 새벽 1시에 이 프로세스가 실행되도록 예약했다는 사실을 네트워킹 팀에 알리지 않았습니다. 데이터베이스는 온라인 상태였으나 백업 중 실행 속도가 무척 느려졌습니다. 데이터베이스로 보내진 모든 트랜잭션이 트랜잭션 로그에 기록되었기 때문입니다.

데이터 로드와 백업이 동시에 실행되어 데이터베이스 트랜잭션 로그 볼륨이 디스크 공간을 모두 차지하고 나서야 이 충돌 사실이 드러났습니다. 데이터 로드 일정을 새벽 3시에 시작하도록 변경하고 나니 문제가 완전히 해결되었습니다. 그러나 며칠간 위기 상황을 겪은 후였습니다.

이러한 응용 프로그램 작업 부하 항목에 관해 일찍 대화를 나누면 향후 겪게 될 불편을 크게 덜 수 있습니다.

개발 팀이 네트워킹 팀에 확인해야 할 정보

미팅 중 네트워킹 팀이 개발 팀에게 설명하는 시간이 되면 먼저 네트워크 다이어그램으로 시작하는 것이 좋습니다. 개발자는 그림 2와 같이 네트워크를 인식하는 경우가 많습니다. 즉 네트워크 없이 웹 서버, 브라우저 및 인터넷만으로 구성된 모습입니다.

그림 2 네트워크에 대한 개발자의 단순한 시각(크게 보려면 이미지 클릭)

물론 현실은 이보다 훨씬 복잡합니다. 그림 3과 같은 다이어그램이 사실에 더 가깝습니다. 물론 이 역시 매우 단순화시킨 것입니다. 그림 3을 보면 "VPN(Virtual Private Network) 사용자는 응용 프로그램을 어떻게 사용할까?", "내부 사용자와 공용 사용자는 인증이 어떻게 다른가?"와 같은 의문점이 바로 떠오르게 됩니다.

그림 3 개발자가 알아야 할 실제 네트워크의 모습(크게 보려면 이미지 클릭)

물론 네트워크 다이어그램을 제시하는 것만으로는 충분하지 않습니다. 네트워크를 자세히 설명하는 것도 중요합니다. 단지 다이어그램을 보는 것만으로는 정확하게 어떤 요소가 응용 프로그램에 영향을 미칠 것인지 알 수 없기 때문입니다. 공용 사용자, VPN 사용자 및 내부 사용자의 실제 연결 프로세스를 자세히 설명해야 합니다. 그리고 다양한 방화벽 규칙이 있다면 그에 관해서도 설명합니다. 특히 복잡한 DMZ 유형의 네트워크 아키텍처에서는 응용 프로그램 측면에서 잠재적인 문제점이 대두되기 마련입니다.

물론 응용 프로그램이 배포되기 전이나 개발에 착수하기 전에 이러한 사항을 모두 협의하면 좋겠지만, 어느 시점에든 이러한 협의가 반드시 이루어져야 하며 참석한 모든 사람이 네트워크 다이어그램 전체를 제대로 이해하는 것이 중요합니다.

또한 네트워킹은 장애 조치와 중복성 모델이 적용되는 영역입니다. 그러나 소프트웨어적인 지원 또는 최소한 동작에 대한 인식마저 없다면 이 모델은 계획한 대로 작동하지 않을 것입니다. 만일에 발생할 수 있는 다양한 장애 조치 시나리오에 대한 세부적인 협의가 이루어져야 합니다. 데이터베이스에 클러스터링이 구현되는 경우 이는 데이터베이스 액세스 관련 코드에 영향을 미칩니다. 예를 들어, 서버 전환 후 쿼리를 재시도할 수 있는가, 중복 사이트가 있는 경우 그 사이트에 데이터가 어떻게 복제되는가, 다른 사이트로의 전환은 어떻게 이루어지는가 등을 확인해야 합니다.

여기서도 가급적 일찍 이러한 정보를 나누는 것이 유익하지만, 늦더라도 그러한 자리를 마련하는 것이 속수무책인 것보다는 낫습니다. 모든 응용 프로그램 관계자는 이러한 사항을 제대로 이해해야 합니다. 장애 조치 솔루션을 마련했으나 필요한 시점에 제대로 작동하지 않는 것만큼 최악의 경우는 없습니다.

마지막으로, 반드시 공유해야 할 또 하나의 중요한 네트워크 리소스는 프로덕션 로그입니다. 프로덕션 로그를 개발 팀에 제공할 것을 언제나 권장합니다. 이러한 요청에 대한 네트워크 팀의 통상적인 답변은 "개발 팀한테 우리에게 요청하라고 하세요. 그러면 보내주겠소."입니다. 이는 올바른 방법이 아니라고 생각합니다. 개발자가 주로 백업 사이트에서 스스로 로그를 검색할 수 있게 하는 것이 훨씬 더 효과적입니다.

문제가 발생했을 때 프로덕션 로그는 중요한 역할을 합니다. 이 로그는 발생한 상황에 대해 사실적인 이력 자료를 얻을 수 있는 최상의 단독 소스입니다. 그러나 이 로그는 위기 상황이 아닌 일반적인 상황에서도 유익하게 쓰입니다. 개발자가 프로덕션 로그에 일상적으로 액세스할 수 있으면 새로운 기능이 어떻게 작동하는지 직접 확인할 수 있습니다. 이는 해당 기능이 예상대로 작동하지 않음을 확인하고 위기로 확산되기 전에 문제를 바로잡을 수 있는 효과적인 방법입니다. 모든 관계자가 로그에 액세스할 수 있으면 보다 신속하게 문제에 대처하고 해결할 수 있습니다.

확장으로 돌아가기

네트워크 팀과 개발 팀 간의 미팅은 사실 ASP.NET 응용 프로그램 확장과 관련된 전체적인 문제를 이해하는 자리입니다. 응용 프로그램이 운영될 실제 환경은 응용 프로그램에서 실행하는 코드가 어떻게 작동할 것인가에 직접적인 영향을 줍니다. 또한 확장에 관한 모든 전략은 실제 환경에서의 동작에 영향을 줍니다. 응용 프로그램 중 SSL 관련 부분을 분리하는 전문성 전략을 적용할 경우, 네트워크 환경의 변경 그리고 아마도 서버 자체의 변경이 필요할 수 있습니다.

캐싱과 같이 코드 중심의 변경처럼 보이는 것도 환경에 영향을 줄 수 있습니다. ASP.NET 응용 프로그램에 데이터 캐싱을 추가하면 메모리 사용량이 늘어나는 대신 데이터베이스 호출의 수가 줄어들기 때문입니다. 그로 인해 필요한 ASP.NET 서버의 수나 서버의 작업자 스레드 재활용 수가 늘어날 수도 있습니다. 그러면 네트워크 모니터링 쪽에서 이벤트가 발생하게 됩니다.

ASP.NET 응용 프로그램 확장은 개발자와 네트워크 담당자 모두에게 영향을 주는 프로젝트입니다. 따라서 양쪽 모두 의사 결정 과정에 참여시키는 것이 효과적입니다. 이 팀들이 개별적으로 작업할 경우 결코 나오지 못할 독창적인 해결책이 그러한 협력을 통해 등장하는 경우도 많습니다. 예를 들어, 네트워크 담당자가 알고 있는 사내의 기존 하드웨어 솔루션이, 개발자가 성능 및 확장 요구 사항을 해결하는 데 도움이 될 수도 있습니다. 응용 프로그램과 환경의 세부 사항에 관해 의견을 나누다 보면 이러한 기회가 오게 됩니다.

협력

ASP.NET 응용 프로그램 확장을 위한 리소스:

확장 프로젝트 중에 문제가 발생하는 것이 항상 나쁜 것은 아닙니다. 해당 응용 프로그램을 사용하길 원하는 수많은 사용자들이 문제를 제기한 만큼 그 응용 프로그램의 가치를 입증하는 것이므로 좋은 기회입니다! 응용 프로그램이 제대로 작동하게 하여 이러한 기회를 살려야 합니다.

다른 행사에 의해 확장 문제가 발생하는 경우도 있습니다. 회사에서 판촉 행사를 진행 중이거나 블로그에서 소개되는 경우 또는 어떤 커뮤니티 사이트를 통해 엄청나게 많은 이들이 한꺼번에 웹 사이트를 방문하는 상황을 예로 들 수 있습니다. 갑자기 응용 프로그램을 원활하게 운영되게 해야 하므로 전쟁을 치르게 된 셈입니다. 물론 이러한 시나리오가 실제로 발생하기 전에 조치를 취하는 것이 최선책입니다. 또한 협력을 통해 이러한 위기 상황을 어떻게 극복할 수 있는지 시연하면 개발자와 네트워크 담당자 간의 미팅을 성공적으로 마무리하는 데 도움이 됩니다.

위기 관리에서 가장 먼저 해야 할 질문은 "사이트가 부하로 인해 성능이 저하되고 있음을 어떻게 감지하는가?"입니다. "CTO의 전화를 받아서"라고 답하는 경우가 많습니다. 웹 사이트에 장애가 있음을 나타내는 첫 번째 징후가 외부인의 전화라면 문제가 있는 것입니다. 전화벨이 울리기 전에 문제를 알리는 적절한 측정 시스템을 갖춰야 합니다. 그렇다고 전화벨이 전혀 울리지 않을 수는 없겠지만, 적어도 답변을 준비할 시간을 벌게 됩니다. CTO에게 "정말입니까?"라고 대답하는 것은 귀하의 경력에 도움이 되지 않는 대처 방법입니다.

다음 질문은 누가 가장 먼저 전화를 받는가 그리고 상황에 누가 대처하는가 하는 것입니다. 대체로 네트워크 담당자가 첫 번째 경고를 접수하는데, 그 사람이 상대적으로 경험이 부족할 수도 있으므로 확실한 상부 보고 절차를 마련해야 합니다. 그 다음에 전화를 받을 사람을 결정해야 합니다. 이제 서둘러 조치를 취해야 합니다. 즉 신속한 진단을 통해 어떤 종류의 문제가 발생하고 있는지 규명합니다. 네트워크 가동 중단과 확장 문제는 전혀 별개의 사항입니다. 확장 문제의 경우 개발 팀원을 일찍 투입하는 것이 바람직합니다.

모든 관계자는 정확한 정보가 필요하므로, 효과적인 액세스 권한을 부여하는 것이 관건입니다. 효과적인 진단이 내려질 수 있도록 최대한 많은 정보를 배포하는 것이 목표이며, 그 진단에 따라 최종 솔루션의 범위가 결정됩니다.

코딩만이 유일한 해답이라면 코딩을 하기 전에 상황이 종료될 때가 많습니다. 물론 향후 개발 작업의 우선 순위를 정할 때 반영되도록 이벤트를 기록해야 하지만, 코딩 후 신중한 테스트도 거치지 않고 프로덕션 환경에 추가하는 것은 올바르거나 현명한 방법이 아닙니다. 어떤 경우에서든 상황을 악화시켜서는 안 된다는 것이 제1 원칙입니다.

확장과 관련된 문제에서는 그냥 기다리는 것이 해결책일 때도 있습니다. 그러나 이 역시 의사 결정 중 하나입니다.

이러한 비상 사태에 대한 계획은 다양한 기법을 신속하게 적용할 수 있음을 의미합니다. 확장 문제 해결에 네트워크와 개발 팀의 리소스를 모두 투입함으로써 매우 빠른 시간 내에 문제가 해결될 때가 많습니다. 판촉 행사를 더욱 성공적으로 마치는 결과를 가져올 수도 있습니다.

결론적으로, 네트워크 팀 입장에서 얻은 교훈은, 우수한 성능과 확장성을 갖춘 ASP.NET 응용 프로그램은 응용 프로그램을 개발한 팀과 이를 배포하고 운영하는 팀 간의 성공적인 협력의 산물이라는 것입니다.

이러한 협력은 반드시 필요하므로 가급적 일찍 두 팀이 만나 정보를 공유하는 것이 가장 좋습니다. 이 미팅의 목적은 응용 프로그램의 모든 요소, 응용 프로그램의 기능과 작동 방식, 종속성, 부하 상태에서의 동작, 시간의 경과에 따라 발생하는 문제에 대처하는 방법 등을 이해하고 합의하는 것입니다.

이러한 협력이 효과를 발휘한다면 문제가 발생했을 때 신속하게 대처하고, 향후 성공을 위해 응용 프로그램에서 필요로 하는 사항에 대한 명확한 목표를 설정해 전달할 수 있는 행동력 있는 기업으로 발전할 수 있습니다.

Richard Campbell은 Microsoft Regional Director이자 ASP.NET의 MVP로 활동 중이며, .NET 개발자를 위한 인터넷 오디오 토크쇼인 .NET Rocks(dotnetrocks.com)를 공동 진행하고 있습니다. 그는 수년간 여러 기업에서 ASP.NET의 성능과 확장에 관한 컨설팅을 수행해 왔으며, Strangeloop Networks의 공동 설립자이기도 합니다.

다음을 통해 공유

목차

추가 리소스