웹진 게시판 페이지

6

오래 전
2024.07.14

오래 전

"윈도우 vs. 전문 도구" 삭제 또는 손상된 SD 카드 직접 복구하는 2가지 방법

SD 카드는 사진, 영상 및 문서 저장에 필수적인 도구지만, 손상되면 데이터 손실 가능성이 매우 높아진다. 그러나 항상 파일 복구에 큰 비용을 들일 필요는 없다.

손상된 SD 카드를 비용 없이 복구하는 방법 2가지를 정리했다. 이 4가지 방법을 따르면 중요 데이터의 액세스 권한을 되찾고 SD 카드 손상에 따른 문제를 극복할 수 있다. 손상된 SD 카드를 복구하고 싶다면 데이터를 되살리는 올바른 해결책을 찾아보자.

우선 숨겨진 파일을 확인하고, 윈도우에 기본 내장된 명령어를 통해 손상된 SD 카드 복구를 진행할 수 있다. CHKDSK 명령은 손상된 SD 카드를 복구하고 귀중한 데이터를 복구하는 데 도움이 되는 윈도우 내장 유틸리티다. CHKDSK 명령으로 SD 카드를 스캔하여 오류를 자동으로 수정할 수 있다.

1. 카드 리더 또는 어댑터를 사용하여 SD 카드를 컴퓨터에 연결한다. 윈도우검색 표시줄에 "cmd"를 입력하고 엔터키를 눌러 명령 프롬프트를 연다.

2. 명령 프롬프트에서 "chkdsk [드라이브 문자]: /f"([드라이브 문자]를 SD 카드에 할당된 실제 문자로 바꾸자)라고 입력한다. 예를 들어, SD 카드에 드라이브 E가 할당된 경우 "chkdsk E: /f"를 입력하고 엔터키를 눌러 프로세스를 시작한다.

3. CHKDSK 유틸리티가 SD 카드에서 오류를 검색하고 복구를 시도할 것이다. SD 카드의 크기와 손상 정도에 따라 오랜 시간이 걸릴 수 있다. 인내심을 갖고 기다리자.

4. CHKDSK 프로세스가 완료되면 SD 카드에서 파일에 액세스할 수 있는지 확인한다. 손상이 경미한 경우 CHKDSK 명령이 SD 카드를 성공적으로 복구한다.

최고관리자
8

5

오래 전
2024.07.14

오래 전

무시하면 안 되는 ‘SSD 사망’ 전조 증상 10가지

오늘날에는 일부 저가형 크롬북을 제외한 거의 모든 최신 컴퓨터가 기본 데이터 저장 형식으로 SSD를 사용한다. 최고 성능을 위해 데스크톱과 노트북에 최고의 SSD를 장착하기 위해 많은 조사를 한 경험이 있을 것이다. 하지만 SSD의 수명은 영원하지 않다. 성능과 내구성이 수년에 걸쳐 향상되긴 했지만, TBW(terabytes written) 등급이 인상적이고 보증 기간이 긴 제품도 언젠가는 수명이 다하기 마련이다.

수명이 다하기 전에 미리 알 수 있는 방법이 있다. 여기서는 SSD 수명이 다했다는 것을 알려주는 몇 가지 주요 경고 신호와 이에 대해 할 수 있는 조치를 알아본다.

우선 SSD가 죽어가고 있다는 의심이 조금이라도 든다면, 이 글의 나머지 부분을 읽기 전에 가장 먼저 데이터를 백업해야 한다. 죽은 SSD에서 데이터를 복구할 수 있지만 쉬운 일은 아니며, 100% 복구를 보장할 수 없고, 시간이 많이 걸리며, 막대한 비용이 들 수 있다. 중요한 작업 파일, 사진, 동영상, 게임 저장 파일 등을 잃어버리는 위험을 감수하지 말자. 백업은 그만한 가치가 있다.

최고관리자
9

4

오래 전
2024.07.14

오래 전

“자바 정책은 엄격하게” 오라클, 대기업으로 라이선스 감사 확대

오라클이 2023년 초에 자바 라이선스 모델을 변경한 후 라이선스 관련 정책의 고삐를 바짝 죄고 있다. 더레지스터(The Register)의 보도에 따르면, 지금까지 오라클은 주로 중소기업에 자바 라이선스 신고를 요청했지만, 이제 대기업까지 대상을 확대하고 있다.

