2018의 게시물 표시

macOS가 갑자기 부팅이 되지 않을 경우 데이터 복구 또는 백업 방법

이미지
어느날 갑작스럽게 Mac이 부팅 되지 않을 때, 그 안에 담겨진 소중한 자료들을 복구 할 수 있는 방법을 소개 합니다.

최악의 상황인 HW 문제가 있다면 소중한 자료들의 확보는 분명 어렵겠지만, OS적인 문제로 부팅이 되지 않을 경우는 다음과 같은 시도를 통해 확보가 가능할 수 있다.

Mac 제품 특히 저장 장치가 SSD인 Mac은 저장장치가 메인 보드에 장착되기 때문에 일반 노트북처럼 2.5인치 내장 저장장치를 꺼내 다른 컴퓨터에 연결할 수 없다. 이런 경우 수리 센터에 맡길 수 있겠지만, 데이터 복구는 개인 정보 때문에 지원받지 못할 수 있다.

그렇다면 어떻게 하면 될까?

바로 '외장 저장장치'에 최신 macOS를 설치 후(시동 디스크 생성과 동일), 이 외장 저장장치로부터 macOS을 부팅하여 Mac 내부에 있는 저장장치에 접근이 가능할 수 있고, 데이터도 복구를 할 수 있다.

1. MacBook 또는 iMac 하드웨어 설정 초기화(NVRAM 초기화) 사용하다가 갑자기 어느날 macOS가 부팅이 안되면 우선 머리가 하얗게 되어 아무런 생각이 없을 것이다. 부팅을 여러번 시도할 것이고, 그래도 안된다면 수리 센터를 생각해 볼 것이다. 비용도 비용이지만 소중한 내 자료를 백업 가능할지 모르겠다.
일반 사용자가 하드웨어 설정(보통 이런 설정은 NVRAM에 저장됨)을 바꾸지는 않을 것이다. 하지만 설치한 하드웨어 또는 소프트웨어들에 의해 값들이 변경될 수 있다. NVRAM에 저장되는 정보의 예를 들면 무선랜에 연결되면 다음에 다시 연결될 수 있도록 연결된 무선랜의 이름과 암호를 저장한다. 이러한 하드웨어 설정들이 동작에 일부 영향을 줄 수 있다.
이 NVRAM을 초기화를 위해서는 전원 버튼을 누른 후 바로 'option' + 'command' + 'P' + 'R' 네 키를 동시에 누르면서 약 20초 동안 유지하면 된다. 애플 로고가 두 세번 보일 수도 있고, 안 보일수도 있는데, 화면이 약간…

Jira를 사용한 Agile 개발 방법 #1 - 주요 용어 정리

이미지
Agile 개발 방법론을 사용하다보면 정말 내가 사용하는 방법이 맞을까? 라는 생각이 들 수 있다.

사용자 스토리, 작업, 버그, 에픽 등 용어들이 나오면 헷갈리기 시작한다. 여기서는 자주 사용하는 기능들에서 일반적인 용어들을 정리해서 Agile 개발 방법을 이해해 보자.

백로그(Backlog)
문제(Problem) Jira Software에서는 사용자 스토리(User Stories), 작업(Tasks) 및 버그(Bugs)를 "문제(Issues)"로 정의한다.

사용자 스토리(User Story)의미
사용자 스토리는 가장 작은 작업 단위로 제품 소유자(PO, Product Owner)가 스케치하면 전체 제품 팀이 세부 요구 사항을 공통적으로 결정한다. 이 요구사항들은 스토리와 곧 나오는 스프린트을 위한 구현 항목을 정의하는데 도움이 되는 세분화 된 작업이다.

백 로그의 각 사용자 스토리에는 기능 코드와 자동화된 테스트 코드가 모두 필요하다. 테스트 팀이 자동화 테스트를 수행하는 동안 일부 팀이 개발자에게 기능 코드를 할당하지만 단일 엔지니어가 전체 세트를 제공하는 것이 더 효과적이라는 것을 알게되었습니다.

형식
As a {type of user}, I want {goal} so that I {receive benefit}.

예제
고객으로서 작년 예산을 돕기 위해 작년에 구매한 항목을 볼 수 있도록 계정을 만들 수 있기를 원합니다.

Agile 추정(Agile Estimation)의미 첫 번째 스프린트를 시작하기 전에 백 로그의 스토리를 예측하여 작업 완료까지 걸리는 시간을 결정하는 것이 중요하다.
그렇다면 애자일 추정이란 무엇인가? 전통적인 소프트웨어 팀은 일, 주, 달 등의 시간 형식으로 작업 시간을 추정했다. 그러나 많은 Agile 팀은 Story Point로 전환했다. Story Point는 피보나치 수열(0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 ..)과 같이 작업의 상대적인 노력으로 등급을 매긴다. 직관적으로 들리지…

CORS(Cross Origin Resource Sharing, 크로스 도메인) 이슈

최근 케이블 통신사와  클라우드 서버간 연동 과정에서 CORS(Cross Origin Resource Sharing, 크로스 도메인) 이슈가 발생했다.

케이블 통신사에서는 STB의 기능들이 브라우저에서 동작하기 때문에 우리가 구축한 서버에 연동을 위해서는 CORS가 우리 서버에서 허용이 필요하다는 의견을 줬다.

그래서 CORS가 무엇인지 확인하고, 보안 이슈가 없는지 등을 검토 해 봤다.

CORS(Cross-Origin Resource Sharing)란 무엇인가? CORS는 한 도메인에서 로드되어 다른 도메인에 있는 리소스와 상호 작용하는 클라이언트 웹 애플리케이션에 대한 방법을 정의한다
최신 웹 브라우저들이 보안상의 이유로 JavaScript나AJAX로 외부 Host로 접속하는 것을 차단하기 시작했다. 그래서 JavaScript는 보안 측면에서 Same Origin Policy 정책을 둬서 자신이 속한 동일 도메인내에서만 서버 요청을 허용하고, 다른 도메인의 서버 요청을 차단한다.
이 문제를 해결하기 위해 CORS가 제안 되었으며, AWS 등 많은 Public Cloud에서도 지원하기 시작했다.
CORS 표준은 브라우저와 서버에 그들이 권한을 가진 원격 URL을 요청할 수 있는 방법을 제공하는 새로운 HTTP 헤더를 설명한다. 일부 유효성 검사 및 권한 부여는 서버에서 수행 할 수 있지만 일반적으로 이러한 헤더를 지원하고 부과하는 제한 사항을 준수하는 것은 브라우저의 책임이다. 
CORS의 종류는 4가지가 있다. Simple RequestPreflight RequestCredential RequestNon-Credential Request Simple Request Simple Request는 세 가지 조건이 있다. GET, HEAD, POST 중 한 가지 방식을 사용해야 함POST일 경우 Context-type이 아래 셋 중 하나를 만족application/x-www-form-urlencodedmultipart/form-datatext/plainCustom …