Hee's Blog

운영체제(Operating System, OS)란 무엇인가?

 * 컴퓨터 하드웨어 바로 위에 설치 되어 사용자 및 다른 모든 소프트웨어와 하드웨어를 연결하는 소프트웨어 계층 

1. 협의의 운영체제 (커널) 

 - 운영체제의 핵심 부분으로 메모리에 상주하는 부분 (좁은 의미의 개념)

2. 광의의 운영체제 

 - 커널 뿐 아니라 각종 주변 시스템 유틸리티를 포함한 개념 

 예) 파일복사 시  동작하는 프로그램 -> 항상 메모리에 상주하지 않음

운영체제의 목적

1. 컴퓨터 시스템의 자원을 효율적으로 관리

 - 프로세서, 기억장치, 입출력 장치 등의 효율적 관리 (하드웨어 자원)

  * 사용자 간의 형평성 있는 자원 분배

  * 주어진 자원으로 최대한의 성능을 내도록 하는 것

 - 사용자 및 운영체제 자신의 보호

 - 프로세스, 파일, 메시지 등을 관리 (소프트웨어 자원)

2. 컴퓨터 시스템을 편리하게 사용할 수 있는 환경을 제공

 - 운영체제는 동시 사용자 / 프로그램들이 각각 독자적 컴퓨터에서 수행되는 것 같은 환상을 제공

 - 하드웨어를 직접 다루는 복잡한 부분을 운영체제가 대행

운영체제의 분류 

* 동시 작업 가능 여부

1. 단일작업(Single Tasking)

 - 한번에 하나의 작업만 처리

 예) MS-DOS 프롬프트 상에서는 한 명령의 수행을 끝내기 전에 다른 명령을 수행시킬 수 없음

2. 다중작업(Multi Tasking)

 - 동시에 두 개 이상의 작업 처리

 예) UNIX, MS Windows 등에서는 한 명령의 수행이 끝나기 전에 다른 명령이나 프로그램을 수행할 수 있음

* 사용자 수

1. 단일 사용자(Single User)

 예) MS-DOS, MS Windows(지금은 서버도 지원하고 있음)

2. 다중 사용자(Multi User)

 예) UNIX, NT server

* 처리방식

1. 일괄처리(Batch Processing)

 - 작업 요청의 일정량 모아서 한번에 처리

 - 작업이 완전 종료될 때까지 기다림

 예) 초기 Punch Card처리 시스템 

2. 시분할(Time Sharing)

 - 여러 작업을 수행할 때 컴퓨터 처리 능력을 일정한 시간 단위로 분할 하여 사용함

 - 일괄 처리 시스템에 비해 짧은 응답시간을 가짐

 - interactive한 방식 (사용자 입장에서 이러한 느낌을 받을수 있음 => 입력하면 즉시 반응)

 - 각 사용자가 컴퓨터로부터 서비스를 제공받는 시간을 숫자로 표시함

 - 정해진 시간이 있는 것은 아님

 예) Unix

3. 실시간(Realtime OS)

 - 정해진 시간 안에 어떠한 일이 반드시 종료됨이 보상되어야 하는 실시간 시스템을 위한 OS

 예) 원자로 / 공장 제어, 미사일 제어, 반도체 장비, 로보트 제어

3-1. 실시간 시스템의 개념 확장

 - Hard realtime system(경성 실시간 시스템) * 마감 시간을 맞추지 못하면 엄청난 손해가남 ( 공장 제어, 미사일 제어 등 )

 - Soft realtime system(연성 실시간 시스템) * 마감 시간을 맞추지 못하더라도 치명적이지 않음 ( 영화 상영 1분에 60 프레임 )

* 범용적인 운영체제 = 다중 작업 + 다중 사용자 + 시분할 방식

용어 정리 

1. Multitasking

 - CPU에서는 매 순간은 하나의 작업만 진행됨 

 - 동시에 진행되는 것처럼 보임

 - 하나의 프로그램이 끝나기 전에 다른 프로그램을 실행시킬 수 있음

2. Multiprogramming

 - 메모리에 여러 프로그램이 올라가는 방식 (메모리 중점)

3. Time sharing

 - 시분할 시스템임을 강조 (CPU 중점)

4. Multiprocess

 - 여러 프로그램 동시 실행 

* 위 4가지 용어는 유사한 의미를 가짐

5. Multiprocessor

 - 하나의 컴퓨터에 CPU가 여러개 붙어 있음을 의미

 - CPU가 여러개라는 뜻 (하드웨어)

운영체제의 예

