전체 피드 목록

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법¶Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부¶페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조¶비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조¶비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스¶비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId);Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser();user.setNickname("Alice");user.setGender(Gender.FEMALE);user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId);getDatastore().put(userKey, user);user = getDatastore().get(userKey);getDatastore().delete(userKey);또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something }}Secondary Index 구현 방법¶HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기¶각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

제가 몸담고 있는 에듀테크 기업 바풀이 운영 중인 소셜러닝 애플리케이션 바로풀기에서 2016년 9월 6일 저녁 자동답변 기술이 탑재된 바로풀기를 버전 업데이트했습니다.‘자동답변’ 기술은 바풀 김영재 CTO를 포함한 3인 프로젝트 팀의 쾌거였는데요. 인프라와 한글엔진, 이미지처리엔진 개발은 김영재 CTO가, 바풀에 완전히 합류하기 전부터 자동답변 팀의 일원이 되어 수식엔진과 딥러닝 개발은 오형석 개발자가, 제대로 인식돼야 할 문제들을 선별하고 인식 결과를 평가하는 등 데이터품질검증은 바로풀기 수학 참고서를 직접 집필하기도 한 박태균 연구원이 맡아서 진행했습니다. 2년이라는 길다면 길고 짧다면 짧은 시간 끝에 바로풀기 자동답변 ver.1을 서비스에 배포하고 시연 영상을 바로풀기 페이스북에서 처음 공개했을 때 반응은 실로 뜨거웠습니다. (아직도 뜨겁습니다. 하하)바풀 페이스북 https://www.facebook.com/bapulmath/videos/1288610331158212/특히 관련 업계 종사자들의 뜨거운 관심과 과분한 찬사를 받았는데요. 도대체 자동답변이 뭔데? 질문 올리면 인공지능이 대답해줘? 아니면 사람을 수백 명쯤 고용해서 막 다 풀어줘? 궁금해하시는 분들을 위해, 아니 사실은 곁에서 인고의 시간을 지켜봤지만 사실 그들이 2년 동안 대체 뭘 한 건지 궁금했던 저(바풀 PR 담당잡니다) 자신의 궁금증 또한 해소하기 위해 김영재 CTO와 간단한 인터뷰를 진행했습니다. (스압 주의)Q. 우리가 개발 초기부터 ‘자동답변’이라고 불러왔지만, 실제로는 학생들이 찍어 올린 문제를 풀어서 자동으로 답변을 구해주는 기술은 아니다. ‘자동답변’을 한 마디로는 어떻게 정리해볼 수 있을까.기술적인 답을 원하느냐, 이해하기 쉽게 포장하기를 원하느냐.쉽게 말하자면, 딱 찍고 딱 올리면 (답이) 딱 나오는 거다. 기술적으로 최대한 간단하게 풀어보면, ‘학생이 질문 사진을 찍어 올리면 20여 단계를 거쳐서 사진 속 수식, 글자, 이미지를 인식하고 그 결과를 즉시 기존 바로풀기 답변이 있는 100만 개의 기존 DB에서 똑같은 질문을 찾아서 보여주는 기술’이다. 답변이 이미 달려 있으니까 똑같은 문제를 찾았다면 ‘자동답변’이 되는 거고, 똑같은 문제가 우리 DB에 아직 없거나 인식의 문제로 찾지 못했다면 유사한 문제를 찾아서 보여준다. 유사한 문제이므로 풀이를 보고 질문한 문제의 답을 구하는 데 힌트를 얻을 수 있을 것이다.Q. 듣기로는 이미지를 인식한 결괏값을 기존 DB와 비교해서 같은 걸 찾는 2~3단계 정도의 기술 같은데 20여 단계를 거친다니, 그중에 가장 중요한 과정이 뭔가.가장 핵심은 ‘수식과 평문’ 두 개를 온전히 인식하는 것이다. 예를 들어 방정식 문제에서 x라는 이미지가 인식됐다면 이건 수식일 수도 있지만 평문일 수도 있다. 이걸 수식으로 보고 결과를 찾을지, 평문으로 보고 결과를 찾을지를 결정하는 과정에서 검색 결과의 정확도가 좌우될 수 있기 때문이다. 지금까지 등장한 기술은 수식만 인식하거나, 평문만 인식하거나 둘 중 한 가지만 가능했지만 바로풀기 자동답변은 이 두 가지를 동시에 인식하여 구분해낼 수 있고 현재 이 기술을 갖고 있는 건 국내에서 바풀이 유일하다. 아마 전 세계적으로도 거의 없는 것으로 알고 있다. 전 세계적으로 드문 이유는 수식이 아닌 수학 문제를 인식하는 것이 공학자들이 해결해야 할 문제의 우선순위에서 높지 않았기 때문이기도 하다. 하지만 우리에게는 최우선이었다.Q. 수식과 평문을 구분해내는 게 그렇게 어려운 일인가.인식할 텍스트의 베이스라인(기준선) 때문이다. 평문 안에 수식이 들어가는 순간 기준선이 달라지는데 우리 팀은 처음부터 달라지는 상황을 가정하고 수식엔진을 설계했기 때문에 기존의 접근방식보다는 훨씬 더 수학 문제 인식에 최적화된 방식이었다고 본다.자동답변 과정Q. 자동답변 기능이 실 서비스에 적용된 지 2주 정도 됐다. 지금까지의 반응은?아직은 100% 똑같은 문제를 찾아내고 있지는 않다.(6:4 정도로 6개가 똑같은 질문, 4개가 유사한 질문) 2년 간의 노력이 드디어 공개된다고 생각하니 긴장이 되기도 했고 인식 품질과 속도에 대해서는 지금도 계속해서 개선 작업을 하고 있기 때문에 별다른 공지 없이 자동답변 기능을 앱에 추가했다.그런데도 2주 만에 2,800명의 이용자들이 7,000회 정도 자동답변 기능을 이용했고, 완전히 다른 문제인지(1점), 힌트가 되는 문제인지(2점), 완전히 같은 문제인지(3점)를 체크하도록 했더니 평점 평균이 2.41점 정도로 예상보다 높게 나왔다. 다만 개발 과정에서 충분히 많은 문제들을 실험해봤다고 생각했는데, 실제로는 훨씬 더 다양한 질문이 들어오고 있는 상황이다. 물론 질문 수준을 예측하지 못한 건 아니지만, 품질은 예상하지 못했기 때문에 인식할 수 있는 품질 수준을 더 올려야겠다는 생각이 들었다.Q. 품질 수준을 올리겠다는 얘기가 나온 김에, 그렇다면 지금 자동답변 팀이 머릿속에 그리고 있는 ‘자동답변’의 완성형은 어떤 모습인가?최종적인 그림은 물론 문제를 찍으면 완전히 똑같은 문제가 최우선으로 나오는 것이다. 그래서 지금 하고 있는 작업은 인식 결과가 빠르고 정확하게 나오도록 하는 것인데, 지금 처리 시간이 최저 사양 기준 4초 정도로, 앞으로 2초대로 줄이려고 한다.역시 OCR 기술을 이용하고 있는 바로단어장의 경우는 처리 속도가 1초 정도였는데, 영문보다는 수식이 들어간 이미지 인식이 더 오래 걸릴 수밖에 없지만 2.5초 정도를 목표로 하고 있다.Q. 빠르고 정확하게.. 원래 정확하게 하려면 오래 걸리고 빨리 하려면 정확도가 떨어질 수밖에 없는 것 아닌가.그래서 어렵다. 지금은 엔진이 수식엔진, 평문엔진, 이를 합치고 관장하는 통합엔진 등 3가지로 나눠져 있는데, 셋 사이의 통신도 느리고, 각각이 하는 일도 복잡하다. 노하우가 좀 더 쌓이고 패턴을 알아내면 각각의 시간도 줄어들고, 때로는 두 개의 엔진을 하나로 합치는 것도 가능해질 수 있다고 본다.앞으로도 질문과 답변은 끊임없이 쌓일 거고 우리 팀의 노하우 또한 축적될 테니 이걸 통해서 정확도를 높이면서도 속도는 줄여나가는 것이 목표다.Q. 바로풀기 페이스북을 비롯해 CEO, CTO의 페이스북에 자동답변 영상 론칭에 대한 소식이 올라갔을 때 대부분은 응원과 격려를 보냈지만, 일부에서는 학생들이 숙제 해결에 악용하는 게 아니냐는 우려의 목소리도 있었다. 자동답변을 만든 진짜 이유가 뭔가. 자동답변 기능이 완성되면 이제 바로풀기는 ‘특정 학생이 모르는 게 뭔지’를 알 수 있게 된다. Knowledge Tracing이 가능해지는 것이다. 모르는 문제를 계속 찍어 올리기만 해도 Knowledge Tracing이 가능하다.교육적 관점에서는, 이 기술만이 현재 우리나라 수학교육의 문제를 해결하는 첫 단추라고 생각한다. 현행 수학 교육은 한 학기에 1천 문제 넘는 유사문제 반복 풀이로 패턴 학습을 강요한다. 반복 풀이에 대한 관성과 노동집약적인 숙제 만으로 시간을 보내도록 하는 교육 문제를 해결하고 싶다.Q. Knowledge Tracing이라면 이미 다른 곳에서도 많이 구현해낸 기술이 아닌가.그게, 차이가 있다. 기존의 Knowledge Tracing은 제공하는 곳에서 설계한 방식대로 그들이 만든 문제를 풀어야만 파악이 가능했는데, 우리는 말 그대로 ‘노매드’다. ‘학습자가 모르는 문제’만 찍어 올리면, 많이 찍어 올릴수록, 우리는 자동으로 Knowledge Tracing이 가능하다.이렇게 해서 어떤 사람이 뭘 모르는지를 알게 되면 이를 활용하는 서비스를 만드는 파트너사에 제공할 수도 있고 우리가 직접 학습 곡선이나 학습 이력을 케어하고, 개별 맞춤 강의나 지도를 제공할 수도 있다.한 사람이 우리 서비스에 ‘모르는 문제’ 데이터를 많이 쌓을수록 학습자 본인보다 우리가 더 학습자의 수준을 잘 파악해 핀포인트 러닝을 제공해줄 수 있게 된다. “넌 인수분해를 해야 해.” -> “넌 이 사람이랑 공부해야 해.”를 통해 1:1 맞춤지도를 제공하는 바풀공부방으로 연계해줄 수 있다.바풀공부방은 처음부터 이런 생각에서 출발했다.첫 번째는, 바로풀기에서 서로 친해진 사람끼리 1:1로 수업할 수 있게 해주자.두 번째는, 바로풀기에서 가공된 데이터와 지식을 활용해 공부방에서 활용하게 해주자.Q. 서비스 출시 후 다양한 업계로부터 다양한 반응이 있었다. 기억에 남는 것들을 정리해본다면?자동답변이 ‘어떤 어떤 기술’로 구현된 것일 거라고 넘겨짚는 부분들이 있는데 그건 실제의 30% 정도도 되지 않는다. 글자 인식과 딥러닝을 썼을 거라고 많이들 추측하는데 틀린 것은 아니지만 그건 현재 우리 기술에서 없어도 될 만큼 중요하지 않은 요소다.또 ‘손으로 쓴 것도 인식해서 똑같은 문제를 찾아주냐?’고 많이들 묻는데 안 된다. 앞으로도 할 생각이 없다. 우리는 계산기를 만드는 것이 아니고 우리의 철학과도 맞지 않다.우리 기술의 핵심은 ‘문제에서 데이터를 뽑아내고(엔지니어링/인식), 그 문제를 이용하는 유저들로부터 지식 추적을 한다(지식 구축)’는 것이기 때문이다.Q. 앞에서도 잠깐 언급했지만 자동답변 기술이 완성되면 숙제 해결 도구로 전락해 오히려 학생들이 수학 공부를 제대로 하지 않을 것이라는 지적이 있었다.할 수 있는 지적이라고 본다. 자동답변이 되면 문제를 깊게 고민하고 풀지 않고 검색해서 답만 찾으려 할지도 모른다는 우려를 할 수 있다. 하지만 우리가 자동답변 기술을 개발하면서 고민하는 지점, 던지는 지점도 결국은 같은 것이다. 우리가 그리는 그림은 단순히 정답만 빠르게 주는 게 아니다. 우리는 오히려 이 기술을 통해 ‘선생님들의 역할’에 대해 질문을 던지고 요구를 하게 될 것이라고 생각한다. 특히 기존 학원들은 잘 팔리는 문제집을 교재로 선택해 숙제 많이 내주고 무조건 문제를 많이 풀게 하는 방식으로 지도해온 게 사실이다. 그간에는 숙제가 정말 도움되는 학습방법이라고 생각해서 숙제를 많이 내줬다기보다는, 한 선생님이 관리할 수 있는 학생수를 항상 넘겨왔기 때문에, 다수 학생을 관리하기 용이한 방식으로서 숙제를 택해왔다고 본다. 따라서 이런 것들을 자동답변이 대체해버린다면 학원에서는 더 이상 이런 방식의 수업을 할 수 없을 것이다.앞으로는 선생님들도 수학을 어떻게 가르쳐야 할지 고민하게 되고 역할까지 바꾸게 되지 않을까. 아이들이 특정한 문제에 대해 좀 더 깊이 고민하고 생각하면서 풀 수 있도록 지도하게 될 거라고 기대한다.Q. 처음부터 ‘자동답변’을 목적으로 연구와 개발이 시작됐기 때문에 ‘자동답변’이라고 부르고 있기는 하지만 2주 정도 테스트 기간을 거쳐보니, 검색 결과를 얻은 유저 중 82%가 답을 받았고 이중 완전히 같은 문제와 답을 결과로 받은 사람은 10명 중 6명. 아직 4명은 유사 문제를 통해 힌트만 얻어가고 있는 상황인데, 기대하는 수준의 ‘자동답변’은 언제쯤 가능할 것으로 보나.1년 내로 가능할 것으로 본다. 우리는 이에 관해서는 국내 최고의 팀임을 자부한다. 어차피 이 문제를 해결해야 한다고 생각하는 곳이 우리 외에는 거의 없기도 하다.Q. 현재는 수학만 가능하다. 다른 과목에도 적용할 계획이 있나.물론이다. 다른 과목에도 적용한다면 다음은 영어, 한국사 순이 될 것 같다. 영어의 경우 이미 ‘바로단어장’으로 검증과 준비가 돼 있고 영어가 인식이 더 쉽기도 하다. 다음으로 한국사를 생각하는 이유는, 한국사 학습자들의 욕구가 유사문제를 반복해서 풀어야 할 필요가 많기 때문이다. 공부 방식 자체가 많은 문제를 풀고, 단 한 문제의 결과에 따라서 당락이 오락가락하기 때문에 검정시험이나 공무원을 준비하는 수험생에게 우리가 실질적인 도움을 줄 수 있을 것 같다.Q. 마지막으로 하고 싶은 말이 있다면예전에 구글이 도서관 정보를 모두 DB화 했을 때도 논란은 있었지만 결과적으로는 모든 사람이 양질의 정보에 쉽게 접근할 수 있도록 한 것이었고 그 기술 자체가 잘못된 건 아니라는 데 어느 정도 합의를 이루었다고 본다. 파장을 일으킨 건 기술 그 자체이고 그걸 앞으로 어떻게 활용할지 기술 등장 이후의 흐름을 어떻게 만들어 가느냐가 우리의 몫이다.바풀이 하려는 게 ‘유저’에겐 Knowledge Tracing을 돕는 것이고, ‘찍어 올린 문제들’에게는 메타 콘셉트 데이터를 구축하는 것이다. 메타 콘셉트 데이터를 구축하면, 문제 하나가 갖고 있는 여러 가지 개념들을 묶어주고 분류할 수 있게 되는데, 특히 유저가 직접 참여해서 만드는 참여형 메타 콘셉트로는 새로운 콘텐츠를 기획하는 데 무척 유용하다.앞으로도 우리는 이런 식으로 교육 방식이나 철학에 대해 끊임없이 질문하고 변화시키고 또 변화된 교육 방식에 우리의 기술과 노하우를 전달하려고 한다.사실 현재로서 제일 뿌듯한 것은, 그 밑에 깔린 기술이 얼마나 복잡한 것이든 관계없이 유저들이 보는 화면에는 귀여운 부엉이가 뛰어놀고 있다는 것이다(문제 검색에 걸리는 3초 정도의 시간 동안 바로풀기의 캐릭터인 부엉이 ’바로'가 날갯짓을 하는 애니메이션이 나온다) 설득력 있고 친절한 기술, 하나의 인격체 같은 기술을 만들겠다는 것이 가장 중요하게 생각했던 부분이고 그래서 이렇게 부엉이를 매개로 유저와 만난다는 것이 솔직히 가장 기분 좋다. 구글에서는 비둘기가 검색 결과를 찾아준다면 우리는 부엉이가 풀이와 답변을 다 찾아준다.이용자들끼리 ‘와 신기하다. 이거 어떻게 하는 거야?’ ‘부엉이가 해준대.’라고 대화하는 장면을 상상하면 흐뭇하다.그렇습니다. 정말 부엉이가 찾아주는 거예요. #둠칫두둠칫바로가 수학문제 풀이와 답을 바로 찾아드립니다#바풀 #솔루션 #바로 #에듀테크 #인사이트 #기획 #인사이트 #서비스소개 #서비스