웹 개발자가 저지르는 가장 일반적인 10가지 실수: 개발자를 위한 자습서

게시 됨: 2022-03-11

World Wide Web이라는 용어가 1990년에 만들어진 이후로 웹 응용 프로그램 개발은 정적 HTML 페이지를 제공하는 것에서 완전히 동적이고 복잡한 비즈니스 응용 프로그램으로 발전했습니다.

오늘날 우리는 모든 종류의 다양한 웹 응용 프로그램 개발에 대한 단계별 지침을 제공하는 수천 개의 디지털 및 인쇄 리소스를 보유하고 있습니다. 개발 환경은 초기 개발자들이 정기적으로 싸워왔던 많은 실수를 포착하고 고칠 만큼 충분히 "스마트"합니다. 단순한 정적 HTML 페이지를 대화형 응용 프로그램으로 쉽게 바꾸는 다양한 개발 플랫폼이 있습니다.

이러한 모든 개발 패턴, 관행 및 플랫폼은 공통 기반을 공유하며 모두 웹 애플리케이션의 특성으로 인해 유사한 웹 개발 문제가 발생하기 쉽습니다.

이 웹 개발 팁의 목적은 웹 개발 프로세스의 여러 단계에서 저지르는 일반적인 실수에 대해 밝히고 더 나은 개발자가 되도록 돕는 것입니다. 유효성 검사, 보안, 확장성 및 SEO와 같이 거의 모든 웹 개발자에게 공통적인 몇 가지 일반적인 주제를 다루었습니다. 물론 내가 이 가이드에서 설명한 특정 예에 얽매여서는 안 됩니다. 이 예는 당신이 직면할 수 있는 잠재적인 문제에 대한 아이디어를 제공하기 위한 것일 뿐입니다.

일반적인 실수 1: 불완전한 입력 검증

클라이언트와 서버 측에서 사용자 입력을 검증 하는 것은 반드시 해야 할 일 입니다! 우리 모두는 "사용자 입력을 신뢰하지 마십시오" 라는 현명한 조언을 알고 있지만 그럼에도 불구하고 유효성 검사에서 비롯된 실수는 너무 자주 발생합니다.

이 실수의 가장 흔한 결과 중 하나는 매년 OWASP Top 10에 드는 SQL Injection 입니다.

대부분의 프론트엔드 개발 프레임워크는 사용이 매우 간단한 즉시 사용 가능한 유효성 검사 규칙을 제공합니다. 또한 대부분의 주요 백엔드 개발 플랫폼은 제출된 데이터가 예상 규칙을 준수하는지 확인하기 위해 간단한 주석을 사용합니다. 유효성 검사를 구현하는 것은 시간이 많이 소요될 수 있지만 표준 코딩 관행의 일부여야 하며 절대 따로 두어서는 안 됩니다.

일반적인 실수 2: 적절한 권한이 없는 인증

계속 진행하기 전에 이 두 용어에 대해 일치하는지 확인하겠습니다. 가장 일반적인 10가지 웹 보안 취약점에 명시된 바와 같이:

인증: 보안 자격 증명(비밀번호, 보안 질문에 대한 답변, 지문 스캔 등)을 올바르게 제공했기 때문에 사람이 특정 사용자인지(또는 최소한 그렇게 보이는지) 확인합니다.

권한 부여: 특정 사용자에게 특정 리소스에 대한 액세스 권한이 있는지 또는 특정 작업을 수행할 수 있는 권한이 부여되었는지 확인합니다.

달리 말하면 인증은 엔터티가 누구인지 아는 것이고 권한 부여는 주어진 엔터티가 무엇을 할 수 있는지 아는 것입니다.

이 문제를 예를 들어 보여드리겠습니다.

귀하의 브라우저는 다음과 유사한 객체에 현재 기록된 사용자 정보를 보유하고 있다고 생각하십시오.

 { username:'elvis', role:'singer', token:'123456789' }

암호 변경을 수행할 때 애플리케이션은 POST를 수행합니다.

 POST /changepassword/:username/:newpassword

/changepassword 방법에서 사용자가 로그인되어 있고 토큰이 만료되지 않았는지 확인합니다. 그런 다음 :username 매개변수를 기반으로 사용자 프로필을 찾고 사용자의 암호를 변경합니다.

따라서 사용자가 올바르게 로그인했는지 확인한 다음 요청을 실행하여 비밀번호를 변경했습니다. 프로세스가 괜찮아 보이죠? 불행히도 대답은 NO입니다!

