웹이 나아갈 길을 Sonarwhal로 검사하자

저자: Stephanie Drescher 원문: https://24ways.org/2017/lint-the-web-forward-with-sonarwhal/

몇 해 전, 필자가 대학 졸업반일 때 웹 개발 과정은 두 가지의 기술에 초점을 두었다. 한가지는 기본적인 것들 즉, HTML과 CSS, 그리고 다른 한 가지는 Adobe Flash였다. 필자는 포트폴리오에 추가하기 위해 Action Script3.0로 사용자와 상호작용하는 웹사이트를 작성하는데 많은 시간을 들였다. 대학을 졸업한 뒤 몇 개월이 지나, 필자는 Flash로 고객의 웹사이트를 만들어 주었고 그것이 처음이자 마지막이었다. Flash는 죽어가고 있었다. 그리고 필자의 이력서나 포트폴리오에서도 사용하지 않게 되었다.

그것은 바뀌는 기술의 변화 속도에 대한 첫 번째 교훈이었고, 졸업 후 이제 막 실무로 뛰어드는 사람에게는 매우 두려운 깨달음이었다. 그 후 7년 후인 지금, 필자는 Microsoft Edge팀에서 디자인을 돕고, 필자가 느꼈던 불안감을 줄여줄 도구(Sonarwhal)를 개발한다.

Sonawhal은 한 웹 커뮤니티에서 만든 검사 도구이다. 오픈소스이며 JS Foundation 위에서 살아가고 있다. 이 도구는 개발자와 디자이너에게 계속되는 변화에 발을 맞출 수 있도록 코드를 어떻게 바꾸면 좋을지 지속적으로 알려준다.

Sonarwhal 마스코트인 "Nellie"

웹 개발을 잘 하기란 힘든 일이다. HTML, CSS JavaScript만이 전부는 아니다. 개발자들은 접근성, 성능, 보안, 새로 생기고 있는 표준, 그 이상의 것들을 이해해야 한다. 몇 개월 마다 이 모든 것에 대한 지식이 새로워진다. 배워야 할 것이 무궁무진하다.

웹 개발은 어렵다

항상 최신의 지식으로 유지하는 것이 이 탐지 도구를 개발하게 한 원동력이다. 당신이 갓 시작한 개발자건, 학생이건, 10년 이상의 경험이 있건 Sonarwhal팀은 모든 브라우저에서 잘 동작하는 당신의 웹사이트를 만드는 것을 돕는다.

현재 Sonarwhal은 5개의 모범 사례 범주를 확인한다. 접근성, 상호 운용성, 성능, Progressive Web Apps, 보안이다. 각각의 검증 조건은 규칙(rule)이라고 불린다. 여러분은 자신만의 규칙을 만들어서 프로젝트에 특화된 지침을 따르도록할 수 있다. (예를들어 통계 지표 검증이나, 페이지의 형태 등 이 있다.)

Sonarwhal 사용에는 두 가지 방법이 있다.

1. 온라인 검사기 버전. 공개된 웹사이트를 빠르고 쉽게 검사할 수 있다.
2. 명령줄 도구 (이하 CLI). 검사의 설정을 원하는 대로 수정하거나, 개발과정에 포함하기 위해 사용할 수 있다.

온라인 검사기

온라인 검사기는 간소화된 웹사이트 검사 방법을 제공한다. URL을 입력하면 여러분은 웹 페이지 검사 결과를 영구적 링크로 받아볼 수 있다. 그리고 그 주소를 언제든 공유하고 재방문할 수 있다.

Sonarwhal 온라인 검사기

필자의 팀이 새로운 규칙을 추가할 때 규칙에 대한 코드를 짜는 시간보다 각 주제, 소스코드 검색, 문서화에 더 많은 시간을 들인다. 검사에 대해 단순히 결과를 알려주는 것도 중요하지만, 어떤 부분에 의해서 실패된 것인지 이해시키는 것도 중요하다. 실패한 각각의 규칙들 사이에서 여러분은 상세한 문서의 링크를 볼 수 있을 것 이다. 그 문서는 왜 여러분이 이 규칙에 주의해야 하며 테스트는 어떻게 이루어지는지, 통과한 예제는 어떤지, 반대로 실패된 예제는 무엇인지, 이 규칙에 관심이 있다면 깊은 이해를 위해 필요한 유용한 문서 링크도 제공한다.

