[마이리뷰] [중고] Effective Unit Testing

[중고] Effective Unit Testing - 클린 코드와 좋은 설계를 이끄는 단위 테스트, 한국어판
라쎄 코스켈라 지음, 이복연 옮김 / 한빛미디어 / 2013년 11월

올해 하반기에 팀 동료들과 유지보수의 어려움에 대한 논의가 있었다. 그 중 유닛테스트 추가가 필요하다는 이야기가 나오게 되었다. 우리는 유닛 테스트를 일부 가지고 있었지만 추가 활용의 어려움이 있었다. 유닛 테스트 추가하기 위해서 우리에게 무엇을 필요한지에 대한 논의를 하게 되었다.

* 유닛 테스트를 추가함으로써 우리는 무엇을 얻게 되는가?
* 유닛 테스트 추가를 방해하거나 어렵게하는 요인이 있는가?

우리는 유닛 테스트가 중요하고 코드 안정성 뿐만 아니라 개발 시간을 줄여주는데 도움을 준다는 것에 모두 동의하였다. 하지만 유닛 테스트 작성이 익숙하지 않으며 어떻게 작성하는게 잘 작성된 것인지를 잘 모른다라는 의견이 있었고 특히 네트워크나 DB 인터페이스를 활용하는 시스템 데몬들은 유닛 테스트 작성이 어렵다라는 의견도 있었다.

원활한 유닛 테스트를 위한 해결 방법 중 1가지로써 책을 선정하여 팀 스터디를 진행하기로 결정하였다. 그렇게 해서 결정된 책이 Effective Unit Testing이다.


100% 코드 커버리지 달성이 중요한 게 아니다.
95%보다는 100%가 물론 듣기 좋다. 다만, 그 차이가 크지 않을 수 있다. 테스트의 가치는 테스트가 확인하지 못한 코드가 어떤 것인가와 테스트가 프로그래밍 실수를 얼머나 정확하게 잡아내는가에 좌우된다. 100% 달성이 단순히 모든 코드를 한 번씩은 실행해보았다는 것만 보장할 뿐일 수 있다. 그러니 커버리지에 대한 강박관념은 버리고 의미 있는 테스트를 작성하는 데 집중하기 바란다.

* 테스트는 실 사용에 적합한 설계를 끌어내준다.
* 테스트는 원하는 동작을 명확히 알려주어 군더더기(gold-plating)를 없애준다.
<Chapter 1 좋은 테스트의 약속>


버그 수정 비용의 증가
구글이 측정한 바로는 프로그래머가 버그를 만들자마자 즉시 수정한다면 $5를 쓴 것이다. 같은 결함을 프로젝트 전체 빌드 때 발견되면 비용은 $50가 된다. 만약 통합 테스트까지 살아남으면 $500로 증가하며 시스템 테스트에 이르면 $5000까지 치솟는다. 이 수치만 봐도 문제는 가능한 한 빨리 발견해야 한다는 건 이론의 여지가 없다.
<Chapter1 좋은 테스트의 약속>


이 책이 좋은 이유는 좋은 테스트가 무엇인지 명확하게 이야기하고 ˝버그 수정 비용의 증가˝와 같이 유닛테스트 장점에 대한 객관적인 데이터를 서술한다는 점이다. 특히 100% 코드 커버리지 달성이 중요하지 않다는 것은 매우 공감한다. 100%를 목표로 하게 되는 순간, 소소하고 크기가 작은 함수들까지 모두 테스트를 만들어야 하게 된다. 경험적으로 100%를 향하게 되면 원하는 동작 검증이 아니라 얼마나 테스트를 많이 만들었는지 집중하게 될 확률이 높아진다고 생각한다. 질보다는 양으로 승부하게 되는 셈이다.


무엇이 테스트를 좋게 만드는 것일까?
* 테스트 코드의 가독성과 유지보수성
* 프로젝트 안에서, 그리고 소스 파일 안에서 코드는 적절히 구조화되어 있는가?
* 테스트가 무엇을 검사하는가?
* 테스트는 안정적이고 반복 가능한가?
* 테스트가 테스트 더블을 잘 활용하는가?
독립적인 테스트는 혼자서도 잘 실행된다. 격리와 독립성이 중요한 이유는 그것이 없다면 테스트를 실행하고 관리하기가 훨씬 어렵기 때문이다. 단위 테스트를 실행하기 위해 개발자가 해야할 귀찮은 작업이 훨씬 많아진다.
<Chapter 2 좋은 테스트란?>