이때 작업을 실행하는 사용자와 비밀번호가 변경된 사용자가 동일한지 확인하는 것이 중요합니다. 브라우저에 저장된 모든 정보는 변조될 수 있으며 고급 사용자는 기본 제공 브라우저 도구 외에 다른 것을 사용하지 않고도 username username:'elvis' 를 username:'Administrator' 로 쉽게 업데이트할 수 있습니다.

따라서 이 경우 사용자가 보안 자격 증명을 제공했는지 확인하는 Authentication 만 처리했습니다. /changepassword 메서드가 Authenticated 된 사용자만 실행할 수 있다는 유효성 검사를 추가할 수도 있습니다. 그러나 이것은 여전히 ​​악의적인 시도로부터 사용자를 보호하기에 충분하지 않습니다.

/changepassword 메소드 내에서 실제 요청자와 요청 내용을 확인하고 사용자가 자신의 데이터만 변경할 수 있도록 요청에 대한 적절한 Authorization 를 구현해야 합니다.

Authentication 과 Authorization 는 동전의 양면입니다. 절대 따로 취급하지 마세요.

일반적인 실수 3: 확장할 준비가 되지 않았습니다.

오늘날의 고속 개발, 스타트업 액셀러레이터, 훌륭한 아이디어의 즉각적인 전 세계 도달 범위에서 MVP(최소 실행 가능한 제품)를 가능한 한 빨리 시장에 출시하는 것은 많은 회사의 공통 목표입니다.

그러나 이러한 지속적인 시간 압박으로 인해 우수한 웹 개발 팀이라도 특정 문제를 간과하는 경우가 많습니다. 확장은 종종 팀이 당연하게 여기는 것 중 하나입니다. MVP 개념은 훌륭하지만 너무 멀리 밀면 심각한 문제가 발생합니다. 불행히도 확장 가능한 데이터베이스와 웹 서버를 선택하고 확장 가능한 독립적인 서버에서 모든 애플리케이션 계층을 분리하는 것만으로는 충분하지 않습니다. 나중에 응용 프로그램의 중요한 부분을 다시 작성하지 않으려면 고려해야 할 세부 사항이 많이 있습니다. 이는 주요 웹 개발 문제가 됩니다.

예를 들어 사용자의 업로드된 프로필 사진을 웹 서버에 직접 저장하도록 선택했다고 가정해 보겠습니다. 이것은 완벽하게 유효한 솔루션입니다. 응용 프로그램에서 파일에 빠르게 액세스할 수 있고 모든 개발 플랫폼에서 파일 처리 방법을 사용할 수 있으며 이러한 이미지를 정적 콘텐츠로 제공할 수도 있습니다. 이는 응용 프로그램의 부하를 최소화한다는 의미입니다.

하지만 애플리케이션이 성장하고 로드 밸런서 뒤에 두 개 이상의 웹 서버를 사용해야 하는 경우에는 어떻게 될까요? 데이터베이스 스토리지, 세션 상태 서버 및 웹 서버를 훌륭하게 확장했지만 프로필 이미지와 같은 단순한 문제로 인해 애플리케이션 확장성이 실패합니다. 따라서 어떤 종류의 파일 동기화 서비스(지연되고 일시적인 404 오류가 발생함) 또는 파일이 웹 서버 전체에 분산되도록 하는 다른 해결 방법을 구현해야 합니다.

처음부터 문제를 피하기 위해 해야 할 일은 공유 파일 저장 위치, 데이터베이스 또는 기타 원격 저장 솔루션을 사용하는 것이었습니다. 이를 모두 구현하려면 추가 작업 시간이 몇 시간 더 들겠지만 그만한 가치가 있었습니다.

일반적인 실수 4: SEO가 잘못되었거나 누락되었습니다.

웹 사이트에서 SEO 모범 사례가 잘못되거나 누락된 근본 원인은 "SEO 전문가"에 대한 잘못된 정보입니다. 많은 웹 개발자는 SEO에 대해 충분히 알고 있으며 SEO가 특별히 복잡하지 않다고 생각하지만 이는 사실이 아닙니다. SEO를 마스터하려면 Google, Bing 및 Yahoo가 웹을 색인화하는 방법에 대한 모범 사례와 끊임없이 변화하는 규칙을 조사하는 데 상당한 시간이 소요됩니다. 지속적으로 실험하고 정확한 추적 + 분석을 하지 않는 한, 당신은 SEO 전문가가 아니며, 자신이 SEO 전문가라고 주장해서는 안 됩니다.

또한 SEO는 마지막에 수행되는 일부 활동으로 너무 자주 연기됩니다. 이것은 웹 개발 문제에 대한 높은 대가를 치르게 합니다. SEO는 좋은 콘텐츠, 태그, 키워드, 메타 데이터, 이미지 대체 태그, 사이트 맵 등을 설정하는 것과 관련이 있을 뿐만 아니라 중복 콘텐츠 제거, 크롤링 가능한 사이트 아키텍처, 효율적인 로드 시간, 지능형 백 링크 등을 포함합니다.