문서를 읽고, Sonarwhal을 지속적으로 사용하는 과정에서 개발자가 최신 모범 사례를 적용 하기를 바란다. 개발자가 사이트를 만들어 나가면서 거듭 발생하는 문제의 결과를 보고 인지할수록, 그들은 자주 빠트린 엘리먼트나, 에러를 발생시키는 코드를 먼저 고치기 시작할 것이다. 이것은 단방향 의사소통이 아니다. 문서는 Sonarwhal 웹사이트 뿐만 아니라, 수정을 위해 Github에도 있으니 더 좋은 문서를 위해 우리를 도와주길 바란다.

검사 결과

현재 Sonarwhal 웹사이트의 검사 설정은 매우 엄격한 상태이다. 그러니, 아마도 여러분의 마음을 상하게 할 수도 있다. (필자의 개인 웹사이트를 테스트 해봤을때는 그랬다.)그러나 CLI에서처럼 모든 규칙의 엄격함 수치를 조정할 수 있다.

Sonarwhal 명령줄 도구

CLI는 Sonarwhal에 대한 모든 조정을 할 수 있다. 어떤 규칙을 사용하며 어떻게 개조할지, 어떤 도메인으로 접속할지 모두 가능하다. NodeJs 버전은 최신 LTS(v8)나 Stable(v9)이 필요하다. 그리고 npm 같은 여러분이 즐겨 사용하는 패키지 매니저도 필요하다:

npm install -g Sonarwhal

설치가 끝났다면 여러분은 이제 어느 곳에서든 다음과 같이 Sonarwhal을 사용할 수 있다:

Sonarwhal https://example.com

명령줄 도구를 사용하기

구성 요소는 .sonarwhalrc 파일을 통해 설정할 수 있다. 사이트를 분석할 때는 파일이 존재하지 않을 수 있다. 이때는 프롬프트로 뜨는 몇 가지 질문에 답해야 한다:

• What connector do you want to use? 연결자는 웹사이트에 연결하고 응답, 자원, HTML 등의 모든 정보를 수집하는 데 사용한다. 현재 jsdom과 Microsoft Edge, Google Chrome이 지원된다.
• What formatter do you want to use?? 결과를 어떻게 보여줄지 정한다. summary, stylish 등이 가능하다. 모든 결과를 다 보고 싶다거나, 빠른 수행 과정이 필요로 할 경우 verbose나 informative가 사용될 수 있다.
• Do you want to use the recommended rules configuration 규칙은 우리가 검사하는 것을 말한다. 문서를 읽고 어떤 규칙을 적용할지 아는 경우를 제외하고, 첫 사용자일 경우에는 추천 규칙을 사용해야 한다.
• What browsers are you targeting? Sonarwhal의 뛰어난 기능 중 하나가 규칙이 목표 브라우저의 응답에 반응해서 규칙을 추가할지, 제거할지 권유하는 것이다. 예를 들어 Highest Document Mode를 사용할 때 "X-UA-Compatible" 헤더를 IE10이나 더 낮은 버전을 위해 추가하거나, IE10보다 높은 버전을 위해 제거하라고 알려준다.

Sonarwhal 환경구성 생성기가 질문하고 있다

한번 이 질문들에 답하면 .sonarwhalrc파일이 아래와 같이 생성된다.

{
    "connector": {
        "name": "jsdom",
        "options": {
            "waitFor": 1000
        }
    },
    "formatters": "stylish",
    "rulesTimeout": 120000,
    "rules": {
        "apple-touch-icons": "error",
        "axe": "error",
        "content-type": "error",
        "disown-opener": "error",
        "highest-available-document-mode": "error",
        "validate-set-cookie-header": "warning",
        // ...
    }
}

