[octave] 2. octave 설치 방법들

아니, 설치방법 그냥 홈페이지에 있잖아? 라고 하려고 해도….. 그렇게 설명하기 힘든게 옥타브 환경 같습니다. 이유를 좀 설명할께요. 우선 다운로드 사이트를 확인합시다.

처음부터 소스 빌드과정과 리눅스, BSD라니… 여기서 뉴비들은 덜덜거릴 수 있습니다.

맥하고 윈도우는 밑에 있습니다. 근데 맥은 왠지 모르게 wiki를 알려주죠?

윈도우를 제외하고는 거의 코드 빌드를 이용하거나, 옥타브에서 제공하는 ftp에서 제공하는 바이너리 빌드된 녀석을 make로 만들어서 이용하는 것이 가장 최신의 버전을 이용할 수 있습니다. 저는 리눅스 민트와 윈도우를 이용하고 있습니다만, 리눅스 민트의 경우에 그냥 뭣모르고 sudo apt install octave를 입력해서 하면 바로 설치는 깔끔하게 되는데, 버전이 6버전이더군요. 패키지 관리자에 아무래도 6버전대를 제공하는 듯 합니다.

그래도 기왕 쓰는데 최신 버전 쓰는 게 낫지 않나…

그래서 일단 제일 쉬운 윈도우는 exe 인스톨러 받아서 설치하면 됩니다. 처음 쓰시는 분들에게는 윈도우 과정을 추천합니다. 근데 윈도우 64비트는 버전이 둘 있는데, 64bit linear alg for large data라고 있는 것이 바로 메모리가 64G 이상의 고용량 메모리를 이용한 연산이 되는 버전입니다. 일반적으로는 그냥 64비트용을 이용하면 충분히 가능합니다.

윈도우에서 GUI로 실행한 환경

윈도우 설치법 및 리눅스 설치법은 별도로 기회되면 작성해보겠습니다.

[octave] 1. octave 시작하기

octave 관련된 간단한 글을 쓰고 싶었는데, 이 기회에 시작합니다.

회사 다니면서도, 아는 중학생과 고등학생 몇명에게 옥타브를 가르쳐 주면서 그냥 간단한 것만 보여주면서 수치해석에 대한 이야기를 간단하게 원격으로 강의를 했었습니다. 근데 애들이 생각 이상으로 즐겁게 시도해보기도 하는 걸 보면서, 쉽게 접근 가능한 녀석으로 가르쳐 주는 것도 좋을 거 같아보이더군요.

뭐, 대학 오면 매트랩(matlab)도 써보고 하면 그쪽에서 충분히 익히겠지만, 전 이쪽이 좀 더 좋아보입니다. 그 이유를 좀 정리하면…

  1. GPL 라이센스의 오픈소스이다.
    이건 엄청 중요하다고 생각합니다. 접근성이 엄청 좋은 것이니깐요. 쉽게 설치해서 쓸 수 있는 것은 시작하기 쉽다는 것이기도 하니깐요.
  2. 여러 운영체제에서 이용 가능하다.
    이게 윈도우, 맥, 리눅스 뿐 아니라 안드로이드에서까지도 사용이 가능합니다. ios도 되었으면 좋겠는데….ㅠㅠ
  3. MATLAB 문법과 거의 비슷하게 이용할 수 있다.
    일부 차이점은 존재하지만, 그것들을 제외하면 어느정도 matlab 코드를 이해하면서 사용할 수 있습니다. 필요하면 그대로 짜서 만들면 그만이니깐요.
  4. 다양한 패키지를 무료로 내려받아서 적용할 수 있다.
    이거 은근 사용하는 사람들이 많아서 좀 많은 패키지들이 존재합니다. 이들을 무료로 받아서 이용할 수 있고, 그를 통한 지식을 습득할 수도 있습니다.

그러나, 이렇게 적어도 좀 단점이랄 것들도 당연히 존재하는데, 단점에 대해서 이야기하면 다음과 같습니다.

  1. 느리다.
    뭐 아주 못쓸 정도로 느린 건 아닌데…. 이걸로 실무에서 쓴다고 하면 그냥 돈주고 매트랩 쓰는 곳들도 많을 것입니다. 근데 이건 개인적으로는, 리눅스 환경이나 윈도우 환경에서 메모리 엄청 때려박는 환경은 그나마 나을지도요.
  2. MATLAB 대비 지원 기능이 떨어진다.
    자료형 관련부터 시작해서 여러모로 matlab에서는 지원하는 자료형 변수, 함수가 octave에는 없을 수 있습니다. 이런 것들은 코드 만드는데 좀 어려울 수 있는데, 이런 것들도 충분히 코드로 짤 수 있으면 문제 없다고 봅니다.
  3. 프로그래밍 환경만 제공하는 octave는 사용에 제약이 있다.
    매트랩은 수치해석 관련한 여러 툴박스를 가지고 있습니다. 이를 통해서 여러 환경을 지원해줄 수 있는데, 그에 반해서 octave는 코드를 짜서 돌리는 것에만 한정된 환경을 제공하기만 해서, 사용성 관련해서 떨어진다고 볼 수 있습니다.

