개발 피드 목록

오픈서베이 이건노 CTO(이하 폴)는 훌륭한 개발팀의 첫 단추로 ‘일단 매출이 나는 서비스 만들기’를 꼽는 현실주의 개발자입니다. 돈을 벌어야 생존 가능한 환경이 갖춰지고 이때부터 좋은 팀에 대해 고민을 할 수 있다면서요. 동시에 모두가 즐겁게 일하며 공동성장할 수 있는 팀이라는 이상을 꿈꿉니다. 지속가능한 서비스는 지속가능한 개발팀에서 비롯되는데, 즐겁지 않은 업무 환경에서는 그런 개발팀이 나올 수 없다고 믿기 때문입니다. 이런 현실주의적 몽상가는 주니어로 입사해 개발 조직 리더까지 지낸 이스트소프트에서의 경험으로 오픈서베이 개발팀을 리빌딩합니다. 구성원 모두가 즐겁게 일할 수 있는 환경을 위해 폴은 어떤 고민과 노력을 했을까요? 오픈서베이 이건노(폴) CTO 폴, 안녕하세요! 안녕하세요. 스타트업은 처음이라 직원 간 출퇴근 시간도 다르고 영어 이름으로 불리고 하는 게 익숙하지 않았는데, 17년 4월에 조인해서 벌써 만으로 2년째 다니고 있네요(웃음). 오픈서베이 개발팀을 총괄하고 있는 폴입니다. 현실주의적 몽상가의 오픈서베이 합류 계기가 궁금합니다(웃음). 경영진 미팅이었어요. 저는 주변 후배들이 이직 고민할 때도 그 회사의 경영진을 꼭 보라고 이야기하는 편인데, 제가 오픈서베이에 조인한 결정적인 계기도 하이(황희영 대표)와의 미팅이었어요. 하이를 만나보니 제품에 대한 애정이 정말 크다는 걸 느꼈어요. 대표가 제품에 애정이 많다는 뜻은 정말 하고 싶은 일을 한다는 의미잖아요. 사실 제품에는 관심 없고 주식, 엑싯 이런 거만 고민하는 대표도 있거든요. 그런데 하이처럼 제품에 애정이 정말 많은 대표가 있는 회사라면 저도 정말 믿고 다닐 수 있겠다고 생각했어요. “대표가 제품에 애정이 많다는 뜻은 정말 하고 싶은 일을 한다는 의미라고 생각해요” 현재 개발팀 구성은 어떻게 되나요? 오픈서베이 개발팀은 현재 프로젝트 매니저 3명, 프론트엔드 개발자 2명, 백엔드 개발자 4명, 그리고 앱 개발자 2명까지 총 11명으로 구성돼 있어요. 최근 회사가 빠르게 성장하면서, 올해는 개발팀도 여러모로 성장하는 한 해가 될 것 같아서 기대됩니다. 팀이 성장하면 어떤 변화가 생기나요? 기업의 규모는 천차만별이지만 업무의 범위는 크게 다르지 않아요. 그러다 보니 인원이 적은 스타트업은 한 명이 얕고 넓게 일하는 구조인데, 회사가 성장하면서 직원이 늘면 각 구성원의 역할을 좀 더 세분화하고 전문화할 수 있게 돼요. 오픈서베이 개발팀도 기존에는 프로젝트 매니저가 기획·QA 등 다양한 역할을 모두 소화했다면 최근에는 좀 더 한 분야에 집중해서 깊게 일하는 식으로 역할의 변화를 주고 있어요. 그래서 서비스 기획자·백엔드 개발자·QA 엔지니어 등 다양한 직군을 채용하고 있고요. 오픈서베이 개발팀의 채용 정보를 알고 싶다면? (링크) 조셉(김경만 오베이 PM) 인터뷰를 보면, 개발팀 세미나 제도를 통해 긍정적인 영향을 많이 받은 것 같아요. 사실 세미나 자체가 주니어 개발자의 발언 기회를 위한 제도예요. 개발자는 스스로 제품이나 기술에 대해 주도적으로 고민할 때 역량이 극대화된다고 생각해요. 그런데 주니어 시절에는 아무래도 고민의 결과를 제품이나 기술에 반영하기 힘들죠. 세미나는 이런 갈증을 느끼는 주니어가 좀 더 의욕적으로 일할 수 있는 창구를 제공하기 위해 도입했어요. 구성원분들 덕에 우리 개발팀에는 잘 적용됐지만, 무작정 도입만 한다고 알아서 잘 작동하진 않는 것 같아요. 세미나가 주니어에게는 동등하게 업무 커뮤니케이션을 할 기회지만, 시니어에게는 사실 귀찮고 번거로운 일이 될 수 있거든요. 해왔던 대로 하는 게 편하다는 생각도 들 수 있고 새로운 기술을 팀에 적용하는 과정에서 드는 리소스도 크고요. 주니어 관점일 때는 생각지도 못했는데 이야기를 들어보니 그렇네요. 사실 저도 마찬가지예요. 저도 CTO이기 전에 개발자니까 주니어 개발자의 신선한 아이디어나 최신 기술을 업무에 적용해보고 싶은 마음도 있어요. 주니어분들의 세미나를 통해 저도 새롭게 배우는 점이 많아요. 그런데 CTO 입장에서는 이를 도입했을 때 우리 제품이나 업무 환경에 어떤 영향이 미칠지를 계산하지 않을 수 없어요. 좋아 보인다고 무작정 도입하면 문제가 터졌을 때 대처할 준비가 안 된 거니까 부담이 너무 크거든요. 그래서 이런 제도는 신중하게 도입하고 모든 구성원이 꾸준히 노력해야 잘 유지되는 것 같아요. 저도 간혹 이런 데서 내적 갈등이 생길 때마다 세미나 제도의 긍정적인 영향을 생각하며 이겨내는 편이에요(웃음). 실제로도 팀 업무 환경 개선이나 기술 수준 향상에 많은 도움이 되고 있고요. “주니어에게도 고민 내용을 공유할 기회를 주려고 해요. 개발자는 주도적으로 제품을 고민할 때 역량이 극대화되거든요” ‘코드리뷰’도 비슷한 제도라고 들었어요. 맞아요. 코드리뷰는 제품이나 소프트웨어의 변경사항을 체계적으로 관리하는 형상 관리의 일환이기도 해요. 오픈서베이 개발팀은 각 개발 담당자가 코드를 업데이트하면 슬랙에 자동으로 알림이 와요. 그럼 구성원들은 자유롭게 코드를 열어보고 의견을 내는 거죠. 여기서 담당자가 놓친 오류나 실수를 점검해 주거나, 더 효율적이고 경제적인 코드에 대한 의견을 주고받기도 해요. 그럼 코드리뷰는 보통 어떤 식으로 진행되나요? 마이너한 코드는 비대면 방식으로 온라인에서 수시로 리뷰를 진행하는데, 메이저한 코드 업데이트가 있을 때는 따로 회의를 열어서도 해요. 경우에 따라 방식은 다르지만 적극적으로 진행하려는 편이에요. 코드리뷰 제도를 도입하고 장려하는 이유는 명확해요. 개발자는 여럿이 함께 일할수록 시너지가 난다고 생각하거든요. 개발자 개인의 실력이 아무리 좋아도 본인이 작성한 코드의 오류나 실수를 다 잡아내기는 힘드니까요. 코드리뷰 자체가 구성원들이 의견을 주고받으면서 시스템 전반을 두루 이해하고 배우는 과정이기도 해요. 탄탄한 개발팀은 한명의 개발자가 하나의 시스템을 맡는 게 아니라 여러 구성원이 여러 시스템을 보조하는 구조거든요. 그래야 특정 담당자가 공백일 때 다른 구성원이 대신 문제를 처리해줄 수 있고, 개인의 부담도 줄어드니까요. 개발팀의 조셉과 로빈이 코드리뷰 중인 화면 그러다 자칫 잘못하면 서로의 감정을 상하게 하거나, 주니어를 향한 시니어의 훈육 공간으로 전락할 수도 있을 것 같아요. 그래서 어떤 제도가 좋다고 해도 무턱대고 받아들이면 안 된다는 생각을 해요. 도입에 앞서 서로 인신공격을 하면 안 된다거나 리뷰 내용은 공개된 채널에서만 주고받아야 한다는 등의 세세한 규칙을 정할 필요가 있어요. 코드에 대한 의견이 상대방을 헐뜯으려는 게 아니라 제품 개선과 모두의 성장을 위해서라는 상호 신뢰도 충분히 형성돼 있어야 하고요. 구성원들이 서로 자극을 주거나 보고 배우면서 함께 성장하는 팀을 지향하는군요. 정확히 맞아요. 개발자는 연차나 경력과 무관하게 개인별로 역량의 편차가 좀 있는 편이에요. 하나의 팀에 똑같은 수준의 역량을 갖춘 개발자만 모여 있는 게 오히려 부자연스러울 정도로요. 그래서 서로 다른 역량을 가진 팀원들이 함께 일할 때 시너지가 날 수 있는 방법이 필요해요. 저도 예전에는 이렇게 생각하지 않았어요. 일 잘하는 개발자에게 일을 몰아 주고 그 친구가 일을 다 하게 했죠. 거기에 따라 보상도 많이 주고요. 처음에는 일이 되는 것 처럼 보였는데 그런 식으로 한두 명이 일을 많이 하니까 금방 지치더라고요. 결국 서로 도와 가면서 팀으로 일하는 게 필요하더라고요. 그렇게 생각한 특별한 계기가 있나요? 개발팀장 시절에 새로 합류한 구성원 한명이 기억나네요. 좀 독특했어요. 에러·버그 등 문제가 생기면 원인을 파악하고 해결하는 개발업무를 ‘트러블슛(Trouble Shoot)’이라고 하는데, 그 친구는 다른 구성원이 담당하는 시스템의 트러블슛도 함께 고민하는데 시간을 많이 쓰더라고요. 사실 전 그때까지만 해도 팀원은 자신에게 주어진 일을 잘하면 되고 팀장은 역량에 맞춰 일을 잘 분배해주면 된다고 생각했어요. 그래서 이 친구 모습을 보면서 왜 자기 일은 안 하고 다른 사람 일을 야근까지 하면서 보고 있을까 생각했었죠. 그런데 시간이 지날수록 팀원들의 역량과 그 친구의 역량이 동반 성장하더라고요. 그것도 눈에 바로 보일 정도로 빠르게요. 서로 자극을 주고 함께 고민하면서 결국은 팀 전체가 성장한 거예요. 서로 시너지가 났던 거죠. 그러면서 자연스럽게 성과도 잘 나왔어요. 하지만 의지만으로는 자신의 업무를 넘어서 다른 구성원의 업무를 함께 고민하기는 힘들 것 같아요. 팀에서 함께 일할 수 있는 환경을 잘 만들어 주는 게 중요했던 것 같아요. 이슈 관리, 형상 관리, 버전 관리, 테스트, 릴리즈 등 개발과 운영을 위해서 필요한 기본적인 이해가 서로 있어야 해요. 그리고 개발 업무에만 집중할 수 있게 빌드, 배포와 같은 반복적인 업무의 자동화나 운영 툴 개발과 같은 것도 중요합니다. 그리고 가장 중요한 건 서로에 대한 배려심이라고 생각해요. 이번에 도와주고 다음에 도움을 받고 하는 서로에 대한 배려가 없다면 함께 일하는 문화는 자리 잡을 수 없어요. 일이 나뉘어 있기도 하지만 결국 같은 목적으로 일하고 있는 동료와 팀이라는 것을 알고 서로 배려해 주는 거죠. “좋은 제품은 좋은 개발 환경에서 나온다고 생각해요. 그래서 좋은 환경을 만들어주고 싶어요” 레드(김승엽 개발자) 인터뷰만 봐도, 로빈(권장호 개발자)를 통해 자극을 받아 공동성장하는 모습이 인상적이더라고요. 폴은 이런 레드에게 팀장을 넘어 멘토로서도 다양한 조언을 해주려는 것 같아요. 개발팀 구성원들이 회사 안에서의 성장에 갇히길 바라지 않아요. 좋은 인연으로 만났는데 회사라는 틀 안에서 팀장과 팀원 관계로 한정할 필요는 없다고 생각해요. 틀을 벗어나면 제가 할 수 있는 조언의 범위도 넓어지고 깊이도 훨씬 풍부해지기도 하고요. 인생 관점에서 조언해줄 수 있잖아요. 그럼 반대로 저도 레드를 비롯한 다른 구성원들을 통해 많이 보고 배울 수 있게 돼요. 쉽게 가지기 힘든 생각 같은데, 폴의 주니어 때 팀장님을 통해 배우신 건가요? 아니요. 사실 저는 팀장님과의 기억이 많지 않아요. 주니어로 입사한 지 2년 만에 엉겁결에 팀장이 됐거든요. 처음에는 기존 팀장님이 갑작스럽게 자리를 비우면서 팀장 업무를 임시로 맡았어요. 이때는 인사권 같은 건 전혀 없고 그냥 팀 업무를 할당받아서 각 구성원에게 배분하는 역할만 잠깐 한다고 생각했죠. 그런데 회사에서 “이왕 한 거 너가 계속해라”라며 아예 팀장을 시켜버리더라고요. 그때는 많이 당황했어요. 저도 완전 주니어일 때라 좋은 팀장님 밑에서 이것저것 배우고 싶었거든요. 그런데 이렇게 일찍 팀장이 되면서 이젠 내게 가르쳐줄 사람이 없는 걸까 싶어서 앞이 깜깜했어요 “나도 개발 잘할 수 있는데 왜 매니저 역할을 주는 거지? 내가 개발을 잘 못 한다는 건가?”라는 삐뚤어진 생각도 했고요. 얼마나 막막했으면 구글에 ‘팀장이 하는 일’ 같은 걸 검색한 적도 있어요(웃음). 위기를 어떻게 극복했을지 궁금해요. 그 과정이 지금의 폴 인사 철학에 많은 영향을 줬을 것 같아요. 그래도 어쨌든 팀장 일을 해내야 하니까 시선을 좀 넓혀봤어요. 제게는 이제 직속 팀장은 없지만 저보다 경력 많고 실력 좋은 선배 개발자가 팀원으로 있었고, 다른 팀에 훌륭한 시니어 개발자나 선배 팀장님도 계셨죠. 시선을 넓히니 오히려 제가 보고 배울 사람이 더 많더라고요. 그분들에게 궁금한 걸 적극적으로 묻거나 보고 배우면서 중요한 시기를 잘 보낼 수 있었던 것 같아요. 그때 처음으로 깨달은 게 아닐까 싶어요. 제가 엉겁결에 팀장이 되면서 다른 많은 분들을 보면서 보고 배운 것처럼, 팀원들도 꼭 팀장이 아니더라도 다른 팀원들을 서로 보고 배우면서 긍정적인 자극을 받으며 성장할 수 있다는 걸요. ‘팀장은 팀원에게 가르쳐주는 사람이야’란 생각에 갇혀 있었으면 절대 깨닫지 못했을 것 같아요. 얘기를 해보니 정말로 저 난관을 통해서 지금과 같은 생각을 할 수 있게 된 것 같네요(웃음). “팀장과 팀원이라는 틀을 벗어나면 훨씬 풍부하게 긍정적인 자극을 주고받을 수 있어요” 폴의 경험과 고민이 결국은 팀 업무 환경이나 문화를 통해 드러나는 것 같네요. 그렇게 봐주시면 정말 고맙죠. 사실 어떻게 하면 더 일하기 좋은 회사와 팀을 만들 수 있을지는 계속 고민되는 부분이에요. 돈 많이 주는 회사가 일하기 좋은 회사라고 간단히 생각해버릴 수도 있는데, 저는 일하기 좋은 회사를 이루는 요건은 좀 더 다양한 것 같거든요. 일단 하는 일이 어떤 가치를 가지고 있고 이것을 쓰는 사람들에게 어떤 가치를 제공해 주는지 알고 있어야 해요. 그래야 내가 하는 일에서 보람을 찾을 수 있으니까요. 물론, 회사에서도 보람을 가질 수 있는 방법을 함께 고민해 줘야겠죠. 보람만으로 회사에 다닐 수 없으니 역세권 사무실, 맛있는 커피, 좋은 경영진, 좋은 팀원 등 중요한 요건들이 엄청 많은데요. 오픈서베이는 서로에게 자극을 주거나 보고 배우며 스스로 성장할 수 있는 좋은 구성원들이 많은 것 같아요. 저도 요즘 구성원들에게 많이 배우고 있습니다. 마지막 질문입니다. 좋은 팀을 위한 폴의 역할은 무엇인가요? 장점을 찾아 주는 게 저의 중요한 일이죠. 잘하는 일을 해야 역량도 극대화되거든요. 장점이 없는 사람은 없다고 생각해요. 장점을 잘 모르는 친구들이 있는데 이런 친구들의 장점을 찾아주고 또 그 장점이 회사에서 잘 발현되도록 도와주는 조력자 역할을 잘 해내는 게 제가 할 일이라고 생각해요. 좋은 장점이 잘 발현되면 개발자는 한 단계 더 성장할 기회가 생겨요. 예를 들어 초기 제품 기능을 빠르게 잘 만드는 게 장점인 친구는 신사업 중심의 일을 할 수 있게 해주면 그 역량이 잘 발현되거든요. 거기서 가치를 인정받고 탄력이 붙으면 지속적으로 좋은 성과를 낼 수 있게 되고요. 이 과정을 저는 “알을 깨고 나온다”라고 표현하는데, 이렇게 알을 깨고 나오면 좀 더 제품이 주는 본질적인 가치를 알게 된다고 생각해요. 개발자로서 일하는 가치와 방법을 알게 되는 거죠. 그런 만큼 오픈서베이의 예비 구성원분들도 좋은 자극을 받으며 성장할 수 있는 계기가 되셨으면 좋겠어요. 회사를 그저 출근해서 일만 해주고 돈을 받아가는 공간이라고 생각하면 회사 다니기가 우울하잖아요. 사람마다 얻어갈 수 있는 건 다 다르겠지만, 긍정적인 영향을 받아 성장하는 계기가 오픈서베이가 될 수 있을 것같아요. “폴과 함께 즐겁게 일하고 싶으시다면 지금 바로 오픈서베이 입사지원을 해보세요”

