Loopin's Page

다음 학기도 남아 있는 상황이라 자료 공개는 할 의도도, 할 수도 없을 것 같습니다;
현재 C로 작성된 프로그램에 대해 Garbage Collection을 삽입하여 메모리 누수를 방지하고, 감시, 운영하는
프로그램을 만들고 있습니다. 리눅스 기반이 아닌 Windows에서의 PEFormat에 대하여 수행하고,
이를 평가 및 관리하는 이론적 기준 확립에 가장 큰 중점을 두고 있습니다.

컴퓨터공학과에서 들어갈 수 있는 최저의 깊이까지 내려온 과제라 넉넉잡고 깊이 확인해봐야 할 것 같습니다.
완성은 가능할 것 같지만 이후에 많은 난항을 겪을 것으로 예측되므로 긴장하고 있는데요;
분석과 설계 중반까지는 끝낸 상태입니다. (아... 설계 초반으로 정정하죠. ㅇㅅㅇ;) 

이번 학기 수강했던 데이터마이닝의 프로젝트 내역입니다. 컴퓨터 판매에 대한 1달간의 판매내역을 중심으로,
이를 요구사항을 정해 분석하여 전략을 제시하는 것이 주요 내역이었습니다. 즉, 과목에서 배웠던 모든 내용들을
총동원하여 엮어나가는 점이 관건입니다.

과목 자체가 무척 흥미롭습니다. 일군의 데이터 묶음으로부터 숨은 관계, 의미를 추출해내는 작업입니다.
마치 규칙없이 사방으로 흩어진 퍼즐 조각을 이리저리 맞추다보니 안에 어떤 숨은 글자가 있는 것과 같은 느낌이랄까요,
그런 점이 이 데이터마이닝의 매력인 것 같습니다. 하지만 실제 적용되기 어려운 점은,

해당하는 변수들에 대해서는 하나의 기준으로 단일화되기 어렵다는 것입니다. 이들은 복합적이기 때문에,
충분히 이들을 정의했으니 이 내부에서 단서들을 찾아내겠지- 하고 단정짓기 어렵다는 것입니다.
두 번째로는 해당 데이터 셋의 수집이 어렵다는 점입니다. 비지니스에 이를 접목하려면 목적하는 데이터 그룹이
확보되어야 하는데 가볍게 통계 정보들로만 보기에는 가치가 높은 정보들이 주류라 공개되어 있는 것이 거의 없고,
수집에 시간도, 노력도, 실질적인 경제적 비용까지도 많이 들여야 할 것입니다.

어쨌건, 그런 제약사항이 있지만 이 조건만 해결된다면 내부에서 생각지 못한 관계, 추측이 가능해집니다.
분류 나무는 직관적으로 나타나는 예시여서 그렇지만 회귀분석이나, 군집 분석 등은 이 데이터마이닝 작업에 있어서
꽃과 같은 내용입니다. 덤으로 붙여보자면 분류 모형, 연관성 분석 등을 꼽아볼 수 있겠습니다.

작업 내용도 재밌었습니다.  한 팀원분과는 잊지 못할 에피소드가 생기긴 했습니다만(-_-;) 잘 해결되어 다행입니다.
고마워요, 발표자분. ^^

Objective-C 로 코딩된 내역입니다. 실제 실행은 시뮬레이터로 돌려봤습니다.
직접 설계한 DB Schema에 따라 작성된 내용은 기본 제약에 거쳐 얻은 결과입니다. 그리고 일부 쿼리는 다음과 같습니다.

select bookname, cname, bcname, authname, pubname, pubdate, popularity, stock, bookno from AUTHOR, BIGCATEGORY, WRITING, PUBLISHER, CATEGORY, BOOK where AUTHOR.authno = WRITING.fauthno and WRITING.fbookno = BOOK.bookno and BOOK.fpubno = PUBLISHER.pubno and BOOK.fccode = CATEGORY.ccode and CATEGORY.fbccode = BIGCATEGORY.bccode order by BOOK.bookno asc;

 