장점과 단점이 명확하지만, 전 그래도 좋은 접근성을 통해서 여러모로 이용할 수 있는 옥타브를 추천하고 그를 간단한 강의로 사용법을 정리해보고 싶어지더군요. 못하는 것이 아니라 좀 번거로운 것이니깐요. AMD GPU로도 딥러닝, 인공지능을 구현하고 할 수 있지만 굳이 사람들이 CUDA 땜에 엔비디아 GPU로만 딥러닝, 인공지능을 이용하는 것과 같은 거라고 보고 있습니다.

그래서 하나하나 쉬운 걸 해보는 걸로 한 번 쭉 써보고, 이걸 가지고 여러모로 활용하는 내용들도 조금씩 적어서 하나하나 정리해보려고 합니다.

잘부탁합니다~

p.s. 좀 많이 써보고 많은 사람들과 내용 공유도 했으면 좋겠네요. 커뮤도 있긴 할텐데… 그래도 내가 써봐야지 말하기 편하죠. ㅇㅂㅇ

flutter 오류 – Windows Version (Unable to confirm if installed Windows version is 10 or greater)

정말 간만에 블로그에 글 남겨놓습니다. 진짜 바쁩니다. 트위터도 못할 정도로요..ㅠㅠ

뭐, 근황 업뎃하고 밀린 내용 올리고 할 껀데, 일단 요즘 좀 찾은 내용 좀 공유하려고 합니다. 바로 flutter 오류인데… 그냥 모바일 앱 개발만 하시는 분들은 상관 없을텐데, 요즘 나온 stable 버전인 3.7.1 버전 설치하고 나서 flutter doctor -v 하면 아래와 같이 나오는 분들 많을 껍니다. (윈도우 환경입니다.)

윈도우 버전 나왔다면서… 왜 이래..?

윈도우 환경에서 플러터 설치 후에 이렇게 나오면, 뭐 안드로이드 개발쪽에 하려고 하는 거면 별 신경도 안쓸텐데…. 저렇게 뜨는 것도 좀 그럴 껍니다.

게다가 쓰는 환경이 윈도우 11인데….

그래서 일단 저 내용이 뭔지 확인해보니… github 이슈는 이미 closed 되어있네요. 해결 되었다는 건데….

진짜 마지막까지 보면 closed 처리되어있다.

근데 이게 좀 골때리는 것이… 마지막에 나온 해결책이 방금 올린 이미지에 그대로 있다. “master 채널을 이용하라.” 라고요.

……

….수정은 했다. 그러니 그거 써라. 이런 건가…

그래서 일단 말하는대로 master 채널로 이동해서 처리하려고 한다. 하는 방법은 간단하다.

  1. flutter channel
  2. flutter channel master
  3. flutter upgrade

이렇게 하나씩 하면 master 채널로 가서 플러터를 업데이트 하게 된다.

stable 쓰면서 안정적으로 하고 싶었는데… 일단 이걸로 해결 되는지는 봐야지.

플러터 업데이트가 진행되는 것이니 시간은 좀 걸린다. 다 진행되고 나면 flutter doctor -v로 확인해보기로 합니다.

오류는 없어졌습니다.

그러니 github에 나온대로 일단 저 이슈 열려있을 때 사람들이 코드 수정한 거 공유 좀 되더니 master에는 일단 수정이 된 듯 합니다. 근데 아직 stable에는 적용이 안되었나보군요. 현재 master는 보다시피 3.8.0의 pre 버전입니다. stable도 3.8.0 되고 나면 이 오류는 없어져 있겠죠…?

저처럼 별 신경도 쓸 필요도 없는 이 오류가 신경쓰이면, 지금은 일단 master 채널로 이동해서 확인해보시면 될 거 같습니다.

Error: CocoaPods’s specs repository is too out-of-date to satisfy dependencies. (iOS)

아니, 플러터면서 왜 이런 오류가..!

하고 생각할 수 있는 오류를 가져와봤습니다. 협업하면서 한번씩은 겪을 문제인데, 사실 이걸 모르는 분들은 왜 생기는지 몰라할 수 있어서…..