1. 유닉스(Unix)

 - 초기에는 어셈블리어로 작성했지만 너무 복잡해져서 언어를 만듬 -> C언어

 - 코드의 대부분을 C언어로 작성

 - 높은 이식성 

 - 초창기에는 소스코드를 공개 했음

 - 최소한의 커널 구조 

 - 복잡한 시스템에 맞게 확장 용이

 - 프로그램 개발에 용이함

 - 다양한 버전 : System V, FreeBSD, SunOS, Solaris, Linux(소스코드 공개됨)

 - 멀티 테스킹 지원

 - 다중 사용자 지원

 * 안드로이드도 커널은 리눅스를 사용함

2. Dos(Disk Operating System)

 - MS사에서 1981년 IBM-PC를 위해 개발

 - 단일 사용자용 운영체제, 메모리 관리 능력의 한계(주기억 장치 : 640KB)

 * 초창기에는 640KB 이상의 메모리가 필요없을 것이라 생각 -> 발전하면서 코드가 복잡해짐

3. MS Windows

 - MS사의 다중 작업용 GUI기반 운영체제

 - Plug and Play 네트워크 환경 강화

 - DOS용 응용 프로그램과 호환성 제공

 - 풍부한 지원 소프트웨어

 - 불안정성(초기)

 - 단일 사용자(초기)

 - 단일 작업 지원(초기)

운영체제의 구조 및 기능

* 운영체제는 FIFO 구조가 아니다. -> 각 하드웨어의 특성에 맞게 효율적으로 관리됨

1. CPU 스케줄링

 - 어떤 프로그램에게 CPU를 할당할지 정하는 것 

 - 초기에는 CPU를 조금 사용하는 프로그램부터 할당하는 방식이었으나 더 효율적으로 변경됨

2. 메모리 관리

 - 한정된 메모리를 어떻게 분배할 지 정하는 것

 - 과거사용 빈도에 따라 메모리에 계속해서 올려놓을지 Disk로 보낼지 결정하는 방법이 있음

3. 파일 관리 (디스크 스케줄링)

 - 디스크에 파일을 어떻게 보관할 지 정하는 것

 - 엘레베이터와 비슷한 개념으로 동작함 -> 헤드가 가장 적게 움직이면서 효율적이게 동작

4. I/O Device 입출력 관리

 - 각기 다른 입출력 장치와 컴퓨터 간에 어떻게 정보를 주고 받게 하는지 정하는 것

 - CPU와 I/O장치는 속도가 매우 다르기 때문에 인터럽트 개념을 적용함

5. 프로세스 관리

 - 프로세스의 생성과 삭제 

 - 자원 할당 및 반환

 - 프로세스 간 협력

6. 그 외

 - 보호 시스템

 - 네트워킹

 - 명령어 해석기(Command line interpreter)

지난번 연휴 때 친구와 둘이 그동안 바쁘다는 핑계로 하지 못했던 일을 했다.

바로 자전거 여행!!

한 2주 전부터 준비 했던 것 같다.

최종 목적지인 부산 해운대에 마지막 날 숙소를 정하고

충주에서부터 출발하기로 했다.

이전부터 자전거를 조금씩 타기는 했지만 

말 그대로 `조금씩`이었고 장거리를 타는 것은 나와 내 친구 역시 처음이라 설렘 반 걱정 반으로 출발한 것 같다.

첫날 우리는 80km를 예상했고 충주에서 이화령고개를 넘어 문경(점촌)까지 가는 것이 목표였다. 

하지만 우리는 고작 27km + 충주댐( 왕복 16km )을 타고 6시가 되어 버렸고 이화령 고개를 남긴 채 수안보에서 

첫 밤을 지냈다.

생각해보면 여러 가지 문제가 있었지만, 우리가 너무 만만히 봤다는 것이 제일 컸던 것 같다. 

둘째 날에는 구미에 숙소 예약이 되어있었기 때문에 전날 못 탔던 것까지 합하여 145km를 타야 했고 

소조령과 이화령이라는 큰 고개를 넘어야 하는 부담이 있었다.

이화령에 대한 악명은 전부터 익히 들어 걱정하고 있었던지라 더욱 부담이 느껴졌던 것 같다.

우리는 아침 일찍부터 출발하였고 소조령에 다다랐을 땐 벌써 아침 8시가 넘었었다.

그러다 문뜩 자전거가 왜 이리 무겁지 생각했을 때쯤에 소조령을 넘고 있었던 것 같다.

아.. 이게 소조령 고개구나.. 생각하고 페달 질을 할 때부터는 아무런 생각이 없어졌다. 

머릿속이 정말 깨끗하게 비워지는 신기한 경험을 한 것 같다. 

숨이 턱까지 차오르고 다리는 멈추지 않기 위해 굴렀다. 

