NDC Replay

테스트 꾸준히 잘하는 법
박종석
넥슨코리아
현재 게임프레임워크팀에 근무하고 있으며, 서버 프로그래밍을 담당하고 있음. 과거, DBMS 개발과 마비노기 영웅전 개발에 참여하였으며, 총 개발 경력은 5년 정도
온라인 게임에서 자동화된 테스트의 중요성은 매우 큽니다. 하지만, 그 자동화된 테스트를 만들고 유지보수하는 비용을 감당하지 못하거나, 또는 그럴 것이라고 생각하기 때문에 자동화된 테스트를 도입하지 못합니다. 이 때문에 매 테스트를 사람의 손에 의지하고 있으며, 사람 손으로 불가능한 테스트 (특징 동접 이상일 때 발생하는 문제)를 하지 못하여 라이브 중에 문제가 발생하기도 합니다. 책을 보면 테스트를 제대로 한다면, 오히려 개발 속도가 단축된다고 이야기 합니다. 하지만 실제로 개발자들은 비현실적인 이야기로 받아들이고 있습니다. 그렇지만 그 개발자들을 보면 잘못된 방법으로 테스트를 하기 때문에 그렇게 볼 수 있습니다. 테스트를 할 시간이 없는게 아니고, 시간이 없기 때문에 자동화된 테스트를 해야 합니다. 이 발표에서는 테스트를 잘하는 방법을 설명하고자 합니다. 기존 책에 나오던 것을 그대로 이야기 하려는 것이 아니고, 비용대비 효과가 좋은 테스트를 하는 법을 발표합니다. 테스트 스크립트를 잘 작성하는 것보다 테스트가 용이한 모듈 디자인을 하는 것이 더 중요한데, 테스트하기 좋은 모듈을 디자인하는 법을 예를 들어서 설명합니다. ui 테스트와 커버리지가 중요하지 않은 이유에 대해서 설명합니다. unit test, 동시성 테스트, 성능 테스트를 하는 것을 c++의 boost를 사용해서 실제로 작성한 코드를 통해서 설명합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 박종석입니다. 발표 시작을 하도록 하겠습니다. 제가 오늘 얘기 하고자 하는 거는 개발자 테스트에 대한 경우고 또 테스트 자동화에 대한 애기입니다. 개발자 테스트가 뭐냐. 개발자가 개발한 모듈을 테스트를 같이 하는 내용인데, 테스트 스크립트를 사용해서 테스트하면 좋습니다. 왜 좋냐? 개발자 테스트와 테스트 자동화가 왜 좋냐? 개발자 테스트와 테스트 자동화가 왜 좋냐에 대해서 얘기를 하자면 한 시간도 더 넘게 얘기를 할 수 있는데 제가 생각하는 가장 핵심적인 거는 두 가지 인 것 같습니다. 첫 번째로 모듈 파티에 좋아지고 두 번째로 이미 작성한 모듈의 테스트가 있으면 그 다음에 개선이나 수정할 때 개발 속도가 더 향상됩니다. 그러면 이 좋은 개발 테스트를 어떻게 만들지 함께 보겠습니다. 제가 아는 분들하고 이거에 대해서 얘기를 하면, 저는 굉장히 테스트를 중요하게 생각하는 사람인데, 대부분 안 합니다. 왜 안 하느냐 물어보면 중요하다고 생각하지 않는 부분이냐 라고 하면 그렇지 않습니다. 대부분 다 중요하다는 걸 알고 있습니다. 그런데 왜 안 할까요? 팀 내에서 테스트 자동화 프로세스가 없어서 그런 분들도 몇 분 계셨던 것 같아요. 그런데 제 경험상 팀을 몇 군데 이동하면서 팀 내마다 개발 프로세스가 있는데 어떤 팀의 경우는 자동화 프로세스가 없는 적도 있었습니다. 그런데 저는 그 상황에서도 혼자 적용 하면서 그 동안 스크립트를 만들고 유지를 하고 수정할 때 적용하면서 장점을 처음에 얘기했던 장점 그대로 가져갈 수 있었습니다. 만약에 여기 계신 분들 중에서도 팀에서 자동화 프로세스가 없어서 안 한다. 그러신 분들은 한번 해보시기를 권장 드립니다. 그리고 대개는 세 번째, 네 번째 이유인데요. 해봤더니 너무 어렵더라. 그리고 테스트에 드는 비용에 비해 효과가 좋지 않지 않더라. 라고 얘기를 하는데 사실 저 두 개는 같은 내용입니다. 테스트가 어려우니까 테스트에 드는 비용이 올라가게 돼서 테스트에 드는 비용이 올라가니까 상대적으로 그것들이 효과가 좋지 않다고 느끼시는 데. 오늘 저는 이것에 대해서 이야기하고자 합니다. 사실 핵심은 두 가지가 중요한데요. 첫 번째로 디자인과 구현이 잘 되어있어야 합니다. 그렇게 잘 되어있으면 여기다가 테스트를 붙이는 것은 정말로 쉽습니다. 그리고 두 번째는 테스트를 꼭 해야 되는 것은 아닙니다. 어떤 모듈인 경우에는 테스트가 굉장히 어려운 부분도 있거든요. 그런 부분은 굳이 잘 되지도 않는데 어렵게 하면 현실적으로 했다고 해도 그 비용이 일단 올라가고 사실 실패할 확률이 더 높습니다. 유지 보수도 크고요. 그래서 그런 부분은 굳이 꼭 해야 하는 건 아닌 것 같습니다. 그래서 이 부분에 대해서 제가 나중에 설명을 드리도록 하겠습니다. 먼저 디자인과 구현이 잘 되어있어야 한다고 했는데 다른 얘기가 아니라 의존성을 줄이는 것에 대한 얘기를 하려고 합니다. 여기 보면 class D를 테스트 하고 싶은데 class D가 A에 의존성이 있어요. 그러면 이 D를 유닛 테스트 하기 위해서는 A가 있어야 합니다. 그런데 실제로 A의 의존성이 걸려 있는 걸까요? 그거를 잘 따져 보면 이렇게 A가 아니라 A 부분적인 곳에 의존성이 걸려있는 경우가 많습니다. 사실 이런 경우는 어떻게 해야 하는지 다들 아실 테죠. 분리를 해야 합니다. 분리를 하면 class D를 유닛 테스트하기 위해서 A만 있으면 됩니다. A를 파라매터 같은 것으로 만들 수도 있고, 아무튼… 이게 사실은 굉장히 기본적인 내용인데 모두들 다 알고 계시죠. 그런데 신경 쓰고 있다가도 부주의하게 약간 신경을 덜 쓰면 실수를 하는 부분이기도 합니다. 이렇게 부주의하게 의존성이 걸려버리면 이 그 때부터는 이미 의존성이 걸려있으니까 막 씁니다. 막 쓰게 되면 나중에 분리하기가 정말 힘들어지죠. 깨진 유리잔 붙이기라고 하죠. 이렇게 의존성이 걸리게 생각하는 주의를 해야 합니다. 이것만 잘 지켜도 의존성을 만들 수 있을 것 같습니다. 그리고 아까 테스트를 꼭 해야 한 다는 거는 아니라고 말씀을 드렸는데요. 테스트를 하라고 발표를 해야 되는 거 아닌가, 얘기하기도 좀 그런데, 거기에 대해서 Kent Beck이 쓴 에세이가 있습니다. 이 에세이를 보고서 이 얘기를 공유해도 되겠다. 라는 용기를 얻었는데 소개해드리도록 하겠습니다. 일단 시스템 테스트와 유닛 테스트에 대해서 잠깐 설명을 드릴게요. 오픈 소스 DBMS 아키텍처인데요. 밑에 부분이 서버고 위에는 클라이언트 입니다. 만약에 서버를 테스트하겠다. 이 때 시스템 테스트를 하겠다는 거는, 시스템 테스트는 오픈 된 인터페이스를 가지고 테스트를 하는 거거든요. 그래서 시스템 테스트를 하겠다는 거는 밑에 테스트 스크립트가 붙습니다. 테스트 스크립트가 붙어서 테스트를 하는 데요. Query, SQL을 가지고 테스트하죠. 그런데 제가 만약에 범퍼 매니저를 만들었어요. 범퍼 매니저를 만들었는데 이거를 시스템 테스트하려고 해요. 그러면 이게 불가능 한 건 아닌데 할 수는 있어요. 그런데 제가 정말 원하는 테스트를 하기는 힘들죠. 원하는 시나리오의 테스트를 하는 게 힘든 게 왜냐면 이 부분을 다 고쳐야 합니다. 이 부분을 다 파악하고 있어야지 내가 원하는 대로 작업을 할 수가 있는데 이런 경우에 유닛 테스트가 더 좋을 수도 있습니다. 바로 옆에 붙어서 함수를 호출해 주면 되거든요. 그런데 유닛 테스트가 무조건 좋으냐? 유닛 테스트는 의존성이 걸리겠죠. 범퍼 매니저는 의존성이 다 걸리기 때문에 이것만을 떼어서 테스트하기도 힘듭니다. 그래서 어떤 경우에는 시스템 테스트가 더 쉽고 좋습니다. 그래서 Kent Beck이 고민을 합니다. 어떨 때는 시스템 테스트가 좋고 어떨 때는 유닛 테스트가 좋고 대체 어디서 테스트를 해야 되는 거지? 라고 에세이에 실려있는데요. 사실은 이 분이 말하고자 하는 것은 어디서 테스트하는 것이 중요한 게 아니라 세 가지를 가지고 테스트를 어디서 할지, 아니면 할지 말지 결정해야 한다고 합니다. 그게 Cost랑 stability, Reliability가 측면인데요. 사실은 cost는 이 두 가지 모두 포함합니다. 여기에 대해서 설명을 좀 드리면 cost란 뭐냐. 테스트를 작성할 때 드는 비용입니다. 유지보수 비용이기도 하고 여기에 더해서 테스트 수행 시간까지도 비용으로 들어가는데 테스트를 적고 빠르게 만들수록 좋다고 합니다. 무슨 소리냐면 테스트 자체는 사실은 최종 결과물에 어떠한 가치도 있지 않습니다. 그래서 아무리 잘 만들어도 최종 결과물에는 좋게 하는 게 없거든요. 테스트의 목적은 뭐냐면 버그를 많이 잡는 거에요. 버그를 많이 발견하도록 하는 건데 여기에 드는 비용을 줄이겠다.라고 얘기를 하는 겁니다. 그리고 stability는 예를 들면 이런 겁니다. 어떤 테스트를 작성 했는데 항상 깨져요. 깨져서 보면 문제가 없죠. 문제가 없는데 깨지면 어떻게 합니까? 수정해야 되죠. 그게 계속 반복이 되요. 그렇게 되면 피곤해지고 멘탈에 유지가 재대로 안 돼서, 멘탈이라는게 사실은 개발자에게 굉장히 중요한데 이런 부분 때문에 개발 비용 자체가 늘어나기도 합니다. 그래서 과연 이 부분을 유닛 테스트나 시스템 자동화로 테스트 자동화를 했을 때 stable한 결과가 나오느냐? 에 대한 것들도 고려를 해야 한다고 합니다. Reliability 측면인데요. 모든 것을 테스트하라는 게 아닙니다. 문제가 있을 만한 곳을 가지고 테스트를 하라는 거고, 사실은 모든 부분을 테스트할 수가 없어요. 왜냐면 테스트로는 버그가 없다는 것을 검증할 수가 없거든요. 그렇기 때문에 모든 부분을 테스트 할 수가 없고 어떤 부분을 해야 하느냐? 개발자의 경험과 직감에 의존할 수 밖에 없는데 문제가 있을 확률이 높고 버그로 인한 기록이 높은 곳에 집중적으로 테스트를 해야 한다고 합니다. 저는 어떻게 하냐면 테스트 스크립트 개수를 많이 안 만들려고 합니다. 그리고 테스트 관심 있으신 분들 다 아실 것 같은데 뒤에서 조금 더 얘기하도록 하겠습니다. MOCK도 가능한 안 쓰려고 합니다. 그리고 stability 측면에서 UI를 결과를 검증하는데 pixel by pixel로 비교를 한다. 이런 것은 안 하려고 합니다. 왜냐하면 정상적인데도 불구하고 에러가 있다고 할 확률이 높거든요. Reliability 측면에서는 로직이 복잡한 부분. 그리고 수동 테스트가 어려운 부분을 철저하게 테스트하는데 수동 테스트가 어렵다는 거는 확률성 아이템 같은 거를 만들 때 10000개 라고 했을 때 1개가 나올 확률 같은 거를 테스트를 하야하는 거는 손으로 테스트하기는 힘듭니다. QA분들이 테스트하는 거 보면서 이런 부분은 개발자가 확실하게 테스트해서 넘어가는 부분이고요. 그리고 동시성 검증도 철저히 합니다. 저는 서버 프로그래머라 그런지 모르겠고 동시성이 있는 곳은 항상 버그 확률이 높고 그리고 버그 빈도도 굉장히 높습니다. 그래서 동시성 검증도 철저히 하는 편이고요. 그런데 이제 믿을만한 모듈은 대충 합니다. 어떤 경우에는 안 하고요. 사실은 믿을만한 부분은 그냥 안 합니다. 어떤 말이냐 하면 오픈 소스를 쓴다든가 아니면 기존에 이미 잘 쓰고 있는 모듈 같은 경우는 테스트 잘 안 하고요. 그리고 새로운 기능이 들어가거나 수정을 해야 되요. 그런 경우에 어떻게 하냐면 가능하면 잘 동작하는 건 안 건드리려고 합니다. 그래서 어떻게 하면 기존 모듈을 잘 사용해서 그 원하는 기능을 만들까? 굉장히 고민을 많이 하는데. 사실 쉬운 건 아니고요. 잘 이해를 해야 되는데, 아무튼 그렇게 하도록 노력을 합니다. 제가 아까 전 테스트 비용을 줄이려면 MOCK 사용을 최소화 해야 한다고 했는데 여기에 대해서 자세히 설명을 드리도록 하겠습니다. 제가 MOCK을 아예 안 쓰는 건 아니고, MOCK이란 건 뭐냐면 실제 모듈을 흉내 내는 클래스라고 보시면 되는데, 내가 원하는 일을 하는 겁니다. 그런데 이게 굉장히 heavy해요. 해결 하는 게 수행시간도 길고 initializer 하는 데도 오래 걸리고. 내가 원하는 일을 시키고 있는, 그래서 이런 부분에 MOCK을 씁니다. 그리고 이런 식으로 legacy 경우에 많이 있는데요. Class D를 테스트 하고 싶은데 A에 dependency가 걸려 있어요. 그런데 A는 여러 dependency의 일부분일 뿐이죠. 그래서 이런 경우에도 MOCK을 써서 이 부분만 테스트 하기도 합니다. 실제로는 이런 방향이죠. 그래도 MOCK은 가급적 안 쓰는 방향으로 하려고 합니다. MOCK이 만드는 것도 힘든데요. 앞에 전 세션을 들어보니까 MOCK 만드는 게 굉장히 어렵다는 얘기를 계속 하시더라고요. MOCK만드는 것도 힘든데 유지 보수하는 것도 힘듭니다. 유지보수 계속 해줘야 되거든요. 원래의 모듈이 바뀌는 경우에 이 MOCK도 계속 유지보수를 해야 하는데, 사실은 MOCK은 테스트 기반, 테스트의 일부이기 때문에 신경이 잘 안가요. 실제로 버그가 있는 부분은 문제가 바로 버그가 있다면 고치는데요. MOCK은 안 고쳐도 문제가 없을 것 같아요. 왜냐면 최종 결과물이 잘 돌아가고 있거든요. 그래서 신경을 안 쓰고 있게 되요. 가급적 테스트 스크립트를 그래도 줄이는 게 좋을 것 같습니다. MOCK을 안 만들면서 어떻게 유닛 테스트를 하냐? Bottom up 방식으로 테스트하면 됩니다. Top down 하고 Bottom up. 되게 유명한 이야기인데요. 디자이너한테 많이 나오는 얘기죠. 제가 설명을 드리겠습니다. Top down은 전체의 요구를 만족하는 설계를 만든 다음에 각 필요한 부분을 세부적으로 들어가서 만드는 것이고요. Bottom up은 일단은 도메인을 추상화 합니다. 그 라이브러리를 가지고 또 추상화해서 올라가고 또 새로 추상화해서 올라가고. 계속 추상화해서 높여가는 방법입니다. 그래서 비교를 해봤는데요. 추상화 순서 제가 지금 말씀 드렸고요. 각 layer의 유구 사항은 Top down의 경우에는 전체가 필요로 하는 요구를 만들어야 됩니다. 그래서 요구사항이 굉장히 명확해요. 그런데 Bottom up은 그렇지 않아요. 현재 layer가 필요한 것을 자기가 매 layer마다 다 생각을 해야 되요. ‘이 layer는 이런 방식으로 추상화할 거야. 이 layer는 이런 방식으로 추상화 할거야.’ 생각을 해야 됩니다. 그래서 Top down 은 보시면 알겠지만 굉장히 빨라요. 굉장히 빠른 대신에 Bottom up은 느리죠. 매번 그렇게 추상화하면서 올라가니까. 대신에 상위layer가 바뀌었어요. 최종 모양이 바뀌는 경우에는 Top down은 밑에 있는 것까지 바꿔줘야 하는 경우가 발생합니다. 왜냐면 그 밑에 있는 게 위에 거를 위해서만 만들어졌기 때문인데, Bottom up은 그렇지 않아요. Bottom up은 밑에 있는 게 그 나름대로의 철학을 가지고 있기 때문에 도메인에서 바뀌는 거면 상위 layer 외에 바뀌는 게 많이 없습니다. 그래서 변경에 대해서 굉장히 유연한 모습을 보입니다. 그리고 순서를 보면 Top Down은 메인부터 작성을 하고 라이브러리를 작성하는 편이고요. 모듈 작동 순서를 보면 어떤 모듈 같은데 나를 호출하는 이미 존재하면 Top down 이고 내가 사용할 MOCK이 존재하는 것입니다. 그래서 나를 호출하는 부분들이 존재하기 때문에 자칫 실수하면, 앞서 말했듯이 호출 함수들에 의존성이 걸려버리니까. 그런데 여기는 내가 사용할 것만 있기 때문에 호출하는 모듈에 의존성은 안 걸리죠. 그래서 bottom up으로 구현하면 의존성에서도 유리합니다. 그런데 이 부분을 자 잘 보시면 이 두 부분은 디자인 관련된 이야기고요. 밑에 두 부분은 구현 관련 얘기입니다. 그러면 사실은 Top down과 bottom up을 같이 섞어서 사용하는데요. 디자인 할 때는 Top down을 써서 전체 구상을 빨리 파악해서 전체 모양을 만들고 그래서 bottom으로 구현을 합니다. 이렇게 되면 얼마짜리인지 명확해 지고요. 그리고 이 부분 때문에 의존성 부분을 잘 잡을 수 있습니다. 그래서 bottom up이랑 top down이 테스트에도 있는데요. Top down testing, bottom up testing. Top down testing은 뭐냐 하면 top down 방식으로 만들면서 하는 테스트 입이고 bottom up 테스트는 bottom으로 만들면서 하는 게 다입니다. 제가 이 부분을 그려드리도록 하겠습니다. 이게 궁극적으로 만들려고 하는 건데 bottom up으로 만들 때는 밑에 있는 것부터 만들고, 근데 이렇게 만들다가 추상화를 잘 해야 됩니다. 그리고 상위 모듈이 없죠. 의존성이 걸리지 않습니다. 이 상태에서 유닛 테스트를 합니다. 유닛 테스트를 하면서 내가 원하는 거를 다 테스트를 해줄 수 있어요. 그리고 한 가지 또 재미있는 게 뭐냐면 가진 모듈이 없는데, 위에 모듈도 사실은 밑에 모듈 이용해서 만든 거거든요. 그래서 유닛 테스트를 하면서 프로토 타이핑을 할 수 있습니다. 과연 내가 만든 인터페이스가 정말 쓰기 편한가? 괜찮은가? 그렇게 해볼 수 있고요. 그리고 이거 자체가 굉장히 좋은 재산 유닛입니다. 무슨 말이냐면, 이 하나가 의미를 가지고 있고요. 그리고 어떻게 쓰는지도 나와있고, 동작도 합니다. 그렇기 때문에 좋은 재산 유닛입니다. 그리고 앞서 했던 유닛 테스트 해봤던 것을 바탕으로 해서 실제 모듈을 만들면 작업 속도가 되게 빠릅니다. 한번 사용해 봤기 때문에. 그리고 여기 또 유닛 테스트를 붙이고 그러면 다시 또 좋은 재산이 되고요. 다시 구현을 하고 유닛 테스트를 붙이고 좋은 재산이 남게 됩니다. Bottom up은 이런 방식으로 개발을 하게 될 겁니다. 이걸 만약에 같은 걸 top down으로 가면 어떨까요? Top down 맨 위에 있는 것부터 만들거든요. 맨 위에 있는 것을 만들고 유닛 테스트를 합니다. 그런데 밑에 거를 쓰는데 밑에게 아직 없죠. 그러면 MOCK을 붙여야 됩니다. 없기 때문에. 그래서 유닛 테스트에 MOCK 비용이 들어갔다는 거. 그리고 실제로 구현하고 다시 되도 MOCK이 들어가야 됩니다. 이 때 이미 상위 모듈이 있기 때문에 제가 처음에 말씀 드렸던 것처럼 부주의하면 위로 의존성이 올라갑니다. 아무튼 그런 다음에 유닛 테스트를 하면 또 MOCK을 붙여야죠. 그런데 아까 상위 모듈에 의존성이 들어갔다면 상위 모듈도 MOCK이 있어야 합니다. 그리고 밑에 있는 모듈도 한 다음에 유닛 테스트 합니다. 그래서 top down 테스트를 하면 테스트 케이스 외에 MOCK 비용 추가로 들어가고 그거뿐만이 아니라 top down 방식으로 구현을 하면 굉장히 장점이 많습니다. 제가 여기에 대해서 설명하는 것은 범위에 벗어날 것 같고 단점이 뭐냐면 bottom up으로 구현하는 건 사실 쉬운 건 아닌 것 같습니다. 왜냐면 추상화를 하면서 올라가야 되는데 이런 어려움하고 똑같습니다. 함수를 여러 개 쪼개고 싶을 때 ……을 지키기가 되게 힘들잖아요? 그런 어려움하고 좀 비슷한데 그것도 하다 보면 늘더라고요. 익숙하지 않으면 어려운데 익숙해지면 많은 장점을 얻을 수 있을 것 같습니다. 커버리지에 대해서 말씀을 드리려고 하는데요. 커버리지는 이렇게 많은 종류의 커버리지가 있습니다. 문장 커버리지 예를 들어보면, 코드가 100라인인데 그 중에 텍스트에서 90라인이 수행됐어요. 그러면 커버리지 90%를 달성했다고 하는데 그거는 단지 문장 커버리지 90%이고요. 그 외에도 다양한 경우를 포괄하는 많은 커버리지들이 있습니다. 그런데 코드 커버리지 80%를 어떤 개발자 분께서는 목표로 삼기도 하는데 이게 사실은 statement coverage거든요. 그런데 개발자 입장에서는, 왜냐면 개발자는 코드를 속속들이 알고 있습니다. 그래서 어떤 부분은 중요하고 어떤 부분은 그렇지 않고, 어떤 부분은 테스트를 많이 해봐야 되고 어떤 부분은 그렇지 않다는 걸 알고 있습니다. 근데 커버리 80%는 그런 중요성을 전혀 반영하지 않고 있습니다. 그렇다고 커버리지 80%를 높이면서 중요한 것까지 다 테스트를 하기에는 개발자의 자제력에 한계도 있고 멘탈도 중요하기 때문에 개발자는 조금 중요한 부분에 핵심적인 테스트를 하는 게 중요하지 커버리지에 신경을 쓰는 건 제 개인적인 생각으로는 아닌 것 같습니다. 커버리지는 그냥 QA가 참고용으로 쓰면 좋을 것 같습니다. 목적이 되어서는 곤란할 것 같습니다. QA분들은 될 것 같습니다. 소스에 대한 지식이 없는 경우에는. 그래서 커버리지 측면에서 Bottom up 테스트를 보면 맨 밑에 있는 모듈 먼저 만들었죠. 그 다음에 vtex를 붙인다고 했는데 그러면 이렇게 커버리지가 확보가 됩니다. 그리고 새로운 모듈을 추가하고 새로운 유닛 테스트를 붙였을 때 이거는 제가 의도했던 부분인데 밑에는 그거에 대한 부분. 같이 테스트를 하면 됩니다. 그리고 붙이고 테스트를 하면 n. 되죠. 테스트도 몇 개 안돼서 많은 부분 테스트를 할 수 있었는데 많으면 좋냐? 테스트가 많이 실패했습니다. 그래서 마지막에 그러면 언제 어디인지 한번에 다 나오지 않습니까? 왜냐하면 ……. 할 수 있기 때문에 만약 MOCK을 썼다면 어땠을까? MOCK을 썼다면 마지막에 문제가 나왔을 때 바로 갈 수 있습니다. 그래서 원인 찾는 게 굉장히 빠르죠. MOCK을 쓰면 이런 일은 좋습니다. 그런데 방금 사실은 용인된 단어도 보입니다. 왜냐면 …… 부분에 중요한 부분은 뭔가 일어났을 때 원인을 모르는 것도 사실 중요한 것에 속하거든요. 왜냐면 문제가 있을 때 바로 안보이면 그게 파생이 돼서 다른 쪽에서 나타나기 때문에 그런 부분도 굉장히 중요하게 생각합니다. 아무튼 중요한 부분은 검증이 됐고 테스트 안 한 부분은 사실은 잘 보이거나 별로 중요하지 않은 부분이기 때문에 경험상 이쪽에 있는 경우가 많더라고요. 이런 부분에 대한 문제는 바로 봅니다. 그리고 한 가지 더. 테스트의 이점은 Defect 된 걸 알려주는 거지 수정에 걸리는 시간을 줄여주는 것은 사실은 테스트의 근본적인 이점은 아니거든요. 그래서 실무에서 많이 쓰는 게 있는데 재현된 버그는 사실 다 잡으면서 하고 있습니다. 그렇기 때문에 이렇게 해서 테스트하는 것도 좋다고 말씀 드리고 싶습니다. 빅뱅테스트라는 게 있는데요. 빅뱅테스트는 뭐냐면 사실 빅뱅이라는 용어가 프로세스나 퀄리티 같은 게 좋지 않은 경우에 쓰이는데요. 이 모듈을 만들 동안 하나도 테스트를 안 하다가 마지막에 한번에 테스트를 할 겁니다. 그렇게 밑에 부분까지 같이 테스트를 하는 거죠. 그런데 단점이 뭐냐면 이거는 밑에 있는 것들을 따로 테스트가 안 됐기 때문에 어디에 문제가 있는지 잘 안 보이고요. 그것뿐만이 아니라 그리고 문제가 하나인 경우에는 별로 장애가 없는데 여러 가지 문제가 섞여서 조합 돼서 나오는 경우는 사실은 버그 찾기가 굉장히 힘들죠. 더 심각한 거는 만약에 이 부분이 굉장히 구고적인 결함을 갖고 있어요. 이 부분자체가. 그런데 초기에 발견을 못했기 때문에 나중에 테스트를 하고 나서 구조 결함 있었다고…... 그런데 제가 이렇게 단점이 많다고 얘기했지만 사실은 굉장히 효과적일 수 있습니다. 테스트를 한번만 했죠. 그래서 잘만 돌아가면 테스트 한번에 다 해볼 수 있기 때문에 상황에 따라서 굉장히 좋고요. 사실은 제는 이 방법 많이 쓰는데요. 어떤 경우에 많이 쓰냐면 뭔가 뻔한 모듈 있잖아요? 어떻게 돌아갈지 뻔히 아는 모듈. 많이 해본 그런 프로그램. 많이 작성해본 부분. 눈 감고도 뻔히 아는 부분. 이런 부분은 사실은 한번만 테스트를 해봅니다. 문제가 어떻게 될지 뻔히 보이거든요. 그래서 이런 방법으로 테스트를 했는데 그거를 실제적으로 작년 하반기에 했던 프로젝트를 가지고 예를 보여드리도록 하겠습니다. 일단 처음에 요구 사항을 수집합니다. 일단 저보고 프로젝트 해당하는 사람한테 먼저 프로젝트 하는 사람한테 요구사항을 수집하고 인터넷도 뒤져보고, 제 스스로도 내고, 사람들한테 물어보고. 그렇게 해서 전체적인 디자인이 나옵니다. 그래서 어떻게 쓰이는 툴이 될 건지, 어떤 자료 구조가 필요한지, 그리고 제한 사항이 뭔지. 멀티 쓰레드를 써보니까 어디서, 어느 분야에서는 돼, 안 돼. 그리고 카피가 있으면 성능도 중요해. 이런 위주로 디자인 사항들이 나오고요. 이것 가지고 그림이 나오고 나면 우선 프로토타이핑을 먼저 해봅니다. 프로토타이핑의 목적은 제가 …… 써본 적이 없었고 프로토콜보다는 C 계열  그런 라이브러리가 있는데 한 번도 써보지 않았기 때문에 이거 가지고 할 수 있느냐. 해서 그런 불학실한 부분에 대해서 일단 써보는 방식으로 프로토타이핑을 해보는 겁니다. 실제로 사용이 가능한지도. 이렇게 불확실함을 제공 하니까 어떻게 만들어야겠다 하고 감이 잡히더라고요. 대충 이렇게 나오겠구나. 라고 잡혀서 지금까지 사실은 top down 방식으로 설계를 한 거죠. Top down 방식으로 만들 걸 명확히 한 다음에 실제로 구현에 들어가는데, 구현에 들어갈 때는 맨 밑에 있는 부분부터 하는 겁니다. 맨 밑에 부분을 만들어서 테스트를 붙이고 그 다음에 이거를 리뷰 시스템에 올립니다. 당시에 리뷰 프로세스가 있었거든요. 제가 아까 이 부분이 재사용 단위라고 했는데 사실은 리뷰에도 되게 좋은 단위입니다. 일단 의미가 있고 돌아가기 때문에 리뷰 하기에도 좋죠. 그러고 난 다음에 했던 경험을 가지고 connection을 작업 합니다. 앞서 한번 써봤기 때문에 굉장히 빠르게 되죠. 그 다음에 유닛 테스트를 붙인 다음에 이 부분을 리뷰에 올립니다. 그리고 RPC 매니저를 만들고 그리고 RPC 매니저가 사용하는 서브 모듈들이 있거든요. 이런 것까지 한꺼번에 만듭니다. 한꺼번에 만들고 이런 것들을 한번에 다 테스트를 합니다. 단순히 뭐냐면 이 부분은 사실 약간 불확실한 면이 있어서 모듈을 테스트 했던 거고 이 부분은 사실은 명확합니다. 그래서 중요한 부분 테스트를 하면서 같이 테스트를 하는 거죠. 테스트를 한 다음에 또 리뷰을 올립니다. 그런데 여기서 끝내려고 했는데 유닛 테스트 작성에서 실제로 최상위 인터페이스를 써보다 보니까 편리하지 않더라고요. 그래서 새로운 유닛 테스트 작성합니다. 뭔가 하나가 더 있어야겠다. 해서 유닛 테스트를 작성하고 나서 실제로 이런 걸 하나 더 만들었습니다. 하나 더 만들어서 유닛 테스트를 붙여서 했더니 너무 쉽고 좋더라고요. 이때 스트레스 테스트랑 동일성 테스트를 다 같이 수행했는데, 스트레스 테스트랑 동일성 테스트를 하는 팁을 간단히 말씀 드리면 쓰레드 수나 패키지 사이즈 같은 거, 덤프 횟수 같은 거를 parameter화 시키면 됩니다. 그래서 테스트를 돌리는 메인이 있을 건데 거기에 parameter 조정하면서 하면 굉장히 쉽게 할 수 있습니다. 그래서 마지막에 작성한 것도 이렇게 리뷰 시스템에 올려서 리뷰를 봤습니다. 그래서 버그 없었냐. 유닛 테스트 중에는 굉장히 많은 뭔가가 나오는데요. 그런데 리뷰 중에는 심각한 버그가 한 개도 안 나왔었습니다. 버그를 왜 테스트에서 못 잡았을까? 사실은 중요한 버그는 테스트에서 다 잡거든요. 그런데 그걸 못 잡아서 저는 사실은 의아했다고 해야 할까요? 왜 못 잡았지? 지금까지 했던 방법이 잘 못 됐나? 살펴봤는데 그 테스트가 우연으로 테스트를 한 부분이라서 몇 번 더 테스트를 돌렸으면 나왔었을 부분이거든요. 이거는 사실은 우연에 맡기지 말고 그거가 팍팍 나오도록 할 수도 있는데 그거는 제가 앞서 말씀 드렸지만 비용이나 이런 측면에서, 번거롭고 귀찮아서 이런 방식으로 씁니다. 그래서 단점은 있지만 근본적으로 내가 원하는 목표를 이루는 데는 문제가 없었다고 생각합니다. 제가 사용했던 툴은 boost unit test라는 툴인데요. 사실 툴도 여러 가지 종류가 있는데 툴이 그리 중요한 것 같지는 않습니다. 처음에 제가 유닛 테스트를 했을 때는 유닛 테스트라는 개념도 사실 몰랐고, 제가 그냥 유닛 테스트 프레임워크를 만들어서 했었거든요. 그래서 어떻게 하는지가 중요하지 어떤 툴을 사용하는지는 그렇게 중요할 것 같지는 않습니다. 그래서 마무리 정리를 해보면 테스트를 할 때 항상 비용을 고려해서 테스트를 해야 하고요. Bottom up 방식으로 하니까 개발 및 테스트가 좋다. 이야기를 드리고 싶습니다. 그래서 이 부분은 제가 어제 추가한 부분인데요. 그렇게 하니까 정말 야근 안 해요. 야근을 하는 이유를 제가 생각을 해보니까 4가지 정도 이유가 있는 것 같아요. 첫 째는 절대적으로 주어진 일이 많은 경우고 두 번째는 예측하지 못한 많은 일들이 생겨서, 뭐냐면 내일 까지 뭘 하기로 했는데 서버가 죽어요. 아니면 테스트를 해보니까 제가 만든 부분에서 버그가 많이 생겨요. 이런 경우는 어쩔 수 없이 야근을 해야 하거든요. 그리고 세 번째는 자기가 통제 안 되는 경우가 있죠. 뭐냐면 괜히 딴 거로 멍하니 시간을 때운다든가. 네 번째는 다른 이유 때문인데요. 예를 들면 팀장님이 눈치를 보내요. 아무튼 이런 이유도 있을 수 있는데요. 사실은 기타 이유나 첫 번째 절대적으로 주어진 일이 많은 경우에는 어떻게 제가 해드립니까, 여러분이 알아서 하셔야죠. 그리고 제가 발표를 한 거는 이 부분에 대해서 포커싱을 맞췄고요. 이 부분을 해결할 수 있다고 봅니다. 테스트가 잘 되면 사실 버그 때문에 야근하는 건 많이 없습니다. 그리고 자신이 통제가 안 되는 경우에 대해서 얘기를 드리려고 하는데요. 회사 와서 웹 서핑이나 이런 거 해서 시간이 많거나 업무 중 절반을 멍 하는 시간으로 보낼 것 같은데요. 이럴 때 야근은 없다 를 하루의 목표로 잡으면 마음가짐이 달라집니다. 그래서 하루 6시간 매일 데드라인 인생을 겪고요. 그렇게 되면 학생인 경우도 있거든요. 학생인 경우도 눈치보고. 학생들한테 과제를 하라고 2시간을 주든, 하루를 주든, 한 달을 주든 나오는 결과는 비슷하다는 얘기인데 왜냐면 어쨌든 걔들이 과제를 하는 거는 데드라인 때 하거든요. 그렇기 때문에 대부분의 시간을 멍하니… 그래서 이렇게 데드라인을 짧게 가져는 자기 마음가짐이 되게 중요합니다. 이렇게 하면 다른 일에 신경을 쓰지 않고요. 저는 사실은 신입사원 때부터, 신입사원이 그런 마음가짐을 가진 게 좋은 건지 모르겠는데, 그런 마음가짐으로 사회 생활을 했습니다. 그리고 이런 마음가짐을 가지면 업무가 늦어져서 야근하는 경우에도 저녁을 먹지 않게 되는, 왜냐하면 조금이라도 빨리 끝내는 게 목적이기 때문에. 저는 일단 먹으면 뭔가 늙어지게 돼서 저는 꼭 마음먹고 야근을 하는 것 같아서, 저녁 먹고 오면 또 웹 서핑하고 그렇게 되니까 저는 업무가 늦어져서 야근하는 경우에도 저녁을 먹지 않습니다. 이것도 때에 따라 다르네요. 가급적 안 먹으려고 합니다. 그래서 …… 이상으로 발표 마치겠습니다. 감사합니다.
(질문자)_MOCK 오브젝트를 사용하는 경우에는 모듈이 준비가 안되어 있어서 라기 보다는 그 모듈을 그대로 사용하게 되는 경우, 테스트에 경과가 많으니까 테스트가 더 오래 걸린다든가, 아니면 테스트에 독립성이 떨어진다든가. 아까 이전 세션에서 나왔던 서버에 문제가 좀 있는 경우에도 마찬가지고요. 그런 게 주요 이유라고 생각을 하거든요. 그 경우에는 아까 말씀하셨던 bottom up 테스트를 해도 문제가 있을 수 있다고 생각하는데, 그러한 경우에 대한 다른 팁이 있나요?
(발표자)_절대적으로 뭐가 옳다라는 건 없는 것 같고요. 사실은 테스트를 하는 데 약간 시간이 걸려도 괜찮을 것 같습니다. 테스트를 하는데 좀 시간이 걸려도 되고요. 그런데 이런 경우는 있어요. 내가 이 오브젝트가 비정상으로 동작했을 때 테스트를 해보고 싶다. 제가 제어를 못하는 거죠. 그런 식에도 사실은 MOCK 오브젝트 같은 경우에 유용하게 쓰이죠. MOCK 오브젝트가 아까도 말했지만 안 쓴다는 건 아니고요. 쓰일 때도 있어요. 그런데 가급적 안 쓰려고 노력을 하는 중이에요. 약간 연산이 오래 걸린다든가 그럴 때는 MOCK 오브젝트 안 씁니다. 기존에 있는 거를 테스트 함으로 인해서, 아까 말씀 드렸지만 겸사겸사 테스트가 다 되거든요. 그 장점이 있기 때문에 테스트 유지보수도 되게 중요하다고 생각해요. 가급적이면 안 쓰려고 하는 것뿐이지 꼭 안 쓴다는 얘기는 아닙니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
