개발자는 코딩만 해야 한다.

제목을 보시고 무슨 말도 안되는 얘기를 하느냐고 생각하시는 분이 대부분일 겁니다.

이러한 생각의 Gap은 소프트웨어를 개발하는데 있어서 개발자의 역할에 대한 인식의 차이에서 비롯합니다.

현실을 보면 개발자라는 이름으로 정의된 소프트웨어 엔지니어들은 대단히 많은 일을 합니다. 

요구사항 분석도 하고, 설계도하고, 코딩도 하고, 테스트도 하고, 빌드도 하고, 팩키징도 하고, 고객지원도 하고, 전화도 받고, 영업도 지원하고, 서비스 회사인 경우에는 실제 운영서버 관리도하고, 장애 해결도 하고, 정말 여러가지 일을 합니다.

이것을 역할로 바꿔보면, Software Analyst, Software Architect, Coder, QA Engineer, Build Engineer, Release Engineer, Technical support engineer, Technical sales engineer, System administrator 등의 서로 다른 역할 들입니다.

이런 일들을 모두 다른 사람이 해야 한다고 하면 배부른 소리하고 있다고 할 겁니다. 물론 그것은 아니죠. 이중에서 개발자가 Coder의 역할만 하는 것은 아니고 몇 가지 역할을 겸해서 할 수는 있습니다. 심지어는 위의 모든 일을 한 명의 개발자가 수행할 수도 있습니다. 하지만 그렇다고 하더라도, 이 각각의 일들은 원래 다른 역할이라는 것을 알아야 합니다. 특히 코딩과 테스트는 한 사람이 동시에 잘 해내기 어려운 조합이기도 합니다. 따라서 여유가 되고 기회가 된다면 적절한 시점에 똑같은 만능개발자를 수평적으로 인원수만 늘릴 것이 아니고, 각각의 역할로 쪼개야 합니다.

그 중에서 개발자(코더)의 역할은 정해진 설계에 따라서 혹은 할당받은 버그에 대하여 소스코드를 수정하고 소스코드관리시스템에 등록하면 끝나는 겁니다. 나머지는 다른 사람들이 할 일이죠. 이것이 지켜지지 않으면 이중에서 비싼 인력인 개발자가 싼 인력이 수행할 수 있는 일들에 치여서 점점 효율성이 떨어지고, 자잘한 사고도 많이 일어납니다. 개발자는 개발이 전문이지, 테스트 전문가도 아니고, 빌드와 릴리즈 전문가는 더욱더 아니라서 코딩 이외의 일들은 잘 해내지도 못합니다. 따라서 조직이 커지고 있다면 적절한 시점에 역할이 분리되지 않으면 커다란 공장에서 수많은 개발자들이 체계적이지 않은 방법으로 인형에 눈깔 붙이듯이 서로 뒤죽박죽 뒤섞여서 일하게 될 수 있습니다. 

지금은 조직이 작아서 개발자가 여러가지 일을 다하더라도 "모드전환스위치"를 가지고 있어서 서로 다른 일을 할 때는 스위치를 잘 해야 합니다. 그리고 언제든지 일을 떼어줄 준비를 하고 있어야 합니다.

개발자 4명보다 개발자 3명과 테스터 1명이 더 효율적입니다.

개발자 30명보다 개발자 20명과 테스터 6명과 빌드/릴리즈 담당자 1명과 3명의 Technical Support 담당자가 있는 것이 더 효율적입니다.

물론 숫자는 절대적인 것이 아니지만, 회사는 계속 커가는데, 구멍가게나 가내수공업식으로 계속하고 싶지 않으면 역할에 분리에 대해서 고민해야 합니다.

살아남은 개발자들

소프트웨어 업계에서 주변을 둘러보면, 실력은 없으면서 탁월한 생존력으로 살아남은 개발자들을 볼 수 있습니다.

소프트웨어 개발 실력은 떨어지지만, 업무지식을 속속들이 알고 있는 개발자

회사의 개발정보를 꼭꼭 숨겨서 자신만 알고 있는 개발자

과거에 개발해 놓은 소스코드의 문서도 만들지 않고 뒤죽박죽으로 섞어놔서 자신이 아니면 유지보수를 못하게 만들어 놓은 개발자