검사를 진행하고 난 뒤 몇 초가 지나면 여러분은 검사 결과가 나타나는 것을 보게 될 것이다. 검사 결과는 어떤 포매터를 사용하냐에 따라 다르게 보이므로, 한 개씩 사용해보고 여러분이 더 선호하는 포매터로 변경하길 바란다.

웹 사이트 Sonarwhal 검사 결과가 나옴과 동시에 필자의 마음도 산산 조각이 났다💔

이제 여러분은 오류 리스트가 생겼다. 이것을 통해 사이트를 개선해보자! 알아둘 것은, 웹사이트를 검사할 때 페이지에 추가된 통계지표나 어딘가에서 가져온 글씨체도 검사한다. 여러분이 이 파일들을 수정하지는 못하지만 CLI를 통해 이 파일들의 도메인을 무시하도록 설정해서 여러분이 제어할 수 있는 파일들만 결과에 나오도록 할 수 있다.

제공되는 문서는 오류를 어떻게 수정할지에 대한 충분한 길잡이가 될 것이지만, 이것만으로는 충분하지 않을 수 있다. 그러니 우리를 도와서 어떻게 수정하면 좋을지 제안을 부탁한다. 이것은 커뮤니티의 노력이며, 여러분이 궁금했던 것을 궁금해할 누군가에게 도움이 되는 일이다. 필자의 웹사이트들을 검사하면서 Sonarwhal은 필자에게 Apple 터치 아이콘이 없다고 경고했다. 필자가 Sonarwhal 문서를 찾아보지 않고 웹 검색을 했을때, 가장 위에 있는 3개의 검색 결과는 필자에게 오래된 정보를 주었다. 필자는 다양한 아이콘 치수를 추가해야한다. 하지만 대응 기기에 맞는 모든 아이콘 치수들까지는 필요하지 않다. 충분히 큰 180px * 180px 한개의 치수를 선언하고 오래된 기기들에 맞게 축소해서 제공하면 된다.

가장 위에 있는 검색 결과라도 항상 옳지는 않으며, 여러분이 오래된 정보들을 검색하지 않길 바란다. Sonarwhal의 가능성이 더 확장돼서, 여러분의 웹사이트를 한곳에서 시범 테스트 할 수 있도록 돕는 것이 목표이다.

지금까지의 여정, 그리고 앞으로는

Microsoft Edge팀은, 개발자들이 멋진 웹사이트를 개발하는 데 도움을 주는데에 몰두해있다. 매일 많은 웹사이트가 우리의 이슈 추적 시스템으로 들어오는 것을 보고 있다.(그런 버그들을 작성해 주는 것에 감사를 전한다. 그들은 Microsoft Edge를 더욱더 좋게 만들고 있다) 계속해서 발생하는 몇 가지 이슈들은 안타까운 실수이거나, 뒤떨어진 '모범 사례들'이며 반드시 피해야 한다. 그래서 이 도구를 만들어서 모두가 웹을 더 좋은 모습으로 만들도록 돕고 있다.

우리가 Sonarwhal을 만들기로 했을 때, 우린 사람들이 더 좋은, 최신 기술의 코드를 그들의 웹 사이트에 사용하길 바랐다. Sonarwhal이 누구에게나 유용하게 사용되기를 바라므로, 초기에 우리가 사용했던 3가지 지침을 정했다:

1. 커뮤니티에 의해 주도된다. 커뮤니티의 가장 큰 관심사를 위해 개발한다. 웹을 모두의 것이며 이 프로젝트 또한 그렇다. 오픈소스이기 때문만 아니다. 우리도 JS Foundation에 기부하고 있고, 개인이나 단체 모두의 협업을 환영하는 포괄적인 관리 모델도 가지고 있다.
2. 사용자 중심적으로 개발하라. 사용자를 중심에 두고 Sonarwhal을 여러분이 하고자 하는 것들을 여러분의 기술 역량이 어떻든 간에 설정하기 쉽게 만들기를 원한다.
3. 협업하라. 이미 발명된 것에 대해 재발명하려 하지 않는다. 그래서 기존에 존재하는 웹사이트를 만들기 위한 도구와 서비스들과 협업한다. 예를들자면 aXe, synk.io, Cloudinary 등이 있다.