조금이라도 멈췄다가는 다시 오르지 못할 것을 느끼면서 조금씩 조금씩 올랐던 것 같다.

내리막길은 정말 무섭지만, 꿀맛 같았고, 올라올 때의 힘듦이 보상되고도 남을 만큼 상쾌했다.

그 상쾌함에 탄력을 받고 텐션을 올리고 있을 때쯤에 

여기가 이화령이구나!!! 온몸으로 느끼게 되었고 또 아무 생각이 없어졌다.

정상까지 남은 거리를 보면서 한 발 한 발 구르기를 반복하는 것 외에는 

프로그래밍에 대한 생각, 앞으로의 진로에 대한 생각, 게임에 대한 생각, 걱정 등이 모두 머리에서 사라졌다.

사실 자전거를 타면서 제일 힘들지만 동시에 제일 큰 장점이 업힐 아닐까 생각한다.

우리는 결국 둘째 날 145km를 모두 타고 구미에 있는 숙소까지 도착했고, 

엉덩이와 허벅지가 아파서 자리에 앉지도 못한 채 서서 바베큐 파티를 했다.

이후에 우리는 셋째 날 비를 맞으며 자전거를 탔고 

넷째 날에는 155km를 타면서 부산, 정확히는 낙동강 하굿둑에 20:00PM 에 도착했다.

우리는 3박 4일간 총 450km를 종주하였고 소조령, 이화령, 다람제, 박제고개 등 5개의 고개를 넘었다.

이것 말고도 정말 많은 일이 있었지만, 정말 정말 가길 잘했다는 생각이 든다.

많은 것을 느끼고 배웠으며 

그것들로 인해 앞으로 더 많은 것이 변화될 것임을 확신하게 된 여행이 되었다.

훗날 이 글을 보며 그날들을 되새기고자 이렇게 느낀 점을 남긴다.

이상 끝.

오늘은 구글 인디게임 페스티벌에 다녀왔다.

참가자로 다녀오고 싶었으나..

군인이라는 신분으로 인해 올해는 투표자로 다녀왔다.

가기전에 많은 도움을 얻을 수 있으리라 생각했지만

생각했던 것 보다 더 많은 정보와 열정을 받아온 것 같다.

내년에는 꼭 참가자로 다녀오도록 하겠다.

오늘까지 튜토리얼 개발했고, 완료했다. 

후... 이제 캐릭터 연출 관련하여 개발을 해야할 것 같다.

다음 목표

- 캐릭터를 뽑는 연출

- 타이틀을 얻었을 때의 연출과 보상을 받았을 때 연출

- 최고기록 및 친구랭킹을 이겼을때 연출

- 일주일에 한번씩 랭킹 초기화 후 연출  

오늘은 9XD 개발자모임에 참가했다.

무려 선착순 2등을 하며 참가자격을 얻었다!! 

생각했던 것 보다 더 고퀄의 강연이었어서 좀 놀랐고 서포터가 데브여서 한번 더 놀랐다.

강연 중 생각나는 것이 데브 서버개발자 분께서 발표하신 GraphQL에 대한 내용이었는데 

페이스북 SDK를 작업하면서도 그래프 API에 대한 편함을 경험한 바 있어서 크게 공감했던 것 같다.

시간을 내어서 지금 구글에 저장하고 있는 유저데이터를 AWS의 DynamoDB 에 사용하면서 GraphQL을 이용하면 좋은 것같다.

그때를 위해 검색해본 URL을 남긴다.

GraphQL 설명 : http://blog.sapzil.org/2015/09/01/graphql-rfc/

GraphQL Parser github : https://github.com/graphql/libgraphqlparser

GraphQL Serverless framework github : https://github.com/serverless/serverless-graphql-blog

GraphQL Explorer : https://graphql-tryout.herokuapp.com/graphql?query=&operationName=undefined

이번에 작업한 것은 튜토리얼이다.

일전에 회사에서 튜토리얼 관련된 코드를 본적이 있었는데 

아무런 생각과 대책없이 튜토리얼을 구현하면 이렇게도 구현할 수 있구나 싶었다.

온갖 조건문과 예외처리 코드가 스파게티처럼 꼬여있어서 새로운 스텝을 추가하기도 수정하기도 쉽지 않았던 기억이 있다.

아무튼 이런 저런 이유로 알기 쉽고 수정과 관리가 용이하게 구현하려 노력했다. 

또 비디오나 스프라이트가 아닌, 사용자 반응형 튜토리얼을 구현하려 했다.

완벽하게 끝이 난것은 아니지만 정리해서 포스팅 해보겠다. ( 원래 리펙토링은 끝이 없기에.. )

먼저 관련 클래스는 3 가지로 나뉜다.

- TutorialManager

- TutorialStep

