이우소프트에 대한 오해와 진실

가끔은 “이우소프트가 개발자에게 그렇게 좋은 회사라면서요?”라는 말을 종종 듣는다. 이 말은 맞기도 하고 틀리기도 하다.

입사지원자에게 듣기도 하고 지인들에게 듣기도 한다. 몇몇 얘기를 듣고 과도하게 확대해석하기도 하고 오해하기도 한다. 모든 현상이 그렇듯이 몇줄의 글을 통해서 상황을 정확히 설명하기란 매우 어렵다. 하지만 내 블로그의 글을 보고 많은 개발자들이 이우소프트에 지원을 하기 때문에 좀더 정확한 설명이 필요하다.

일단 이우소프트는 “개발자가 일하기 좋은 회사”를 만드는 것이 목적인 회사는 아니다.

이우소프트의 비전은 “글로벌 경쟁력을 갖추고 세계 1등의 Software를 만들어 내는 것”이다. 거의 모든 것은 여기에 맞춰져 있다. 이를 위해 행해지는 것들이 개발자에게 좋을 수도 있고 나쁠 수도 있다. 또한 어떤 개발자에게는 좋은 것이 어떤 개발자에게는 나쁜 것이 될 수도 있다. 

퇴근 후 개인 시간이 거의 보장된다.

퇴근 후 개인 시간을 보장해야 하는 이유는 생산선 향상 때문이다. 어차피 하루 8시간 이상은 몰입이 어렵다. 또한 퇴근 후에 영어, 운동, 신기술습득, 문화활동 등 장기적으로 성장하기 위한 활동을 해야한다. 그리고 야근이 없다는 오해도 있는데 야근은 있다. 최대한 합리적으로 프로젝트를 진행하려고 하지만 야근에 내몰리는 경우도 종종 있다. 또한 자발적으로 야근을 하는 개발자도 있다.

개발일정은 개발자가 정한다.

기본적으로 맞다. 하지만 여유로운 개발일정을 정하는 것은 절대 아니다. 프로젝트마다 일정의 중요도가 다르기 때문에 프로젝트마다 다른 기준에 따라서 일정이 정해진다. 개발자가 산정한 일정을 가장 우선시하지만 가끔은 고정된 일정에 개발자가 맞춰야 할 때도 있다. 이때는 합리적으로 조정하려고 노력한다. 부족한 일정만큼 개발자를 더 투입하거나, 외주를 투입하거나, 기능을 축소하거나, 단계별로 기능을 제공하거나, QA를 더 투입하거나, 상용 라이브러리를 구매하는등 여러 수단을 동원한다. 스펙을 철저히 쓰고 그렇게 합리적으로 진행하더라도 예상치 못한 Task가 추가로 생기는 등의 변수로 인해서 어려움에 봉착하기도 한다. 이를 해결하기 위해서 PM(Project Manager)과 TL(Technical Leader)은 머리를 맞대고 해결책을 고민한다. 최대한 합리적으로 계획을 세우고 해결책을 수립해도 프로젝트에는 어려움이 닥친다.  PM과 TL은 노하우를 쌓아서 이런 상황을 최소화 해나가고 있다.

개발자 캐리어는 확실히 보장한다.

개발자는 확실히 개발만 하게 한다. 그래야 효율성이 높기 때문이다. 전문 PM이 별도로 있어서 관리는 PM이 전담한다. PM 또한 대단한 전문성을 요구한다. 개발자에게는 개발만 요구하기 때문에 개발자로서 확실한 실력을 보여줘야 한다. 끊임없이 공부하고 노력해서 연차에 걸맞는 실력을 보여줘야 한다. 그렇지 않으면 신입 개발자들에게 밀리는 일이 발생한다. 사람들과의 관계와 공력으로 버티는 개발자들은 살아남기 힘든 환경이다. 야근이 별로 없다고 하더라도 퇴근 후에 해야 할 공부가 많다. 개발자는 평생 공부해야 한다고 하지만 성향에 따라서는 쉬운 일이 아니다. 나조차도 종종 고3때보다 공부를 더 하는 것 아닌가 생각할 때가 있다.

모든 것을 공유해야 한다.

공유하지 않는 것은 거의 없다고 보면 된다. 오늘 내가 한 모든 것이 온라인 시스템을 통해서 공개되고 공유된다고 보면 된다. 서로 만나서 말로 논의하고 끝나는 경우가 없다. 10분짜리 회의라도 Wiki 시스템에 기록이 남고 ITS(Issue tracker system)을 통해서 모든 이슈(버그, 개선, 신기능, Task 등)는 시스템에 기록되고 온라인으로 논의한다. 개발외에도 모든 업무가 온라인을 통해서 진행된다. 모든 직원이 당장 떨어져서 일해도 전혀 어려움이 없는 상황이다. 글로 적는 습관과 실력이 없는 사람들은 보통 곤역스러운 일이 아니다.