탁월한 인화력으로 후배 개발자들과 똘똘 뭉쳐있는 개발자

미래에 경쟁이 될만한 새싹은 미리 밟아 버리는 개발자(관리자)

화려한 언변으로 경영자들에게 거짓된 신임을 얻고 있는 개발자

위와 같은 방법의 생존이 소프트웨어 업계에서 살아가는 한 방법이기도 하지만, 또 일부 기술은 부러운 기술이기도 하지만, 이는 결국 회사와 개발자 모두의 경쟁력을 갉아 먹고, 그 부메랑은 개발자에게 돌아옵니다. 이런 방식으로는 10년, 20년 꾸준히 소프트웨어 엔지니어로서 일을 하면서 성장하기는 어렵습니다. 개발자로서 오래 살아남고 싶다면, "생존력"보다는 "경쟁력"이 필요합니다.

"경쟁력"이 구체적으로 무엇인지는 제 블로그 전반에서 계속 주장하고 있으니 살펴보세요. ^^

도대체 얼마나 자세히 적어 달라고?!

소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고

구현을 하기 전에 설계서를 작성하고

테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.

즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.

따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

왜 이리 버그가 많아요?

소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다.

소프트웨어는 그 종류가 셀 수 없이 많아서 획일적으로 얘기할 수는 없어도, 릴리즈를 구분하여 부르는 것은 필요합니다. 릴리즈를 구분하다는 것은 현재 릴리즈가 어떠한 것이고, 그에 따라서 어떠한 프로세스를 따라야 하고, 어떠한 기대값을 가져야 하는지 그 이름만 들어도 알 수 있게 합니다.

하지만, 팩키지를 개발하는 소프트웨어 회사는 나름대로 릴리즈 구분에 익숙해져 있지만, SI회사, 게임회사, 포탈 등의 서비스 회사, 금융회사들은 릴리즈는 그냥 릴리즈라는 생각을 하고 합니다. 따라서 수많은 릴리즈를 함에도 불구하고 각 릴리즈를 부르는 버전도 없는 경우가 허다하고, 개발자가 임의대로 릴리즈를 하는 경우도 많습니다.

그럼 릴리즈를 어떻게 구분하여 부르면 의사 소통에 도움이 될지 알아보죠.

업그레이드 릴리즈 (Upgrade release)

계획된 일정에 따라서 제품의 주요한 기능이 바뀌어서 릴리즈 되는 것을 일컫습니다. 그 규모와 성격에 따라서 메이져 또는 마이너 업그레이드라고 하고 정상적인 개발 프로세스를 거치며 테스트로 전 기능에 걸쳐서 철저하게 이루어 지는 것이 보통입니다.

패치 릴리즈 (Patch release)

특정 기능에서 발생한 버그나 작은 기능을 개선한 것들을 모아서 릴리즈 하는 것을 말합니다. 보통 계획적으로 일정을 잡거나 업그레이드 릴리즈 후 고객들의 반응을 보고 패리 릴리즈 일정을 잡기도 합니다. 보통 유지보수 개발자들이 개발을 담당하고 테스트로 업그레이드 릴리즈 때보다는 간소화 하기도 합니다.

핫픽스 (Hotfix)

심각한 버그가 발견되어서 긴급하게 특정 고객을 대상으로 또는 전체 고객에게 버그를 수정한 버전을 전달하는 것을 말합니다. 이 경우 사안이 긴급하여 개발 및 테스트 프로세스가 상당부분 생략되며, 이로 이한 위험부담을 어느 정도 감수하는 릴리즈를 말합니다.

또 제품의 완성도에 따라서 알파, 베타, RC 릴리즈로 나뉠 수 있습니다.

알파 릴리즈는 제품의 기능은 구현이 다 되었으나 버그는 좀 있을 수 있습니다. 하지만, 제품을 더이상 써 볼 수 있는 정도의 심각한 버그는 없어야 합니다.

베타 릴리즈는 제품의 심각한 버그는 거의 없어서 기능을 거의다 정상적으로 사용할 수 있는 상태를 말합니다.

RC 릴리즈는 제품을 출시할 수 있는 정도로 사소한 버그가 몇개만 포함된 버전을 말합니다.