이것은 시작에 불과하며 여전히 해야 할 일이 많으며, 앞으로의 릴리스를 위한 끝내주는 기능들을 열심히 목록으로 만드는 중이다. 그 기능들은 다음과 같다:

• 성능, 접근성, 보안, Progressive Web Apps 등을 위한 다양한 새로운 규칙들
• Visual Studio Code를 위한 플러그인: Sonarwhal을 통해 여러분이 더 나은 웹사이트를 개발하길 원하며, 그것이 여러분의 에디터보다 좋을 것이다.
• 온라인 서비스를 위한 환경 설정 옵션: 기반시설을 미세 조정을 통해 우리의 스캐너 규칙 설정이 잠겨있지만, 더 나아가 CLI의 사용자 정의 옵션을 온라인에서도 지원하려고 준비 중이다.

이것은 웹 커뮤니티를 위한, 웹 커뮤니티에 의한 도구이다. 여러분이 Sonarwhal에 관심을 가지거나, 더 좋은 웹을 만들고 싶거나, Sonarwhal에 기여하기를 원한다면 연락하길 바란다. 우리의 이슈 중 몇 가지는 여러분이 도울 수 있을지 모른다. Sonarwhal을 알기 위해 Github organization도 방문하는 것도 잊지 마라. PR은 언제나 여러분에게 열려있다.

@NarwhalNellie Twitter로 스캐너에 대해 어떻게 생각하는지 여러분의 의견을 알려주길 기다리겠다. 우리와 함께 웹의 미래를 검사하자!

Weekly Magazine

• [Javascript Weekly] Issue 364 — December 7, 2017
• [FrontEnd Focus] Issue 319 — December 7, 2017
• [Node Weekly] Issue 217 — December 8, 2017

Weekly Pick!

원문 : https://24ways.org/2017/lint-the-web-forward-with-sonarwhal/

웹이 나아갈 길을 Sonarwhal로 검사하자

몇 해 전, 필자가 대학 졸업반일 때 웹 개발 과정은 두 가지의 기술에 초점을 두었다. 한가지는 기본적인 것들 즉, HTML과 CSS, 그리고 다른 한 가지는 Adobe Flash였다. 필자는 포트폴리오에 추가하기 위해 Action Script3.0로 사용자와 상호작용하는 웹사이트를 작성하는데 많은 시간을 들였다. 대학을 졸업한 뒤 몇 개월이 지나, 필자는 Flash로 고객의 웹사이트를 만들어 주었고 그것이 처음이자 마지막이었다. Flash는 죽어가고 있었다. 그리고 필자의 이력서나 포트폴리오에서도 사용하지 않게 되었다.

그것은 바뀌는 기술의 변화 속도에 대한 첫 번째 교훈이었고, 졸업 후 이제 막 실무로 뛰어드는 사람에게는 매우 두려운 깨달음이었다. 그 후 7년 후인 지금, 필자는 Microsoft Edge팀에서 디자인을 돕고, 필자가 느꼈던 불안감을 줄여줄 도구(Sonarwhal)를 개발한다.

Sonawhal은 한 웹 커뮤니티에서 만든 검사 도구이다. 오픈소스이며 JS Foundation 위에서 살아가고 있다. 이 도구는 개발자와 디자이너에게 계속되는 변화에 발을 맞출 수 있도록 코드를 어떻게 바꾸면 좋을지 지속적으로 알려준다.

Sonarwhal 마스코트인 "Nellie"