이것은 회사에게는 큰 장점이다. 직원이 하나 갑자기 빠져나가도 회사는 문제 없이 돌아간다. 하지만 개발자에게는 좋기도 하고 나쁘기도 하다. 열심히 일한 개발자는 자신이 과거해 해놓은 일에 발목을 잡혀서 새로운 일을 못하지 않는다. 언제든지 다른 사람들에게 유지보수를 맡기도 새로운 일을 할 수 있다. 하지만 의도치 않게 자신의 지식과 정보를 숨겨서 이를 자신의 존재가치로 삼는 개발자에게는 아주 안좋은 환경이다. 이런 회사는 개발자가 중요한 자산이기도 하지만 Risk가 되기도 한다.

자연스럽게 모든 정보를 시스템에 남기는 형태로 일하는 것은 습관이 되기 전에는 매우 곤역스러운 일이다. 따라서 모든 개발자에게 꼭 좋은 환경이라고 볼 수는 없다.

개발을 위한 신입사원 교육이 없다.

신입사원 교육이 있기는 하지만 회사의 일반에 관련된 내용이고 개발을 하기 위한 신입사원 교육이 없다. 이는 좋기도 하고 나쁘기도 하다. 신입사원은 입사하자마자 이슈(버그, 신기능, 개선 등)를 할당 받기 때문에 알아서 개발을 해야 한다. 단, 시스템에 거의 모든 정보가 있기 때문에 정보를 찾아가면서 개발을 해야 하고 멘토나 팀장이 가끔 가이드를 해준다. 하지만 옆에 끼고 가르치는 것은 없다. 고참들은 신입사원이 많이 들어와도 이들을 가르치기 위해서 시간을 빼앗기지 않는다. 신입들은 아무도 가르쳐주는 사람이 없어서 막막하겠지만 시스템을 검색해보면 필요한 정보가 거의 다 있기 때문에 본인의 능력여하에 따라서 훨씬 빨리 배울 수 있다. 또한 자연스럽게 본인들도 공유하는 습관을 가지게 된다.

이렇게 어떤 개발자에게는 좋은 환경이기도 하고 어떤 개발자에게는 매우 나쁜 환경이 되기도 한다. 하지만 이런 과정을 통해서 모든 프로젝트는 일정을 지키며 개발자들의 생산성은 매우 높다. 개발자는 글로벌 회사의 개발자들과 다를바 없는 수준으로 꾸준히 회사와 같이 성장할 수 있도록 노력하고 있다.

막연히 좋은 점만 상상을 했다면 이우소프트는 그런 모습은 아니다. 회사가 글로벌 회사들과 경쟁하는 것이 목표이며 이를 위해 필요한 모습을 갖추고 있을 뿐이다. 성향이나 적성이 일치하다면 좋은 환경이지만 그렇지 않다면 적응하기가 쉽지 않다. 물론 신입개발자들은 대체로 적응을 잘한다. 백지에는 무엇이든지 잘 써지기 때문이다.

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.

그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.

완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

 

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.

모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.

소프트웨어 회사에서 경영자가 하면 안되는 것들

필자는 23년 경력의 개발자이며 이우소프트의 CEO다. 과거 8년 동안 소프트웨어 공학 컨설턴트로서 소프트웨어 개발에 관한 글을 써왔다. 우리나라의 열악한 소프트웨어 개발 환경의 핵심이 개발문화 때문이라고 생각해서 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례 소개하고 있다.

오늘은 소프트웨어 회사에서 경영자가 하면 안 되는 것들을 소개하려고 한다. 물론, 회사마다 기업문화가 달라서 사람에 따라서는 괴리감을 있을 수 있다. 문화란 원래 경험하지 않은 사람은 괴상하다고 생각할 수도 있고 현실성이 없다고 느낄 수도 있다. 하지만 우리 회사에서는 당연하게 생각되는 것들이고 이런 문화가 글로벌 소프트웨어 기업들과 경쟁하기 위해서 필요하고 생각하기 때문에 소개를 한다. 

첫째, 개발자들의 개발 기간 예측(Estimation)을 무시하기

많은 회사에서 벌어지고 있는 일이고 일방적으로 경영자의 잘못으로 치부하기도 힘들다.

사례는 워낙 많지만 개발자들이 1년 이하로는 도저히 개발할 수 없다고 주장하는 프로젝트를 경영자가 6개월안에 무조건 끝내라고 하는 경우는 매우 흔하다. 이유도 여러 가지다. 개발자의 주장을 믿지 않기도 하고, 프로젝트가 늦어질 것을 감안하여 필요 일정보다 무조건 당겨서 끝내라고 하기도 한다. 또한, 이렇게 개발자를 강하게 압박하지 않으면 개발자들이 야근도 안하고 열심히 일을 안 한다고 생각하는 경영자도 많다. 

당장은 이렇게 해서 몇몇 프로젝트가 성공할 수도 있고 개발 일정도 당겨지고 이익을 보기한다. 하지만, 이런 행위가 관행처럼 굳어지면 결국에는 개발자, 경영자 모두가 손해를 본다. 또한 회사의 개발 문화도 한참 후퇴한다. 경영자가 일정을 무조건 줄이면 개발자는 다음부터 어쩔 수 없이 예상보다 조금씩 늘려서 얘기를 하곤 한다.