select userid, bookname, predictretdate from USERINFO, LENDING, BOOK where userno = fuserno and bookno = fbookno and actualretdate = '0' order by predictretdate, userid asc;

시간이 부족해서 하고 싶었던 부분들을 많이 하지 못해서 조금 아쉬움은 남습니다. 하지만 이런 욕심을 빼고 나면
초기 계획했던 내용은 모두 삽입된 것이니 나름 괜찮아요. ^^~ 

증강현실 기술과 GPS, Gyro Sensor를 이용한 SNS 서비스가 프로젝트 주제였습니다.
"Project Doodle"로 불린 내용으로 이름 그대로 피켓을 달아두는 서비스 내용입니다.
구현전 작업인 설계 단계까지만 진행하여 이 결과를 확인하는 프로젝트였음에도,
기술적 구현 가능성을 이미 검증한 내용이었습니다. 지금 구현해보라고 한다면 적당한 시간 내로
할 수 있을 것 같네요. (이번 4학년 때 스마트폰 프로젝트 경험이 도움이 되었습니다.)

위 클래스 다이어그램은 원본 파일을 잃어버려서 (방심하고 백신을 멈춰놨다가 벌어진 사태입니다...ㅠ.ㅠ)
보고서에 기재되어 있는 것을 가져왔더니 이렇게 찌그러져서 나오네요. ㅇㅅㅇ;;;

소프트웨어경진대회 장려 수상작입니다. 실제 구현까지 해보라고 했다면 장려 이상도 가능했을 것 같아요.
(물론 충분한 시간과 지금 4학년인 제 입장에서의 Objective-C 혹은 Java 경험이 뒷받침되었을 때 이야기지만요;)

마이크로프로세서 프로젝트는 두 대의 라인트레이서를 규정된 맵 위에 올려두고 랜덤하게 배치될 장애물을 제외한 나머지 영역을
순회하는 내용입니다. 두 대가 함께 순회한다는 예외사항들과, 최대한 빠른 시간 내로 탐색하는 것에 따라 성적이 결정됩니다.
디지털 논리 실습을 거치면서 임베디드 기기에 포팅하고 다뤄보았지만 실제 포팅된 기기에 모터가 달려서 직접 운행되는 것을
보는 것- 무척 색다른 경험이었습니다. 그런만큼 애먹은 부분도 많았고요.
 

직접 부품에 대해 조립 및 포팅하고 알고리즘을 적용한 코드를 이용하여 최고 효율을 찾아내기 위한 작업들은,
여지껏 경험해본 컴퓨터정보공학 커리큘럼과는 조금 거리가 있는 내용이었기 때문에 더 느낀 바 많았던 것 같습니다.

사실 맵은 고정, 장애물 위치만 임의로 주어질 뿐 그 크기와 개수는 고정이었기 때문에 이를 예측하여 하는 방법이
있습니다. 대표적인 방법으로 맵을 분할하는 것입니다. 하지만 여기서 조심해야 하는 부분이 있습니다.
라인트레이서가 서로를 향해 바라보는 시점 혹은 다른 측면 센서가 다른 라인트레이서의 센서에 직선상에 위치할 경우
이를 반사한 적외선 센서로 인식해버려 장애물이 있다고 착각하는 점입니다.
치명적이게도 이 센서 자체에 대한 제어권 없이 Read만 되는 형태이기 때문에 더더욱 난감한 것이죠.

그러면 맵 분할은 불가능한가? 아닙니다. 두 대의 라인트레이서를 서로 엇갈려 순회할 알고리즘으로 4분할 하는 방법이
있습니다. 그래서 서로 맵 탐색 시간동안 두 라인트레이서를 대각 방향에 엇갈려두면 서로 마주칠 일이 없고, 두 대 모두
해당 Area의 탐색이 끝났을 때 맵의 끝 부분으로 돌아가 지나가도록 하는 방법이 있습니다. (뭐 조금 가까워진다면
다른 쪽 라인트레이서의 센서를 완벽히 감추는, 그러니까 거꾸로 돌린 형태로 두는 방법이 있습니다.)