독립적인 테스트(격리와 독립성) 이야기는 꽤 반가운 이야기였다. 나는 테스트는 반드시 독립적이어야 한다고 생각한다. 독립적인 테스트를 만들지 않으면 이미 만들어놓은 테스트가 어느 순간 동작하지 않을 가능성이 높아진다. 이미 작성된 대부분의 테스트를 재작성하거나 구축하는 것은 낭비이기 때문이다. 독립적인 테스트의 중요성에 대해서 상관없거나 무관심한 사람과 함께 일한다면 중복이나 낭비에 대한 개념이 없는 사람이니 되도록이면 멀어지는게 좋다.

독립적 테스트와 관련된 경험한 사례를 이야기하면,
1. 유닛테스트를 다른 레파지토리에 운영하고 버전으로 운영하자.
2. 모든 팀이 활용하는 계측기로 자동화 테스트를 돌리자. 환경이 무너질 가능성이 있지만 구축하면 결국 도움이 될 것이다.

1번은 당췌 어떤 장점을 얻게 되는지 몰라서 강력하게 거절했다. 유닛 테스트를 실행할 때 마다, 버전을 고려해야 하는 불편함이 오히려 생기게 되는데 말이다. 2번 사례도 환경이 매번 무너지면 결국 도움이 안될 것이라고 주장했지만 결국 시간을 들여서 구축을 하였다. 아쉽게도 구축한 테스트 환경의 운영은 한달도 안되서 무너졌고 1-2번 재정비했지만 결국 그 이상은 운영하지 않았다.

테스트 주도 개발 책에서도 독립적인 테스트 관련하여 일부 답을 얻을 수 있다.


TDD의 부산물로 자연히 생기는 테스트들은 시스템 수명이 다할 때까지 함께 유지돼야 할 만큼 확실히 유용하다. 하지만 이 테스트들이 다음과 같은 다른 종류의 테스트들을 대체할 수 있을 거라고 예상해서는 안된다.
* 성능테스트
* 스트레스 테스트
* 사용성 테스트
<17장>


Effective Unit Testing 책 내용 대부분은  ˝Part 2 테스트 냄새˝에 해당한다. 여기에서는 다양한 예시와 나열하고 저자의 해결책들을 확인해볼 수 있다. 아래는 책 내용 중  조건부 테스트라는 내용을 요약한 것이다.

유지보수성의 조건부 로직과 비슷하다. 여기에서는 아예 조건문 때문에 테스트가 동작안하는 상황을 의미한다. Assert가 조건문을 통해서 실행되는지 확인하라. 어쩔수 없이 if문 조건이 필요하다면 if문 조건까지도 assert로 검증하라.

예를 들어 아래와 같은 assert에 대해서,
if( process.exitCode() == 0)
{
     assertEquals(“hello.txt”, process.output);
}

다음과 같이 변경하자.
assertEquals(0, process.exitCode())
assertEquals(“hello.txt”, process.output);
<Chapter 6 신뢰성>


참고로 예제 코드 대부분이 자바로 작성되었기 때문에 최소한 객체지향언어에 대한 이해가 필요하다.

이 책은 다른 Effective 시리즈와 같이 해당 기술에 경험이 없는 사람이라면 단순히 읽기에는 적절치 않다고 생각한다. Chapter1만 읽고나서 다양한 유닛테스트를 먼저 작성해보는 것을 추천하고 싶다. 그리고 나서 Chapter2를 읽어보게 되면 이미 내가 작성한 유닛 테스트를 가지고 고쳐나가는 실습을 할 수 있으며 집중력도 높아질 것이다.

[마이리뷰] 테스트 주도 개발

테스트 주도 개발 ㅣ 프로그램 프로그래밍 프로그래머 5
켄트 벡 지음, 김창준 외 옮김 / 인사이트 / 2014년 2월

테스트 주도 개발(TDD, Test-Driven Development)은 동작하는 깔끔한 코드를 위해서 테스트를 먼저 작성하는 개발 방법론을 의미한다. 여기서 테스트란 유닛 테스트를 의미한다. 