- TutorialHelper

간단하게 설명하자면 TutorialStep 이 모여 하나의 Tutorial이 된다.

예를들어 처음 플레이 하는 유저가 게임 방법에 대한 튜토리얼을 진행한다면 

"BEGINER_TUTORIAL"이라는 Key를 사용하는 TUTORIAL 아래 1 ~ 3의 STEP이 추가된다.

Step 1. "시작버튼을 누르세요" 라는 메시지 박스 출력

Step 2. "화면을 터치하면 캐릭터가 움직입니다."라는 메시지 박스 출력

Step 3. 유저가 화면을 터치하면 캐릭터가 움직이고 "잘하셨습니다!!"라는 메시지 박스 출력 

위와같은 방식으로 총 59 STEP으로 이루어진 BEGINER 튜토리얼을 구성했다.

또 설정 팝업에 추가하여 언제든 튜토리얼을 다시 할 수 있도록 하였다.

오늘도 퇴근한 후 약간의 버그 수정을 한 후 그림을 그렸다.

미세하지만 어제보다 실력이 좋아진듯하다(?)

행성과 어울리는 크리스탈 미사일이다.

작은 화면에서는 뭔가 알루미늄처럼 보이긴 하지만 그럭저럭 쓸만한 것 같다. 

오늘은 그림을 그려보았다. 

처음에는 어색했던 포토샵도 이제는 제법 다룰줄 알게 되었다.

물론 결과물이 만족스럽지는 않지만 점점 나아질 것으로 기대된다.

기본행성이 될 듯 하며 이제 총알과 미사일을 그리면 될 듯하다. 

1. 메뉴 화면

아이콘 부터 그림까지 하나하나 다 혼자 하려니 별거 아닌 일도 오래 걸렸다.

2. 캐릭터 선택창

일반 캐릭터의 경우 어둡게 보이고 레어 캐릭터의 경우엔 검은 음영으로 처리되어 있다.

3. 페이스북 랭킹 창

랭킹은 일주일에 한번 초기화 되는데 어디에 표시할 지 고민중이다.

4. 아이템의 기본 스텟을 올릴수 있는 창 

유아이들도 다 더미라서 바꿔야하는데... 그래픽은 다 돈이다.

5. 옵션 창

옵션창에는 오디오, 데이터 저장, 언어 선택, 획득한 타이틀 등을 확인 할 수 있다.

6. 게임을 진행하고 있는 화면이다.

좌측상단에 점수와 코인 UI가 있다.

우측상단에는 페이스북을 연동한 경우에만 플레이어의 다음 목표가 되는 친구의 점수가 위치해 있다.

7. 일시정지 화면

게임 중 달성할 수 있는 작은 목표가 중앙에 위치하며 좌측 상단에 홈으로 가기, 다시하기 버튼이 위치한다.

아래에는 게임을 종료할수 있는 버튼과 게임으로 돌아가기 버튼이 있다.

8. 결과 화면

최종 점수와 나의 최고 점수를 보여 준다.

여기까지가 지금까지 개발된 화면 구성이다.

게임 플레이도 영상으로 올리고 싶지만.. 

안타깝게도 동영상을 찍을 수 있는 형편이 되질 않아 다음을 기약 해야겠다.

앞으로 남은 계획을 한번 나열해보자.

1. 게임 중에 깜짝 캐릭터를 얻는 시스템이 있었으면 좋겠다.

2. 캐릭터를 뽑는 연출이 필요하다. 

3. 타이틀을 얻었을 때 보상을 주는 연출이 필요하다.

4. 게임안에서 스크린샷을 찍고 카톡 등으로 공유할 수 있어야 한다.

5. 최고기록을 냈을 때 연출이 필요하다.
6. 유저데이터를 암호화 해야 한다.

7. 네트워크가 연결되지 않았을 경우에 유니티 광고를 보려고 할때의 처리가 필요하다.

8. 인앱결제가 필요하다.

9. 구글 로그인시 유저 데이터를 받아오는데 로컬에 저장되어있는 정보와 다른 계정일 경우 처리가 필요하다.

10. BGM 및 효과음이 필요하다.

11. 피버 및 연속 피버가 들어가면 재밌지 않을까 생각중이다.

12. 행성마다 다른 스테이지가 존재하면 각각 클리어 하는 재미가 있지 않을까 생각중이다.

여기까지가 그동안 Wunderlist로 관리하던 남은 일정이고 이외에도 아직 더미로 사용하고 있는 데이터들이 많이 있다.

이것들도 차츰 실데이터로 변경해야 할 것 같다.

여기까지 하고 내일은 지금까지 개발한 게임의 동영상이나 스크린샷 정도는 올려도 좋을 것 같다.