이렇게 릴리즈를 나누는 이유는 각 릴리즈에 따라서 들어가는 비용과 개발 프로세스가 다르고, 리스크가 다르기 때문입니다. 이러한 구분이 없이 그냥 개발자가 소프트웨어를 수정하는 대로 릴리즈를 하고 있다면, 테스트 등 릴리즈에 들어가는 비용을 들이지 않는 주먹구구식 개발일 가능성이 높습니다. 하지만 이러한 마구잡이식 릴리즈가 결국 더 많인 비용을 이미 지불하고 있다는 것을 알아야 합니다.

악순환 vs. 선순환

지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다.

회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다.

회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다.

그럼 악순환과 선순환에 대해서 알아보죠.

Domain 지식에 점점 매달리게 되는 악순환의 고리

• 주먹구구식 개발
• 개발자에 의존한 코딩 중심의 개발 주도
• 없거나 빈약한 개발 프로세스 및 개발 문서
• 회사의 지식은 개발자 머리 속에 보관
• 개발자 간 지식의 공유가 어려움
• 후배 개발자들에게 지식 전달이 잘 안됨
• 프로젝트가 커질수록 협업이 점점 어려워짐
• 점점 더 경험 많은 개발자에 의존하게 됨
• 경험 많은 개발자는 계속 더 바빠짐
• 경험 많은 개발자들도 체계적인 개발은 꿈도 못 꾸고 매일 밑바닥 개발에 매달림
• 개발자들이 Domain 지식은 점점 늘어가는데 소프트웨어 공학지식은 잘 늘지 않음
• 회사에서는 신규 직원을 뽑아도 같이 협업이 잘 안되므로, 동일 Domain의 경험이 많은 개발자를 선호하게 됨
• 경험 많은 개발자들이 퇴사를 해서 회사가 큰 타격을 입기도 함
• 또 고참 개발자들이 퇴사할 까봐 전전긍긍하게 됨
• 회사에서는 개발자들의 머리 속에 있는 지식을 공유하고 체계적으로 개발하고 싶으나 방법을 모름
• 이에 대한 개혁을 해보려고 해도 번번히 고참 개발자들의 방해로 무산됨
• 점점 더 경험 많고 Domain 지식이 풍부한 개발자들에게 의존하게 됨
• 규모 있는 개발을 못하고 인원수에 의존한 개발을 하게 됨
• 회사는 성장을 못하고 정체하게 됨
• 고참 개발자들은 성장을 못하고 매일 밑바닥 코딩과 문제 해결에 매달리게 됨
• 또 주먹구구식, 가내 수공업식 개발을 반복하게 됨

프로세스 중심의 선순환의 고리

• 회사가 소프트웨어 개발에 필요한 적절한 프로세스와 인프라스트럭처 시스템을 갖추고 있다.
• 개발자들은 프로세스 중심으로 개발이 되도록 잘 훈련 되어 있다.
• 프로젝트 진행 시 꼭 필요한 스펙 문서와 설계 문서를 적절하게 만든다.
• 문서와 코드에 대해서 적절히 Peer review가 이루어져서 지식의 전달이 잘 되고 결함이 사전에 제거된다.
• 고참 개발자들은 코딩 보다는 주로 아키텍처와 비즈니스에 대해서 고민하고 해결한다.
• 잘 작성된 스펙 문서와 설계 문서를 보고 후배 개발자들이 코딩하고 테스트 팀이 테스트를 진행한다.
• 고참 개발자들은 오랜 개발 경력으로 Domain 지식도 풍부하지만 소프트웨어 공학 지식 및 경험도 풍부하다.
• 후배 개발자들은 Domain 지식은 부족하지만, 설계 문서를 보고 인프라스트럭처 시스템을 활용해서 프로세스에 따라 개발하는데 별 문제가 없다.
• 신규 개발자를 뽑아도 교육이 용이하고 바로 실무에 투입하기가 쉽다.
• 고참 개발자들이 퇴사를 해도 상당히 많은 지식이 문서화 되고 이미 후배들에게 전파가 되어 있으므로 회사의 타격이 상대적으로 적다.
• 퇴사한 고참 개발자들은 이직이 용이하고 더 높은 연봉으로 타 회사로 옮길 수 있다.
• 회사에서는 Domain 지식이 너무 매달리지 않고, 실제로 Software 공학 지식이 뛰어나고 Software 개발 자체를 잘하는 인재를 선호하게 된다.
• 회사가 성장하고 개발 규모가 커져도 문제 없이 대응할 수 있다.