유닛테스트란 소스코드에 대한 개발자에게 함수와 모듈의 동작을 검증을 할 수 있게 도와주는 도구이다. 유닛 테스트는 개발된 코드의 사용 방법을 가이드 할 뿐만 아니라 여러 가지를 한번에 고민해야 하는 개발자에게 실수를 줄여주고 작성한 코드에 대한 테스트를 진행할 수 있어 견고한 수문장 역할을 한다고 말할 수 있다. 이미 많은 개발자들이 유닛테스트 활용이 중요하다는 것을 알고 있다고 생각한다. 팀이든 1인 개발이든 말이다.


이 책에서 다양한 유머들을 책 곳곳에서 찾아볼 수 있다. 저자 ˝켄트 벡˝은 단순 일 밖에 모르는 아저씨가 아님은 확실하다. 실제로 켄트 벡은 소프트웨어 엔지니어로 애자일의 XP 방법론을 창시한 사람으로도 유명하다. 또한 애자일 메니페스토를 만든 사람 중 1인으로써 개발 생태계에서 많은 활동을 하고 있는 사람이기도 하다. 


책 구성은 화폐예제, xUnit 예시, 테스트 주도 개발의 패턴 이렇게 3가지로 크게 나눌 수 있다. 이 중에서 화폐예제는 매우 흥미로운 부분이다. 화폐예제는 하나의 프로그램을 수정해나가는 과정을 이야기하는데 다음과 같은 특징을 갖는다.
* 테스트 주도 개발 절차를 소개하고 그대로 활용하는 예제를 보여준다.
* 바로 옆에서 코드를 고치면서 알려주듯이 이야기 한다.
* 테스트 주도 개발을 하면서 겪게 되는 고민들까지 포함되어 있다.
위에서 테스트 주도 개발을 위해서는 테스트를 먼저 작성해야 하는 것이라고 설명했다. 작성한 코드가 없는데 테스트를 먼저 작성하라니 코딩을 해본 사람이라면 이 문장이 쉽게 이해가 되지는 않을 것이다. 화폐예제를 통해서 ˝아, 테스트를 먼저 작성한다는 것은 이런 걸 의미하는구나˝라고 좀 더 쉽게 이해할 수 있다.

하지만 이 책을 읽기 위해서는 기본 지식이 필요하다.  자바 언어를 예제로 사용하고 있는데 자바를 모르더라도 최소한 객체지향 언어에 대한 이해가 있어야 한다. 또한 유닛테스트에 대한 경험이 없다면 흥미롭게 작성된 화폐예제를 읽게 되더라도 몰입이 되지 않을 것이다.

이 책을 읽으면서 얻어가야하는 것은 2가지라고 생각한다.
* 테스트 주도개발은 왜 해야 하는가? 테스트를 먼저 작성함으로써 무엇을 얻을 수 있는가?
* 테스트 주도 개발은 무엇이고, 테스트 주도 개발은 어떻게 해야 하는가?

테스트 주도 개발의 목적은 작동하는 깔끔한 코드다. 
작동하는 깔끔한 코드(clean code that works). 론 제프리즈의 핵심을 찌르는 이 한마디가 바로 테스트 주도 개발의 궁극적인 목표다. 작동하는 깔끔한 코드가 훌륭한 목표임을 말해주는 수많은 이유가 있다.
<저자의 글>

작동하는 깔끔한 코드를 위해서는 왜 테스트를 먼저 작성해야 하는가? 의외로 간단하다. 목적은 작동하는 깔끔한 코드다. 일반적으로 코딩 과정을 생각해보면 깔끔한 코드를 먼저 작성하고 작동 여부를 확인한다. 반대로 생각해보는 것이다. 일단 코드를 작동하게 하고 깔끔한 코드를 만들게 하는 것이다.

‘제대로 동작하는’을 푸는 동시에 ‘깨끗한 코드’를 해결하는 것은 한번에 하기에는 너무 많은 일일 수 있다. 그렇게 되면 우선 ‘제대로 동작하는’으로 되돌아 가서 그걸 해결하고, 그 후에 ‘깨끗한 코드’를 느긋하게 해결하도록 하라.