하지만 이 방법은 일부이지만 Time lose가 발생합니다. 동시에 범용성 있는 알고리즘이라 하기 힘듭니다. 때문에,
우리 팀은 이 제약사항을 무시하고 어떤 환경에서도 인식할 수 있는 범용적 성격의 패턴을 구상하게 됩니다.
'개미'가 탐색하는 방법으로부터 고안한 인공지능적 접근으로 해결하였습니다. 때문에, 오히려 위 4분할 방법보다
 더 시간 손실이 큽니다. 하지만, 어디에나 적용될 수 있으니 이것으로 가자 - 라는 것이 팀의 판단이었습니다.

대부분의 팀들이 2분할 방법으로 이 문제를 해결하였습니다. 분명히 예외사항으로 장애물의 사이즈가 2분할의 한
영역을 모두 덮을 수 있습니다. 얼마든지 교수님께서 그렇게 지시하신다면 순회가 불가능해질텐데 - 하지만 교수님께서
그렇게까지는 안 하시더군요;;;

결과는 좋았습니다. 기록상에서 1등은 아니었지만 범용성에 대해 인정받았다 생각합니다.

제목은,
"블링크 ~ 샤프 찾기 대모험 ~" 입니다. 본격적인 게임을 만들었습니다. 시나리오 작업까지 이뤄졌고,
현실 세계를 풍자했습니다. (.....)

상태, 데이터과 같은 기본 골격 구조에 대한 Design을 함께 설계했습니다. 직접 해보면서 느꼈지만 이 골격을 구성한다는 건,
전체 프로그램 구조를 이해하고 있어야 가능한 일입니다. 하지만 이번 프로젝트는 처음 배우는 OpenGL 라이브러리에 대한
것으로, 가벼운 그림 그리기조차 버거웠던 제가 3D 게임을 원활하게 설계한다는 것이 조금 무리였다고 생각됩니다...만.
다행히 팀원들 도움과 어우러져 이룰 수 있었네요.

퀄리티 덕에 팀 성적에서 1위였습니다. (ㅎㅎ)
 

프로젝트는 아닙니다. 오히려 그 다음 학기인 4학년 1학기 때의 "데이터베이스 실습" 과목이 본격적입니다.
이 때는 기초적인 내용을 학습한 후 이를 C 코드에 삽입하는 형태로 작성된 프로그램입니다.
프롬프트창에서 커맨드를 입력하는 방식으로 된 녀석이라 투박해보이지만 어플리케이션의 운용보다
내부 DB Schema와 이용했던 SQLite를 어떻게 이용하느냐에 달려 있었던 내용입니다.
 

나름의 예외처리도 삽입된 내용입니다;;;
이후 디비 실습 때는 UI도 간략히 삽입됩니다. 

프로젝트 스케일에 있어서 가장 컸고, 많은 시간을 공들였던 내용으로 기억합니다.
시기가 어쩌다보니 맞아떨어져서 기말고사 이후에 집중할 기회가 있었을 거예요.

 
담당했던 부분은 서버 설계, 동기화 조정, 암호화 컴포넌트 설계였던 것으로 기억합니다. 아, 짧게나마 오프닝 동영상을
만들기도 했습니다! ....하지만 제가 담당했으니 미적감각에 무리가 좀 있었지 모르겠네요.
방대한 리소스 확보와 인터페이스, 애니메이션 작업은 팀 동료들이 맡아주었습니다. 코드량이나 노력으로 따져봐도
잘 배합되었던 팀 구성이었습니다.

암호화 부분은 당시 배웠던 정보보호론의 내용을 적용시켜 구현한 내용이었고요, 서버 부분은 돌렸던 단말기가 넷북 환경이었기때문에 더 많은 양의 접속이 발생하면 버벅거리더군요. 서버 설계 후 이 테스팅 및 디버그를 제가 해야 하는 부분이라 이런
작은 부분까지도 많은 신경을 써야 했습니다.

