개발 피드 목록

오랜만에 돌아온 크로키닷컴 인터뷰!요즘 채용이 활발하게 진행 중인 크로키닷컴의 [프론트엔드 개발자] 에 관해 궁금해하시는 분들을 위해, Dev.팀에서 근무하고 있는 프론트엔드 개발자 두 분! 영준님, 케빈님을 모셨습니다.Chapter 1. 저를 소개합니다!Q. 영준님, 케빈님 반갑습니다! 간단하게 자기소개 부탁드릴게요.영준 저는 프론트엔드 개발자 김영준이고요, 지그재그의 또 다른 신사업 서비스를 만들어가고 있습니다. 프론트엔드 개발은 5년 정도 했고, 요즘은 신사업 서비스에 새로운 기능이 들어갈 예정이라 그 작업을 열심히 하고 있습니다! 참, 원래 저는 공대 출신은 아니고 디자인과를 졸업했어요.(우와.. 디자이너에서 개발자로 전향하신 특별한 계기가 있으셨나요?)그때 당시 어도비 플래시가 잘 되던 시기였는데, 플래시가 좋아서 그쪽 수업을 많이 들었거든요. 그때부터 관심을 갖게 돼서 첫 회사에는 플래시 개발자로 입사했었어요. 이후에 플래시 사용률이 점차 줄어들면서 프론트엔드 개발 쪽으로 전향하게 되었습니다.케빈 어.. 제 본명은 성훈이고요.(웃음) 저는 원래 풀스택 개발자로 2년 정도 일을 했었어요. 본격적으로 프론트엔드 쪽으로 전향한 지 2년 정도 된 것 같아요. 저도 영준님이랑 비슷하게 공대는 아니고 영상그래픽을 전공했어요. 3D나 특수효과 같은 거? 교양수업으로 HTML 수업을 듣다가 개발에 관심이 생겨서 시작하게 됐습니다!(그렇군요! 케빈님 곧 있으면 입사 100일을 맞이하시게 되는데 소감이 어떠신가요?)프론트엔드 포지션에 온전히 집중해서 일을 해본 건 처음이에요. 이전에 바라 왔던 업무환경에 많이 근접한 것 같고 점차 적응 중에 있습니다.Q. 어떠한 연말을 보내고 계신가요?영준 어! 저 얘기할 거 있어요. 얼마 전부터 회사에서 전세자금 대출 이자를 지원해주기 시작한 덕분에 난생처음으로 독립을 하게 됐거든요. 이자를 지원받게 되니 집도 더 잘 구하게 된 것 같아요! 그래서 요즘은 자취 초년생으로서 이것저것 해보고 있어요. 요리도 해보고 그동안 해보고 싶었던 것들? 하지만 집에서 부모님이 해주시는 게 얼마나 감사한 지도 알게 됐어요. (그래도 다시 돌아가긴 싫으시겠죠?)영준 네, 독립해서 진짜 좋아요. 그래서 요즘 일하는 시간 외에는 인테리어 고민을 많이 하고 있어요. 지금 집에는 아무것도 없거든요. 곧 영준님만의 감성으로 채워질 집!케빈 아.. 저는 딱히 뭐가 없는데..영준 아 아직 입양 안 받았어요?케빈 아! 맞아요. 제가 동물을 입양하려고 준비하고 있어요. 그 동물에 대해서 공부 먼저 하고 제대로 알게 된 다음 입양하려고요. (입양이요? 강아지? 고양이?!) 케빈 페럿이라고 아세요? 페럿을 입양하려고 공부하고 있어요. 돈도 많이 든다고 해서 모으고 있기도 하고요. 그것 빼고는 하는 게 없어요 아직.키우는 분이 별로 없는 희귀한 동물, 페럿! 애교가 많은 동물이라고 하네요 :-)Chapter 2. 직잭러가 되어가는 과정Q. 지그재그로 이직하고 싶었던 특별한 계기나 이유가 있었나요?영준 이직할 때 개발자로서 성장이 가능한 회사를 찾으려고 했어요. 이전 회사가 에이전시이다 보니 코드 리뷰 문화가 없었거든요. 코드 리뷰는 프로덕트에도 좋은 영향을 끼치지만 개발자 개개인의 성장에 더 영향을 많이 끼친다고 생각했거든요.(실제로 겪어본 이후로는 확신합니다!)프로덕트에 대한 이해를 높이는 것은 물론 양질의 코드를 실컷 볼 수 있고, 또 어느 코드 하나 허투루 작성할 수 없어요. 그래서 꼭 코드 리뷰가 있는 회사로 가려고 했는데, 지그재그가 딱 그랬습니다!케빈 저도 코드 리뷰 문화에 한 표! 저는 프론트엔드 분야에서는 늦게 공부를 시작했기 때문에 배울 수 있는 환경이 매우 중요하다고 생각했거든요. 아 그리고 저는 이직을 고려할 때, 그 회사에 대해서 미리 프레스나 github을 다 찾아보는데, 그러다 보면 이 회사는 '이렇게 근무를 하는구나'가 어느 정도 보이더라고요. 근데 지그재그 팀을 찾아보면서 여기서 꼭 같이 일해보고 싶다고 생각했어요. 찾아보시면 지그재그 개발 문화와 관련된 소스코드나 오픈소스 프로젝트가 공개되어 있는데요, 왜 이런 코드를 썼고 이런 규칙을 정했는지 오픈해두고 같이 생각해볼 수 있게끔 되어 있어요.영준 저는 기술 블로그도 재밌게 봤어요.케빈 맞아요. 특히 주니어의 입장에서는 발전에 대한 욕망이라고 해야 하나?(웃음) 욕심이 클 수밖에 없는데 기술 블로그가 지그재그 팀에 대한 궁금증을 풀어주는데 많은 도움이 됐어요.나름 활발한 (?) 지그재그 기술 블로그에도 놀러 오세요! https://devblog.croquis.com/ko/Q. 입사 전 인터뷰 때 가장 인상 깊었던 질문이나 에피소드가 있으신가요?영준 일단 면접 절차 진행이 너무 친절해서 당시 기억이 엄청 좋았어요. 또 정해진 질문지에 대한 뻔한 대답보다, 저에게 fit된 인터뷰를 진행했던 것도 좋았고요. 전 회사에서는 인터렉션 관련된 작업을 많이 했었는데, 쟈니님(CEO)이 인터렉션이 프로덕트에 어떤 도움을 줄 수 있을까에 대한 질문이 되게 참신하고 좋게 다가왔습니다. 물론 제가 답한 것 들 이외에도 어떤 영향을 끼칠 수 있는지 말해주어서 더 좋았어요! 아, 재밌는 에피소드가 하나 있는데.. 쟈니님이 '영준님은 친구들 사이에서 어떤 사람이에요?'라고 질문을 하셔서 '먹는 것 좋아하는 사람이요.'라고 대답했더니, 쟈니님이 '그럼 안 되겠네요. 저희는 밥을 다 사드리기 때문에 영준님이 오시면 거덜 날 것 같아요'라고 하셨어요.(빅웃음) 쟈니님은 워낙 장난이 많으신 분이라 재밌었어요.케빈 저는 2차 인터뷰 때 엄청 떨었어요. 그래서 어떤 질문이 나왔고 어떻게 대답을 했었는지 하나도 기억이 안 나네요. 입사 후 수습기간이 끝나갈 즈음에 쟈니님과 미팅을 한 번 더 했었는데, 쟈니님이 제가 인터뷰 때 떨었던 것과는 너무 다르게 업무 커뮤니케이션을 잘한다는 팀원들의 반응이 많아서 놀랐다고 하셨어요.영준 케빈님 1차 인터뷰 때에도 엄청 긴장되시지 않았어요?케빈 맞아요. 그땐 그래도 기술적인 질문이 많아서 나름 덜 떨었답니다.(?) 그리고 아까 영준님이 답해주셨듯이, 저도 마찬가지로 제가 경험한 것을 중심으로 질문을 많이 해주셔서 수월하게 대답할 수 있었던 것 같아요. 입사한 지 얼마 되지 않아 interviewer로 몇 번 참석했었는데, 지원자분의 경험을 중심으로 대화를 나누는 게 실제로 지원자분에 대해서 더 잘 알아갈 수 있는 좋은 방법인 것 같아요!Q. 입사 전 기대했던 지그재그의 모습과 실제 겪어본 지그재그의 모습은 어때요? 많이 다른가요?케빈 저는 기대했던 것과 크게 다르지 않았어요. 많은 개발자들이 기술적으로 더 성장할 수 없다고 느껴질 때 상실감을 크게 느낄 거예요. 전 직장에서도 서로 토론하고 의견을 공유하는 문화가 있었는데 바쁘다 보니 그 문화가 점점 사라지게 되어 많이 안타까웠죠. 그래서 지금은 지그재그 개발팀의 좋은 문화가 유지될 수 있게, 계속 활발하게 운영이 될 수 있도록 적극적으로 참여하려고 노력하고 있어요. 영준 사실 전 지그재그 팀이 딱딱한 분위기에서 업무를 할 거라고 생각했었어요. 워낙에 빠르게 성장하고 있는 회사이다 보니? 근데 막상 들어와 보니 이만큼 같이 일하는 게 재밌고 캐릭터가 독특한 사람들이 많은 회사는 처음이에요. 그리고 저희가 매주 월요일에 전 직원이 모여서 주간 미팅을 하잖아요. 거기서 팀별로 프로젝트 진행상황을 공유하는데 정확한 데이터 수치를 기반으로 꼼꼼하게 분석하고 리뷰하는 모습에 놀랐어요. 추가적으로 개발에 대한 열정이 있는 동료들이 많았으면 하는 소망도 있었는데, 실제로 만난 지그재그는 개발 욕심 가득한 사람들의 모임이라 매일매일 자극받으며 근무하고 있어요.매주 월요일 전직원이 참여하는 주간 미팅!Q. 지그재그 팀에 들어온 후에서야 비로소 알 수 있었던 좋은 문화나 제도가 있을까요?영준 사내 스터디가 많은 거? 아마 우리 회사가 다른 어떤 회사보다 스터디가 많을걸요? 원한다면 누구든 만들어서 모집할 수 있거든요. 다들 매우 적극적입니다.(그럼 영준님은 몇 개의 스터디에 참여하고 계세요?) 저는 1월에 새로 시작할 스터디까지 하면 두 개요!케빈 개발자들에겐 스터디도 큰 요소일 거예요. 다양한 스터디가 지속적으로 운영되는 게 쉬운 일은 아니라, 기술 블로그를 보면 '진짜 이만큼이나 공부한다고?'라고 의문이 들 수밖에 없으니까요. 아! 그리고 스터디는 아니지만 개발 미식회라는 프로그램이 있어요. 다른 사람들과 함께 의논해보고 싶은 코드가 있거나 혹은 본인이 만든 코드를 공유하고 싶은 사람이 자발적으로 신청자를 받아서 점심을 함께 먹으면서 발표도 하고 의견도 나누는 시간이에요. 한 달에 1-2회 정도 진행이 되고 있어요. 다음 주에 저도 발표하기로 했거든요. 신청자가 없어서 못하게 되면 안 되는데..영준 그리고 발표를 했던 사람은 다음 개발 미식회의 점심 메뉴를 선정할 수 있는 특혜가 주어집니다.(웃음)케빈 오! 그건 몰랐어요. 그리고 저는 저번에 영준님이 발표하실 때에도 신청해서 들었어요. 영준 다들 서로 발표를 하고 싶어서 바쁜 와중에도 열심히 공부해요. 바쁠 땐 듣는 게 좀 부담스러울 텐데도, 다들 적극적으로 들어주려고 하니 고맙죠.영준 님의 개발 미식회 모습! 제가 더 떨리네요 @.@Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. 먼저 Dev. 팀은 어떤 방식으로 일을 하나요?영준 백엔드에 계시는 분들도 그렇고 다른 포지션에 계신 분들도 프론트엔드에 관심이 많으셔서 도와주실 때가 많이 있어요. 아무래도 다들 공부를 많이 하다 보니 그런 것 같아요. 그러다 보니 업무 할 때 같이 고민할 수 있어서 좋죠. 그리고 프로젝트를 일정에 맞추어 진행하다 보면 포기해야 될 부분이 생기기 마련인데요, 지그재그 팀은 유저의 사용성 향상을 위해 기획했던 것들을 최대한 포기하지 않고 가져갈 수 있는 방향을 모색하는 편이에요. 포기하면서 잃는 것도 생각하고 얻게 되는 것도 생각해야 하니 항상 신중해야 합니다.케빈 프로젝트를 진행하면서 문제가 생기면 다 같이 의논해서 풀려고 해요. 그리고 그 과정에서 여러 가지 다른 의견이 나오면 합의점을 찾으려고 하고요. 이건 팀 내에서 뿐만 아니라 유관부서랑 함께 일할 때도 같아요. 팀원들 모두가 개인적인 관점이 아닌 product 관점과 사용자 관점으로 생각하려고 하기 때문이죠. 또 프로젝트를 통해 유저분들에게 더 좋은 경험을 전달해주고자 노력하고 있어요. 그래서 유저분들의 기대에 부응한 부분과 그렇지 못한 부분이 무엇인지에 대해 사용자 데이터를 기반으로 회고하는 과정도 함께 진행하고 있습니다.Q. 회사 안에서 해보고 싶은 특별한 프로젝트가 있으신가요?영준 저는 직잭버디를 뽑는 시스템을 만들고 싶어요. 그리고 의류, 패션에 관련된 새 프로젝트도 해보고 싶네요. (*직잭버디는 신규 입사자의 빠른 적응을 도와드리는 멘토링 프로그램입니다!)케빈 저는 개인적으로 점심시간 메뉴 고르는 룰렛을 만들고 싶어요. 회사 주변에 밥집이 너무 많아서 오히려 메뉴를 고르기가 어려워요. 만들면 잘 쓰지 않을까요? 의견을 받아서 다 같이 만들어봐도 재밌을 것 같아요.Q. 요즘 [프론트엔드 개발자] 채용이 한창인데요, 어떤 분과 함께 일하고 싶으신가요?케빈 개발 환경을 기반으로 여러 개발 항목들을 유저의 관점에서 대조해 봤을 때, 깊게 생각해보고 경험해 본 분이면 좋겠어요. 유저의 관점에서 더 생각해보고 적용하시는 분이라면 지그재그 서비스에 대해 애정을 가지고 일할 수 있을 것 같아요.영준 요구사항에 맞게 동작하는 프로그램을 만드는 것은 물론, 유저의 사용성을 생각하는 개발자였으면 좋겠어요. 예를 들면 모바일 기기에서의 최소 터치 영역을 생각한다든지... 유저를 직접 만나는 최접점에 있는 개발이다 보니, 사용성에 관해서는 가장 관심이 많아야 한다고 생각하거든요. 또 프론트엔드 개발 자체가 빠르게 발전하고 있는데, 왜 이렇게 바뀌고 있는지를 생각하는 개발자면 좋을 것 같아요. 그리고 회사가 커지면서 여러 가지 새로운 서비스들도 생기고 새로운 경험도 많이 하게 될 텐데요, 새로운 걸 만들어 보고 겪어보고 싶은 분이라면 지원해주세요!케빈 평소에 업무를 하실 때 깊이 있게 고민하면서 선택하신 본인의 라이브러리, 도구들에 대해 왜 이런 선택을 했는지.. 또 코드 한 줄 한 줄을 어떤 의도로 작성했는지에 대해 생각해보신 분이라면 어렵지 않게 인터뷰를 진행하실 수 있을 거예요. 또, 그런 분들이 계시다면 저희도 꼭 모시고 싶어요!Chapter 4. 마무리Q. 올해 지그재그 팀에 합류하면서 개인적으로 성장한 부분, 그리고 2020년의 목표나 버킷리스트가 있으신가요?영준 지그재그 서비스가 이커머스가 되어가는 과정을 함께 하면서 성장했다고 느꼈어요. 내년 목표는 신사업 성공시키기! 업무 외적으로는 운동을 열심히 해서 바다에서 사진 찍는 거예요. (몸짱 영준)케빈 저는 Z결제 서비스가 오픈되면서 마케팅 이벤트를 위한 개발을 많이 했는데요, 이벤트에 대한 유저의 반응이 폭발적인 걸 보면서 더 유저의 입장에서 생각하려고 하는 스스로를 보며 성장하고 있다고 느꼈어요. 더 공부하려고 하기도 하고요. 그리고 개인적으로는 내년에 영어공부를 열심히 하고 싶어요. 제가 즐겨하는 PC게임이 있는데, 외국인 유저와 더 편하게 대화하면서 게임하고 싶어서요.(웃음)Q. 다음 인터뷰는 어느 팀에서 하면 좋을까요? 그 팀에 특히 궁금한 것이 있다면요?영준 저는 서버 개발자 또는 데이터 팀이요! 지그재그 서비스의 서버 개발자들은 각자 태스크를 부여받아서 진행하는 방식으로 업무를 한다고 들었는데, 구체적으로 R&R이나 업무 프로세스가 어떤 방식으로 이루어지는지 궁금해요. 그리고 데이터 팀에는 수많은 데이터들을 앞으로 지그재그 서비스의 발전을 위해 어떻게 활용할 수 있을지, 그리고 데이터팀에 계시는 인성님께 어떻게 그렇게 매일 웃으며 즐겁게 지내실 수 있는지 여쭤보고 싶어요.케빈 저는 디자인 팀! 지그재그의 다양한 디자인들을 작업하고 의사결정을 내리기까지의 논의 방식이 궁금해요. 그리고 디자인 팀에도 인원이 늘었는데, 그로 인해 어떠한 변화가 생겼는지도 궁금합니다.지그재그에서는 웹 프론트엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [웹 프론트엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지 더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기