개발자도 경영자가 납득할만한 근거를 가지고 적절한 개발 기간을 제시하지 못하는 문제도 벌어진다. 그래서 경영자는 개발자가 제시한 일정을 납득하지 못하고 무조건 일정을 줄이고 본다. 이 싸움은 누구도 승자가 될 수 없는 싸움이다. 개발자는 아키텍처가 망가지는 고통 속에서 야근을 거듭하고 경영자는 프로젝트의 예측 가능성이 낮아져서 비즈니스를 수시로 그르치게 된다.

먼저, 개발자는 잘 분석된 스펙을 바탕으로 납득할 수 있는 일정을 제시해야 한다. 그리고 경영자는 개발자가 예측한 일정을 믿어주는 신뢰관계가 필요하다. 그래야 개발자는 항상 최선을 다해서 정확한 일정을 산정하려고 노력한다. 개발자가 제시한 일정을 단축해야 하는 경우에는 합리적인 수단을 사용해야 한다. 야근도 하나의 방법이기는 하지만 습관적인 야근은 이익보다 손실이 큰 방법이다. 합리적인 수단이란 기능 축소, 핵심 기능에 집중, 단계별 개발, 전문 컨설턴트 투입, 일부 상용 모듈 구매 등 여러 가지가 있다. 

이런 개발자와 경영자 간의 신뢰 관계는 개발 방법론과 상관없이 필요하며 정착하는데 상당한 기간이 필요하다. 그리고 이렇게 개발하는 방법이 소프트웨어를 가장 빨리 개발하는 방법이라는 것을 깨달아야 한다.

둘째, 합의된 요구사항을 경영자의 취향대로 바꾸기

우리나라 회사들은 경영자가 무엇이든지 뒤집을 수 있는 막강한 권력을 가진 경우가 많다. 출시 임박한 제품의 모양을 경영자가 갑자기 바꾸거나, 취향대로 색깔을 바꾸기도 한다. 소프트웨어 분야에서도 흔히 벌어진다.

프로젝트에서 경영자의 역할은 프로젝트마다 다르다. 하지만 경영자가 프로젝트에서 절대 권력자는 아니다. 한 명의 Stakeholder일 뿐이다. 대부분의 프로젝트에서 경영자의 역할은 비전과 전략을 담당한다. 빌게이츠는 초창기 프로젝트의 기술적인 내용까지 깊숙이 간섭을 했는데 이는 경영자로서가 아니고 Chief Architect로서의 역할을 한 것이다.

프로젝트에서 경영자는 경영자 관점에서 비전과 전략 요구사항을 전달해야 한다. 그것도 초기에 제시해야 한다. 전략이 바뀌면 프로젝트는 엄청나게 바뀌는 것이므로 가능하면 초기의 전략이 유지되는 것이 좋다. 전략이 바뀌더라도 합리적인 변경을 해야 한다.

경영자가 프로젝트 막바지에 뒤늦게 관여를 해서 감 놔라 대추 놔라 하는 것은 금기사항이다. 이런 일이 벌어지면 아키텍처는 완전히 엉망이 되고 개발자들의 사기는 땅에 떨어지면 신뢰관계는 금이 간다. 우리 회사에서는 스펙이 Close 된 후에는 경영자가 요구사항을 바꾸려고 해도 Change Control Process를 통과해야 한다. Change Control Board에서 변경이 거부되면 아무리 경영자가 요구한 내용이라고 변경이 불가능하다. 

이래야 경영자도 프로젝트에서 자신의 역할을 제대로 수행하기 위해서 최선을 다한다. 뒤늦게 아무 때나 간섭할 수 있다는 생각은 하지 않게 된다.

셋째, 개발자에게 아무 때나 가서 말을 시키거나 지시하기

우리 회사에서는 경영자뿐만 아니라 누구도 개발자에게 아무 때나 말을 걸고 개발을 방해하지 않는다. 개발자가 개발에 집중을 하고 있는 경우에 중간에 방해를 하면 엄청난 손해가 발생한다. 피플웨어에서는 30분 정도의 손실이 발생한다고 한다. 이런 방해가 하루에 3,4번 벌어지면 하루를 망친다.

개발자와 면담을 할 것이 있으면 몇 시간 전이나 하루 전에 미리 시간을 Arrange해야 한다. 급하게 할 얘기가 있으면 개발자가 집중을 하고 있는지 조심스럽게 살핀다.

그래서 우리 회사에는 메신저도 금지되어 있고 근무 중에는 카카오톡도 무음 설정을 해야 한다. 개발자가 집중해서 일을 하고 있는데 메신저가 부르거나 "까똑" 거리면 집중해서 일할 수가 없다. 개발자에게 전화를 거는 일도 거의 없다. 대신에 근무 시간에 최대한 집중을 하고 야근은 되도록 하지 않는다. 