그럼 악순환에서 선순환으로 바뀌는 방법에 대해서 의문을 가질 수 밖에 없습니다.

이는 참 어려운 숙제입니다.

운동을 안한다. -> 몸이 무거워진다. -> 운동을 더 안한다. -> 몸이 더 무거워진다.

이런 악순환의 고리를 끝는 것은 무엇을 까요? 일단 운동을 시작한다? 99%는 실패할 겁니다.

운동은 습관도 안들어 있고, 제대로 운동하는 방법도 모르고, 또 귀찮아지면 언제든지 포기하고, 잘못된 운동 방법으로 다칠 수도 있습니다. 그러면 운동에 대한 나쁜 기억만 쌓이고 다음번에는 더욱더 운동을 시도하지 않게 될 겁니다.

그래서 악순환의 고리를 끝는 것을 쉽게 얘기를 할 수 있어도 현실적으로 가능한 방법을 제시하는 것은 쉽지 않습니다. 물론 가장 적절한 방법도 회사마다 다릅니다.

하지만, 악순환의 고리를 끝는 방법 중에서 필수 요소는 경영자의 의지입니다. 경영자가 이러한 상황을 전혀 이해 못하고 있거나 의지가 없다면 그냥 계속 악순환의 고리를 돌면서 영업이나 잘하는 수 밖에 없습니다.

개발자들이 으쌰으쌰해서 점진적으로 개혁을 해보려는 시도는 매우 더딜뿐만 아니라 다양한 도전 및 방해로 무산될 가능성이 큽니다. 그래도 그런 과정에서 개발자들이 본인 스스로 공부는 될 수 있겠네요.

경영자가 의지만 있다면, 조직, 시스템, 프로세스적인 다양한 측면에서 효과적이고 적절한 개혁을 시도하여 회사를 바꿔나가서 점점 선순환의 고리로 옮겨 갈 수 있습니다. 

이 바닥을 못 벗어난다.

우리나라 소프트웨어 개발자들은 자신이 처음부터 일해온 바닥을 못 벗어나는 경향이 있습니다.

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, SI회사 등 쉽게 그 바닥을 못 벗어나곤 합니다. 

이러다 보니 개발자가 이직 시 선택의 폭이 좁아지고, 분야가 조금만 바뀌어도 자신의 Value가 확 줄어드는 현상이 일어나곤 합니다.이런 일이 비일비재하게 일어나는 것을 보면 개발자의 전문성이란 어디에 있는 것인지 궁금하지 않을 수 없습니다.

금융에 대한 전문지식을 많이 가지고 있고, 게임에 대한 많은 지식을 가지고 있는 것을 개발자의 전문성이라고 볼 수도 있습니다. 또 그러한 Domain 지식이 없으면 개발을 할 수 없다고 단정적으로 얘기를 하는 개발자도 많습니다.

소프트웨어 엔지니어가 소프트웨어를 개발하기 위해서는 크게 2가지의 지식이 필요합니다.

그 중 하나는 이미 앞에서 언급한 Domain 지식입니다.

그리고 또 하나는 Software Engineering 지식입니다.

Domain 지식은 개발 분야가 바뀌면 거의 쓸모가 없는 산업 지식이고, Software Engineering 지식은 개발 분야가 바뀌어도 항상 사용되는 지식들입니다.

Domain 지식은 너무 광범위해서 나열을 할 수는 없습니다.

하지만 Software Engineering 지식은 무엇인지 설명할 수 있습니다.

요구분석, 설계, 구현, 테스트, 소스코드 관리, 버그 관리, 프로세스 등 소프트웨어를 개발하기 위한 일련의 지식들입니다.