빌드하다가 터지는 녀석…

이런 일이 생기는 건 간단하다. flutter pub이 내가 작업하던 것과 다른 사람이 작업하던 녀석이 충돌해서 그렇다. 내가 개발하다가 넘겨준 부분에 pub 라이브러리를 작업하는 곳에서 새로 업뎃하였다. 그러면서 여러모로 바꿔서 진행한 것도, 새로 추가된 것도 있고..

이러다보니 여러모로 추가된 녀석과 내가 먼저 이용해서 빌드에 이용한 녀석하고 충돌한 거다.

아, 당연하지만, pubspecs.yaml 파일이 충돌한 게 아니다. 이 파일의 내용을 가지고 ios 빌드를 진행해야 하는 CocoaPods가 새로 업뎃해서 받아오고 해야 하는데 그걸 그냥 더 추가하고 넘기는 작업으로만 하다보니 그런 것이다. CocoaPods를 써본 사람들은 알겠지만, 사실 방법 자체는 여러모로 합리적이다. 기존에 이용하는 것들은 이미 .lock 파일로 만들어서 고정해 두고 빠른 작업을 진행하도록 해놓는 것으로 빌드 시간을 단축할 수 있으니깐..

근데 뭐, 내가 쓰다가 이렇게 오류 나면 오류 나는 것이니 풀어줍시다.

내 작업에서 보이면 그냥 오류일뿐…

그럼 어떻게 하는지 하나하나 따라하면 됩니다. 근데 저기서 알려주는 pod repo update는 쳐봤자 오류납니다.

ios 폴더로 들어갑니다.

그리고 이 일의 원흉인 Podfile.lock 파일을 지워줍니다.

그리고는 위와 같이 pod install –repo-update 를 실행해서 repo를 업데이트 해줍니다. 그러면 pubspecs.yaml에 지정한 녀석들을 받아다가 업뎃을 쫙 진행해줍니다.

그리고 나서 다시 플러터 프로젝트의 루트로 올라가서 flutter clean 명령으로 현재 프로젝트의 빌드 관련 정보로 생성한 녀석들을 싹 지워줍니다.

그러고 나서 다시 빌드를 진행하면 문제 없이 빌드되는 것을 알 수 있습니다.

이건 CocoaPods를 좀 이용해보고 하면 금방 해결할 수 있는데, 처음부터 flutter를 접하면서 여러명과 작업하고 그러다 보면 그냥 보이는 오류여서 좀 정리해봤습니다.

간만에 쓴 블로그가 이런 내용인데 도움 좀 되었으면 좋겠군요. ;ㅅ;

요즘 너무 바빠서….

No toolchains found in the NDK toolchains folder for ABI with prefix: arm-linux-androideabi

외주로 플러터 앱 개발 작업을 하고 있는 도중에 이번에 안드로이드 스튜디오가 업데이트 되었더군요. ㅎㅎ….

보통이었으면 업데이트를 안했을 텐데, 왠지 모르게 이건 업데이트를 해야 할 거 같았습니다. 구글 애드몹(AdMob) 적용하는 pub도 안드로이드 업데이트 땜에 맛이 갔던 기억도 있고, Gradle 버전 땜에 짜증났던 경우도 상당히 많았기에 업데이트를 통해서 확인해야 할 듯 하더군요. 이건 또 무슨 문제 터질것인지를 생각하면 진짜….

(근데 iOS에서는 진짜 아무 문제도 없이 잘 실행되던 거 보면 더더욱 열받습니다. 그러니 여러분 제발 아이폰 쓰세요.)

뭐, 저한테 플러터는 지금 버전 업되면서 여러모로 충돌나는 좀 많이 짜증나는 녀석으로 인식이 박히고 있었는데… 이건 좀 경험 공유를 해야 할 거 같습니다.

일단 안드로이드 스튜디오가 업글되고, 개발 화녁이나 API 업글이 되고 나서 갑자기 이런 메시지가 발생하기 시작합니다.

…대놓고 빨간색이야…
으앙….ㅠㅠ

에러 메시지의 주 내용은 제목에 적은 내용 그대로 ndk toolchain을 찾을 수 없다는 내용입니다.

근데 이런 오류가 나면, 보통을 플러터 환경 문제일 것이라고 가장 먼저 떠올릴 수 있습니다. 당연하잔하요. ndk toolchain이 없다니… 이건 뭐 설치 오류 아니겠어요?

근데 이걸 공유하고자 맘먹은 이유는….