넷째, 수시로 보고서를 요구하기

공유 문화가 잘 정착되어 있는 회사에서는 진행되는 거의 모든 일이 온라인 시스템에 잘 기록되어 있다. 그래서 별도의 보고서가 없어도 경영자는 거의 모든 내용을 실시간으로 모니터링이 가능하다. 그래서 특수한 경우가 아니면 시스템에 있는 정보를 다시 정리해서 보고하라고 하지 않아야 한다. 보고서는 경영자의 시간을 약간 절약해 주지만 직원들은 수십, 수백 배의 시간을 소모해야 한다. 일보다 보고서 작성에 더 많은 시간을 쏟기도 한다. 또한 보고서만으로 업무를 파악하면 가공과정을 거치면서 내용이 왜곡되곤 한다. 시간이 허용하는 한 최대한 많은 정보를 직접 보는 것이 좋다. 보고서는 꼭 필요한 경우에만 작성해야 한다. 이것이 가능 하려면 공유 문화가 완전히 정착되어 있어야 한다. 

지금까지 네 가지 경영자가 하면 안 되는 일을 소개했다. 그럼 경영자는 별로 할 일이 없는가? 경영자는 회사의 비전, 전략을 정하고 목표를 설정해야 한다. 인재를 채용하고 직원을 코칭, 육성해야 하며 회사의 규칙을 만들고 문화를 만들어가야 한다. 이외에도 경영자가 해야 할 일은 수없이 많다. 

필자는 CEO일 뿐만 아니라 아키텍트의 역할도 일부 수행하며 또한 소프트웨어 국제화 전문가이다. 그래서 소프트웨어 공학, 아키텍처, 국제화 관련 이슈에도 전문가로서 직접 관여를 한다. 하지만 그 외의 것은 위에서 얘기한 것처럼 Stakeholder로서 의논에 참여를 하고 의견을 제시하지만 결정에 과도한 압력을 가하거나 합의된 결정을 뒤집지는 않는다. 합의를 바꾸려면 정해진 절차를 따른다. 

글로벌 수준의 개발 문화 속에서 경영자와 개발자가 각자의 전문 역할을 충실히 수행할 때 글로벌 소프트웨어 회사들과 비로소 경쟁을 시작할 수 있을 것이다.

개발 문화는 후진적인데 개발자 하나하나가 선진적이고 뛰어나다고 해서 소프트웨어가 경쟁력을 갖출 수 없다. 개발 문화라는 것이 반바지를 입는다고 공짜 점심을 준다고 좋은 공학툴이나 방법론을 도입한다고 해서 제대로 정착되는 것은 아니다. 모든 구성원의 마음과 습관을 바꾸는 것이 핵심인데 매우 어려운 과정이며 경영자부터 바뀌지 않으면 안 된다. 

이 글은 ZDNet Korea에 기고한 글입니다.

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연이 끝나고 나오는 과정에서 X-Ray 검색대에서 와이브로 단말기가 발견이 된 것이다. 보안 담당자는 와이브로 단말기는 압수하고 조사 후 일주일 정도나 뒤에 돌려준다는 것이다.

​

필자는 이동이 잦고 와이브로를 통해서 인터넷을 사용했기 때문에 이런 처사는 받아들일 수 없었다. 그리고 반입금지 물품 안내에 와이브로는 있지도 않았었다. 결국 임원분이 보증을 서서 해결을 했는데 어이 없는 해프닝이 아닐 수 없었다.

​

강연을 하러 간 강사를 잠재적인 도둑 취급하는 것은 너무한 처사가 아닐까 생각도 들었지만 먼저 직원들은 얼마나 불편할까 하는 측은함도 들었다. 하지만 몇몇 직원들은 이러한 공항 보안 검색대보다 철저한 보안 절차에 익숙해져서 당연하게 생각하고 있었다.

​

사실 회사 입구에 있는 보안 검색대는 직원들을 잠재적인 도둑 취급하는 것 같아서 기분은 별로지만 잠깐의 불편함만 감수하면 그럭저럭 견딜만하다. 정작 과도한 보안 정책의 문제는 실제 일을 할 때 발생한다. 회사마다 보안정책이 다르지만 보안이 철저할수록 개발자들은 일하기 힘들어진다.

​

개발자를 소스코드를 훔쳐갈 수 있는 잠재적인 도둑으로 보고 소스코드 접근을 철저히 통제하는 회사가 많다. 자신이 고칠 소스코드만 승인을 거쳐서 내려 받을 수 있도록 하거나 전체 소스코드는 절대로 보지 못하도록 하기도 한다. USB는 아예 차단을 하거나 소스코드를 눈으로 볼 수는 있지만 파일은 접근하지 못하도록 하기도 한다. 소스코드를 사진으로 찍어 갈 수 있다고 휴대전화 카메라에 스티커를 붙이기도 한다.

​

물론 보안은 매우 중요하다. 하지만 우리 주변에서 벌어지고 있는 소프트웨어 회사들의 보안 정책을 보면 소프트웨어를 이해하지 못한 경영진들이 소프트웨어를 잘 개발하지 못하게 방해하고 있다는 생각이 든다.

