글쓴이 보관물: plusha

대학생의 옵션 구매

옵션이란?

경제에서 옵션은 선택할 수 있는 권리를 말합니다.

예를 들어, 현재 브렌트유 가격이 리터당 1700원이라고 해봅시다. 한 달 후에 1리터를 1750원에 살 수 있는 권리를 50원에 팔고 있다고 해봅시다. 사겠습니까?

한 달 후 유가가 리터당 1800원이 넘어갈 것이라 예상한다면 이 권리를 사는 것이 좋습니다. 만약 2000원이 된다면 1750원을 내고 2000원짜리 브렌트유 1리터를 살 수 있으므로 250원 이득이네요. 옵션 구매에 50원을 투자했으니 총 이득은 250원에서 50원을 뺀 200원이 됩니다. 50원 투자해서 한 달만에 200원 순이익을 남겼다면 대단히 성공적인 투자죠?

반대로 유가가 1400원으로 떨어졌다고 해봅시다. 얼마나 손해를 볼까요? 옵션은 권리라고 했습니다. 손해볼 것 같으면 안 사면 됩니다. 따라서 유가가 아무리 떨어져도 최대 손실은 옵션 구매에 쓴 50원으로 제한됩니다.

이렇게 이득은 커질 수 있고, 손실은 제한되는 비대칭적 선택권이 바로 옵션입니다. 미래에 변동이 없다면 옵션은 필요 없습니다. 유가가 한 달 후에도 1700원이라면 옵션을 구매할 이유가 없죠. 변동성이 크고 불확실할수록 옵션은 빛을 발합니다.

대학생의 옵션

옵션을 대학 생활에 적용해봅시다. 4년 동안 열심히 공부해서 우수한 성적으로 졸업하고 원하는 기업에 취직할 것이 확실하다면 옵션이 필요 없습니다. 부모님께 물려받을 재산이 많다면 역시 옵션이 필요 없습니다. 졸업 후가 불확실하다면 나만의 옵션을 준비하는 것이 어떻까요?

대학생은 돈이 별로 없으니 옵션은 시간과 노력으로 구매해야 합니다. 예를 들면 인스타그램 보는 시간을 줄이고, A0 받을 만큼 공부하는 대신 B+ 받을 만큼만 공부해서 남는 시간과 노력으로 미래에 도움이 될 수도 있을만한 다른 것을 공부하거나 만드는 것입니다. 이 때 많이들 하는 스펙 쌓기가 아니라 남들과 차별화할 수 있는 일을 해야 좋은 옵션이 됩니다.

어학 연수? 단순히 어학 연수 다녀왔다는 것은 좋은 옵션이 아닙니다. 원어민처럼 말하고 듣는다면 물론 좋은 옵션이 될 수 있지만 시간, 노력 뿐 아니라 돈도 많이 들 수 있습니다. 생성AI 공부? 빠르게 실력을 쌓는다면 향후 몇 년간 좋은 옵션이 될 수 있을 것으로 보입니다. 컨텐츠 크리에이터? 2년 이상 한 가지 분야에서 전문성을 쌓아가는 과정을 보여준다면 훌륭한 옵션이 될 수 있습니다. 창업? 대학생 때 창업을 한다면 우선 위험 부담 없는 창업으로 경험을 쌓기를 권장합니다. 역시 좋은 옵션이 될 수 있습니다.

옵션은 권리라고 했습니다. 자신이 준비한 옵션이 졸업 후 취업이나 창업에 도움이 된다면 사용하면 되고, 도움이 되지 않는다면 안 쓰면 됩니다. 손해보는 것은 물론 옵션을 준비하는데 들어간 시간과 노력(나중에 보면 손해가 아닐 수도 있습니다)이지만 잘 될 경우 옵션으로 인해 여러분의 진로와 인생이 달라질 수 있습니다.

📦 연구도 상자 안에서

컨테이너를 이용하면 컴퓨터를 이용한 과학 기술 연구 효율성을 높일 수 있습니다.