오라클은 2023년 1월 말에 기존의 "자바 SE 구독" 및 "자바 SE 데스크톱 구독" 라이선스 모델을 대체하기 위해 "자바 SE 유니버설 구독"을 도입했다. 개정된 자바 모델의 새로운 점은 사용자 기업이 더 이상 실제 자바 사용자 또는 프로세서만 라이선스를 구매해서는 안 된다. 대신 전체 직원 수를 라이선스 비용 계산의 기준으로 삼으며, 직원의 범위에는 정규직이나 시간제 직원은 물론 임시직 직원도 모두 포함된다. 컨설팅 회사, 아웃소싱 업체 또는 협력업체와 같은 다른 회사의 직원도 해당 기업의 비즈니스를 지원하는 경우 직원 수에 포함된다.

오라클은 이전 모델의 고객은 기존 조건에 따라 구독을 계속 연장할 수 있다고 밝혔다. 그러나 동시에 새로운 직원 기반 라이선스 모델로 전환하도록 고객을 독려하고 있다. 이 방식이 더 투명하고 법적 확실성을 제공한다는 것이 오라클의 주장이다. 이를 통해 PC와 서버부터 서드파티 업체의 클라우드에 이르기까지 회사 전체에서 자바를 보편적으로 사용할 수 있다. 라이선스 관리가 더 간단해지고 기업은 더 이상 자바를 사용하는 시스템을 명확하게 파악하지 않아도 된다.

그러나 이런 단순화에는 대가가 따른다. 많은 기업은 자바 라이선스 비용이 훨씬 더 비싸질 것이다. 2023년 중반, 가트너는 개별 기업의 라이선스 비용이 최대 5배까지 높아질 것이라고 추산하기도 했다. 업계 전문가들은 전 세계의 기업이 오라클이 자바 라이선스 정책을 강제하기 위해 더 많은 감사를 실시할 것이라며, 이에 대비해야 한다고 경고했다.

당시의 우려와 경고가 이제 현실화되고 있는 것으로 보인다. 작년에 오라클이 기업들에 "자바 구독에 대한 논의를 제안"하는 이메일을 보낸다는 보도가 여러 차례 있었다. 수신자는 대부분 중소기업이었다. 하지만 이제는 상황이 바뀌고 있는 것 같다.

소프트웨어 라이선스 컨설팅 전문업체인 팰리세이드 컴플라이언스(Palisade Compliance)의 CEO 크레이그 과렌트는 "한 달 전이라면, 오라클은 포춘지 선정 200대 기업은 감사하지 않는다고 했을 것”이라고 말했다. 이제 상단의 문턱은 사라졌다. 과렌트는 최근 몇 주 동안 오라클이 포춘지 선정 100대 기업에 보낸 공식 감사 서한을 여러 차례 받았다고 밝혔다.

과렌트는 오라클 고객이라면 가능한 한 빨리 자사의 위치를 평가하고 정말 필요한 경우에만 자바에 대한 비용을 지불해야 한다고 조언했다.

장기 계약을 체결하는 것은 좋은 생각이 아니다. 이는 사용자 기업에 막대한 비용을 초래할 수 있는 업체 종속을 초래할 수 있기 때문이다. 과렌트는 "오라클에 연간 100만 달러를 지불하고 3년 구독 계약을 맺었다면 갱신할 때 어떤 일이 일어날 것인가?”라고 반문했다. 100만 달러를 인상하지는 않겠지만, 오라클이 얻을 수 있는 만큼의 금액이 될 것이라며, 오라클에 묶여 이탈할 수 없는 기업은 훨씬 더 많은 비용을 지불해야 할 것이라고 덧붙였다.
editor@itworld.co.kr

최고관리자
9

3

오래 전
2024.07.14

오래 전

"형식 힌트부터 가상환경까지" 현대 파이썬 코딩의 4가지 핵심

파이썬은 2021년에 30주년을 맞이했지만 언어의 폭발적인 도입과 성장, 미래지향적 개발은 여전히 비교적 최근의 일이라고 할 수 있다. 파이썬의 많은 기능이 처음 등장 이후 바뀌지 않았지만 해가 지나고 새로운 에디션이 나올 때마다 이러한 발전을 활용하는 새로운 작업 방법과 새로운 라이브러리가 등장한다.

그래서 파이썬에는 예전 방식도 있고 새로운 방식도 있다. 당연히 편리한 최신 기능을 사용하여 파이썬을 다루는 방법을 익히는 것이 좋다. 이 기사에서는 2024년의 현대적 파이썬, 즉 파이썬의 최신 관용구와 개념, 기능을 사용하는 소프트웨어를 작성하기 위해 이해해야 하는 핵심 개념을 정리했다.