기획부터 시작해서 디자인, 구성, 설계, 아이디어, 리소스 확보 등 전방면으로 노력한 완성형 프로젝트라 말씀드릴 수 있습니다.
많은 테스팅으로 프로그램 완성도도 매우 높았고요.

프로젝트는 아니었고, 가산점이 부여된 일반 개인 과제였습니다.
DES 알고리즘의 동작형태를 이해하고 직접 코딩하면 되는 내용으로 위 캡쳐 화면이 결과화면입니다.
초기설계부터 완성까지 약 4시간 걸렸는데 컴포넌트별 분리하고 통합하는 과정을 끝내고 실행했을 때
단번에 돌아가는 프로그램을 보면 그 짜릿함은 이루 말로 다 할 수 없습니다.

조금 더 스케일이 커졌다면 이야기는 달라졌겠지만요. (-_-;) 

GeekOS는 OS 수업에 있어서 학생들이 직접 이를 구현해보고 이해할 수 있도록 제공되는 프로젝트 타입 학습물입니다.
각 Step별로 구현해나가는 단계가 점진되는 방식입니다.

사실 이를 정확히 학습자세로 구현한다는 것은 커널에 대해 깊은 이해가 있는 것과 동시에 이런 이론적인 내용이 이 코드상에선
어떻게 유도되었는지를 파악하여 해당 위치에 대해 구현하여야 합니다. 어셈블리 단계까지 함께 봐야 하는 케이스도 더러 있기에
만만하지 않은 내용이었죠.

개인적으로는 ELF Format을 다뤘던 Project 1 때 제일 고생했던 것 같습니다. 실제 구현되는 양이 가장 적었음에도 해법을
찾지 못해 가장 우왕좌왕 했거든요.

다른 전공과목이 진행되는 것과 함께 이 많은 내용이 한 학기에 진행되다보니 밤도 많이 샜습니다. 

2009년 말 수강했던 윈도우즈프로그래밍의 프로젝트 과제가 그림판을 만드는 것이었습니다. 바로 전 학기 때는 QT에서 만들었던 객체 방식의 그림판과는 달리, MFC를 이용하여 실제 비트맵 방식의 그림판을 설계한 것으로 보다 그림판에 가깝고, 그 이상의 임팩트를 줘야 했던 내용이었습니다.
위 그림이 그 결과인데요, 다소 투박해보이는 디자인은 공돌이들의 기본 소양이었으니 넘어가고요,(ㅇㅅㅇ;;;)
왼쪽에는 그림 작성에 쓰이는 도구와 필터 효과 색상 정보 표현 및 선택 등이 있고요,
오른쪽에는 작성한 내역에 대한 히스토리가 설정되어 있습니다.

팀은 세 명으로 구성되었고, 전 아이디어 도출 및 선택, 색상, 대화상자 등의 기본 및 부수 요소들을 구현했습니다.

히스토리 구현의 차이는 이전 객체 방식에서는 그린 객체의 작업 하나하나를 단위별로 구분하여 해당 작업 내역에 대해 지정된 구조체에 저장시켜 이를 Undo 혹은 Redo 하는 방식이었는데요, 비트맵 환경에서는 작성된 내역을 구조체로 보유하기에 한정된 정보로는 무리한 부분이 있어 다른 방식을 택했습니다.

여러 독특한 기능들과 함께 전 학기 때 배웠던 멀티미디어 이론을 바탕으로 필터 기능을 구현했다는 점이 크게 가산점으로 작용한 것 같습니다. 발표도 무난하게 잘 되서 최고점을 받았었습니다.