​

반도체 공장에서 설계도면 훔쳐가면 큰 일이 나듯이 소프트웨어도 소스코드를 훔쳐가면 큰 일 나는 것으로 생각한다. 그럼 A사의 개발자들에게 물어보자. 이렇게 보안을 철저하게 하면 개발자가 절대로 소스코드를 가지고 집에 갈 수 없나요? 대답은 당연히 아무리 보안을 철저히 해도 개발자는 모든 소스코드를 들고 집으로 갈 수 있다. 그리고 개발자는 집에서 일을 하기도 한다.

​

이것을 보고 있으면 우리나라 인터넷 뱅킹이 생각난다. 보안을 철저히 한다고 액티브X에 키보드보안, 개인방화벽, 보안카드, 인증서, OTP 등 수많은 장치들을 두어서 인터넷 뱅킹을 불편하게 하고 있지만 사고는 계속 발생한다. 그럴수록 점점 더 복잡하게 만든다. 그렇다고 보안사고가 잘 줄지 않고 있다. 복잡할수록 구멍이 많아진다.

​

소프트웨어 회사에서도 개발자가 소스코드를 훔쳐가려면 다 훔쳐갈 수 있다. 보안 담당자들은 개발자들과 창과 방패의 싸움을 해서는 보안도 못 지키고 개발 효율만 엄청 떨어질 뿐이다. 경영자는 보안 담당자의 목소리만 들어서는 안된다. 개발자들의 목소리도 균형 있게 들어야 한다. 보안도 지키면서 개발 효율도 떨어뜨리지 않는 방법을 치열하게 연구해야 한다.

​

하지만 대부분의 회사는 보안 담당자(전문가는 아닌)의 목소리가 크고 개발자들의 불편하다는 아우성은 귀담아 듣지도 않는다. 보안을 위해서는 어쩔 수 없다고 생각한다. 생산성을 중요시하는 경영진들이 이런 비효율적인 결정을 하는 이유는 직원들을 잠재적인 도둑, 또는 노예 취급을 하기 때문으로 생각한다. 그렇다고 보안이 잘되는 것도 아니다.

​

보안을 강조하는 회사에서는 소스코드를 신주단지 모시도록 하지만 소프트웨어 회사에서 소스코드의 보안적인 가치는 별로 없다. 사실 자사에서도 자신들이 개발한 소프트웨어의 소스코드를 유지보수하기가 쉽지 않다. 그런데 이런 소스코드가 유출이 된들 누가 이 소스코드를 가지고 소프트웨어를 흉내 내서 만들어 낼 수 있을까? 중요한 것은 개발자들의 경험과 노하우다. 소스코드보다 개발자를 지키는 것이 더 중요하다.

​

어떤 개발자는 소스코드를 옆 팀, 심지어는 동료들도 안 보여준다. 보안 때문이라고 한다. 이런 경우 십중팔구 개발자가 철 밥그릇 지키려고 소스코드를 공개하지 않는 것이다.

​

우리 회사에서 소스코드가 중요하고 가치가 있는 이유는 이를 잘 아는 개발자들이 있기 때문이다. 소스코드 내용뿐만 아니라 소스코드를 이해하고 개발하는데 필요한 많은 지식과 경험이 있기 때문이다. 게다가 대부분의 소스코드는 다른 개발자가 이해하기 쉽게 잘 작성되지도 않는다.

​

보안이 중요하지 않다는 것이 절대로 아니다. 엉뚱한 방향으로 헛발질 하고 있는 것이 문제다. 물리적인 보안에 너무 치중하다가 정작 중요한 것을 놓치는 경우가 많다. 물리적인 보안도 신경을 써야 하지만 직원들의 의식 교육이 더 중요하다. 그리고 경영진들은 소프트웨어에 대한 이해를 좀더 높여야 한다. 어디 공장에서나 쓰일 법은 규칙을 소프트웨어 개발현장에 들이밀면 개발자들의 개발 효율성은 뚝 떨어진다. 하지만 개발은 엄청 불편하게 만들어 놓고 개발 시간을 더 주지 않는 것이 현실이다. 이는 결국 소프트웨어 품질의 저하로 이어지고 개발 문화의 후퇴를 가져온다.

이 글은 ZDNetKorea에 기고한 칼럼입니다.

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있다. 이런 얘기를 들어보면 우리나라에서 개발자는 나이를 먹을수록 할만한 직업이 아니라는 생각이 든다.

필자는 이런 현상이 벌어지는 이유 중 하나로 리뷰를 잘 안 하는 문화를 꼽고 싶다. 개발자라면 각자 생각해보자. 지금까지 얼마나 많은 리뷰를 해왔던가? 자신이 작성한 문서, 소스코드를 다른 사람이 얼마나 리뷰를 해줬고, 나는 또 다른 사람이 만든 문서와 소스코드를 얼마나 많이 리뷰를 해줬던가? 잘 생각해보자. 개발자가 10년 정도 일을 했으면 수백 건의 문서와 수만에서 수십만 라인의 코딩을 해왔을 것이다. 그 중에서 리뷰를 받은 경우는 몇 %나 될까?