가짜로 구현하기를 강력하게 만드는 두 가지 효과가 있다.

 1. 심리학적 - 초록 막대 상태에 있는 것은 빨간 막대 상태에 있는 것과 천지 차이다. 막대가 초록색일 떄, 자신이 어디에 서 있는지 안다. 당신은 확신을 갖고 거기부터 리팩토링해 갈 수 있다.

 2. 범위(scope) 조절 - 프로그래머들은 모든 종류의 미래 문제를 상상하는데 탁월하다. 하나의 구체적인 예에서 시작해서 일반화하게 되면, 쓰잘데기 없는 고민으로 때 이르게 혼동하는 일을 예방할 수 있다. 다음 테스트 케이스를 구현할 때, 이전 테스트의 작동이 보장된다는 것을 알기 때문에 그 다음 테스트 케이스에도 집중할 수 있다.

<28장 초록 막대 패턴>


TDD 주기는 다음과 같다.
 1. 작은 테스트를 추가한다.
 2. 모든 테스트를 실행하고, 실패하는 것을 확인한다.
 3. 코드에 변화를 준다.
 4. 모든 테스트를 실행하고, 성공하는 것을 확인한다.
 5. 중복을 제거하기 위해 리팩토링한다.

<17장 Money 회고>

테스트 주도 개발을 어떻게 해야하는지는 ˝화폐예제˝를 통해서 알 수 있다. ˝xUnit˝과 ˝테스트 주도 개발의 패턴˝은 실제로 활용하는데 도움이 되는 내용으로 되어 있다.

이 책은 테스트 주도 개발의 개념과 기본 방법을 익히는데 아주 탁월한 책이다. 다만 테스트 주도 개발을 ˝잘˝ 하기 위해서는 숙련된 유닛 테스트 방법이 필요하다고 생각한다. 여기에서는 유닛 테스트를 어떻게 잘 작성하는게 좋을까에 대해서는 답을 얻어가기 어려울 것이다. 이를 위해서는 추가 학습이 필요하다.

[마이리뷰] 리모트

리모트 - 사무실 따윈 필요 없어!
제이슨 프리드 & 데이빗 하이네마이어 한슨 지음, 임정민 옮김 / 위키미디어 / 2014년 12월

전세값 상승이라는 큰벽을 만나게 되었다. 게다가 원격 근무의 일종인 디지털 노마드까지 알게 되어 원격 근무에 대한 관심이 무척 높아진 상태였는데 상사이자 오랜 친구인 동료가 추천을 해주어서 책을 읽게 되었다. 

이 책은 basecamp, campfire등의 프로젝트 관리 툴을 개발하고 서비스하는 37 signals의 제이슨 프리드, 데이빗 하이네마이어 한슨가 지은 책이다. 이 회사는 원격 근무를 지원하는 회사로도 유명하다. 사무실에서 일하는 것도 가능하지만, 놀라운점은 개인이 선택할 수 있다는 점이다. 저자는 다년간의 원격 업무를 계획하고 실제로 경험한 사례를 기반으로 책을 만들었다.

결론부터 이야기하자면 이 책은 나에게 개발 일에 대한 영감 뿐 아니라, 원격 근무에 대한 가이드가 되는 훌륭한 책이 되었다. 전반적으로 원격근무와 출근을 배타적으로 편가르지 않는다. 원격근무 또한 일을 해나가는 하나의 방식이라는 개념으로 이야기를 풀어나간다. 사실 단점이 있다라고 이야기를 끝내면 그것은 부정적인 면으로만 받아들여진다.


원격근무 도입은 곧 사무실이 필요 없거나, 없어진다는 의미가 아니다. 모든 직원이 한곳에 모여서 일할 필요가 없다는 뜻이지, 반드시 각자 집에서 일해야 한다는 의미도 아니다. 원격근무는 직원 모두가 어디에서든 최상의 컨디션으로 일하는 데 목적이 있다. 각기 다른 규모의 회사들이 다양한 형태로 원격근무를 유연하게 도입하고 있다. 

세계적 가구회사 허먼밀러의 지식디자인팀은 팀원 모두가 미국 내 10개 도시에 흩어져서 일하는 원격근무 시스템을 갖추고 있다. 디지털커뮤니케이션 회사 젤리비전은 직원의 10%가 원격근무를 하고 있고, 20% 정도가 주중 며칠씩 재택근무를 하고 있다. 나머지는 시카고 본사에서 근무한다. 
<41p>