왜 프로그래밍에는 창의성이 필요하다고 할까요? 실제로 프로그래밍을 하다 보면 복잡한 문법을 이해하고, 암호 같은 에러를 차분히 해결해야 하니, 오히려 수학적이며 논리적인 사고가 더 필요해 보입니다. 그런데도 프로그래밍이 창의적이어야 하는 이유는 하나의 프로그램을 만드는 답이 여럿이기 때문입니다.답이 하나여도 가르치기 어려운데, 다양한 방법을 어떻게 가르쳐야 하는 걸까요? 또, 기상천외한 학생들의 코드를 보며 이해하고 교육하는 것이 얼마나 긴 시간이 필요하며 어려운 일인가요? 어디서부터 해결해나가야 할지 막막합니다.Elice 리서치 팀에서 하는 일 중 하나는 학생들의 수많은 코드 중 비슷한 타입들을 추려내는 것입니다. 코드를 몇 가지 타입으로 추려내고 나면, 선생님은 학생 하나하나의 코드를 보고 교육하는 것이 아니라, 비슷한 형태의 코드를 작성한 학생 그룹 전체에게 적절한 피드백을 줄 수 있습니다. 이렇게 그룹 전체에게 피드백을 준다면 선생님은 같은 시간에 더 많은 학생을 교육할 수 있을 것입니다.그럼 이제, 비슷한 코드를 어떻게 찾아내서 분류할지 이전 연구를 보며 알아봅시다. (현기증이 날 수 있으며, 다 이해할 수 없어도 괜찮으니 걱정하지 마세요!)지프의 법칙과 숙제 제출 패턴자연어 처리(Natural Language Processing;NLP)를 배울 때 자주 거론되는 사람이 있습니다. 바로 미국의 언어학자인 조지 킹슬리 지프George Kingsley Zipf인데, 이 사람이 만든 지프의 법칙은 자연적으로 일어나거나 생성되는 특정 정보들이 일정하게 나타내는 경향을 나타낸 것입니다. 지프는 영어로 된 텍스트를 분석하던 도중, 자주 쓰이는 단어를 순서대로 나열하면 각 단어의 빈도는 그 단어의 출현 순위에 반비례함을 찾아냈습니다. 영어에서 가장 많이 사용되는 단어 1~3위가 “the”, “of”, “and” 인데, “the”는 “of”의 약 두 배, “and”의 약 세 배의 빈도를 보입니다.이것을 수학적으로 표현하면, 일정 크기 이상의 영어 말뭉치(corpus)에 들어 있는 단어들의 개수를 전부 세서 그 단어들을 가장 많이 쓰이는 것부터 순위를 1위부터 나열했을 때, 특정 단어의 순위가 k 라면 (즉 전체에서 k번째로 많이 쓰인 단어라면) 그 단어가 말뭉치에서 쓰인 개수는 1/k에 비례한다는 것입니다. 이것을 그래프로 그려보면 다음과 같습니다. 재미있는 사실은, 여기에서 x축과 y축에 log를 씌워 보면 (이것을 log-log scale로 변환한다고 합니다.) 다음과 같은 직선 형태로 변환된다는 것입니다.이것이 도대체 숙제 제출과 무슨 관계가 있길래 이렇게 장황한 설명을 한 것일까요? 위에서 나온 지프의 법칙을 기억하시나요? 학생이 낸 숙제를 채점하다 보면 꽤 많은 학생이 비슷한 방식으로 숙제를 푸는데, 제출된 풀이 방식들을 비슷한 것끼리 묶어 분석해 보니, 이것 또한 지프의 법칙을 따른다는 것이 발견되었습니다. 예를 들어 가장 인기 있었던 풀이 방식으로 100명이 숙제를 제출했다면, 두 번째로 인기 있는 풀이 방식으로는 약 50명이 숙제를 제출했다는 뜻입니다.여기서 우리가 찾아낼 수 있는 인사이트는 무엇일까요? 첫째, 학생들의 숙제들을 비슷한 것끼리 묶을 수 있다면, 그리고 이 분류를 컴퓨터로 자동으로 할 수 있다면 조교가 채점하거나 코멘트를 할 때 써야 할 시간이 상당히 줄어들 것입니다. 둘째, 방법 서너 개에 대해서만 어떻게 채점할지 혹은 어떻게 코멘트할지에 대해 준비를 해놓으면, 그걸로 숙제 대부분을 채점/코멘트할 수 있을 것입니다. 대다수의 숙제는 몇 가지 인기 있는 풀이방식으로 만들어졌을 것이기 때문입니다.그러면 이제 다음 문제는, ‘비슷한 풀이 방식으로 푼 프로그램 코드’를 어떻게 찾아낼 것인가? 를 고민해봅니다. MIT의 Elena Glassman은 이에 대한 해법으로 Overcode를 제시했습니다.Overcode뉴스 기사나 책, 블로그 글 등 자연어로 이루어진 텍스트 데이터를 분석하고, 여기에 어떤 주제가 들어있는지 밝혀내는 연구는 많이 진행 됐습니다. 이를 위한 머신러닝 알고리즘 중 하나가 토픽 모델, Topic model 입니다(토픽 모델에 대해서는 다른 글에서 자세히 다룰 예정입니다). 그러나 토픽 모델링을 프로그래밍 문제에 실제로 적용하기는 쉽지 않습니다. 코드에 사용되는 문법이나 키워드가 자연어와 1:1로 매칭되지 않기 때문에, 기존에 자연어에서 사용되던 모델을 그대로 사용할 수 없기 때문입니다. 가령, 슬쩍 보면 무척 달라 보이는 아래 두 파이썬 코드는 사실 완전히 같게 동작합니다. 이 두 코드를 (사람들이 일상생활에서 사용하는) 자연어를 분석하는 모델로 분석한다면 제대로 된 결과를 낼 수 없는 건 당연합니다.def fibonacci(): parents, babies = (1, 1) while babies < 100 xss=removed>fibonacci()def fib(parents, babies): ‘’’ parents = 1 babies = 1 ‘’’ while True: print ‘This generation has {0} babies’.format(babies) parents = babies # set parents as babies babies = parents + babies # recursively add number of babies if babies >= 100: break fib(1, 1)Elena Glassman이 제시한 Overcode의 목적은 비슷한 로직으로 만들어진 프로그래밍 코드들을 모으는 것입니다. 이제 Overode가 어떻게 작동하는지 간단하게 소개하도록 하겠습니다. 가장 먼저 수행되어야 하는 것은 서로 다른 형식으로 쓰인 소스 코드들을 정리하는 것입니다. 소스코드 정리에는 주석 제거, 줄 및 공백/들여쓰기를 일정하게 맞추는 작업 등이 포함됩니다.Image from Overcode하지만 이 작업만으로는 충분하지 않습니다. 거의 같아 보이는 코드도 실제로 프로그램을 실행하기 전까지는 같은지 알 수 없고, 꽤 달라 보이는 코드도 실제로는 완전히 같게 동작할 수 있기 때문입니다 (여기서 같게 동작한다 함은, 결과를 같게 내는 것 이상으로 결과를 내는 중간과정이 완전히 같다는 것을 의미합니다). 다시 위로 돌아가, fibonacci() 함수와 fib(parents, babies) 함수를 살펴봅시다. 위 두 코드는 기존의 자연어 처리 기법에 따르면 완전히 다른 프로그램일 것입니다. 변수명이 달라서가 가장 큰 이유일 텐데, 사실 컴퓨터의 입장에서 변수는 어떤 값을 할당하는 공간에 불과하며, 그 공간에 어떤 이름을 붙이느냐는 중요하지 않습니다. 코드를 작성하는 것이 사람이기 때문에 공간에 편하게 이름을 붙이는 것뿐입니다. 서로 다른 프로그램에서 어떤 변수가 서로 같은 역할을 하는지, 컴퓨터가 알아내려면 어떻게 해야 할까요? (컴퓨터는 창의적이지 않습니다!)Image from OvercodeElena가 제시한 방법은 프로그램을 실행하면서 변수의 값이 어떻게 바뀌는지를 추적한 것입니다. 아래 두 코드를 보고, 한번 머릿속으로 프로그램을 실행해 봅시다. 학생 B의 코드는 for문으로 5의 3승을 계산했고, 학생 C의 코드는 while문으로 5의 3승을 계산한 것입니다. 학생 B의 코드가 실행됨에 따라 r이라는 변수가 어떻게 변하는지, 학생 C의 코드에서 result가 어떻게 변하는지 확인해보면 둘 다 1 → 5 → 25 → 125 의 값을 가지게 됩니다. 그렇다면 컴퓨터는 이렇게 판단할 수 있습니다. “B의 코드에서의 변수 r과 C의 코드에서의 result가 완전히 같은 방식으로 변하니, 같은 의미로 사용된 것이다.”Image from Overcode이제 같은 의미를 가지는 변수들을 알아냈다면, 컴퓨터는 쉽게 가장 “흔한” 이름으로 변수의 이름을 바꿔치기 합니다. 그러면 처음에 서로 다르게 보였던 코드들도 이제 같아질 것입니다.물론 이것이 다는 아닙니다. 예를 들어, 간단한 테스트 케이스들을 통해 결과를 비교함으로써 변수를 분석하기 전에 먼저 거르는 방법, 너무 흔한 변수들을 처리하는 방법 (예를 들어 완전히 다르게 동작하는 코드들에서도 반복문에서 사용되는 인덱싱 변수들은 같이 변화할 것입니다), 한 변수가 다른 의미론적으로 두 번 사용되는 경우 처리하는 방법… 등이 논문에는 더욱 자세히 적혀있습니다. 궁금한 독자들은 한번 논문을 읽어보도록 합시다.남은 문제들Elena가 제시한 방법은 위에서 보여준 예제와 같은 간단한 코드에서 꽤 잘 동작합니다. 예를 들어, 다음과 같은 문제들이 있습니다.a의 b승을 구해서 리턴하는 프로그램N번째 피보나치 숫자를 리턴하는 프로그램다항식의 미분 결과를 리턴하는 프로그램하지만 대학교에서 1학년만 넘어가더라도 이런 간단한 프로그램 과제는 내지 않습니다. 예를 들어 Elice에서 교육 중인 기초 프로그래밍/ 프로그래밍 유치원 수업을 듣는 학생들은 매우 많은 실습문제를 풉니다. 여기에서 푸는 과제들은 초반 몇 주가 지나면 이 정도의 간단한 프로그래밍 수준을 뛰어넘기 때문에, 코드가 꽤 길어지고 다양성이 생기게 되는데 이런 경우 이 방법은 잘 동작하지 않습니다.또 다른 문제는, 이 방법이 “동작하는” 코드에서만 작동한다는 것입니다. 예를 들어, 수강생들이 아직 기초 문법을 배우고 있다면? 제대로 실행도 되지 않는 코드를 만들었을 때, 비슷한 실수를 한 사람들끼리 묶어주고 싶다면? 아쉽게도 Elena가 제시한 방법은 이렇게 에러가 나는 코드에서는 동작하지 않습니다. 코드가 실행되지 않는다면 변수의 값의 변화를 추적할 수 없기 때문입니다.마치며이번 포스트에서는 학생의 제출 코드를 비슷한 것끼리 묶는(Clustering하는) 방법에 대해 간단하게 살펴 보았습니다. 학생이 낸 비슷한 답안을 모아주는 솔루션은 수학 문제 같은 단답식 문제, 혹은 영어 에세이같은 자연어에 대해서는 이미 상용화가 되어 있습니다. 영어 에세이의 경우 여러분들이 가장 친숙할 만한 상용화된 솔루션은 아마 copy detector일 것입니다.하지만 프로그래밍 코드의 클러스터링은 연구가 계속 진행되고 있습니다. 앞서 말했듯 코드에서 한 글자 한 글자가 가지는 의미가 자연어에서 가지는 알파벳과는 완전히 다르기 때문이기도 하고, 정말 실행을 해 보기 전까지는 어떻게 동작하는지 예측하는 것이 매우 어렵기 때문이기도 합니다. Elice 리서치 팀에서도 프로그래밍 코드에 대한 분석을 자동으로 수행하는 머신러닝 연구를 수행하고 있습니다. 이러한 기술을 통해 선생님이나 조교가 학생을 더욱 효율적으로 지도하고, 컴퓨터의 도움으로 지도에 아낀 시간을 한 단계 더 개인화된 도움을 주도록 하는 것이 Elice의 목표 중 하나 입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice김재원: KAIST 전산학부 박사과정 / The Lead, Elice배휘동: KAIST 전산학부 박사과정 / Frontend Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개

스토리 홈

인터뷰

피드

뉴스

타운어스 신규플랫폼을 오픈하며

우리는 비정상인걸까?

대시보드 만들다 문득,

워크로그 개발기

Android Studio JCenter 이용하기

음성 기반 인터페이스와 TPO

[인공지능 in IT] 인공지능 기업에서 하드웨어 엔지니어로 사는 법

컴공생의 AI 스쿨 필기 노트 ⑤ 베이즈 결정이론

비트윈이 사용자를 분석하는 방법 - VCNC Engineering Blog

SQS + Lambda

변화하는 웹 플랫폼 따라가기

레진 기술 블로그 - 모두를 위한 설계. 레진 웹 접근성 가이드라인.

오픈서베이 이건노 CTO가 ‘공동성장 가능해야 좋은 개발팀’이라 말하는 이유

프로그래밍에는 왜 창의성이 필요하다고 할까요?

Node.js - Event

Humans of TODAIT : 전설의 전성윤을 만나다