확장성과 마찬가지로 웹 애플리케이션 구축을 시작하는 순간부터 SEO에 대해 생각해야 합니다. 그렇지 않으면 SEO 구현 프로젝트를 완료하는 것이 전체 시스템을 다시 작성하는 것을 의미한다는 것을 알게 될 수도 있습니다.

일반적인 실수 5: 요청 처리기에서 작업을 소모하는 시간 또는 프로세서

이러한 실수의 가장 좋은 예 중 하나는 사용자 작업을 기반으로 이메일을 보내는 것입니다. 너무 자주 개발자는 SMTP 호출을 만들고 사용자 요청 처리기에서 직접 메시지를 보내는 것이 해결책이라고 생각합니다.

온라인 서점을 만들고 매일 수백 건의 주문으로 시작할 것으로 예상한다고 가정해 보겠습니다. 주문 접수 프로세스의 일부로 사용자가 주문을 게시할 때마다 확인 이메일을 보냅니다. 이것은 처음에는 문제 없이 작동하지만 시스템을 확장하고 갑자기 확인 이메일을 보내는 수천 개의 요청을 받으면 어떻게 될까요? SMTP 연결 시간 초과, 할당량 초과 또는 현재 사용자 대신 이메일을 처리하기 때문에 애플리케이션 응답 시간이 크게 저하됩니다.

가능한 한 빨리 HTTP 요청을 해제하는 동안 시간 또는 프로세서 소모 작업은 외부 프로세스에서 처리해야 합니다. 이 경우 주문을 받고 알림을 보내는 외부 메일링 서비스가 있어야 합니다.

일반적인 실수 6: 대역폭 사용을 최적화하지 않음

대부분의 개발 및 테스트는 로컬 네트워크 환경에서 이루어집니다. 따라서 각각 3MB 이상인 5개의 배경 이미지를 다운로드할 때 개발 환경에서 1Gbit 연결 속도 문제를 식별하지 못할 수 있습니다. 그러나 사용자가 스마트폰에서 3G 연결을 통해 15MB 홈 페이지를 로드하기 시작하면 불만 및 문제 목록을 준비해야 합니다.

대역폭 사용을 최적화하면 성능이 크게 향상될 수 있으며 이러한 향상을 얻으려면 몇 가지 트릭만 있으면 됩니다. 다음을 포함하여 많은 훌륭한 웹 개발자가 기본적으로 수행하는 몇 가지 작업이 있습니다.

  1. 모든 JavaScript의 축소
  2. 모든 CSS 축소
  3. 서버 측 HTTP 압축
  4. 이미지 크기 및 해상도 최적화

일반적인 실수 7: 다양한 화면 크기에 맞게 개발하지 않음

반응형 디자인은 지난 몇 년 동안 큰 주제였습니다. 다양한 화면 해상도를 가진 스마트폰의 확장으로 인해 온라인 콘텐츠에 액세스하는 많은 새로운 방법이 생겼고 웹 개발 문제도 많이 발생했습니다. 스마트폰과 태블릿을 통한 웹사이트 방문 횟수는 나날이 증가하고 있으며 이러한 추세는 더욱 가속화되고 있습니다.

웹 사이트 콘텐츠에 대한 원활한 탐색 및 액세스를 보장하려면 사용자가 모든 유형의 장치에서 액세스할 수 있도록 해야 합니다.

반응형 웹 애플리케이션을 구축하기 위한 수많은 패턴과 사례가 있습니다. 각 개발 플랫폼에는 고유한 팁과 요령이 있지만 플랫폼에 독립적인 일부 프레임워크가 있습니다. 가장 인기 있는 것은 아마도 Twitter Bootstrap일 것입니다. 모든 주요 개발 플랫폼에서 채택한 오픈 소스 및 무료 HTML, CSS 및 JavaScript 프레임워크입니다. 애플리케이션을 빌드할 때 부트스트랩 패턴과 관행을 따르기만 하면 전혀 문제 없이 반응형 웹 애플리케이션을 얻을 수 있습니다.

일반적인 실수 8: 브라우저 간 비호환성