컨테이너가 왜 중요할까요?

  • 연구 프로젝트들의 작업 공간을 분리하여 관리하기 쉬워집니다.
  • 프로그램 설치 및 환경 설정이 간단해집니다.
  • 연구 재현성(reproducibility)을 높일 수 있습니다.

컨테이너를 이용한 프로젝트 작업 공간 분리

정리하는 뇌라는 책에 보면 여러 개의 프로젝트를 진행하고 있을 경우 프로젝트별로 작업 공간을 분리하는 것이 두뇌 활동에 도움이 된다는 이야기가 나옵니다. 2018년 이 책을 읽고 학교 연구실에서 수업 준비 및 행정 업무용 책상과 연구용 책상(그리고 컴퓨터)을 분리했던 적이 있습니다. 수업 준비를 하다가 연구를 하려면 자리를 옮겨야 했고, 이를 통해 두뇌에 작업이 달라졌다는 것을 확실히 알려주기 위해서였죠.

연구용 책상을 따로 분리할 수는 있었지만 공간 제약으로 인해 여러 연구 프로젝트들끼리의 물리적 공간 분리는 할 수 없었습니다. 대신 Tmux를 이용해 클러스터 서버에서 터미널을 분리해서 작업할 수 있었고, 실제로 이 프로젝트 작업하다가 저 프로젝트 작업하면서 뒤죽박죽되는 상황이 많이 줄었습니다. Tmux에서 프로젝트별로 터미널 세션을 만들어 작업했했는데, 세션 전환을 통해 이제 다른 프로젝트 작업을 시작한다는 것을 두뇌에 알려준 셈이죠.

이후 도커 사용법을 배워 컨테이너 가상화도 프로젝트 작업 공간 분리에 함께 사용하기 시작했습니다. 이전에는 같은 호스트 운영체제에서 터미널만 분리해 작업했던 반면, 컨테이너를 사용하면 프로젝트별로 서로 다른 운영체제를 사용하는 셈이기에 작업 공간 분리에 더 좋습니다. 

세컨드 브레인 책에도 프로젝트별 파일 정리에 대한 언급이 나옵니다. 트와일라 타프라는 창의적인 안무가도 새로운 작품을 시작하면 새로운 상자를 준비해 작품과 관련된 모든 자료를 상자에 보관했다고 합니다. 프로젝트를 잠시 보류했다가도 나중에 다시 상자를 쉽게 찾아 진행할 수 있었고, 내용물을 공유하기도 좋았다고 합니다.

연구 프로젝트들도 컨테이너 상자를 이용해 정리합시다.

컨테이너와 표준화

부산에서 부두 근처를 지나다 보면 부두에 쌓인 컨테이너들과 컨테이너선, 컨테이너를 싣고 다니는 트럭들을 볼 수 있습니다. 최초의 컨테이너선은 1956년 운항을 시작한 말콤 맥린이라는 사람의 배였다고 합니다. 당시 컨테이너들은 규격이 일정하지 않았지만 이후 컨테이너의 표준화와 항구 대형 크레인 설치를 통해 화물 운송 효율이 증가하고 선박 운송 비용이 감소하여 국제 무역이 크게 증가했다고 합니다. 컨테이너는 단순한 박스이지만 세계 경제를 바꾼 혁신이었죠(마크 레빈슨, 더 박스).

도커에서 말하는 컨테이너가 바로 이 컨테이너입니다. 그래서 도커의 로고도 컨테이너선을 따라 만들었죠. 컴퓨터에서 컨테이너는 가상화 기술의 일종입니다. 실제로는 격리된 프로세스들의 집합이지만, 호스트 운영체제와 구분된 별도의 운영체제인 것처럼 생각할 수 있습니다. 컨테이너 기술은 도커 전에도 존재했지만 2013년 공개된 도커에서 컨테이너 기술을 쉽게 쓸 수 있도록 만든 후 컨테이너 기술이 널리 쓰이게 되었습니다.