책 진입부에는 원격근무에 대한 정의를 이야기 한게 되는데 모든 직원이 한곳에 모여서 일할 필요가 없다라고 말한다. 나는 이 부분에서 잠시 책을 접고 고민에 빠졌다. 한 곳에 모여서 일을 하면서 얻게 되는 이점이 무엇일까? 

대부분 우리는 출근을 통해서 한곳에 모여 일을 하고 있다. 사무실에서 얼굴을 보며 기술 회의나 스터디를 함께 진행할 수 있다. 직접 대면하면서 회의를 진행하는 장점은 대부분 알고 있을 것이다. 아무리 디지털 시대이지만 정답이 없는 문제를 논의하는 과정에서 화이트 보드를 통해 흐름을 설명하거나 바디 랭귀지로 서로의 발언 타이밍을 추측하거나 눈빛으로 호소하는등 다양한 상호 작용이 일어나기 때문이다. 

하지만 대면할 수 없다고 해서 아예 회의를 할 수 없는 것도 아니다. 노트북과 웹미팅 서비스를 활용하면 어느정도는 진행이 가능하다. 한편 출근해서 일을 하게 되면 개발 편의를 위해 마련된 사무실의 인프라들을 누릴 수 있게 된다. 소소하게는 사무실에 있는 커피머신부터 사무용품까지도 손쉽게 사용할 수 있는 장점이 된다. 

그 동안은 몰랐던 사무실 업무가 주는 장점들이 눈에 띄기 시작했다. 그 장점을 어떻게 활용하면 좋을지에 대하여 집중할 수 있게 되어 나름 도움이 되었다고 생각한다.  


중요한 것은 업무뿐 “언제 출근했나요?” 대신 “오늘 한 일은 무엇인가요?”라고 물어보자. 업무 결과물에 대한 질문이 더 의미가 있다. 또 “오늘 무슨 일을 했나요?”라고 묻지 말고 “오늘 한 일을 보여주세요”라고 묻자. 그러면 관리자는 업무를 직접적으로 평가할 수 있다. 원래 업무 결과물이 그 사람에게 월급을 주는 이유가 아니던가? 업무 결과물과 관계없는 나머지는 무시하면 된다. 
<p104>


출퇴근 관리는 그만 관리자의 역할은 양떼를 모는 일이 아니라, 조직을 리드하고 업무를 검증하는 것이다. 이렇게 하려면 해당 업무에 전문지식을 가지고 있어야 한다. 직원들이 하는 일을 모르면 그들을 효율적으로 관리하기 어렵다. 

현명한 관리자는 출퇴근을 관리하지 않는다. 언제 어디서 일을 하는지는 실제 업무 결과와 거의 무관하다. 광고카피를 런던에서 썼는지, 마벨라에서 코딩을 했는지, 에드몬드에서 디자인했는지는 훌륭한 광고카피, 제대로 된 코드, 아름다운 디자인과 전혀 상관없다. 
<p176>


놀라운 경험을 하게 되었다. 회사에서 동료들과 회의를 통해서 출퇴근 및 업무 시간보다 업무의 결과와 커뮤니케이션 능력이 그 사람의 실력을 가르킨다는 것에 대한 논의를 한 적이 있다. 모든 사람이 동의하지는 않았지만 대부분은 시간보다는 업무의 결과가 중요하다는 것에 동의를 했다. 

하지만 함께 일하는 몇몇 사람들은 결과보다는 출퇴근 시간, 점심 시간, 자리를 얼만큼 비우는지등에 생각보다 많은 의미를 부여한다는 점을 깨달았다. 업무 결과가 중요하지 않다라고 말한 이상한 사람은 없었지만 중요도에 대해서 차이가 있었다. 만약 원격 근무를 일부가 하게 된다면, 몇몇 사람들은 상대적 박탈감을 느낄 수 있겠구나라는 생각을 갖게 되었다. 

책 중간 중간, 애자일에서 이야기하는 투명한 업무 공유를 엿볼수 있었다. 


37시그널스에는 ‘이번주에는 무슨일을 했나요?”라는 제목의 주간회의 게시판 글로 정보를 공유한다. 구성원 모두는 이번주와 다음주에 무슨일을 계획하고 있는지 몇줄로 요약해서 올린다. 이는 정확할 필요도 없고, 예측하거나 협업을 조직하는 것도 아니다. 단순히 모두가 같은 배에 타고 있다는 정도만 확인하면 된다.  