flutter doctor, flutter doctor -v로 돌려도 정상으로 나옵니다. 아래처럼 말이죠…

이게 그냥 flutter doctor 돌렸을 때
이건 flutter run -v 돌렸을 때, 도중에 flutter doctor -v를 스스로 돌려서 툴에 문제 있는지 보여주는 화면
….와 이런 오류 진짜 싫습니다….

어떤 크로스플랫폼 이용하는 녀석들 중에 ndk 안쓰는 녀석이 어딨다고?! 이미 설치 다 해놨을텐데 왜?!

진심 최악입니다.

검색해보니 다행이도 쓰레가 있습니다. (링크도 걸어둡니다.) 다른 곳에서 다른 사용자가 비슷하게 질문 올렸는데 전부 이 스레 하나로 통일되어 나옵니다.

정확하게 이 쓰레 딱 하나 나옵니다.

근데 뭐 이 쓰레 제대로 이해 못할 분들을 위해 결론부터 적으면, 안드로이드 스튜디오의 ndk 버전 다운그레이드 하시면 됩니다.

안드로이드 스튜디오에서 SDK Manager를 통해 SDK를 확인하고 SDK Tools에서 NDK가 그냥 체크 표시 되어있는 경우에는 업데이트 하면서 NDK도 그냥 자동으로 업데이트 된 상황인 것입니다. 전 이미 버그 안나도록 다운그레이드 해서 저렇게 되어있을 뿐…

그럼 이전 버전은 어떻게 설치하냐고 물으시면, 아래와 같이 Show Package Details를 클릭하면 설치 가능한 버전들을 보여줍니다.

스레에서 말하는 제일 오류 안나는 버전으로 다운그레이드 했습니다. 다른 건 안건드려도 상관 없습니다.

그리고 원하는 버전의 ndk를 체크하고, 최신 ndk를 체크 해지해서 지워줍니다. 그리고 적용하면 바뀐 버전으로 설치가 진행될 것입니다. (ndk 설치는 시간이 오래 걸립니다.)

그리고 나서 버그난 플러터 프로젝트 다시 빌드하면 저 오류 어디서 튀어나왔냐는 듯이 없어집니다.

진짜 개운해졌습니다…ㅠㅠ

이거 스레 내용이 이해가 제대로 안되어서 정신 차리고 제대로 보고 다시 하느라 솔직히 하루 이틀 날려먹은 것도 어이가 없긴 한데….

ndk 버전 타기 시작하면 진짜 열받습니다. 다행이 지금 쓰고 있는 pub들 중에서 낮춘 ndk에서 문제 안터지게 되었으니 다행인데, 만약 계속 써야 하는 녀석이 ndk 버전 타고 하면 골때려지기 시작하는데….

다른 버전 충돌과 문제인 것은, 보통의 버전 충돌이나 참조 충돌같은 경우에는 각각이 다 독립적인 라이브러리들이다 보니 그냥 버전을 맞춰준다 = 그냥 개발자만 좀 불편해진다에서 끝날 수도 있는데 이런 건 그냥 운영체제 동작환경 자체에도 영향을 주는거니…

차후에 새로운 프로젝트로 해보면서 확인 좀 해봐야겠지만… 이건 좀 많이 위험하네요.

예전에 Cocos2d-X 할 때 생각나서 더 머리아프군요….ㅠㅠ

시간 날려먹은 거 땜빵하러 전 이만…

p.s. 이런 오류 안터지게 잘 개발하는 분들도 있겠지만, 그냥 플러터에 올라온 거 잘 이용하면 뭔 문제 있겠냐 수준의 분들이라면 그냥 더 이상 할 말은 없습니다.

Swift는 배우기 어려운가?

결론적으로 이야기 하면 아니다라고 해야 하는데…. 난감하다.

왜냐..?

매년 버전이 올라가고 있어서 따라가기 힘들어서 배우기 어렵다는 게 맞는 듯 하다.

스위프트도 그렇고, 코틀린, Go 등 요즘 나오는 언어들은 배울 때 어렵게 배우는 것들이 없다고 본다. 공식 홈페이지에 도큐먼트들도 너무 잘나온다.

그런데도 불구하고 왜 아이폰 앱 개발이 어렵다고 하는 걸까에 대해서 밖에서 떠들다가 스위프트가 배우기 어려운 언어인가를 생각하니… 난 개인적으로는 아닌 듯 하다.

것보다 Objective-C를 쉽게 써먹던 나날이 있다보니….

Objective-C가 쉽다면 뭔 변태야라면서 이렇게 반응할 분들이 있긴 하다만….

근데 왜 이럴까..?