종류별로 컨테이너들을 쌓아놓고 작업에 따라 필요한 컨테이너를 꺼내서 그 안에서 작업하고, 다 쓴 후에는 다시 넣어놓는 방식으로 일하는 경우를 생각해봅시다. 도커에서 쌓아놓은 컨테이너에 해당하는게 이미지입니다. 도커에는 필요한 프로그램들을 미리 설치해놓은 이미지들이 있습니다. 필요할 때 원하는 이미지를 실행해서 메모리에 올리면 그게 도커 컨테이너입니다. 메모리에 올린 후에는 컨테이너 안의 프로그램들을 이용해 작업을 할 수 있죠. 작업이 끝나면 컨테이너를 정지시키는데, 이미지는 그대로 남아 있어서 나중에 필요할 때 다시 쓸 수 있습니다. 이미지가 필요 없다면 지울 수도 있고, 직접 원하는 프로그램을 설치해서 나만의 이미지를 만들 수도 있습니다.

컨테이너는 해상 운송 뿐 아니라 컴퓨터 가상화 방식도 바꿨습니다.

소프트웨어를 이용한 연구에서 발생하는 몇 가지 문제들 예방하기

저는 대학원생 때부터 수학적/공학적 알고리즘을 개발하고 프로그래밍을 통해 구현해서 검증하는 방식의 연구를 많이 해왔습니다. 컴퓨터를 이용해 연구를 수행하다 보니 다양한 소프트웨어 관련 문제들을 겪어 왔습니다.

  1. 정전으로 클러스터 서버 전원이 꺼지면서 하드디스크가 고장나 소스 코드 파일이 손상되는 문제
  2. 실수 소스 코드를 지워버리는 문제 (리눅스 커맨드라인에서 파일을 지우면 복구하기가 매우 어렵습니다)
  3. 코드 수정 후 결과가 달라졌는데 한꺼번에 너무 많은 부분을 수정해서 어디를 어떻게 수정했는지 찾기 어려워지는 문제
  4. 동일한 코드인데 다른 서버에서 컴파일이 안 되는 문제
  5. 동일한 코드인데 다른 서버에서 실행 결과가 달라지는 문제
  6. 새 서버가 들어올 때마다 연구에 필요한 프로그램들을 설치하기 전까지 사용하지 못하는 문제

대학원생 때는 이러한 문제들로 인해 시간을 많이 빼앗겼는데, 새로운 기술들로 인해 이제는 위의 상황들이 발생하지 않거나 발생해도 심각한 문제가 되지 않습니다.

1-3번 문제는 소스 코드 버전 관리 시스템을 이용해, 4-6번 문제는 Docker 컨테이너를 이용해 예방/해결할 수 있습니다. 1, 2번은 Git 로컬 저장소와 GitHub 원격 저장소에 2중으로 코드를 백업하기 때문에 소스 코드가 지워져도 금방 복구가 가능합니다. 3번의 경우 git diff 명령으로 수정 부분을 쉽게 확인할 수 있습니다. 한꺼번에 많은 부분을 수정하기보다는 작게 나눠서 수정하고 자주 commit하는게 좋습니다. 4, 5번은 서버의 라이브러리나 컴파일러 등이 달라서 생기는 문제인데, Docker 컨테이너 가상환경을이용해 서버의 환경을 동일하게 만들어 주면 연구 결과 재현성(reproducibility)을 높일 수 있습니다. 6번 또한 시스템에 Docker만 설치해 놓으면 금방 Docker 이미지를 받아 컨테이너를 실행하여 다른 서버와 동일한 연구 환경을 준비할 수 있습니다.

Git과 GitHub는 제가 대학원에 있을 때 공개 되었습니다. 버전 관리 소프트웨어는 그 전부터 존재했죠. 박사과정 때는 Mercurial이라는 소프트웨어를 잠깐 이용했었는데, 이후 Git과 GitHub가 버전 관리 업계를 거의 평정(?)했죠. Docker는 제가 박사과정을 마친 후에 나왔습니다. 컨테이너 기술은 그 이전에도 있었지만 Docker가 컨테이너 기술을 대중화했죠. 연구에서 프로그래밍을 진지하게 다룬다면 Git은 거의 필수입니다. Docker는 서버 컴퓨터를 많이 다루는 연구실에서 유용하게 쓸 수 있습니다.

생성AI 학부 수업