디지털 논리 실습 프로젝트는 2가지였습니다.
처음 것은 FPGA에 디지털 시계를 구현하는 것이었습니다. 구현 자체의 어려움을 떠나서
정확한 분주 구성과 많은 테스트를 통해 시간 흐름과 동일한 클럭 주기를 잡아주어야 한다는 점이 어려웠습니다.
왜 코딩하다보면 그런 것 느끼잖아요, "분명히 문제가 없는 소스인데 왜 포팅해서 돌리니까 안 되는거지?"
임베디드 분야의 흥미로운 부분이자 단점으로도 말할 수 있지요.

이 시계를 마치고 학기말 프로젝트로 부여받은 것이 MU0 Design입니다.
컴포넌트의 구성은 맨 윗 그림과 같고요, 컨트롤 유닛의 상태도표가 두 번째 그림입니다.
만약 프로젝트가 바쁜 기말 기간에 2주간이라는 제약된 기간이 아니었다면 두 번째 그림의 도표가 주어지지 않고
직접 구현하는 방향으로 나왔을지도 모르겠어요. 저 부분의 상태값들이 왜 그런 것인지, 어떠한 흐름을 갖는지를
이해하는 것이 이 프로젝트의 첫 번째 핵심이거든요.

마지막 그림은 수행한 결과입니다. 예제로 주어진 인스트럭쳐에 대해 수행하면 그림과 같은 결과를 갖게
되는데요, 두 번째 핵심이 이 같은 결과가 나오게 되는 메모리 참조 흐름입니다. 물론 첫 번째 핵심이나 두 번째나
마찬가지의 공통집합을 갖습니다.

정확한 이해를 기반으로 컴포넌트를 구분하여 설계한 뒤 통합하면 되는데요, 이 설계에 모호함이 포함되거나
인터페이스 정의에 문제가 있었다면 Integration 작업에서 꽤나 애먹어요.

제가 속한 팀은 이 문제로 골머리를 앓다가 한 명이 담당하는 편이 빠르겠단 결론을 내리고 홀로 뛰어들었습니다. (ㅋㅋㅋ)
팀원의 요구내용을 파악하고 Bottom-up Approach 로 연결하였는데, 이전의 실패를 교훈 삼아 사전 정의를 명확히
해두었더니 이 부분의 에러는 없었습니다.
비록 날을 새야 했지만 완성하고 나니 좋더군요.

어셈블러로부터 목적코드가 만들어지는 과정을 이해하고 이를 C 코드로 작성하는 프로젝트였습니다.
모든 어셈블러 명령어를 소화하는 것은 아니었고 일련의 범위 제한은 있었지만, 이건 구현하는데 있어서
일부 반복적인 작업들이 줄었다는 의미이지, 전체적인 구조와 흐름을 이해하고 처리 방향을 만들어내는 것과는
거리가 있는 이야기입니다.

당시 C++을 배웠습니다. 그래서 구현 언어가 특별히 C로 한정된 것이 아니어서 C++ 문법을 이용한 코드를
만들었는데 객체지향 언어인 C++을 이용한 절차지향적 프로그램이 만들어졌지요. (-_-;;)

이 정도 학부생이라면 객체지향의 개념에 대해 학습하지만 막상 이를 자기 것으로 소화하고 활용해야 한다는 점에선
많은 어려움이 따릅니다. 이는 설계 관점에는 더욱 거시적으로 바라보고, 직관적으로 이해할 수 있기엔 무리가 따르기
때문이기도 합니다.

약 2주간 진행 되었습니다. 대부분의 프로젝트 마감 및 최종검사(혹은 발표)가 기말고사 기간과 오버랩되기 때문에
2주 중의 한 주 가량은 사실상 작업에 매진했다고 보기 어렵고요, 1주일 가량은 학교 휴게실에서 넷북을 조원들이 서로
꺼내들고 노숙하다시피 작업했던 것으로 기억합니다. (수면은 집에서... 하지만 주말은 모조리 반납하였지요.)