파이썬의 형식 힌트파이썬에 최근 도입된 형식 힌트 구문은 린터와 서드파티 코드 품질 툴이 런타임 전에 코드를 분석하고 발생 가능한 오류를 사전에 감지할 수 있게 해준다. 다른 사람들과 공유할 파이썬 코드를 많이 만들수록 만드는 본인이나 다른 사람들 모두 형식 힌트 사용의 혜택을 얻을 가능성도 커진다.

파이썬은 후속 버전이 나올 때마다 더 정교하고 강력한 형식 주석을 제공한다. 단기적으로 형식 주석 사용법을 익히는 습관을 들이면 형식 힌트의 새로운 혁신이 나올 때 더 잘 활용할 수 있게 된다.

형식 힌트는 필수가 아니라 ‘선택’임을 기억하는 것이 중요하다. 모든 프로젝트에서 형식 힌트가 필요하지는 않다. 형식 힌트를 사용해서 규모가 큰 프로젝트를 더 쉽게 이해할 수 있도록 만들 수 있지만 간단한 50줄짜리 스크립트라면 생략해도 무방하다. 또한 형식 힌트는 런타임에 적용되지 않지만 파이댄틱(Pydantic)을 사용하면 가능하다. FastAPI를 포함해서 널리 사용되는 파이썬 프로젝트의 상당수가 파이댄틱을 폭넓게 사용한다.
파이썬 가상 환경과 패키지 관리간단한 프로젝트와 까다롭지 않은 개발 작업에서는 파이썬에 내장된 venv 툴을 사용해 프로젝트와 프로젝트의 요구사항을 분리할 수 있다. 그러나 파이썬 툴의 최근 발전 덕분에 다음과 같은 더 많은 옵션이 제공된다.
Pyenv : 다양한 프로젝트 요구사항을 충족하기 위해 여러 버전의 파이썬을 설치한 상태로 유지해야 한다면 Pyenv를 통해 전역으로 또는 프로젝트별로 버전 사이를 전환할 수 있다. 프로젝트별 가상 환경의 컨텍스트를 벗어나 명령줄에서 다양한 파이썬 에디션으로 작업하는 경우가 많은 경우 유용하다. 참고로 윈도우는 공식적으로는 지원되지 않지만 비공식 윈도우 이식 버전이 있다. Pipenv : "인간을 위한 파이썬 개발 워크플로우"를 표방하는 Pipenv는 가상 환경과 프로젝트의 모든 종속 항목을 관리하기 위한 용도로 개발됐다. 또한 종속 항목의 결정적(deterministic) 속성을 보장한다. 즉, 원하는 특정 버전을 얻고 요청한 조합으로 작동한다. 다만 Pipenv는 어떤 형태로든 패키징과는 맞지 않으므로 최종적으로 PyPI에 업로드하거나 다른 사람과 공유할 프로젝트에는 적합하지 않다. 포에트리(Poetry) : Pipenv의 툴셋을 기반으로 확장된 포에트리는 프로젝트와 요구사항을 관리하고 프로젝트를 PyPI에 쉽게 배포할 수 있게 해준다. 또한 프로젝트 디렉터리와 별도로 가상 환경을 관리해준다. PDM : 파이썬 개발 마스터(Python Development Master)의 줄임말인 PDM은 이 분야의 최신 프로젝트다. 포에트리, Pipenv와 마찬가지로 PDM도 프로젝트 설정, 종속 항목 관리, 배포 아티팩트 빌드를 위한 단일 인터페이스를 제공한다. 또한 패키지를 프로젝트에 로컬로 저장하기 위해 PEP 582 표준을 사용하므로 프로젝트별 가상 환경을 만들 필요가 없다. 다만 비교적 새로운 툴인 만큼 프로덕션에 도입하기에 앞서 잘 작동하는지 확인해야 한다. 해치(Hatch) : 해치 프로젝트는 프로젝트 설정 및 관리를 처리할 뿐만 아니라 빌드 시스템, PyPI에서 재배포하기 위한 프로젝트 패키징 툴, 테스트 처리 및 그 외의 많은 유용한 기능을 제공한다.uv : 실험적인 uv 프로젝트는 러프(ruff) 파이썬 린팅 툴을 만든 사람들이 만들었다. pup, venv와 그 외의 여러 명령줄 파이썬 툴을 동시에 대체하는 것이 목표다. 러프와 마찬가지로 빠른 속도를 위해 러스트로 작성됐으며 상당수 명령이 pip를 비롯해 uv가 대체하는 다른 툴의 명령과 비슷하므로 비교적 쉽게 배울 수 있다.
팀 환경에서 사용되거나 예를 들어 PyPI를 통해 다른 사람들에게 배포한 목적으로 새 프로젝트를 만드는 경우 요구사항 및 프로젝트 구성에 최신 pyproject.toml 형식, 그리고 이와 함께 사용되는 프로젝트 레이아웃을 사용해야 한다. 이전의 requirements.txt 파일을 pyproject.toml과 나란히 사용할 수도 있지만 후자가 더 폭넓은 사용 사례를 처리하고 프로젝트의 상위 호환성도 확보할 수 있다.
새로운 파이썬 구문파이썬이 발전하면서 언어 자체에 많은 새로운 기능이 추가됐다. 지난 몇 번의 파이썬 버전에서는 더 강력하고 간결한 프로그래밍을 위한 유용한 구문 구조가 추가됐다. 필수는 아니지만 새로운 써드 파티 모듈에서 이를 사용할 수 있으므로 대략이라도 알아두는 것이 좋다.