사람은 누구나 동료를 실망시키지 말아야겠다는 본능이 있어서 자신의 진도가 시각적으로 보여지게 되면 더욱 열심히 하게 된다.  팀장보다 팀원을 속이기가 더 어렵다. 기술을 잘 모르는 프로젝트 매니저에게 개발자가 30분이면 끝날 작업을 일주일 내내 걸리는 대작업처럼 이야기하기 쉽다. 그러나 다른 개발자들에게도 이런 정보가 모두 공개되면 금방 들통 나기 마련이다.  모두가 업무 진행 상황을 공유할 때 좋은 결과가 나온다. 
<p101>


이외에도 고용, 기업문화, 원격근무 초기 도입, 원격 근무시 주의사항등 다양한 이야기를 엿볼 수 있다. 만약 개발자라면 개발 조직의 경험이 있어야 여러면에서 충분한 공감과 영감을 줄 것이라고 믿는다.  기업마다 사정이 있고 개성있는 문화를 가지고 있기 때문에 이 내용이 정답이라고 말할 수 없다. 갑자기 내가 당장 내일부터 원격근무를 하더라도 정답을 이 책에서 찾을 수 없을 수도 있을 것이다. 하지만 나의 고민을 도와줄 든든한 멘토 역할을 충분히 할 것이라고 믿는다.

[마이리뷰] 첫아이를 임신했어요!

첫아이를 임신했어요! - 임신에서 출산까지 ㅣ 토리짱과 함께 시리즈 1
콘도우 아키 지음, 정윤아 옮김 / 이덴슬리벨 / 2016년 3월

임신한 아내를 위해서 구매한 책이다. 실제 경험담을 보면 막연한 불안감도 줄여주고 기타 심적으로 도움이 되지 않을까해서 구매하였다.

출산과 육아의 과정이 결코 쉽지 않다는 것을 세삼 깨닫게 해준다. 출산 과정에서 아내가 말하기 어려운 부분이 있을 수 있구나라는걸 알게 되었다. 조금이나 이해하고 무엇을 함께 해야하는지를 알기 위해서 남편들도 함께 보면 좋지 않을까 싶다.

표지에서 남편이 가장 작게 보이는 것은 기분 탓인가.

[마이리뷰] 가장 쉬운 네트워크 가상화 입문 책

가장 쉬운 네트워크 가상화 입문 책 ㅣ 가장 쉬운 책 시리즈 4
와타나베 카즈히코 외 지음, 신은화 옮김 / 비제이퍼블릭 / 2014년 8월

클라우드 컴퓨팅이란 인터넷 등을 통해서 네트워크상에 존재하는 컴퓨터 자원을 이용하여 서비스를 제공하는 컴퓨팅 형태를 말한다.
사용자는 서비스를 제공 받을 뿐, 실제 컴퓨터가 어떻게 동작하는지, 네트워크가 어떻게 연결되어 있는지 등은 신경쓰지 않는다.
한편, 가상화란 하나의 물리적인 자원을 복수의 논리적인 자원으로 활용하거나 복수의 물리적인 자원을 하나의 논리적인 자원으로 활용하는등의 형태를 의미한다.
이와 같이 클라우드와 가상화의 개념은 그 목적이 다르다.하지만 실제로는 클라우드 서비스를 제공하는 사업자가 시스템 자원의 효율적인 활용을 위하여 가상화 환경을 구축한다.
<p8 가상화란>


이 책은 가상화란 무엇인지 그리고 서버, 스토리지, 데스크탑, 네트워크에 대한 가상화 기술들에 대해서 그림을 통하여 친절하게 설명되어 있다. 
무엇보다도 가상화, 클라우드라는 IT 용어에 대해서 내가 명확하게 알고 있지 않다라는걸 깨닫게 해준 책이다. 대부분 왜 이 기술이 필요한지 배경을 공유해주어서 좋으나 특정 부분은 간단한 소개만 나오는 경우도 있다.

인프라를 다루거나 네트워크에 관심이 있다면 읽어보라고 권장하고 싶다. 참고로 기술에 대한 설정 방법과 설명등은 빠져있다.
네트워크 장비들은 다양한 벤더들이 있고 설정 방법들도 각각 다르기 때문에 설정 방법까지 다 알려주는 것은 어려운 일이긴 하다.