버전이 계속, 그것도 빠른시간안에 계속 올라간다는 것은 여러모로 개발자들한테 불안감을 주고 있는 것은 확실하다는 느낌이 든다. 지금 Go 쓰려다가 갈아엎고 다시 이전에 쓰던 것들로 돌아가는 케이스도 너무 봤다. 특정 버전, 특정 환경 기준으로 개발을 했는데 업데이트 된 거에는 그게 맞는건지 아닌지도 모른다… 이거 무지 어려운 거다.

지금 스크립트 언어 중에 그렇게 해서 난이도 개판된 것이 바로 루비랑 레일즈다. 특정 버전에서는 아예 설치 스크립트랑 언어 인스톨러 오류 땜에 일어나는 문제가 개발자 문제인지 어려워할 정도의 시절도 있다. 이게 좀 빨리 고쳐져서 다행이었지만 솔직이 이 때에 뭔 버전이 있었고 뭐가 바뀌었는지는 이미 머릿속에서 지워졌다. 그만큼 오류땜에 시달린 인상이 강하기 땜에….

스위프트도 지금 그런 상황인 듯 하다. iOS 업뎃도 매년 이루어지면서 프레임워크, 개발 환경도 계속 갈아엎혀서 답답한데 거기에 언어까지 그러니 더더욱 답이 없을꺼다.

뭐, 그래도 기본적인 문법 제대로 익히고, 제대로 앱 한번 개발해보고 나면 사실 다 그냥 지나갈 이야기이지만….

그렇다고 이렇게 반응해주진 마세요… 상처입어요. ㅠㅠ

C로 다시보는 알고리즘 01 – 알고리즘이란

어떤 문제를 해결하기 위한 논리나 절차를 알고리즘이라고 한다. 하나의 문제를 해결하기 위한 알고리즘의 형식은 다양하지만, 일반적으로는 사람이 생각하는 알고리즘을 그대로 적용하는 데에는 한계가 있다.

예를 들어서 최대 공약수를 구하는 방법에 대해서 생각하게 되면, 두 수의 약수를 찾는 것은 사람의 경험적 직감에 의존하게 된다. 경험에 따라 문제를 해결하기 위해 접근하는 숫자에 대해서 도중식이 다를 수 있다. 이를 컴퓨터에서 실행한다면 논리가 엄청나게 복잡해지게 된다. 그래서 이를 기계석인 방법(=정형화된 수식화)을 통해서 해결하는데 유클리드 호제법을 이용한다.

그리고 하나의 문제를 해결하기 위해서는 여러 방법이 존재할 수 있다. 이 중에서 가장 적합한 방법의 알고리즘을 찾는 것 또한 중요하다. 그러한 것을 찾기 위해서는 여러 요건들이 존재한다.

  1. 신뢰성이 높을 것
    정밀도가 높고 올바른 결과를 얻을 수 있어야 함.
  2. 처리 효율이 높을 것
    계산 횟수가 적고 처리 속도가 빨라야 한다. 알고리즘의 효율성은 O 표기법(Big-O Notation) 단위를 사용하여 처리하는데, 이에 대해서는 뒤에서 추가로 설명한다.
  3. 일반적일 것
    특정 상황에서만 사용되는 알고리즘이 아닌, 다양한 상황에서 통용될 수 있어야 한다.
  4. 확장성이 있을 것
    변경 사항을 간단하게 수정할 수 있어야 한다.
  5. 알기 쉬울 것
    누가 봐도 알기 쉬워야 한다. 이해하기 힘든 알고리즘은 프로그램의 유지, 보수에 엄청난 걸림돌이 된다.
  6. 이식성이 높을 것
    유용한 프로그램은 다른 곳에서도 사용할 가능성이 높다. 따라서 프로그램의 이식성을 높일 수 있도록 해야 한다. 그 프로그램에서 이용된 알고리즘 또한 마찬가지이다.

이 알고리즘이 학문적일 경우에는 사실 1,2번에만 신경을 써도 된다. 그러나 실제로 사용할 경우에는 어느 정도 나머지 것들에 대해서도 고려를 해야 한다.

또한 컴퓨터에서는 다양한 형테의 데이터를 다루게 되는데, 데이터를 처리하는 데에는 특정한 데이터 구조(자료 구조)를 사용하느냐에 따라서도 문제 해결에 필요한 알고리즘이 생기게 된다. 이 이야기는 “Algorithms + Data Structure = Program” (Prentice-Hall, 1976)이라는 책에서도 언급되었던 내용이다. 데이터 구조와 알고리즘은 밀접한 관련이 있으므로 좋은 데이터 구조를 선택하는 것은 좋은 프로그램을 만드는 기초로 이어지게 된다. (그래서 자료구조도 중요하다)