개발 프로세스는 대부분의 경우 상당한 시간 압박을 받고 있습니다. 모든 애플리케이션은 가능한 한 빨리 출시되어야 하며 훌륭한 웹 개발자라도 디자인보다 기능을 제공하는 데 집중하는 경우가 많습니다. 대부분의 개발자는 Chrome, Firefox, IE가 설치되어 있음에도 불구하고 시간의 90% 중 하나만 사용합니다. 개발 중에 하나의 브라우저를 사용하는 것이 일반적이며 애플리케이션이 거의 완성되면 다른 브라우저에서 테스트를 시작합니다. 이것은 이 단계에서 나타나는 문제를 테스트하고 수정할 시간이 많다고 가정할 때 매우 합리적입니다.

그러나 애플리케이션이 브라우저 간 테스트 단계에 도달할 때 상당한 시간을 절약할 수 있는 몇 가지 웹 개발 팁이 있습니다.

  1. 개발하는 동안 모든 브라우저에서 테스트할 필요는 없습니다. 시간이 많이 걸리고 비효율적입니다. 그러나 그렇다고 해서 브라우저를 자주 전환할 수 없는 것은 아닙니다. 이틀에 한 번씩 다른 브라우저를 사용하면 최소한 개발 단계 초기에 주요 문제를 인식하게 될 것입니다.
  2. 브라우저를 지원하지 않는 것을 정당화하기 위해 통계를 사용하는 데 주의하십시오. 새로운 소프트웨어를 채택하거나 업그레이드하는 데 느린 조직이 많이 있습니다. 그곳에서 일하는 수천 명의 사용자는 여전히 귀하의 애플리케이션에 액세스해야 할 수 있으며 내부 보안 및 비즈니스 정책으로 인해 최신 무료 브라우저를 설치할 수 없습니다.
  3. 브라우저 특정 코드를 피하십시오. 대부분의 경우 브라우저 간 호환이 가능한 우아한 솔루션이 있습니다.

일반적인 실수 9번: 이식성을 계획하지 않음

가정은 모든 문제의 어머니입니다! 휴대성과 관련하여 이 말은 그 어느 때보다 사실입니다. 하드 코딩된 파일 경로, 데이터베이스 연결 문자열 또는 특정 라이브러리를 서버에서 사용할 수 있다는 가정과 같은 웹 개발 문제를 본 적이 있습니까? 프로덕션 환경이 로컬 개발 컴퓨터와 일치한다고 가정하는 것은 단순히 잘못된 것입니다.

이상적인 애플리케이션 설정은 유지 관리가 필요 없습니다.

  1. 애플리케이션이 로드 밸런싱된 다중 서버 환경에서 확장 및 실행될 수 있는지 확인하십시오.
  2. 단일 구성 파일에서 간단하고 명확한 구성을 허용합니다.
  3. 웹 서버 구성이 예상과 다를 때 예외를 처리합니다.

일반적인 실수 10: RESTful 안티 패턴

RESTful API는 웹 개발에서 자리를 잡았고 앞으로도 계속될 것입니다. 거의 모든 웹 애플리케이션은 내부용이든 외부 시스템과의 통합용이든 일종의 REST 서비스를 구현했습니다. 그러나 예상되는 방식을 따르지 않는 깨진 RESTful 패턴과 서비스를 여전히 볼 수 있습니다.

RESTful API를 작성할 때 저지르는 가장 흔한 두 가지 실수는 다음과 같습니다.

  1. 잘못된 HTTP 동사를 사용합니다. 예를 들어 데이터 쓰기에 GET을 사용합니다. HTTP GET은 멱등성이고 안전하도록 설계되었습니다. 즉, 동일한 리소스에서 GET을 몇 번 호출하더라도 응답은 항상 동일해야 하고 애플리케이션 상태는 변경되지 않아야 합니다.

  2. 올바른 HTTP 상태 코드를 보내지 않습니다. 이 실수의 가장 좋은 예는 응답 코드 200으로 오류 메시지를 보내는 것입니다.

     HTTP 200 OK { message:'there was an error' }

요청에서 오류가 발생하지 않은 경우에만 HTTP 200 OK를 보내야 합니다. 오류의 경우 400, 401, 500 또는 발생한 오류에 적합한 기타 상태 코드를 보내야 합니다.

표준 HTTP 상태 코드에 대한 자세한 개요는 여기에서 찾을 수 있습니다.

마무리

웹 개발은 웹 사이트, 웹 서비스 또는 복잡한 웹 응용 프로그램의 개발을 합법적으로 포함할 수 있는 매우 광범위한 용어입니다.

이 웹 개발 가이드의 주요 내용은 항상 인증 및 권한 부여에 대해 주의하고 확장성을 계획해야 하며 성급하게 아무 것도 가정하지 않아야 함을 상기시키십시오. 그렇지 않으면 긴 목록의 웹 개발 문제를 처리할 준비가 되어 있어야 합니다!