머신러닝이 점점 널리 쓰이고 있습니다. 2019년 대학원에, 2020년 학부에 처음 머신러닝(기계학습) 수업을 개설했습니다. 수업에서 2021년까지는 지도학습과 비지도 학습, 모델 훈련, 심층신경망, 합성곱신경망, 순환신경망, 오토인코더, GAN과 같은 내용을 다뤘습니다. 2022년에는 연구년이라 제 수업이 없었고요. 2023년 2학기부터 학부 수업은 머신러닝 모델을 직접 만들고 훈련시키는 내용이 아니라 이미 만들어진 각종 AI 모델들, 특히 생성AI를 활용하는데 중점을 두고 진행하려고 합니다.

데이터 분석 도구들 중 널리 사용하는 엑셀에 대해 생각해봅시다. 데이터를 분석하는데 엑셀에서 지원하지 않는 기능이 필요하다면 해당 기능을 지원하는 다른 도구를 찾아 쓰던가 직접 도구를 만들어 사용해야 합니다. 하지만 엑셀에 해당 기능이 있다면 엑셀 사용법을 배워서 쓰는게 더 효율적이죠.

머신러닝의 경우도 필요한 모델을 직접 만들어 쓸 수도 있지만, 많은 경우 원하는 기능을 제공하는 모델의 사용법을 익혀서 쓰는게 효율적입니다. 대학원에서는 연구를 위해 직접 모델을 개발하는 경우가 많기 때문에 기존의 내용을 유지하겠지만, 학부 수업에서는 활용법을 다루는 것도 학생들에게 도움이 되리라 생각합니다. 학과에 다른 교수님의 머신러닝 수업이 있기에 파이썬 프로그래밍, 머신러닝 기본 개념과 같은 내용들은 알고 있다고 생각하고 바로 활용으로 넘어가려고 합니다. 3학년 “지구물리기계학습 및 실습” 수업을 들을 학생들은 먼저 2학년 “에너지자원 머신러닝 및 실습” 수업을 듣고 오시길 바랍니다.

AI가 연구도 집어 삼키고 있습니다

소프트웨어가 세상을 집어 삼키고 있습니다

소프트웨어가 세상을 집어 삼키고 있습니다(Andreessen). 각종 아날로그 매체에 담겨있던 정보들은 디지털 비트로 증발하고 있죠(Negroponte; Tercek). 레코드판, 카세트테이프, 비디오테이프가 증발하였고, 신문과 책도 증발하고 있습니다. 증발된 정보는 클라우드에(cloud) 존재하며, 사용자가 원할 때(on-demand) 아날로그 매체 없이 비트만 받아 텔레비전, 컴퓨터, 스마트폰으로 보고 들을 수 있습니다.

하드웨어 장치들도 증발하고 있습니다. 비디오플레이어, CD 플레이어, MP3 플레이어, 카메라, 계산기 등은 이제 컴퓨터 소프트웨어나 손바닥 안의 앱으로 존재합니다. 각 기관들에서 운영하던 서버 컴퓨터들도 클라우드로 옮겨가고 있습니다. 소프트웨어 개발자들은 이제 인프라도 코드로 관리합니다(Morris).

코로나19는 회사 사무실들을 증발시켰고, 학교와 학원 교실에서 진행되던 수업들을 증발시켰습니다. 재택 근무와 온라인 강의는 코로나19 이후에도 일정 부분 남아 있겠죠. 앞으로 많은 사회적 경제적 활동들이 가상의 소프트웨어 세상인 메타버스에서 일어날 것입니다(Dionisio et al.).

소프트웨어가 연구도 집어 삼키고 있습니다

다양한 과학 기술 분야의 연구도 컴퓨터 소프트웨어로 진행되고 있습니다(Hannay et al.; Prabhu et al.). 수치해석을 이용한 컴퓨터 시뮬레이션은 많은 물리 모형 실험을 대체했습니다. 디지털 트윈은 현실 상황을 컴퓨터로 재현합니다(Negri et al.). 물론, 실제 계산은 CPU, GPU와 같은 하드웨어에서 수행하지만 사용자는 소프트웨어를 이용해 하드웨어를 제어하죠.