웹 개발을 잘 하기란 힘든 일이다. HTML, CSS JavaScript만이 전부는 아니다. 개발자들은 접근성, 성능, 보안, 새로 생기고 있는 표준, 그 이상의 것들을 이해해야 한다. 몇 개월 마다 이 모든 것에 대한 지식이 새로워진다. 배워야 할 것이 무궁무진하다.

웹 개발은 어렵다

항상 최신의 지식으로 유지하는 것이 이 탐지 도구를 개발하게 한 원동력이다. 당신이 갓 시작한 개발자건, 학생이건, 10년 이상의 경험이 있건 Sonarwhal팀은 모든 브라우저에서 잘 동작하는 당신의 웹사이트를 만드는 것을 돕는다.

현재 Sonarwhal은 5개의 모범 사례 범주를 확인한다. 접근성, 상호 운용성, 성능, Progressive Web Apps, 보안이다. 각각의 검증 조건은 규칙(rule)이라고 불린다. 여러분은 자신만의 규칙을 만들어서 프로젝트에 특화된 지침을 따르도록할 수 있다. (예를들어 통계 지표 검증이나, 페이지의 형태 등 이 있다.)

Sonarwhal 사용에는 두 가지 방법이 있다.

1. 온라인 검사기 버전. 공개된 웹사이트를 빠르고 쉽게 검사할 수 있다.
2. 명령줄 도구 (이하 CLI). 검사의 설정을 원하는 대로 수정하거나, 개발과정에 포함하기 위해 사용할 수 있다.

온라인 검사기

온라인 검사기는 간소화된 웹사이트 검사 방법을 제공한다. URL을 입력하면 여러분은 웹 페이지 검사 결과를 영구적 링크로 받아볼 수 있다. 그리고 그 주소를 언제든 공유하고 재방문할 수 있다.

Sonarwhal 온라인 검사기

필자의 팀이 새로운 규칙을 추가할 때 규칙에 대한 코드를 짜는 시간보다 각 주제, 소스코드 검색, 문서화에 더 많은 시간을 들인다. 검사에 대해 단순히 결과를 알려주는 것도 중요하지만, 어떤 부분에 의해서 실패된 것인지 이해시키는 것도 중요하다. 실패한 각각의 규칙들 사이에서 여러분은 상세한 문서의 링크를 볼 수 있을 것 이다. 그 문서는 왜 여러분이 이 규칙에 주의해야 하며 테스트는 어떻게 이루어지는지, 통과한 예제는 어떤지, 반대로 실패된 예제는 무엇인지, 이 규칙에 관심이 있다면 깊은 이해를 위해 필요한 유용한 문서 링크도 제공한다.

문서를 읽고, Sonarwhal을 지속적으로 사용하는 과정에서 개발자가 최신 모범 사례를 적용 하기를 바란다. 개발자가 사이트를 만들어 나가면서 거듭 발생하는 문제의 결과를 보고 인지할수록, 그들은 자주 빠트린 엘리먼트나, 에러를 발생시키는 코드를 먼저 고치기 시작할 것이다. 이것은 단방향 의사소통이 아니다. 문서는 Sonarwhal 웹사이트 뿐만 아니라, 수정을 위해 Github에도 있으니 더 좋은 문서를 위해 우리를 도와주길 바란다.

검사 결과

현재 Sonarwhal 웹사이트의 검사 설정은 매우 엄격한 상태이다. 그러니, 아마도 여러분의 마음을 상하게 할 수도 있다. (필자의 개인 웹사이트를 테스트 해봤을때는 그랬다.)그러나 CLI에서처럼 모든 규칙의 엄격함 수치를 조정할 수 있다.

Sonarwhal 명령줄 도구

CLI는 Sonarwhal에 대한 모든 조정을 할 수 있다. 어떤 규칙을 사용하며 어떻게 개조할지, 어떤 도메인으로 접속할지 모두 가능하다. NodeJs 버전은 최신 LTS(v8)나 Stable(v9)이 필요하다. 그리고 npm 같은 여러분이 즐겨 사용하는 패키지 매니저도 필요하다:

npm install -g Sonarwhal

