Ⅲ. 인력양성 성과
3. 참여학생 역량 및 만족도
다 . 기타 인력양성 성과
o 논문 연구 능력 향상
- 석사과정 학생의 논문연구 과정을 가능한 기업의 연구개발 분야와 매핑시켜 논문 지도 수행
- 총 4편의 논문 제출로 인한 논문 작성 능력 향상
- 추가로 2편 이상의 논문을 작성하여 제출 준비 중에 있음
산학협력 성과
Ⅳ
1. 산학협력 추진실적
가 . 산학협력 추진체계
1) 역할 분담 및 추진 체계
2) 협력활동 계획 o 워크샵
- 연 2회, 학생의 하계․동계 방학 기간 이용 - 업체 또는 학내 세미나실
- 산업계와 학계 서로 간 이해관계를 돈독히 하고 관점의 차이를 좁히는 의사소통의 장 마련
o 정기 세미나 개최
- 분기별 1회, 사업기간 중 총 4회 - 업체 또는 학내 세미나실
- 서비스 개발 항목과 직․간접적으로 연관이 있는 최근 기술 및 연구 동향 공유
o 월간 회의
- 매월 마지막 주 목요일
- 온라인 또는 원격 회의, 안건에 따라 오프라인 협의 진행
- 한 달 동안의 작업 진행 상황 공유, 애로 사항이나 지원 요청 사항 등 논의
o 주간 회의
- 매주 월요일
- 온라인 또는 원격 회의
- 한 주 동안의 작업 진행 상황 공유
o 기타
- 사업과 직․간접적으로 연계되는 외부 산․학 기술 세미나 및 교육이 있을 시 정보를 공유하여 함께 참석, 미참석자와 교육 내용 공유
- 기업 연구원과 학교 연구원 간 직접 의사 소통 경로(온라인 메신저, 이메일, 유무선 전화 등)를 통해, 작업 진행 중 발생하는 이슈 사항을 즉시 공유
나 . 산학협력 세부내역
o 워크샵 개최
- 각 1회씩 총 2회 진행
- 산업계와 학계 서로 간의 관점을 이해하고 신기술 개발에 대한 의사 소통의 장 마련
o 정기 세미나
- 정기 세미나를 참여기업에서 개최함으로써 학생은 기업 현장을 방문 - 세미나를 통해 최근 기술 동향을 공유하고 기업에서 필요한 기술 전수 - 총 4번의 정기 세미나 진행
그림 21. 2014.2.19. 정기 세미나
o 현장 연수
- 총 1,159 시간의 현장 연수 진행
- 현장 연수를 통한 기업 내 업무 분위기 파악 - 실무자와의 대화와 협력을 통해 실무능력 향상
o 주간 회의 및 월간 회의
- 총 33회의 주간 회의를 통해 개발 및 논문 지도
- 총 10회의 월간 회의를 통해 프로젝트 점검 및 작업 진행 상황 공유
그림 23. 2013.07.01. 월간 회의
다 . 산학협력 효과
o 저비용 인력
- 대학과 기업의 긴밀한 산학협력을 통해 중소기업에서 필요한 인력을 최소의 비용으로 단기간에 확보할 수 있다.
그림 22. 2014.4.29. 정기 세미나
o 고급인력 양성
- 지역 대학과 중소기업 간의 산학협력을 통해 기업은 제품개발에 참여한 대학원생 인력 을 미리 확보함으로써 고급인력을 안정적으로 확보할 수 있음
- 클라우드 기반 제품을 개발함으로써 기업은 새로운 비즈니스의 창출이 가능하고 학생들 은 신기술에 대한 여러 가지 지식을 확보할 수 있음
- 기업은 고급인력을 안정적으로 확보하고 대학은 졸업생의 취업률 향상에 기여함
라 . 기타 산학교류 실적
2. 참여기업 만족도
연구개발 성과
가. Open API 1) 개요
그림 25. Open API 구조도
o 본 연구과제에서는 내부 개발자가 웹 하드와 클라우드 스토리지를 이용하여 응용프로그 램을 개발하거나 다른 응용프로그램과 연동하여 새로운 서비스를 개발할 수 있게 하기 위하여 Open API를 제공하고 있다. 그림 25는 Open API의 구조도를 나타내는데, Open API는 웹 하드 API와 클라우드 스토리지 API로 구분되어 있다.
o 웹 하드 API는 클라우드 스토리지를 이용하여 개발자에게 웹 하드를 이용한 다양한 서 비스를 개발할 수 있도록 한다. 개발한 웹 하드 API의 특징은 기본적인 웹 하드 기능(폴 더 관리, 파일 관리 등) 외에 추가적으로 공유 폴더 기능과 조직도 관리 기능을 제공한 다는 것이다. 웹 하드 API는 조직도와 연계하여 사용자를 관리하며, 이들 사용자에게 권 한을 부여하여 공유 폴더 사용을 제한할 수 있다. 이 웹 하드 API를 이용하여 (주)더존 뉴턴스의 그룹웨어 제품인 bizbox와 결합시켜 다양한 서비스를 개발할 수 있다.
o 클라우드 스토리지 API는 기존 오픈스택 스위프트 API를 이용하여 개발하였다. 그 이유 는 기존 스위프트 API가 초보자 및 신입사원이 사용하기 어렵기 때문이다. 클라우드 스 토리지 API도 웹 하드 API와 같이 대용량 웹 메일 저장, 사용자 개인 웹 하드 공간 등 여러 가지 용도로 다른 애플리케이션과 결합하여 사용할 수 있도록 개발하였다.
2) 웹 하드 API 설계
o 웹 하드 API는 웹 요청을 통해 사용할 수 있게끔 개발 하였다. API를 요청하는 방식은 그림 26과 같이 모든 매개변수를 URL에 포함하는 GET 방식으로 설계하였다. 또한 요청 에 대한 결과 값은 JSON(JavaScript Object Notation) 형태로 반환된다. JSON은 경량 DATA 교환방식으로 대부분의 웹 API에서 사용하고 있는 데이터 반환 형식이다.
그림 26. (a) 디렉토리 리스트 요청 예제, (b) 디렉토리 리스트 요청 결과 예제
o 그림 26의 (a)는 웹 하드 API를 사용하여 디렉토리 리스트를 조회하는 예제이다. 디렉토 리 리스트를 요청할 때에는 사용자 인증키인 Token, 그리고 로그에 쓰일 IP 주소, 조회 할 리스트의 경로 및 종류, 공유 폴더 번호를 입력해야 한다.
o 그림 26의 (b)는 디렉토리 리스트 조회의 결과를 나타내고 있다. 전체적으로 리스트 조 회의 결과는 data와 code 부분으로 나뉘게 된다. code 부분은 조회 결과의 에러 코드로 써 에러코드를 담고 있다. 모든 데이터는 data 배열 안에 들어가게 되며 data는 디렉토 리를 조회한 사람의 ID, 요청한 디렉토리 경로, 그리고 파일리스트 배열 정보를 갖고 있 다. 파일리스트 배열 안에 있는 각 파일의 정보에는 파일의 경로(RePath), 이름(name), 크기(size), 종류(Type, 디렉토리 또는 파일), 파일 생성 시간(time) 등이 있다. 디렉토리 리스트 조회의 같은 경우에 반환되는 결과 값이 많지만, 디렉토리 생성과 같은 경우에는 결과 코드 하나만을 반환한다.
o 표 31은 디렉토리 리스트 요청 시 결과로 반환되는 에러 코드의 설계를 보여준다. 만약 에러에 대한 요청이 성공하게 된다면 시스템은 에러 코드를 0으로 출력하게 된다. 만약 에러가 발생한다면, 시스템은 각 번호에 해당하는 에러코드를 출력한다.
CODE 설명
0 성공
1 jdbc 드라이버 오류
2 DB connection 실패
3 Statement 객체 생성 실패
4 Token Table로부터 id 검색 실패
5 FileTable 획득 실패
o 그림 27은 웹 하드 API의 전체적인 모듈을 보여주고 있다. 웹 하드 API는 부서를 관리 하는 Department, 사용자를 관리하는 User, 파일의 업로드와 다운로드 등의 기능을 담당 하는 FileManager, 관리자 모드 기능을 지원하는 ManagerMode로 총 4개의 기능으로 구 성되어 있다, ManagerMode 같은 경우에는 하위 목록으로 부서를 관리하는 Department, 사용자의 로그를 기록하는 Log, 공유 폴더를 관리하는 Share, 사용자를 관리하는 User, 웹 하드의 기타 기능을 관리하는 WebHard로 구성되어 있다.
그림 27. 웹 하드 API 구조도
2) 클라우드 스토리지 API 설계
o 클라우드 스토리지 API도 웹 하드 API와 같이 웹 애플리케이션 형태로 제공된다. 웹 하 드 API의 경우 직접 API를 구현하였지만, 클라우드 스토리지 API의 경우에는 오픈스택 스위프트 API를 기반으로 개발하였다. 기존에 스위프트를 다루기 위한 API가 존재함에도 다시 개발한 이유는 스위프트 API의 사용 난이도 때문이다.
6 요청한 상대 경로가 존재하지 않음
7 해당 폴더가 이미 존재
8 디렉토리 생성 실패
9 공유 폴더 권한 확인을 위한 부서 코드 획득 실패
10 공유 폴더 권한 테이블 획득 실패
11 공유 폴더에 쓰기 권한이 없음
12 사용 기한이 지난 공유 폴더
101 필수 파라미터 null 불가
표 31. 웹 하드 API - 디렉토리 생성에 대한 에러 코드 설계
대한 예제이다. 그림 34의 (a)를 보면 기존 스위프트 API 같은 경우, 웹 URL에도 값을 넣어야하고 HTTP Header에도 데이터를 정보 넣어야 하는 형태이다. 그러나 이러한 형 태는 초보자나 신입 사원이 사용하기 복잡하여 해당 API를 이해하는데 시간이 더 오래 걸린다. 반면 클라우드 스토리지 API는 모든 URL에 매개변수를 포함시켜 초보자들도 쉽 게 사용할 수 있도록 설계하였다.
그림 28. (a) 스위프트 API 파일 리스트 요청 예제, (b) 클라우드 스토리지 API 파일 리스트 요청 예제
o 그림 29는 클라우드 스토리지 API의 전체 구조도를 나타낸다. 클라우드 스토리지 API는 계정을 관리하는 Account, 디렉토리를 관리하는 Container, 파일을 관리하는 Object 로 전체적으로 3개의 기능을 가지고 있다.
그림 29. 클라우드 스토리지 API 구조도
나. 웹 하드 1) 개요
o 본 연구과제의 당초 목표 중 하나는 크로스 브라우징을 지원하고 반응형의 웹 기반 노 드 관리 도구를 개발하는 것이었다. 그러나 내부 회의를 통해 일반 사용자들이 사용하는 웹 하드는 크로스 브라우징을 지원하고 모바일을 지원하는 웹 애플리케이션으로 개발하 고 관리 도구는 크로스 브라우징을 지원하는 웹 애플리케이션으로 개발하는 것으로 변 경되었다.
o 본 연구과제에서 개발된 웹 하드는 확장성이 좋은 클라우드 스토리지를 기반으로 개발 되어 급격하게 증가하는 사용자의 요구에 빠르게 반응할 수 있다. 또한 클라우드 스토리 지의 복제 정책을 활용하여 사용자 데이터의 일관성을 보장한다.
o 웹 하드는 공유 폴더 기능과 조직도 기능을 제공한다. 공유 폴더 기능은 다른 웹 하드 사용자와 부서에게 자신의 폴더를 공유할 수 있는 기능이며 각 사용자와 부서에게 읽기, 쓰기, 관리 권한을 부여할 수 있다.
2) 웹 하드 설계
그림 30.웹 하드 시스템 구조도
API” 장에서 소개한 웹 하드 API와 클라우드 스토리지 API를 사용하여 구현되었다. 웹 하드 시스템은 여러 개의 계층으로 나누어져 있는데, 이것의 장점은 해당 계층의 API를 다른 API로 대체하여 새로운 서비스를 개발할 수 있다는 것이다. 예를 들면 웹 하드 API 부분을 다른 부분으로 교체하여 클라우드 스토리지 기반의 서비스를 새로 개발할 수 있
API” 장에서 소개한 웹 하드 API와 클라우드 스토리지 API를 사용하여 구현되었다. 웹 하드 시스템은 여러 개의 계층으로 나누어져 있는데, 이것의 장점은 해당 계층의 API를 다른 API로 대체하여 새로운 서비스를 개발할 수 있다는 것이다. 예를 들면 웹 하드 API 부분을 다른 부분으로 교체하여 클라우드 스토리지 기반의 서비스를 새로 개발할 수 있