AI가 소프트웨어를 집어 삼키고 있습니다

그런데 세상을 집어 삼키고 있는 소프트웨어를 AI가 집어 삼키고 있습니다(Huang). 머신러닝/딥러닝을 통해 기존의 소프트웨어들로는 하지 못했던 일들도 가능해지고 있습니다. 생성AI는 코드를 작성해주기도 합니다.

연구에 있어서도, 제 전공 분야에서 체감상 최근 발표되는 연구의 반 이상은 머신러닝을 이용한 연구인듯 합니다. 물리탐사 자료처리 분야가 예전부터 컴퓨터를 많이 사용하던 분야라 머신러닝 도입이 빠르기는 합니다. 탄성파 탐사 연구실에서도 최근에는 딥러닝을 이용한 연구들을 주로 진행하고 있습니다. 이제는 머신러닝이 수치해석과 같은 필수 도구가 되었습니다.

이슈 관리 프로그램을 이용한 작업 방법

이슈 관리 프로그램

이슈(Issue)는 소프트웨어 개발에서 기능 추가, 버그 수정 등의 작업을 의미합니다. 이슈 관리 프로그램들로는 JIRA, YouTrack, Redmine, GitHub Issues 등 다양한 소프트웨어들이 있습니다.

제가 이슈 관리 프로그램을 본격적으로 사용하기 시작한 것은 2020년입니다. 그 전에도 연구용 소프트웨어 개발을 위해 Trello 보드를 이용해 간단하게 이슈를 관리했습니다. 하지만 GPU 병렬 연산 최적화 프로젝트를 위해 본격적인 이슈 관리 프로그램의 필요성을 느껴 BitBucket 저장소에 JIRA를 연결해 사용했습니다. Git으로 소스코드를 관리하며 커밋 메시지를 통해 이슈를 자동으로 관리하는 기능도 유용하지만 제게는 필요한 기능들을 적어놓고 하나씩 구현하는 작업 방식 자체가 개발 속도 향상에 큰 도움이 되었습니다.

작업 절차: 시행 착오(작은 성공, 빠른 실패, 빠른 피드백)

요구사항에 따른 초기 설계 후에 제가 이슈 관리 프로그램을 이용해 소프트웨어를 개발하는 절차는 다음과 같습니다.

  1. 필요한 작업을 30분~1시간 작업 분량 정도의 작은 단위로 나눠 이슈 관리 프로그램에 등록합니다. 짧은 시간 작업해서 빠르게 피드백을 얻을 수 있도록 작업을 잘게 나눕니다. 이슈는 생각 날 때마다 수시로 등록합니다.
  2. 작업할 이슈를 하나 정해서 해당 개발 작업을 수행합니다. 한 번에 하나의 이슈에만 집중해서 개발을 진행합니다.
  3. 작업 결과를 점검합니다. 원하는 결과가 나오면 작은 성공을 얻은 것이죠. 원하는 결과가 안 나왔다면 피드백을 통해 프로그램이나 이슈를 수정합니다.
  4. 잠깐 쉬었다가 2번 과정으로 (반복)

이 때 빠르게 피드백을 얻을 수 있도록 하나 하나의 실험(이슈)을 작게 설계합니다. 큰 기능도 작게 나눠서 구현하며 중간중간 확인하면 실패의 리스크를 줄일 수 있습니다. 실험별 성공/실패를 판단하기 위해서는 원하는 결과가 명확해야겠죠.

GPU 최적화 때 성공적인 결과는 수치해석 결과가 달라지지 않으면서 계산 속도가 향상되는 것이었습니다. 속도가 향상될 수 있을 만한(일부는 불확실한) 내용들을 이슈 관리 프로그램에 등록해 놓고 하나씩 구현한 후 GPU 프로파일러로 실행하며 속도와 결과를 비교했습니다. 동일한 결과에 계산 속도가 빨라지면 다음 이슈로 넘어갑니다. 속도가 빨라지지 않거나 결과가 달라지면 수정 이전의 코드로 돌아가고 해당 이슈는 취소하는 방식으로 작업했습니다.