개발자와 개발 조직에게 소스코드 리뷰는 필수적이다. 팀간의 협업과 대화를 보다 원활하게 만들어 주는 매우 필요한 절차이다. 슬랙과 같은 협업도구가 명쾌하게 의미 있게 활용되려면 개발팀 간의 소스코드 리뷰는 필수적으로 수행되는 것이 좋다.매우 당연한 이야기이지만, 소스코드 리뷰는 거북하고 불편하고 어렵고 힘들다. 그럼에도 불구하고 필수적인 이벤트가 되어야 하는 이유가 너무도 많다. 개발자들에게 코드리뷰에 대한 이슈를 설득하고 실제 행위를 발생시키는 것은 정말 어려운일이다. 더군다나 뜬금없이 코드리뷰 이야기를 회사나 팀리더에게서 갑자기 듣는다면 개발자는 매우 불편해 한다. 그것은 매우 당연한 반응이다. 그러므로, 가능하다면 팀 세팅 초기 시부터 이 소스코드 리뷰 문화는 만들어질 수 있게 노력하는 것이 최선일 것이다.초기에 세팅된다면 그 후에 들어오는 팀원들은 자연스럽게 그 문화에 익숙해진다. 이런 일련의 작업들은 결국 조직과 팀의 단결과 협력, 향후 유지보수에 매우 긍정적인 효과를 준다.매우 당연하지만 개발자들은 팀에 소속되고 빠져나가기를 반복한다. 이를 두려워하지 않는 방법 중에 가장 먼저 선택할 수 있는 것이 바로 코드 리뷰라는 행위다. 인수인계와 유지보수를 위해서 소스코드 리뷰를 각 단계별에 배치해두고, 그 시간을 투자하는 것을 아까워하지 않도록 하자.그렇다면, 소프트웨어의 본체인 소스코드를 타인이 리뷰한다는 것이 왜 어려울까? 그것은 소스코드는 언제나 완성상태가 아니라는 점 때문이다. 개발자의 생각은 무언가 다양한 변화를 예측하고 있고, 그 상세한 준비를 담고 있다. 언제나 소스코드는 완성 상태가 아니라, 변화되어야 하는 시간의 축을 담고 있기 때문이다.하지만, 소프트웨어 품질이 중요한 현재의 시점에서 본다면, 코드 리뷰라는 행위는 정말 필수 불가결한 행위에 해당한다고 생각한다.이런 필수적인 코드리뷰는 그 형태와 범위에 대해서 팀 내부에 잘 정의되어야 한다.그래서, 보통 이 코드리뷰를 어떻게 할 것인가에 대해서 조직이나 담당하는 사람의 경우에는 명쾌한 판단 기준이 있어야 한다. 그러한 ‘판단기준’을 가져야만 명확한 리뷰될 수 있다.이를 두고, 디자이너에게는 크리틱(critique-비평)이 있고, 개발자에게는 코드리뷰가 있다고 정의한다.좋은 비평을 받고 좋은 리뷰를 하려면 다음의 3가지 원칙이 필수이다.1. 리뷰는 언제나 상호 합의가 되어진 상황에서 진행되어야 한다.2. 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지해야 한다3. 개발자 자신의 작업물에 대해서 정말 객관적으로 바라볼 수 있는 작성가가 선정되어야 한다.특히, 소프트웨어 코드는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면, 리뷰는 그 방향성을 상실하게 된다. 그중에 특히, 정량적인 검토와 기본적인 규칙들은 가능한 자동화하고, 소스 형상관리 도구에서 기본적인 것들의 규칙들을 지키도록 권장하여야 한다. 최소한 이 정량적인 것만 자동화하고 규칙화해도 소프트웨어의 품질은 급상승한다.하지만, 코드는 논쟁을 발생시키고, 어떤 것이 우선적인지에 대해서 서술하기 매우 어렵다. 이러한 점은 정성적인 부분에 대해서 검토할 때에 고민하자.코드리뷰의 정도는 어느 정도 해주어야 하는가?그 전부터 주목하는 개발 방법론의 추세는 ‘테스팅’을 주로 하고, SRS와 같은 요구사항에 집중하기 보다는, TDD와 같은 방법으로 완성 산출물을 높이는 방법을 현재에는 주로 사용하고 있다.그것은 과거에는 요구사항을 통해서 결과물이 완성되는 SI성 개발이 주로였다면, 현재에는 요구사항은 계속 변화하고 버그 없는 결과물이 중요시되는 테스트를 얼마나 더 집중적으로 하느냐에 따른 웹서비스의 시대이기 때문에 그 방향성은 시대에 따라서 변화를 많이 하였다. 그래서, 슬프지만, 당장의 성과물을 위해서라면 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 고속 개발하고 테스트를 통해서 버그를 찾은 다음 수정하는 것이 ‘특정 기능들을 나열하고 기능을 만족하는 소프트웨어’의 경우에는 테스트 주도 개발 방법이 가장 적합하다고 할 수 있다.물론, 이러한 방향성이나 전체적인 틀에 대해서는 아키텍트가 잘 결정하여야 한다. 내가 속한 개발 결과물이 어떤 결과물이냐에 따라서 이 방법은 혼용되어져서 사용되어야 하기 때문이다.하지만, 이번 글의 주목적은 코드리뷰. SRS중심이건, TDD중심이건. 코드리뷰는 중요하다는 것을 강조하고 싶다. 특히, 코드리뷰는 ‘기능 나열’이 아닌, 어느 정도 이상의 복잡도나 코드 품질이 필요한 경우에는 필수적으로 수행하는 것이 매우 현명한 행동이다.물론, 코드리뷰 행위가 불필요한 업무들도 많다. 정해져 있는 단순한 업무를 수행하는 경우에는 굳이 할 필요 없다. 국내에서 SI를 하는 경우에는 대부분 코드리뷰가 필요 없는 업무를 하는 소프트웨어 개발자들이 절대 다수인 경우도 많이 보았다.일반적인 SI의 형태라면 워크 스루의 형태만 적합하다. 특정 도메인에 매몰되어 있고, 처리방법이 명쾌하기 때문에, 해당 경험들을 교환하는 것으로도 충분하기 때문이다. 그리고, 자동화된 테스트 수행방법을 최대한 갖추어두는 것이 가장 현명하다.그러므로, 코드리뷰는 어느 정도 솔루션이나 서비스 등을 고려하고 있는 곳에서 더욱 적합하다고 정의한다.코드리뷰는 특정 제품이나 서비스를 발전적으로 지향하고 있는 경우라면 필수적으로 선택해야 한다. 하지만, 일부 제품의 경우에는 발전적인 지향이 굳이 필요 없는 제품 라인업을 가진 경우에도 굳이 수행할 필요 없다.그 경우에는 선택적인 코드리뷰를 지향하면 된다. 비용상의 문제 때문에 굳이 코드리뷰를 억지로 진행할 필요는 없는 경우도 많다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들고, 통과시키는 것으로써 충분한 신뢰를 가지면 충분한 경우가 대부분이다.특히, 시장이 고착상태이거나, 특별한 변화의 폭이 없다면, 그 정도로 충분한 경우가 된다. 다만, 글로벌 서비스나 웹서비스 등의 지속적인 확장이 필요한 경우라면, 코드리뷰는 필수라고 할 수 있다.코드리뷰가 필요 없는 경우 체크리스트는 다음의 5가지 정도를 체크해보자.1. 특정 도메인만 다루는 팀이나 회사의 개발팀인가?2. 지난 2~3년 정도 솔루션이 크게 변한 것이 없으며, 향후로도 기업이나 팀에서 투자가 없을 예정이다.3. 현재 개발자들이 해당 솔루션에 대한 개발일을 5년 이상하고 있다.4. 기능 위주의 SI성 업무를 주로 처리하고 있으며, 복잡한 알고리즘은 존재하지 않는다.5. 비용과 일정상 개발팀에게 리소스 투여가 불가능하다위의 사례에서 1개 이상이라도 체크된다면, 코드리뷰는 성립하기 힘들다. 대부분 단념하고, TDD나 테스트 케이스를 가능한 많이 축적하여 소프트웨어 품질을 올리기를 권장한다.코드리뷰가 필요한 경우의 체크리스트도 다음의 5가지 정도를 체크해보자.1. 다국어와 시장이 다변화된 환경에서 소프트웨어가 구동되어야 한다.2. 코드의 복잡도가 높으며, 단순 기능 나열의 요구사항이 아니라, 소프트웨어 아키텍처가 별도로 구성되기 시작하였다.3. 사용자의 경험성을 증가하기 위하여 매우 많은 변화가 예측된다.4. 현재 개발 중인 서비스는 중단 없이, 지속적으로 발전되어야 하는 서비스이다.5. 목표 요구사항이 계속 변화하고 있고, 프레임워크를 지향하여 소프트웨어 품질의 요구사항이 매우 중요하다.위의 케이스에서 하나라도 해당이 된다면, 코드리뷰는 매우 효과적으로 소프트웨어에 의미 있는 결과물들을 얻어 내기 위한 좋은 방법이 된다.하지만, 다음과 같은 경우도 같이 고려하여야 한다.코드리뷰의 정도와 질에 대한 검토 리스트의 최소 체크리스트는 다음의 3가지이다. 물론, 이 정의는 조직 내의 아키텍트나 아키텍트 롤을 하는 사람이 결정하는 것이 좋다.1. 실험적인 코드인가?2. 1~2명 이상이 공동으로 작업하는 코드인가?3. 향후 버려질 가능성이 높은 코드인가?코드리뷰를 하지 않는 경우에는 해당 코드의 repository나 디렉터리를 완전하게 분리하고, 리뷰가 안된 코드를 명쾌하게 구분할 수 있어야 한다. 그리고, 그 정보는 팀 전체에게 공개되어야 한다.가장 첫 번째는 코딩규칙 가이드라인의 준수 여부를 체크하는 것이다.개발자들 간의 상호 중요한 것은 스타일 가이드이다. 하지만, 정말 지키기 어려운 것 또한 스타일 가이드라고 할 수 있다. 하지만, 스타일 가이드는 가능한 준수해야 한다. 하지만, 100% 준수하려는 것은 매우 비효율적인 상황을 만들 수 있다. 하지만, 이 경우에 최소한 리뷰어가 제시하는 기준이나 변경 방향에는 대부분 수긍하는 것이 가장 현명하며, 이 부분은 해당 팀의 가장 경험이 풍부한 사람이 리드하는 것이 좋다.그래서, 소프트웨어 개발에는 경험이 풍부한 아키텍트의 역할과 선임의 역할이 가장 중요하다. 소셜에서 이야기하는 가장 중요한 포인트는 이런 경험이 풍부한 선임 개발자가 있다면, 돈이 얼마가 들더라도 ‘개발팀’에 모셔야 한다! 가 정답일 것이다.아직까지 이 부분은 ‘공학’으로 해결할 수 없고, ‘엔지니어링’과 ‘경험’에 의존할 수밖에 없다.주석의 경우에도 ‘가독성’이 충 부한 코드에는 서술할 필요 없다. 이 부분에 대해서는 꾸준한 팀원들 간에 코딩 문화에 대해서 커뮤니케이션하면서 주석의 범위에 대해서 공론화하는 것이 현명하다. 그래서, 소프트웨어 개발은 대부분이 ‘커뮤니케이션’이고 ‘소통’이다. 그래서, ‘팀워크’이 가장 중요한 것이고. 변수의 명칭에 대해서도 ‘명확’하다는 선에서 합의해야 한다.테스트가 쉽지 않은 구조는 다른 문제를 야기한다. Junit과 같은 단위 테스트 도구로 손쉽게 정의가 가능한 구조가 아니라면, 변경해야 한다.코드리뷰 후에 분명하고 타당한 지적에도 고집이 세서 변화가 없는 경우에는 한두 번 이야기하고 더 이상 변화가 없다면, 포기하고. 해당 코드를 격리하여 관리하는 것이 현명하다. 팀원들 간에 감정이 상하는 것이 더 위험하다. 사람은 변하지 않는다 감정에 대한 다툼이나 기대를 할 필요가 없다.UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공을 들여서 추상화를 실현하지 않으면, 해당 코드 때문에 프로젝트가 심각해질 수 있다. 사용자에게 더 좋은 경험을 전달하려고 하면, UI코드는 계속 변화를 일으킨다.테스트 코드 여부? 로직에 대한 검토, 변수 네이밍 검토와 레이아웃에 대한 것들? 에 대해서는 다음과 같이 판단하고 체크해보자.코드리뷰는 대부분 ‘직관’에 의존한다. 그래서, 정말 어렵고. 경험이 풍부한 사람이 할 수밖에 없다. 다만, 이러한 코드 리뷰 시의 체크리스트 항목을 몇 가지 간단하게 정리할 수 있다. 최소한의 2가지는 꼭 지키자.코드 리뷰 시의 필수 내용 두 가지는 다음과 같다.1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.2. 코드는 200라인 이상을 한 번에 검토하지 마라이 기준이 어겨지면, 리뷰어는 제대로 된 리뷰를 하기 어려울 것이다. 그리고, 이러한 리뷰를 하는 동안 기능에 대한 검토 체크사항에 대해서 나열해 보면 다음과 같이 나열이 될 수 있을 것이다.1. 시스템의 요구사항이 제대로 반영되었는가?2. 시스템의 설계의 규격대로 구현되었는가?3. 과도한 코딩을 하고 있지 않는가?4. 같은 기능 구현을 더 단순하게 할 수 있는가?5. 함수의 입출력 값은 명확한가?6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?10. 모든 변수는 사용 전에 초기화하고 있는가?11. 사용하지 않는 변수가 있는가?12. 하나의 함수는 하나의 기능만 수행하고 있는가?또한, 스타일과 코딩 가이드에 대해서고 검토하고 리딩을 해야 한다.1. 코딩 스타일 가이드를 준수하고 있는가?2. 각 파일의 헤더 정보가 존재하는가?3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?4. 주석은 적절하게 기술되어있는가?5. 코드는 잘 구조화되어있는가? ( 가독성, 기능적 측면 )6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?7. 변수와 함수의 이름이 일관되게 기술되어 있는가?8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?9. 숫자의 경우 단위에 대해서 기술하고 있는가?10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?12. 수행되지 않는 코드는 없는가?13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )14. 간결하지만 너무 특이한 코드가 존재하는가?15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?가장 중요한 아키텍처에 대한 검토를 잊으면 안 된다.1. 함수의 길이는 적당한가? ( 화면을 넘기면 안 된다. )2. 이 코드는 재사용이 가능한가?3. 전역 변수는 최소로 사용하였는가?4. 변수의 범위는 적절하게 선언되었는가?5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )6. 관련된 함수들이 흩어져 있지 않는가?7. 중복된 함수나 클래스가 있지 않는가?8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )9. 데이터에 맞게 타입이 구체적으로 선언되었는가?10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라11. Switch/case문이 중첩되었다면 이를 더 구분하라12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?14. 스택 변수를 반환하고 있는가?15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?당연하겠지만, 예외처리 관련 체크리스트도 제대로 검토해야 한다.1. 입력 파라미터의 유효 범위는 체크하고 있는가?2. 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?3. 호출 함수가 어려와 예외처리 코드를 가지고 있는가?4. Null포인트와 음수가 처리되는 구조인가?5. 에러코드에 대해서 명쾌하게 선언하고 처리하고 있는가?6. switch문에 default가 존재하고, 예외처리를 하고 있는가?7. 배열 사용시에 index범위를 체크하는가?8. 포인트 사용시에 유요한 범위를 체크하는가?9. Garbage collection을 제대로 하고 있는가?10. 수학계 산시에 overflow, underflow가 발생할 가능성이 있는가?11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?12. 에러 메시지와 에러코드가 에러의 의미를 잘 전달하는가?13. Try/catch 에러 핸들링 사용방법은 적절하게 구현되었는가?요즘 프로그램은 대부분 이벤트성으로 구동되지만, 시간의 흐름에 대한 체크는 프로그램의 뼈대를 이루게 된다. 이 부분에 대해서도 제대로 검토해야 한다.1. 최악의 조건에 대해서 고려하였는가?2. 무한루프와 재귀 함수는 특이사항이 아니라면 없어야 한다.3. 재귀 함수 사용시에 call stack값의 최댓값이 고정되어 있는가?4. 경쟁조건이 존재하는가?5. 스레드는 정상 생성, 정상 동작하는 코드를 가지고 있는가?6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?7. 임베디드의 경우에도 최적화가 매우 중요하지 않다면, 가독성을 더 중요하게 해야 한다가장 중요한 검증과 시험에 대해서도 제대로 인지하여야 한다. 그리고, 테스트를 위해서 가능한 최대한 자동화를 하기 위한 방법들을 이용해야 한다.1. 코드는 시험하기 쉽게 작성되었는가?2. 단위 테스트가 쉽게 될 수 있는가?3. 에러 핸들링 코드도 잘 테스트되었는가?4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?5. 경계값, 음수값, 0/1등의 가독성이 떨어지는 코드에 대해서 충분하게 경계하고 있는가?6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?8. 최악의 조건에서도 리소스 사용은 문제가 없는가?9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?10. 테스트를 위한 주석 코드가 존재하는가?간혹 등장하는 하드웨어에 대한 테스트도 마찬가지이다. 다음과 같은 기준들을 통해서 검토해야 한다.1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?3. 멀티 바이트 하드웨어 레지스터가 read/write오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?6. 대기모드 진입 시와 빠져나 올 때에 시스템이 옳게 동작하는가?7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?8. EEPROM손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가? ( 쓰기 동작 중 powe loss)등구체적으로 코드리뷰를 하고자 한다면, 다음의 코드리뷰에 대한 기법과 적당한 방법을 다음과 같이 설명할 수 있다.이러한 코드 리뷰를 위한 몇 가지 방법들이 알려져 있다. 그것들을 몇 가지 정리하여 보면 다음과 같다. 코드 인스펙션은 가장 정형화된 기법으로 전문화된 코드리뷰팀을 통해서 구분하는 방법이다. 이 방법은 리소스가 풍부하고, 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형 포털에서 구현 가능한 방법이라고 할 수 있다. ( 이런 곳에 있다면 행복해 하자. ~.~ ) 하여간, 비용과 일정 등이 있다면 이 방법이 현명하다. 그리고, 코드리뷰에 대한 품질에 대해서 정량적인 보고와 구성을 만들어 낼 수 있다는 것은 코드 인스팩션의 가장 좋은 장점이다. 이 코드 인스팩션을 하기 위한 롤을 구분하면 다음과 같이 4가지 롤로 구분할 수 있다.1. ModeratorA. 실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고, 프로세스에 대한 정의와 산출물의 정리를 담당한다.2. ReaderA. 각 산출물을 읽고, 리뷰하고, 방향성을 제시한다. 보통, 지식이 많은 사람이 담당한다.3. Designer/CoderA. Reader의 지시에 따라서 코드를 검증하고 잠재적인 발견 등의 수정 방안을 만든다.4. TesterA. 진행 중인 코드와 권장 수정 코드에 대해서 검증한다.그리고, 코드 인스펙션은 다음과 같은 6단계로 진행된다.1. PlanningA. 계획 수립2. OverviewA. 교육과 역할 정의3. PreparationA. 인터뷰와 필요한 문서 습득, 툴 환경 구축4. Meeting(Inspection)A. 각자의 역할대로 수행5. ReworkA. 보고된 Defect 수정6. Follow-upA. 보고된 Defect가 수정되었는지 확인이러한 절차를 통해서, 코드 인스팩션이 수행되면, 상당히 명쾌한 리뷰가 진행되게 된다. 하지만, 일정과 비용 문제 때문에 이 작업은 대부분의 스타트업에서는 선택하기 어렵다. 그래서 사용하는 방법 중의 하나가 팀 리뷰이다.팀 리뷰는 일정한 계획과 프로세스만 따르는 방법으로, 코드 인스펙션보다는 좀 덜 정형화된 방법으로 진행한다. 보통은 일주일에 한번 정도 팀 리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 하는 방법을 사용한다.또한, 위험하거나 의견이 필요한 경우에도 팀 리뷰는 유용하다. 일반적인 팀에서 사용하는 방법이다.하지만, 이 역시. ‘리뷰’에 대한 제대로 된 인식이 없다면, 적용하기 어렵다. 그래서, 가끔 사용되는 방법이고, 과거 국내 SI업체들이 주로 사용하던 방법 중의 하나가 ‘웍쓰로’이다.웍 쓰루(Walkthrough)는 단체로 하는 코드 리뷰 기법 중에 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 가지는 방법으로써 주로 사례에 대한 정보 공유나 아이디어 수집을 위해서 사용하는 방법이다.이 방법은 ‘특정 도메인’에 종속된 코드를 만들거나, 비슷한 SI성 형태의 업무를 수행하는 경우에 적합하다. 그래서, 국내의 SI업체에서는 적극적으로 사용되면 좋겠지만. 이 ‘시간’마저도 부정확하고, 갑을병정의 SI체게에서 ‘정보공유’나 ‘아이디어 수집’과 같은 커뮤니케이션이 자유롭게 일어나는 것은 매우 힘들다.이 웍 쓰루는 동일한 조직 내에서 동일한 목적의식이 분명한 팀에서나 활용이 가능한 방법이다. 웍 쓰루를 SI에서 시도한 경우에는 대부분 실패했거나, 목적의식이 다르기 때문에 불분명한 결론들이 대부분 도출되었다.대부분의 국내 스타트업이나 IT 전문기업들은 ‘리뷰’에 대해서 상급 관리자들이 제대로 허락을 해주지 않는다.대부분은 팀내에서 어떻게든 자체적으로 해보려고 한다. 그래서, 팀장의 권한 선에서 적절하게 리뷰를 하는 방법 중의 하나가 Peer review or over the shoulder review방법이다. 이 방법은 보통 2~3명이 진행하는 코드리 뷰로 코드의 작성자가 모니터를 보면서 코드를 설명하고, 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.또한, 이 방법은 신입사원이나 인턴사원의 경우에 업무 이해도를 높이면서 해당 코드를 사용할 수 있는 수준으로 활용할 경우에 의미 있는 방법이다. 문제는 이 방법은 개발자의 인력 투입이 거의 두배 이상으로 증가하는 것으로써, 고품질의 영역을 개발하거나, 빠른 시간 안에 신입 개발자의 업무 이해도를 높이는 경우가 아니라면 시행하지 않는다.이렇게도 리뷰가 진행이 되지 않으면, Passaroud는 돌려 보기 방법을 사용한다. 이 방법은 원래 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아니라, 리파지토리나 이메일 등을 사용하여 천천히 리뷰하는 방식에 해당하는데, 속도는 느리지만, 중요한 코드이거나, 제품의 기능 개선이 필요한 경우에는 아주 의미가 있다. 보통은 제품의 기능 개선을 위하여 사용하는 방법이다.이처럼 리뷰의 방법에는 다양한 방법이 있지만, 결론적으로는 어느 정도 개발 조직이 서로 커뮤니케이션하고, 목적의식을 통일하고, 적절한 시간 분배를 통해서 리뷰를 할 수 있는 시간을 만들어 내느냐가 리뷰의 핵심이라고 할 수 있다.리뷰를 통해서 소프트웨어의 품질을 끌어올리고, 개발자들과 소통하고, 방향성을 만들어 내며, 새로운 기능 개선 작업을 위해서 리뷰는 다양하게 활용된다. 어떤 관점으로 리뷰를 할 것이고, 어떤 관점으로 리뷰라는 프로세스를 개발 프로세스에 탑재할 것인가에 대해서 진지하게 고민하는 것. 그것이 아키텍트의 첫 번째 역할 아닌가 한다.