최근에 추가된 구문 중에서 특히 주목할 만한 세 가지는 다음과 같다.

패턴 매칭
최근 파이썬 3.10에 추가된 가장 눈에 띄는 기능은 구조적 패턴 매칭이다. 종종 "파이썬을 위한 switch/case"라고도 하지만 그 이상이다. 구조적 패턴 매칭을 사용하면 객체의 내용 또는 구조를 기반으로 제어 흐름 결정을 내릴 수 있다. 간단히 말해, 값이 아니라 형식 또는 형식의 모양(예를 들어 int와 string이 있는 목록)을 기반으로 매칭하는 방법이다.

'바다코끼리 연산자'
모양(:=)으로 인해 바다코끼리라는 이름이 붙은 이 연산자는 파이썬 3.8에 추가됐으며 이를 통해 한 단계로 변수에 값을 할당하고 이 변수에 테스트를 적용하는 할당 식이 도입됐다. 예를 들어 결과를 보존하면서 함수의 반환 값을 확인하는 등 일반적인 많은 상황에서 코드의 장황함을 줄일 수 있다.

위치 전용 매개변수
최근에 추가된 소소하지만 유용한 파이썬 구문은 위치 전용 매개변수다. 어느 함수 매개변수를 키워드 인수가 아닌 위치 매개변수로 지정해야 하는지를 지정할 수 있게 해준다. 명확성을 높이고 코드베이스의 향후 개발을 용이하게 하기 위한 것으로, 이는 파이썬의 다른 많은 새로운 기능이 초점을 맞추고 있는 목표이기도 하다.
파이썬 테스트코드베이스에 대한 테스트 작성은 매일 치실을 사용하는 것과 같다. 좋다는 것은 모두가 알지만 실천하는 사람은 극소수다. 최신 파이썬 코드베이스에는 당연히 테스트 모음이 있어야 하며, 현재 나와 있는 테스트용 툴을 사용하면 쉽게 테스트 모음을 만들 수 있다.

파이썬에는 내장된 자체 테스트 프레임워크인 unittest가 있다. 기본 옵션으로 나쁘지는 않지만 설계와 동작 모두 구식이다. 파이테스트(Pytest)는 이를 대체하는 프레임워크로 부상했다. 더 유연하고(subset에 국한되지 않고 코드의 어느 부분에서나 테스트를 선언할 수 있음) 상용구를 써야 하는 경우도 훨씬 더 적다. 또한 파이테스트에는 기능 확장을 위한 애드온이 풍부하다(예를 들어 비동기 코드 테스트).

테스트의 다른 중요한 부가 요소는 테스트가 실제로 코드베이스의 얼마나 많은 부분을 커버하는지를 결정하는 코드 커버리지다. 이름 그대로 커버리지(Coverage) 모듈이 사용되며, 파이테스트에는 커버리지 모듈을 사용하기 위한 플러그인도 제공된다.
editor@itworld.co.kr

최고관리자
9

2

오래 전
2024.07.14

오래 전

노련한 개발자와 초보자의 기술적인 차이 4가지

시니어 개발자가 되기 위해 무엇이 필요한지에 대한 글을 보면 대부분 소프트 스킬에 초점을 맞추고 있다. 기술을 최신 상태로 유지하고, 의사소통 방법을 배우고, 후배 개발자를 멘토링하라는 식이다. 이런 권장 사항은 모두 필요하고 적절하지만 솔직히 말해서 다소 공허하기도 하다. 사실 시니어 개발자와 주니어 개발자의 본질적인 차이는 소프트웨어 개발 현장에서 보낸 시간의 크기와 이에 따른 교훈이다. 이를 염두에 두고 시니어 개발자가 힘들게 얻은 경험을 통해 알고 있는 4가지를 정리했다.