개발자를 성장하게 해주는 가장 효율적인 수단은 “리뷰”다. 물론 책을 보거나 인터넷을 통해서 지식을 익히는 것도 하나의 수단이다. 하지만 리뷰를 통해서는 훨씬 더 효율적으로 배우고 책을 통해서는 도저히 알 수 없는 수많은 것을 배운다. 물론 본인도 리뷰를 통해서 다른 사람에게 나의 경험과 지식을 전달해줘야 한다.

리뷰는 요구사항을 확인하고 문제점을 찾아내고 바로 잡는 역할도 하지만 자연스럽게 개발자들의 성장을 돕는다. 물론 리뷰를 제대로 해야 한다. 수박 겉핥기 식으로 훑어보는 것은 제대로 된 리뷰가 아니다. 문서든 소스코드든 본인의 전문적인 관점으로 철저하게 수행해야 하면 여기에 많은 시간과 노력을 투자해야 한다. 리뷰를 귀찮은 절차로만 생각하고 바쁘면 생략하거나 흐지부지 사라지는 경우가 많다. 하지만 생략되거나 엉터리 리뷰 때문에 제품이 잘못되기도 하지만 장기적으로는 개발자들이 성장을 하지 못한다.

내가 경험하기로는 중소기업이나 대기업이나 리뷰를 하고 있다고 한 회사치고 진짜 리뷰를 제대로 하고 있는 회사는 매우 드물다. 대부분은 정형화된 프로세스를 따르기 위해서 형식적으로 수행하거나 리뷰를 위한 시간을 주지 않아서 개발자들이 어쩔 수 없이 리뷰를 대충하는 경우가 많다.

그럼 이렇게 꼭 필요한 리뷰가 우리나라에서 리뷰가 잘 안 되는 이유가 무엇일까?

첫 번째 이유는 바쁘다는 이유다. 바빠서 리뷰를 할 시간이 없다는 것이다. 하지만 바빠서 리뷰를 하지 않거나 소홀히 하면 점점 더 바빠질 것이다. 문제가 조금씩 더 쌓이고 개발자들이 실력이 정체되어서 개발 효율이 점점 더 떨어지기 때문이다.

두 번째 이유는 리뷰에 익숙하지 않기 때문이다. 그래서 리뷰를 거북해하는 개발자가 많다. 리뷰를 하면 지휘고하를 막론하고 자식이 작성한 스펙, 설계, 소스코드를 철저히 검토 받는다. 리뷰를 진행하면 지적을 당하기도 하고 다양한 의견 충돌이 있어서 협의, 조율해야 할 때도 있다. 물론 도움을 받는 경우도 많다. 하지만 나이별, 직급별 상하관계가 굳건한 조직이라면 아랫사람은 쉽게 반대 의견을 제시하기 어렵다. 자존심이 상하기도 하고 관계가 틀어지기도 한다. 또, 윗사람의 의견은 지시처럼 들리기 일쑤다. 이런 딱딱한 조직에서 리뷰는 쉽지 않다.

그럼 우리나라 대기업들은 어떨까? 회사마다 다르지만 보통 개발자들은 자기 분야의 보직을 바꾸지 않고 오랫동안 일을 한다. 그러다 보니 그 개발자가 일하는 것을 봐줄 사람도 별로 없고 리뷰를 하지 않아도 별 문제 없이 일이 진행되는 것처럼 보인다. 회사에서 리뷰를 강제화해도 진짜 리뷰가 잘 되는지 파악하기는 쉽지 않다. 이런 문제를 보완하고자 자꾸 프로세스와 절차를 만들어도 개발 효율만 떨어지지 리뷰가 잘 되는 것은 아니다. 이런 문제를 가지고 있는 회사가 리뷰를 잘하고 있는 회사보다 훨씬 많다.

리뷰를 제대로 안 하면 버그도 많아지고 이를 고치기 위해서 비용이 더 많이 든다. 테스트를 강화해서 해결을 하려는 노력도 많이 하지만 리뷰를 잘하는 것보다는 장기적으로 더 비싼 방법이다. 

결정적인 문제는 개발자가 성장하기 어렵다는 것이고 한가지 일에 매몰돼서 빠져 나오지 못하는 경우가 많다. 리뷰를 잘 하고 있다는 얘기는 자연스럽게 공유가 잘된다는 의미와도 같다. 말로만 공유한다고 떠들어도 리뷰를 안 하면 문서가 제대로 작성된 것인지 알 수가 없다. 하지만 리뷰를 제대로 하면 문서가 조금만 부실해도 바로 발견이 된다. 리뷰를 제대로 하면 문서가 충실하게 작성될 뿐만 아니라 그 내용이 리뷰를 통해서 동료들에게 전달된다.