그래서 이 블로그에서는 알고리즘에 대한 이야기를 주로 작성하지만 일반적인 자료구조에 대해서도 다루게 될 것이다.

프로그래밍 언어가 숙달되는 것에 대한 개인적인 생각

사실 이건 그냥 내 잡소리다. 걍 내 경험 섞인 잡소리….

근데 아무래도 이건 그냥 경험으로 터득하라고만 하기에는 여러모로 느껴지는 게 전혀 다른 이야기들이라…. (결국은 느껴지긴 하는데…. 그걸 위해 도달하는 시간과 방법 차이가 너무 난다.)

프로그래밍 언어는 하나만 제대로 해도 나머진 문제 없다고 하는 이야기들이 오래전부터 전해져옵니다. 근데 이건 뭐 사실 그냥 프로그래밍 언어 하나 제대로 공부하다 보면 여러모로 알게 될 사실이기도 해서 더 이상 설명도 안하고 그냥 그러려니 하고 가르치는 분들도 많습니다만….

요즘은 좀 아닌 듯 하군요. 스크립트 언어들 그냥 바로바로 익힌 후에는 걍 바로 프레임워크들 뭐 있는지 써보고 나서는 거기서 끝나는 경우가 많은가봅니다. 제대로 된 과정 밟다보면 그렇지 않다는 걸 알게 되겠지만 사실 그쪽에서 가르치는 과정에서 주로 배우는 건 자바일꺼고… 자바도 산으로 간다 하면 산으로 가는 교육하기 참 좋은 언어인지라…/먼산

프로그래밍 언어 학습에는 어느 정도 이상이 되면 학습 패턴이 바뀌게 됩니다. 큰 틀로 보게 되면

특정 프로그래밍 언어 -> 언어의 기법, 서법 -> 언어를 이용한 알고리즘

이런 식으로 갑니다. 이 과정들은 학습 과정, 학습하는 사람이 역량에 따라서 숙달되는 정도가 전부 다릅니다. 게다가 이러한 과정들에서 학습 내용은 점점 언어 자체보다는 언어를 통해 표현하고자 하는 것에 그 중점이 옮겨지게 되고, 그를 추상적인 표현을 써서 학습하게 됩니다. 이 학습이 조금이나마 편하기 위해서 언어는 추상적 표현을 얼마나 잘 할 수 있는지제 맞춰서 진화하게 된 것도 있습니다. 그것은 문제 해결 능력으로도 이어지기 때문이죠.

언어를 이용한 알고리즘 쪽으로 갈 경우에는 점점 언어의 형태가 흐려지다 못해서 없어지는 경우도 있습니다. 제가 C언어를 주로 이 블로그에서 작성하고 있습니다만, 알고리즘을 설명하고 할 때에는 C 언어로 코드 동작하는 것까지는 보여주겠지만 알고리즘에 대한 설명 자체는 글 혹은 수도 코드(pseudocode, 프로그램을 작성할 때 각 모듈이 작동하는 논리를 표현하기 위한 언어)를 이용하여 설명하기도 합니다. 그만큼 언어쪽 본질보다는 언어를 통해 해결하고자, 구현하고자 하는 내용쪽에 좀 더 집중하는 모양새가 나오게 되는 것이죠.

그럼 그냥 알고리즘만 따로 배워도 나쁜 거 없지 않겠냐고 생각하겠지만.. 알고리즘 이론이야 추상적인 가상 언어로 표현하여 설명해도 배울 수는 있습니다. 가르치는 입장에서도 솔직히 그냥 걍 수학적인 내용으로 가르치는 게 훨씬 쉽습니다. 하지만 구체적인 언어를 들어서 완전한 프로그램을 보여주고, 그걸 실제로 컴퓨터에 구현해서 하는 편이 이해가 쉽습니다. 우리는 컴퓨터에서 동작하는 알고리즘을 이용해야 하기 때문에 그렇게 배우는 쪽이 훨씬 쉽죠. 컴퓨터에서의 동작 환경에 대해서도 좀 더 깊은 이해를 할 수 있고요…