초반 Pass1의 설계 때 이후의 작업을 고려하여 설계하는 부분을 담당하고 Pass2 또한 지원할 예정이었습니다.
하지만 이 당시 느꼈던 분량 많은 코드에서 느껴지는 울렁증 덕에 Pass1 설계를 마치고 Pass2 에서 큰 도움이 되진
못한 것 같습니다.  다행인건 Pass2에서 그대로 활용할 수 있도록 함수 입출력을 유용하게 설계한 점을 위안 삼았지요.

"울렁증"은 다행히 여기까지로 그쳤습니다. (이후 설계 과목들을 더 접하면서 점점 익숙해지더니 무리 없어지더군요.)
당시 팀워크도 상당히 좋았고, 조원 구성도 알맞게 이뤄졌습니다. 서로 잘 도와 무사히 마친 프로젝트로 좋은 성과를
거두었습니다. 

당시 복학한 후 처음으로 수행한 프로젝트였습니다.
해당하는 과목은 객체지향 프로그래밍(Object-Oriented Programming)으로,
C++ 언어와 함께 객체지향 개념을 배우는 커리큘럼에 입소문으로만 들어오던(-_-;) 리눅스를 설치 및 활용해보고
QT를 이용한 그림판 작성 프로젝트가 요구되었지요.

본론으로 들어가기 전에 여담 하나만 늘어놔 볼께요.
리눅스 개념을 전혀 모르던 내게 상세한 지침 없이 (물론 스스로 학습할 수 있도록 개략적인 안내는 있었습니다.)
설치 & 활용의 과제는 그렇다고 쳐요... 문제는, 당시 삼성 NC10 넷북을 구매했던 제게 파티션을 건드리지 않고
무선랜 드라이버와 한글 입출력 문제는 생각지도 못한 난제였습니다. 무려 주구장창 5일간 허비.
학교 실습실 컴퓨터 뒤의 유선랜을 이용할 수 없었다면 치사하게 MAC 어드레스에 케이블 망 사용 허가를 했던
집의 인터넷 상황 덕에 더 큰 고비를 맞이했을지도요.

어찌어찌해서 리눅스 환경을 갖춰놨더니 이번엔 QT... 문법은 C++과 거의 동일했지만 기본 구조를 전혀 모르는
탓에 애먹었습니다. (생각해보면 이 프로젝트 덕에 스스로 학습하며 성과물을 체크해보는데 익숙해졌던 것 같네요.)

비트맵 방식이 아닌 객체 방식(Microsoft Office 군의 PowerPoint의 그림들과 같은 속성)으로 완성되었습니다.
기본 구현 사항인 도형 작성, 파일 저장 및 불러오기, 색상 부여 등에
추가 기능으로 도형 선택, 이동, 크기 조절, 정렬, Redo & Undo 등이 구현되었고요.

투박한 디자인 덕에 성능 또한 같이 평가절하 받을 것 같지 않나요? 물론 성능과는 별개였으니 다행이지요.
그리고 안타깝게도 디자인을 제가 제의했던 것 같네요. (당시 미적감각을 발휘할 여유가 없었다고 작게 변명해봅니다. ㅠ.ㅠ)

아쉬운 점은 코드 상의 초반 기본 틀(설계 수준까지는 아닌)과 일부 구현에 그치고,
코드 분량이 커짐에 따라 내가 제 역할을 못한 것 같아요.
후반 작업은 통합쪽으로 임무를 달리했으나 그마저도 버벅거렸던 탓에
1000줄 이상의 코드에 내가 울렁증이 있는 게 아닌가 걱정했던 때이기도 합니다.

다행스럽게도 같은 팀원들이 이런 부분을 커버해준 덕에 최종발표에서 좋은 성과를 얻을 수 있었습니다.
결론짓자면, 이 프로젝트를 통해서 뚜렷한 목적을 지닌 실무적 첫 팀활동으로 경험과, 팀워크의 장점,
제가 엔지니어로서 부족한 부분이 어떤 것인지 파악할 수 있었던 유익한 과정이었어요.