리뷰를 제대로 안 하는 현상이 지속되면 특정 지식을 특정 개발자만 알고 있게 되고 이런 개발자가 많아질수록 조직의 유연성은 대단히 떨어진다. 소수의 개발자만 퇴사를 해도 회사가 휘청거리고 개발자들이 정말 바쁠 때 다른 개발자가 도와주기 어렵게 된다. 바쁜 사람은 항상 바쁘고 노는 사람은 노는 회사가 된다.

리뷰는 치열하게 해야 한다. 리뷰에 참여를 했다는 의미는 공동책임을 진다는 의미다. 고참 개발자가 될수록 다른 사람의 문서나 소스코드 리뷰를 더 많이 해줘야 한다. 그런 과정을 통해서 개발자는 계속 성장할 것이고 개발자 본인을 자유롭게 한다. 언제든지 현재 업무를 다른 사람에게 넘기고 새로운 일을 할 수 있도록 해준다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

Image by http://www.lab-initio.com

55세 개발자가 막내인 개발팀

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소프트웨어 개발자라면 알만한 시스템을 개발하는 회사다. 
 
그 회사의 제품군을 알고 있는 사람들은 100여명 밖에 안되는 개발자들이 일하고 있다는 것에 놀랄것이다. 우리나라 소프트웨어 회사라면 20년간 커왔고 전 세계 많은 나라 기업들에서 사용하고 있는 시스템을 만든다면 개발자가 수백명에 육박할 것이다. 하지만 매우 적은 인원으로 효율적으로 개발하고 있다는 것은 놀라운일이다. 그런데 이렇게 효율적인 소프트웨어 회사가 우리나라 밖에는 엄청나게 많다. 
 
P사 제품의 코어엔진을 만드는 팀에는 7명의 개발자가 일하고 있다. 그중 제일 고참이 60세라고 한다. 막내는 55세다. 또 관리자의 나이가 가장 어리다. 60세 개발자는 회사 초창기부터 20년간 근무했다. 대충 짐작해도 35년은 엔지니어로 일하고 있는 것으로 보인다. 비단이 회사에만 이런 할아버지 개발자들이 있는 것은아니다. 개발자 본인이 원하고 실력이 된다면 20년, 30년 원하는 만큼 개발자로 일을할 수 있다. 
 
우리나라에서는 한 분야에서 오랫동안 한가지 제품만 개발하고 있는 개발자들의 걱정이 있다. 다양한 분야를 접하지 못하다 보니 경험이 제한되고 시야가 좁아지고 엔지니어로서의 가치가 떨어지는 것이 아닌가 하는 우려를 한다. 실제로 금융분야에서 10여년 일한 개발자를 보면 사용하고 있는 프레임워크만 알고 기계적인 코딩밖에 하지 못하는 경우를 종종 본다. 다른 분야도 마찬가지다. 그럼 한 분야에서만 일한 미국의 30년차 개발자도 그럴까? 물론 개인차가 있겠지만 개발하는 문화나 방식이 좀 다르기 때문에 상황은 다르다.
 
P사에서 개발하는 방식을 보자. 눈에 띄는 것은 개발 방법론이 어찌됐건간에 제품을 꾸준히 업그레이드하면서 코딩을 하기 전에 스펙 문서를 자세히 작성해서 전세계 많은 관련자와 세밀하게 리뷰를 한다. 스펙에는 아키텍처도 포함되어있다.  스펙은 개발자끼리만 리뷰를 하는 것이 아니다. 애플리케이션 개발자와 리뷰도하지만 QA엔지어와도 리뷰를하고 기술 지원 엔지니어 등 거의 모든 분야 관련자들과 리뷰를한다. 
 
리뷰는 그냥 훑어보는 것이 아니다. 자신이 담당하거나 전문인 분야의 지식을 총동원한 후 검토를 해서 향후 발생할 문제 등을 면밀히 분석하는 것이다. 이 과정에서 아주 기술적인 세밀한 부분까지 토론하고 논쟁한다.
 
이런 과정을 거치면 제품의 완성도는 훨씬 올라가고 아키텍트는 튼튼해진다. 이런 얘기를 들으면 우리도 시간이 충분하면 이렇게할 수 있다고 한다. 하지만 이런 생각은 착각이다. 이렇게 개발을 하기 때문에 적은 인원으로 더 빨리 개발을 하는 것이다. 논어에는 세명이 길을가면 그중에는 반드시 내 스승이 있다고 했다. 철저한 리뷰는 더 좋은 제품을 만들기도 하지만 리뷰를 통해서 많은것을 배운다. 개발자는 본인의 직접적인 경험과 책만으로 배우는 것은 한계가 있다. 여러 개발자와 또 개발자가 아니라도 여러분야의 전문가와 토론하면서 많은것을 배우게 된다.
 