명확성이 가장 중요하다는 것을 안다개발자가 할 수 있는 가장 중요한 일은 읽기 쉬운 코드를 작성하는 것이다. 이는 너무나 당연한 것이므로 말할 필요도 없다. 하지만 세상에는 쉽게 읽을 수 없는 코드가 엄청나게 많다. 너무 많은 코드가 미래의 어느 시점에 누군가 읽어야 한다는 사실에 고려하지 않고 작성된다. 그리고 우리 대부분은 그 불쌍한 사람이 바로 내가 될 수 있음을 간과한다. 좋은 코드는 나중에 읽힐 목적으로 작성될 뿐만 아니라 디버깅을 목적으로 작성되기도 한다. 모든 언어가 다르고 모든 디버거가 각자의 방식으로 작동하지만, 코드는 항상 디버깅하기 쉬운 방식으로 작성해야 한다.

놀랍게도 읽기 쉬운 코드를 작성하는 것과 디버깅하기 쉬운 코드를 작성하는 것은 서로 밀접한 관련이 있다. 디버깅의 대부분은 특정 순간에 실행 중인 애플리케이션의 상태를 이해하는 것이다. 코드가 실행될 때 함수, 클래스 등을 명확하게 선언하면 디버거에서 해당 코드가 어떤 상태인지 확인할 수 있다. 또한 코드를 가독성 있게 만드는 장점도 있다.

코드의 명확성은 주석이 필요 없는 코드를 작성할 때도 중요하다. 일단 개발자가 코드에 주석을 달 필요가 있다고 느낀다면 그 이유를 자문해야 한다. 코드가 명확하지 않기 때문에 주석이 필요하다고 생각하는 것이 아닌지 의심해야 한다. 이런 의견에 동의하지 않는 이들도 있겠지만, 놀랍게도 세상에는 코드에 모든 줄에 주석을 달아야 하는 기업이 있다. 하지만 개발 업계에 오래 종사할수록 필자는 주석이 필요하지 않다고 더 강하게 믿는다. 코드에 주석을 달아야 할 필요가 있다고 생각되면 코드를 다시 작성하는 것이 맞다. 주석이 필요하지 않도록 처음부터 코드를 작성하는 것이 더 좋은 방법이다.

최고관리자
8

1

오래 전
2024.07.14

오래 전

전 세계 1% 리눅스 기여자가 말하는 eBPF "리눅스와 플랫폼 엔지니어링의 미래"

2013년 도커가 등장한 시점에서 보면 리눅스 컨테이너가 마치 하룻밤 사이에 성공한 것처럼 느껴질 수 있다. 하지만 사실 컨테이너, 마이크로서비스와 쿠버네티스의 진화는 리눅스 운영체제의 커널 프리미티브를 기반으로 수십년에 걸쳐 이뤄졌다.

도커는 가볍고 사용하기 쉬운 소프트웨어 패키징 형식을 만들기 위해 이러한 프리미티브, 즉 cgroup과 네임스페이스를 빌딩 블록으로 사용했다. 리눅스 컨테이너는 오래전부터 구글을 비롯한 여러 기업에 사용됐는데 단지 도커가 등장하면서 주류 개발자가 컨테이너에 쉽게 액세스할 수 있게 된 것이다.

지금의 eBPF는 그렇게 해서 리눅스 커널 프리미티브에서 탄생한 또 다른 기술이다. 현재 모든 주요 네트워킹, 관찰가능성 및 보안 벤더는 "eBPF 기반" 제품을 제공한다고 주장한다. 실리움(Cilium), 테트라곤(Tetragon), 팔코(Falco)와 같은 eBPF 툴이 엔터프라이즈 아키텍처와 클라우드 서비스 제공업체 제품에서 모두 자리를 잡고 있다. 또한 eBPF를 만든 장본인 한 명에 따르면 지금은 eBPF 기반 혁신의 시작에 불과하다.

Infoworld는 eBPF의 공동 창시자이며 현재 리눅스 커널의 eBPF 공동 유지관리자인 대니얼 보크만에게서 이 기술의 기원, eBPF가 리눅스 커널 프로그래밍과 커스터마이징을 위한 표준 접근 방법으로 부상한 이유, 그리고 이것이 리눅스와 플랫폼 엔지니어링의 미래 측면에서 의미하는 바에 대한 이야기를 들어봤다.

최고관리자
8

웹진 게시판

웹진 게시판 포인트 정책

검색