설치가 끝났다면 여러분은 이제 어느 곳에서든 다음과 같이 Sonarwhal을 사용할 수 있다:

Sonarwhal https://example.com

명령줄 도구를 사용하기

구성 요소는 .sonarwhalrc 파일을 통해 설정할 수 있다. 사이트를 분석할 때는 파일이 존재하지 않을 수 있다. 이때는 프롬프트로 뜨는 몇 가지 질문에 답해야 한다:

• What connector do you want to use? 연결자는 웹사이트에 연결하고 응답, 자원, HTML 등의 모든 정보를 수집하는 데 사용한다. 현재 jsdom과 Microsoft Edge, Google Chrome이 지원된다.
• What formatter do you want to use?? 결과를 어떻게 보여줄지 정한다. summary, stylish 등이 가능하다. 모든 결과를 다 보고 싶다거나, 빠른 수행 과정이 필요로 할 경우 verbose나 informative가 사용될 수 있다.
• Do you want to use the recommended rules configuration 규칙은 우리가 검사하는 것을 말한다. 문서를 읽고 어떤 규칙을 적용할지 아는 경우를 제외하고, 첫 사용자일 경우에는 추천 규칙을 사용해야 한다.
• What browsers are you targeting? Sonarwhal의 뛰어난 기능 중 하나가 규칙이 목표 브라우저의 응답에 반응해서 규칙을 추가할지, 제거할지 권유하는 것이다. 예를 들어 Highest Document Mode를 사용할 때 "X-UA-Compatible" 헤더를 IE10이나 더 낮은 버전을 위해 추가하거나, IE10보다 높은 버전을 위해 제거하라고 알려준다.

Sonarwhal 환경구성 생성기가 질문하고 있다

한번 이 질문들에 답하면 .sonarwhalrc파일이 아래와 같이 생성된다.

{
    "connector": {
        "name": "jsdom",
        "options": {
            "waitFor": 1000
        }
    },
    "formatters": "stylish",
    "rulesTimeout": 120000,
    "rules": {
        "apple-touch-icons": "error",
        "axe": "error",
        "content-type": "error",
        "disown-opener": "error",
        "highest-available-document-mode": "error",
        "validate-set-cookie-header": "warning",
        // ...
    }
}

검사를 진행하고 난 뒤 몇 초가 지나면 여러분은 검사 결과가 나타나는 것을 보게 될 것이다. 검사 결과는 어떤 포매터를 사용하냐에 따라 다르게 보이므로, 한 개씩 사용해보고 여러분이 더 선호하는 포매터로 변경하길 바란다.

웹 사이트 Sonarwhal 검사 결과가 나옴과 동시에 필자의 마음도 산산 조각이 났다💔

이제 여러분은 오류 리스트가 생겼다. 이것을 통해 사이트를 개선해보자! 알아둘 것은, 웹사이트를 검사할 때 페이지에 추가된 통계지표나 어딘가에서 가져온 글씨체도 검사한다. 여러분이 이 파일들을 수정하지는 못하지만 CLI를 통해 이 파일들의 도메인을 무시하도록 설정해서 여러분이 제어할 수 있는 파일들만 결과에 나오도록 할 수 있다.

제공되는 문서는 오류를 어떻게 수정할지에 대한 충분한 길잡이가 될 것이지만, 이것만으로는 충분하지 않을 수 있다. 그러니 우리를 도와서 어떻게 수정하면 좋을지 제안을 부탁한다. 이것은 커뮤니티의 노력이며, 여러분이 궁금했던 것을 궁금해할 누군가에게 도움이 되는 일이다. 필자의 웹사이트들을 검사하면서 Sonarwhal은 필자에게 Apple 터치 아이콘이 없다고 경고했다. 필자가 Sonarwhal 문서를 찾아보지 않고 웹 검색을 했을때, 가장 위에 있는 3개의 검색 결과는 필자에게 오래된 정보를 주었다. 필자는 다양한 아이콘 치수를 추가해야한다. 하지만 대응 기기에 맞는 모든 아이콘 치수들까지는 필요하지 않다. 충분히 큰 180px * 180px 한개의 치수를 선언하고 오래된 기기들에 맞게 축소해서 제공하면 된다.