HPC 작업 관리 프로그램에서는 추가하는 기능에 따라 원하는 결과가 다릅니다. 입력이 잘 되는지, 배치 파일이 잘 만들어지는지, 작업 제출이나 취소가 잘 되는지, 모니터링이 잘 되는지 등을 확인하며 피드백을 받습니다. 잘 안 되면 버그를 찾아 고치거나 다른 구현 방식을 시도합니다.

보통 연구를 진행할 때는 어떤 결과가 나올지 잘 모르는 경우가 많기 때문에 연구용 수치해석 소프트웨어 개발 과정과는 약간 차이가 있네요.

이렇게 다양한 시행 착오를 통해 배우며 경험을 쌓아가고 있습니다. 특별한 것은 없지만 나름대로 과학적 방법론, 애자일 개발, 린 스타트업, 리스크 관리, 뽀모도로 기법, 인지심리학 등을 통합 적용한 의식적인 개발 방법이고, 이 작업 방법도 세부적으로 시행 착오를 거치며 조금씩 바꿔가는 중입니다.

JIRA에서 Linear로

JIRA가 좋기는 하지만 이름이 별로 마음에 안 들고^^; 프로그램 인터페이스가 약간 불편하고, 결정적으로 최근에 JIRA 개발사에서 MacOS용 프로그램 개발을 중단해서 다른 이슈 관리 프로그램들을 찾아봤습니다. Linear라는 소프트웨어를 알게 되었는데, 수학적인 이름이 마음에 들고^^ 프로그램 인터페이스가 멋지고, MacOS에서 키보드를 이용해 대부분의 작업을 수행할 수 있어서 Linear로 옮겼습니다. 현재는 Linear와 GitHub를 사용하고 있습니다.

바흐와 함께

평소 소프트웨어를 개발할 때 바흐의 “평균율 클라비어곡집”이나 “골드베르크 변주곡”을 배경 음악으로 틀어놓고 작업하는 경우가 많습니다. 이번 여름엔 방열기 공사로 연구실 벽에 구멍이 뚫려 있어서 조용히 작업하고 있네요. 글을 쓰다 보니 “바흐: 천상의 음악”이라는 책을 반 정도 읽다가 만 것이 생각나 책을 꺼냈습니다. 이제 책을 읽어야겠습니다^^

슈퍼컴퓨터 작업 관리 프로그램 제작 시작

한 컴퓨터 회사의 의뢰로 7월 말부터 슈퍼컴퓨터(High Performance Computer)의 작업 관리 프로그램을 만들기 시작했습니다. 이 프로그램의 목적은 클러스터 서버 사용자들이 작업 스케줄러 프로그램 사용법을 몰라도 쉽게 서버에 작업(Job)을 제출하고 모니터링할 수 있도록 만들어주는 것입니다.

작업 스케줄러(Job Scheduler)

클러스터 컴퓨터는 보통 여러 사용자들이 사용합니다. 여러 사용자가 동시에 자신의 작업을 실행하면 멀티태스킹으로 인해 전체적인 계산 효율이 떨어지게 됩니다. 서버 자원(CPU, GPU 등)을 효율적으로 사용하기 위해 작업들에 계산 자원을 효율적으로 할당하는 역할을 하는 것이 작업 스케줄러입니다.

작업 스케줄러에는 Slurm, PBS, TORQUE, Oracle Grid Engine 등 여러 가지들이 있는데 일단 만들고 있는 것은 Slurm의 명령어를 이용하는 GUI (Graphical User Interface)입니다. 이런 GUI 프로그램들은 대부분 상용이고 공개 프로그램도 소수 있습니다.

최소 기능 제품 (MVP, Minimum Viable Product)

회사의 피드백을 받아가면서 빠르게 작업할 수 있도록 최소한의 기능을 담은 제품을 만들었습니다. 현재 일반적인 MPI 작업을 제출하고 모니터링하고 취소할 수 있습니다.

다음은 현재 진행중인 작업을 확인/취소할 수 있는 페이지입니다.