그래서 한 언어를 깊게 파다보면 해당 언어를 이용한 여러 가지 기법(=패턴)들을 익히고, 그를 이용한 알고리즘 구현 방법까지 해보다 보면 언어를 보다 깊은 추상적인 방법으로 접근할 수 있게 됩니다. 이러한 방법은 유사한 패러다임을 가진 다른 언어에도 쉽게 적용해 볼 수 있게 되므로 새로운 언어를 배울 때 해당 언어를 배우는 러닝 커브가 전혀 다른 구조를 가지게 됩니다. 깊은 이해와 유연한 적용 사고를 가지게 되는 겁니다. 여러 언어를 어느 정도 배워서 구현하는 것도 좋은 능력입니다만 한 가지 언어를 깊게 배우는 것도 나쁘지 않은 선택이 될 수 있는 것이죠.

그래서 요즘은 배우는 트리도 다양하지만 해당 언어마다 초급, 중급, 고급 형태로 난이도를 둬서 언어 기초 -> 언어를 이용한 기법 -> 고급 적용 및 알고리즘 이런 형태로 책들 나오는 것도 이런 내용들이 쌓이고 쌓인 결과라고 생각됩니다.

그렇다고 해서 자바가 거의 뭐 시장을 재패하는 듯한 모 반도 국가는 좀 문제가 심각합니다만…. (딱 요 근래에는 언어만 바뀌었을 뿐 하는 건 비슷비슷한듯…)

어차피 가다보면 깊게 가야 할 판이라면 이 깊게 가는 방향에 대해서도 다시 한 번 생각해보고 싶었다. ㅇㅅㅇ

C로 다시보는 알고리즘 00 – 시작

알고리즘과 디자인 패턴 중에서 여러모로 고민을 좀 많이 했다… 기존에 못썼던 C 내용을 더 쓰긴 할텐데 그거 말고도 내가 뭘 좀 더 해볼까 하는 것을…. 개발 기술이야 뭐 하나하나 느긋하게 올려서 쓰면 된다만…. 활용에 대한 것들을 적다보면 역시 도달하는 과정 중 하나는 알고리즘과 디자인 패턴이기 때문이다.

이 둘에 대해서 고민하는 이유… 내 블로그는 그냥 내가 쓰고싶은대로 글을 만들어 쓰고 있지만 그냥 여러모로 ㅂ고 들어오는 사람들이 맣ㄴ을 꺼라 생각해서 정리해본다.

알고리즘과 디자인 패턴은 컴퓨터공학에서 주로 2~3학년 과목으로 있는데, 이 둘은 주로 개발에 대한 이론적인 것을 다루는 여러모로 골아픈 과목 취급당할 수 있다. 그러나 이 둘을 잘 하는 것은 중요하다. 쉽사리 잘 할 수 있는 과목들은 아니지만 말이다…ㅇㅅㅇ;;;

특히 알고리즘은 프로그래밍 할 때의 문제 해결을 위한 생각의 기초 체력을 올려주는 것에 비유할 수 있다. 반면 디자인 패턴은 문제 해결을 할 수 있는 여러 가지 툴을 써보면서 이 툴을 어떻게 응용해야 할 지를 고민하게 해준다. 둘 다 사고력 업을 위해서 공부하는 것이지만 이 사고의 방향성이 다르게 된다.

이 중에서도 우선적으로 선택한 것이 바로 알고리즘이다. 디자인 패턴은 범위도 너무 넓지만 이렇다할 정답 또한 있는 것이 아니기 때문에…. 그래서 옛날에 공부했던 내용들을 다시 꺼내보면서 하나하나 진행해 보려고 이 챕터를 시작하였다.

참고로 내가 공부할 때에 봤던 자료들을 다시 정립하면서 코드를 짜는 거라 걍 내가 쉽게(?) 할 수 있는 C를 기반으로 작업한다.

….쉽잖아요. C언어….

눈에 보이는대로 그려지듯 개발한다 – 비주얼 프로그래밍 언어에 대한 이야기…

오늘 영업팀 사람과 대화를 하다가 제목과 같은 이야기가 나왔다. 그러면 내 부담 좀 줄여주면서 우리도 개발 도움될 수 있는 거 아닌가 하고… 이렇게만 보면….좀 착한 분이지만…… 정말 많은 문제가 있다. ;ㅅ;

근데 이 이야기를 전에 내가 블로그에 적은 거 같기도 하고 아닌 거 같기도 하고…. 하지만… 또 나오는 이야기인지라 한번 더 적어보련다. 블로그 적는 거에 대해서 몸풀기도 좀 될 듯 하고…ㅇㅅㅇ;;;

글 안쓰다가 쓰면 뭔가 이상하다…;ㅅ;