물론 소프트웨어를 개발하기 위해서는 Domain 지식과 Software Engineering 지식 모두가 필요합니다. 하지만 흔히 접하는 현상을 보면 개발자들이 점점 Domain 지식이 치중하는 경향이 있습니다. Software Engineering에 대한 전문성을 떨어진 상태에서 Domain 지식만 점점 늘어가니 당장 일은 잘하고 있는 것 같아도, 동료나 후배들과 협업이 잘 안되고, 프로젝트 규모가 조금만 커져도 문제가 있고, 이직 시에는 심각한 가치 하락이 발생합니다.

그럼 어떻게 해야 할까요? 소프트웨어를 개발하면서 자연스럽게 얻게 되는 Domain 지식에만 의존해서는 안됩니다. Software Engineering 지식을 꾸준히 발전시켜서 소프트웨어 전문가가 될 수 있도록 해야 합니다. Software Engineering에 능통한 소프트웨어 전문가가 된다면, 어느 소프트웨어 회사를 가더라도, 여전히 전문가로서 높은 가치를 가지고 개발을 할 수 있습니다. 새로운 분야로 이직을 하더라도 Domain 지식은 일을 하는 과정에서 차츰 배워 나갈 수 있습니다. 

그리고 Domain 지식에 능통한 개발자에게만 의존해서 개발이 진행되는 소프트웨어 회사는 매우 큰 리스크를 안고 있는 겁니다. 그런 개발자가 한 명만 퇴사를 해도 회사는 큰 위험에 봉착합니다.  

결국, 회사를 위해서도, 개발자들을 위해서도 개발 개발자들의 머리 속에 들어 있는 Domain지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.

나는 혼자가 아니다.

지금 내가 생각하고 행동하는 것은 나 스스로의 힘이 아닙니다. 과거의 수많은 대가들이 이룩해 놓은 지식, 경험과 지혜를 간접적으로 배우면서 자라온 내가 있고 그 바탕 위에 내가 존재 합니다.

이런 성현들의 지식이 없다면 지금의 내가 존재 할 수 있을까요? 원시인과 별 차이 없는 내가 있겠죠.

소프트웨어를 개발하다 보면 수많은 문제에 부딪히는데 그 대부분은 이미 과거에 소프트웨어 개발의 대가들이 다 겪은 후에 그 해결책을 다 만들어 좋은 것들입니다. 그렇지 않고 소프트웨어 역사상 처음 발생하는 이슈는 거의 없습니다.

그런데 많은 개발자들의 개발 행태를 보면 마치 최초의 선구자 같이 행동을 합니다. 과거에서 배우지 않고 자신의 지식과 경험 테두리 안에서 별 희안한 방법들을 생각해 냅니다.

피아노를 배우려고 하는데, 모짜르트도 모르고 그냥 혼자 피아노를 연습하는 것 같습니다. 지금의 피아노 연주 기술은 과거의 수많은 음악가들이 없었다면 존재 할 수 없죠. 또 그 기술은 혼자서 인터넷 보고 익힐 수 있는 것이 아니고 스승에게 배우고, 혼자서 또 부지런히 연습을 해야 합니다.

문서를 왜 써야 하는지? 

Peer review를 왜 해야 하는지? 

소스코드를 어떻게 관리해야 하는지? 

빌드는 어떻게 해야 하는지? 

고객이 요구사항을 자주 바꾸는데 어떻게 해야 하는지?

테스트는 어떻게 해야 하는지?

Internationalization은 어떻게 해야 하는지?

버그 관리는 어떻게 해야 하는지?

개발 시간을 어떻게 단축할 수 있는지?

이외에도 수천가지 소프트웨어 개발 이슈들은 이미 과거의 대가들이 다 고민하고 방법들을 제시해 놓은 것들입니다. 하지만 이를 배울 스승이 부족하고, 책만 보고 배우기는 어렵기 때문에 나름대로의 방법들을 사용하고 있습니다. 그래서 결국에는 한계에 부딪히게 됩니다.

이러한 지식들을 총칭해서 소프트웨어 공학이라고 합니다. 과거의 대가들에게서 간접적인 도움을 받으면서 소프트웨어를 효과적으로 제대로 개발을 하려면 소프트웨어 공학에 관심을 가져야 합니다. 책을 보면서 간접 경험을 하고 전문가나 스승을 만날 기회가 있다면 최대한 많이 배우려고 노력하고, 가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요.