우리나라 개발자들은 흔히 토론, 리뷰에 약하다. 토론의 경험도 적고 막상 토론을 하면 직급으로 누르거나상대방을 공격해서 상처를 주거나 논리적으로 진행되지 않는 경우가 많다. 한두번 이런 일을 겪고 나면 이런 자리는 자연스럽게 피하게 된다. 결국 혼자서 땅굴을 파는 것에 편하게 되고 그렇게 오랜시간 개발을 하다 보면 한 분야의 전문가는 될 수 있어도 다양한 경험과 통찰력을 가진 개발자로 발전하기는 힘들게 된다.
 
또, 주목할만한 것은  소프트웨어 선진국에서는 아주 흔한 근무형태지만 재택근무가 아주흔하다는 것이다. 위에 언급한 모든것의 진행이 온라인 시스템과 화상회의로 이루어진다. 장소에 구애 받지 않고 일하고 회의도 화상회의 시스템을 많이 이용하고 꼭 필요할 때만 회사에 나가도 된다. 이런 재택근무 문화는 개발자에게 일할 기회를 제공한다기보다는 장소에 구애받지 않고 회사가 뛰어난 엔지니어의 도움을 받을 수 있다고해석하는 것이 좋겠다. 
 
리뷰도 어차피 대양을 건너 세계 각국 많은전문가와 진행하는 것이기 때문에 한자리에서 같이 일할 필요는없다. 이렇게 뛰어난 엔지니어들이 모이면 서로의 성장에 도움이 된다. 온라인이 아니면 이런 엔지니어들이이렇게 같이 일을할 수 있겠는가?
 
이글을 읽는개발자라면 우리도 환경이 되면 이렇게할 수 있다고 생각할 수 있겠지만 막상 쉽지는 않다. 대부분의 엔지니어가 문서 작성을 코딩하는 것처럼 익숙해져 있고 잘 작성해야 한다. 이런 온라인 협업은 시스템과 문서로 진행이 되기 때문에 문서작성역량은 매우 중요하다. 많이 자세히 작성하는 것이 잘하는 것은아니다. 효율적으로 필요한 핵심 내용을 적절히 작성해야 한다. 고참 엔지니어가 될수록 문서작성능력은 더욱더 중요하다. 나뿐만 아니라 내 주변의 수많은 개발자들 이렇게 일을 할때 30년 이상 개발자로 즐겁게 일할 수 있을 것이다.

개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화 중 하나는 '공유’ 문화라고 할 수 있다. 소프트웨어개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20년, 30년 계속 개발자로 일할 수 있도록 하는 기초 체력이기도 하다. 

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다. 내 주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다. 특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다. 하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은 잘 들려오지 않는다. 그 이유는 무엇일까?

여러 가지 이유가 있겠지만 그 첫 번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다. 

‘죄수 딜레마’라고 들어본 적이 있는가? 

상황은 다음과 같다. 두 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다.

•    둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

•    둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

•    둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

죄수A는 죄수B가 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다. 죄수B가 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A는 죄수B가 어떤 선택을 하든지 자백을 선택한다.

죄수B도 죄수A와 동일한 상황이므로, 마찬가지로 죄수A가 어떤 선택을 하든지 자백이 유리하다.

따라서 둘 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B 는 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건, 죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 더 빨리 교차로를 빠져나갈 수 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히있으면 교차로를 가장 늦게 통과하게 될 것이다. 심지어는 주변의 차들에게 욕먹을 각오도 해야 한다.꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 몇 배 더 손해를 보게 되어 있다. 그래서 어쩔 수 없이 다같이 손해를 보는 경우를 선택하게 된다.

몇 년 전 가족과 함께 괌의 한 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운 일을 목격했다. 수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다. 선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다. 몇 시간 후나타난 선배드의 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선배드를 찜 해놓고아침식사를 하러 간 것이었다. 사실 선배드는 모든 사람이 충분히 쉴 만큼 많았다. 하지만 이용도 하지않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀 쉴 곳이 없게 된 것이었다. 한국에서는 이런 현상이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지,바뀌었는지 알 수 없다. 어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드 몇 개를 찜 해 놓는 일에 동참하는 우리를 발견하게 되었다.

이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는확신이 없다면 약속은 순식간에 무너진다.

그럼, 규칙을 엄하게 적용하면 해결될 수 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 수있지 않을까? 이런 식으로 해결이 될 수 있었다면 우리나라의 대부분의 회사가 이미 공유문화가 잘 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

첫째 만들어 놓은 규칙이 엄격하기만 할 뿐 공유 문화 정착에 효과적인 경우가 별로 없다. 왜냐면 그엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해 본 적도 없는 사람들이기 때문이다. 대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이없다. 게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다. 문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들 수 있지만 진짜 필요한 내용이 다 들어 있는지 확인할방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜공유는 피해 다니게 되어 있다.

셋째 나만 공유를 제대로 하게 될 경우 나만 손해를 볼 수 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을내는 것도 안 된다. 현재 상황을 잘 파악해서 공유문화를 만들어 갈 수 있는 단계적인 접근이 필요하다. 개발자들이 소화할 수 있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과일치를 해야 한다. 이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 될 것이라는 확신을 직원들에게 심어주어야 한다.

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다. 그럼 비효율이 정착된 회사가 될것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.