규링이 2008년도에 대학에 들어갔을 때, 마이크로소프트는 학생들을 위한 사이트를 운영하면서 자신들의 솔루션을 학생 인증을 하면 이용할 수 있는 사이트를 운영하고 있었고, 그때 마이크로소프트의 다양한 솔루션을 볼 수 있었다. 그 중에 있던 것 중에 지금도 생각나는 것이 바로 Microsoft Robotics Developer Studio다. 이게 2006년도에 나와서 당시 닷넷 프레임워크 3.5 기반의 visual studio 2008 이랑 같이 해서 설치해서 이용하면 로보틱스 관련된 프로그래밍을 할 수 있도록 해주는 기반 툴이었는데…. 정말 많은 기능이 있었다. 기본 베이스가 닷넷을 이용한 CCR 기반이었기 때문에 닷넷 프로그래밍에 익숙한 사람들은 닷넷 프로그래밍 기반의 여러 기술들을 이용하여 병렬 테스크, 서비스 기반의 런타임과 메시지 패싱, 멀티플 서비스 관리 등 일반 응용 프로그램 개발하는 듯한 느낌으로 구현할 수 있었기 때문에…

여기서 난 처음으로 visual programming language를 보게 되었다. 데이터플로우 프로그래밍 기반으로 되어 있었기 때문에 기본적인 룰 자체는 내가 다이어그램을 제대로 그리고 짤 줄 안다면 그대로 연결하여 진행하는 것만으로도 뭔가 구현이 되니깐… 신기해서 한참을 썼던 기억이 있다.

사실 뭐 위키피디아에 보면 알겠지만… 수많은 비주얼 프로그래밍 언어들이 존재한다. 예전에 비하면 엄청난 발전들을 하고 있고, no code programming이라는 분야까지 나타날 정도로 진짜 많은 발전이 일어났다. 하드웨어 구현이 가능하고 실시간 시스템까지 구현 할 수 있는 녀석이 나타났다는 것 자체만으로도 언어로써의 구현 범위는 충분한 수준이라고 생각한다. 요즘 최신 언어적인 요소가 없다고 해서 언어로 취급 안하고 하는 건 아니니깐…. (가끔 이런 인간들이 상당히 있는데… C로 비슷한 거 구현해서 보여주면 죄다 버로우 타더라….)

뭐 그래도 여러모로 논의되어야 할 내용들은 존재한다. 구현에 대한 것으로는 언어의 기능을 갖추었다면 이제는 복잡한 문제 해결에 대한 내용을 갖추어야하지만…. 어렵다. 진짜 어렵다. 복잡한 문젤 해결하기 위해서 규링 뿐만 아니라 모든 프로그래머들은 프로그래밍 방법에 대한 여러 가지 방법론을 배웠다. 하지만 이걸 비주얼 프로그래밍에서 유용하게 이용할 수 있는가에 대해서는 여러모로 논란이 된다.

또한 언어 특유의 표현을 위한 자율성보다는 언어에서 지원해주는 대로만 개발해야 하는 제약 또한 많이 발생하게 된다. 당연한 것이겠지만… 이건 정말 어려운 문제다. 똑같은 언어로 개발을 하더라도 규링이랑 규링 밑에 있는 개발자랑도 코드 짜는 스타일부터 시작해서 생각하는 방식이 다 다르기 때문에… 근데 그걸 비주얼 프로그래밍에서도 할 수 있을 것인가에 대해서는 여러모로 논의 좀 되어야 할 부분이겠지만…

그대로 이 분야가 발전한 것에 대해서는 여러모로 공감한다. 여전히 1인 개발, 1인 창작에 대해서는 수요가 있다. 게다가 프로그래밍 언어의 어려움과 복잡함에 있어서는 러닝 커브가 어느 수준 이상 존재하는 건 물론이지만 많은 사람들은 그것과 관계 없이 구현하고 싶어한다. 그로 인해 여러 기술들 사이에 자연스럽게 비슷한 기능들이 녹아들어가는 것이라고 본다.

이러다가 진짜로 그냥 가벼운 앱 개발이 가능한 수준의 비주얼 프로그래밍 언어가 발전할 수도 있겠지만… 그걸로 개발자들을 밀쳐내기에는 어려울 것이다. 그것들의 진화하면 여타 다른 프로그래밍 언어들과 비슷한 것들을 구현할 수 있을 정도가 될 것이고, 그때에는 키보드로 치는 언어 배우는 수준과 같은 수준의 러닝 커브가 생길 테니…

별 쓸데없는 상상에서 시작을 했지만… 그래도 뭐, 생각해봐서 나쁠 건 없는 그런 상상이기도 하고, 지난 10년동안 발전해 온 것들을 보면 어떻게 될 지도 모르는 거라고 생각은 한다. ㅇㅅㅇ;;;