다음은 현재 클러스터 컴퓨터의 전체/파티션(노드 그룹)별/노드별 CPU/Memory 사용량을 모니터링할 수 있는 페이지입니다.

아래는 작업에 필요한 파일들을 서버에 업로드하고 관리하는 페이지입니다.

다음은 작업 제출에 필요한 정보를 입력하고 제출할 수 있는 페이지입니다.

고급 사용자의 경우 앞에서 입력한 정보를 바탕으로 생성된 작업 제출 스크립트를 확인/수정하고 제출할 수도 있습니다.

앞으로 상용 해석 프로그램(Abaqus, Ansys, StarCCM+ 등) 작업 제출 기능과 사용자 관리 기능 등을 추가할 계획입니다.

외부 기관을 위한 소프트웨어 제작

외부 기관을 위한 소프트웨어 제작은 이번이 세 번째입니다.

첫 번째는 2019년 국방과학연구소의 GPU를 이용한 수중채널모델링 프로그램이었습니다. 파동 전파를 이용하는 프로그램이었기 때문에, 제 연구 분야와도 관련이 있었죠.

두 번째는 2020년 부산대/대우조선해양의 쇄빙선 모델링 프로그램의 GPU 병렬화 프로젝트였습니다. 제 전공 분야가 아니었기에 2019년 처음 의뢰가 들어왔을 때는 거절했었죠. 부산대에서 자체적으로 1년간 진행했으나 원하는 성능이 나오지 않는다고 2020년 여름에 다시 의뢰가 들어왔습니다. 그래서 8월 한 달간 프로그램 개발을 진행했고 만족할만한 성능을 얻었습니다. 해당 경험을 통해 보유 기술을 전공 분야에만 한정하는 것보다 기술을 필요로 하는 다른 분야에 적용하는 것이 사회적으로 더 큰 가치가 있을 수 있다는 것을 깨달았습니다.

앞의 두 번은 모두 수치해석 프로그램이었지만 이번 프로그램은 직접적인 수치해석 프로그램은 아닙니다. GUI 프로그램이나 웹 개발도 평소 연구와 거리가 멀기에 몇 달 전 의뢰가 들어왔을 때 처음에는 거절했었죠. 회사에서는 다른 곳에 의뢰해서 개발을 진행했으나 결과가 마음에 들지 않아서 제게 다시 의뢰가 들어왔고, 이번에도 한여름에 개발을 진행하고 있습니다. 앞의 프로젝트와 패턴이 유사하네요. 이번 2학기 지구물리 기계학습 수업과 내년 1학기 지구물리 클러스터 컴퓨팅 수업에서 웹 개발을 일부 다룰 계획인데, 이번 개발이 좋은 경험이 될 듯 합니다.

Docker 이미지 저장 경로 바꾸기

Docker pull을 사용하다가 리눅스 서버의 root에 마운트된 디스크가 꽉 차서 Docker Root 경로를 바꾸는 방법을 찾아봤습니다(참고: link).

현재 Docker Root Dir이 /var/lib/docker, 변경할 이미지 저장 경로는 /data/docker/root라고 하겠습니다. 이미지 저장 경로는 미리 만들어 둡니다. 참고로, 현재 Docker Root Dir은 다음 명령으로 확인할 수 있습니다.

$ docker info |grep Root

아래 작업들은 root 계정으로 진행합니다. 먼저 docker daemon을 정지합니다.

# service docker stop

/etc/docker/daemon.json 파일에 다음 내용을 추가합니다(Docker v17.05.0 이상).

{ 
   "data-root": "/data/docker/root"
}

기존의 Docker 데이터를 새로운 경로로 복사합니다. 기존 데이터를 지우기 전에 Docker가 잘 작동하는 것을 확인하려고 합니다. 이를 위해 기존 경로의 이름을 바꾸고 Docker를 재시작합니다.

# cp -rp /var/lib/docker/* /data/docker/root/
# mv /var/lib/docker /var/lib/docker.old
# service docker start

Docker가 잘 작동하는지 확인한 후 기존 경로를 삭제합니다.

# docker info |grep Root
# docker images
# rm -rf /var/lib/docker.old