가장 위에 있는 검색 결과라도 항상 옳지는 않으며, 여러분이 오래된 정보들을 검색하지 않길 바란다. Sonarwhal의 가능성이 더 확장돼서, 여러분의 웹사이트를 한곳에서 시범 테스트 할 수 있도록 돕는 것이 목표이다.

지금까지의 여정, 그리고 앞으로는

Microsoft Edge팀은, 개발자들이 멋진 웹사이트를 개발하는 데 도움을 주는데에 몰두해있다. 매일 많은 웹사이트가 우리의 이슈 추적 시스템으로 들어오는 것을 보고 있다.(그런 버그들을 작성해 주는 것에 감사를 전한다. 그들은 Microsoft Edge를 더욱더 좋게 만들고 있다) 계속해서 발생하는 몇 가지 이슈들은 안타까운 실수이거나, 뒤떨어진 '모범 사례들'이며 반드시 피해야 한다. 그래서 이 도구를 만들어서 모두가 웹을 더 좋은 모습으로 만들도록 돕고 있다.

우리가 Sonarwhal을 만들기로 했을 때, 우린 사람들이 더 좋은, 최신 기술의 코드를 그들의 웹 사이트에 사용하길 바랐다. Sonarwhal이 누구에게나 유용하게 사용되기를 바라므로, 초기에 우리가 사용했던 3가지 지침을 정했다:

1. 커뮤니티에 의해 주도된다. 커뮤니티의 가장 큰 관심사를 위해 개발한다. 웹을 모두의 것이며 이 프로젝트 또한 그렇다. 오픈소스이기 때문만 아니다. 우리도 JS Foundation에 기부하고 있고, 개인이나 단체 모두의 협업을 환영하는 포괄적인 관리 모델도 가지고 있다.
2. 사용자 중심적으로 개발하라. 사용자를 중심에 두고 Sonarwhal을 여러분이 하고자 하는 것들을 여러분의 기술 역량이 어떻든 간에 설정하기 쉽게 만들기를 원한다.
3. 협업하라. 이미 발명된 것에 대해 재발명하려 하지 않는다. 그래서 기존에 존재하는 웹사이트를 만들기 위한 도구와 서비스들과 협업한다. 예를들자면 aXe, synk.io, Cloudinary 등이 있다.

이것은 시작에 불과하며 여전히 해야 할 일이 많으며, 앞으로의 릴리스를 위한 끝내주는 기능들을 열심히 목록으로 만드는 중이다. 그 기능들은 다음과 같다:

• 성능, 접근성, 보안, Progressive Web Apps 등을 위한 다양한 새로운 규칙들
• Visual Studio Code를 위한 플러그인: Sonarwhal을 통해 여러분이 더 나은 웹사이트를 개발하길 원하며, 그것이 여러분의 에디터보다 좋을 것이다.
• 온라인 서비스를 위한 환경 설정 옵션: 기반시설을 미세 조정을 통해 우리의 스캐너 규칙 설정이 잠겨있지만, 더 나아가 CLI의 사용자 정의 옵션을 온라인에서도 지원하려고 준비 중이다.

이것은 웹 커뮤니티를 위한, 웹 커뮤니티에 의한 도구이다. 여러분이 Sonarwhal에 관심을 가지거나, 더 좋은 웹을 만들고 싶거나, Sonarwhal에 기여하기를 원한다면 연락하길 바란다. 우리의 이슈 중 몇 가지는 여러분이 도울 수 있을지 모른다. Sonarwhal을 알기 위해 Github organization도 방문하는 것도 잊지 마라. PR은 언제나 여러분에게 열려있다.

@NarwhalNellie Twitter로 스캐너에 대해 어떻게 생각하는지 여러분의 의견을 알려주길 기다리겠다. 우리와 함께 웹의 미래를 검사하자!