진짜 잡소리입니다만…

개발을 한 프로그램을 배포할 때에는 많은 정보를 작성하게 됩니다. 특히 배포자(게시자)의 이름과 프로그램 지원 링크, 버전 정보, 설치 날짜 같은 정보는 정말 기본 정보이죠. 이 정보들을 통해서 어떤 오류가 발생할 수 있을지를 가장 기초적으로 판단하는 것인데, 프로그램 자체에도 기록이 되어 있지만 배포용 프로그램들에도 기록이 되어 있습니다. IDE들끼리 플러그인으로 연동되어 있으면 이 정보가 자동으로 처리되지만 그렇지 않을 경우에는 해당 프로젝트에서도 관리를 일일이 해줘야 합니다.

이 정보가 왜 중요하냐고 하면 주로 프로그램의 오류 찾기일수도 있지만, 다른 프로그램이 해당 프로그램의 기능을 침범하는 경우에도 회사에 해당 정보를 넘겨 회사끼리 처리하도록 하는 것도 은근 중요합니다. 개인이 대응하는 것보다 훨씬 더 자세하게 대응할 수 있습니다.

그럼 이런 정보는 어디서 찾을까요? 리눅스나 맥의 경우에는 배포 단위에 어느 정도의 프로그램 정보가 들어있습니다.

윈도우 설치 프로그램의 경우에는 설치 정보가 기록되어 있습니다. 프로그램 추가/제거 환경에 보면 정보가 기록되어 있습니다. (윈도우 프로그램의 경우에는 부적절한 예시를 보여드려 죄송합니다.)

그리고 마지막으로, 스토어들의 경우에는 스토어들의 정보가 공유됩니다. 보여드리는 건 앱스토어지만 구글 플레이, 스팀, 플레이스테이션 네트워크 또한 다 마찬가지로 이런 정보들을 가지고 있습니다.

트위터에서 어떤 분이 프로그램간 충돌로 피해를 보신 분이 계시던데, 이런 정보를 통해서 AS 잘 받으실 수 있었으면 하기도 하고, 이젠 슬슬 사람들이 이정도 정보는 알고 있어야 할 것이란 생각도 들어서 한번 적어봤습니다.

다들 알고 있는 이야기이기도 하고…. 이런 글 별로 쓰고 싶진 않은데….좀 열받더라. (그래서 글에 두서도 없이 막 씀.)

잡소리임. 보기 싫은 분들은 꺼도 됨.

사실 유료 컨텐츠를 결제하는 데 있어서 실제 돈이랑 직접 1:1로 연계되는 방식이 제일 신뢰가 가는 방식이다. 그리고 될 수 있으면 초기의 방식 그대로 고수되면서 제도가 안변하는 것이 좋다. 실제로 충전을 하는 입장에서는 충전 한 만큼의 사이버 머니 형태로 전달을 받게 되고, 소정이나마 추가 포인트를 받고 하면 뭔가 더 주는 거 같아서 좋아보이는 것도 있는데 여기에 속으면 곤란하다.

해당 사이트에서만 이용 가능한 형태의 머니가 되면 그 머니를 제어하는 곳은 해당 사이트의 운영자들이다. 즉, 맘대로 할 수 있다는 거다. 그러니 해당 머니가 출리는 이벤도 많이 하고, 광고를 통해서 머니를 풀기도 하는 등 돈만 되면 다 하는 식으로 머니를 관리하게 된다. 그 정점이 되는 것이 바로 포인트제도를 변화하는 것인데, 이때 이득보는 이용자은 없다. 왜냐면 돈을 지불한 순간으로부터는 그 돈에 해당하는 포인트를 1:1로 받는데, 그게 한번이라도 변동을 일으키면 기존 가치와의 차이를 가지게 된다. 그 가치 차액을 이용해서 이용자를 제어할 수도 있다.

가치 차액을 이용하는 것도 두 방법인데, 하나는 서로간의 환율 조정으로 버는 것이고, 나머지는 그에 해당하는 컨텐츠 이용가에 차이를 두어 더 충전하여 사용하도록 하는 것이다. 전자의 경우에는 뭐 골드라는 단위에서 무슨 미라라는 신규 단위로 바뀐다고 가정해보자. 일단 바뀌는 거 자체가 좀 여러모로 눈에 확 튄다. 그래서 그런 일이 일어나면 찾아보기 쉽다. 그리고 이제 얼마로 대응되어서 바꿔주는데, 신뢰도 확 떨어진다. 사이버머니는 운영자가 관리하는 거니 운영자 맘대로 수치를 조정할 수 있는 것이다. 그리고 그 수치에 해당되는 컨텐츠 이용료가 책정되었는지도 운영자가 멋대로 만들기 때문에 당연히 회사에 이득이 되는 형태로 되어 있다. 그렇게 되면 사용자들이 더 결재를 하는 방식으로 바뀌는 경우가 많은데(기존 컨텐트들은 차이를 별로 안두겠지만 신규 컨텐츠부터는 차이를 확실히 두는 형태로 간다. 그래야 사람들이 바뀐 가격에 별 반응 없이 적응한다.), 주로 작은 사이트들에서 발생할 수 있는 형태이지만 실제로 일어나면 사용자들을 제어할 수 없다. 걍 그 바닥을 떠나버리니깐.. 그래서 이런 곳은 콘텐츠 가격으로 후려치고 하는 방식으로 들어간다.

반면 후자는 여러 결제 시스템들이 연동되어서 처리가 되어야 한다. 그래야 차이를 이용자가 스스로 판단하기 어렵다. 예를 들어 모 대형 사이트에서는 자기네 쇼핑 결제 시스템에서 사이버머니를 그대로 원으로 쓰면서 다른 곳에서는 해당 금액만큼의 사이버머니를 별도로 충전해서 쓰는 방식이다. 즉, 거래가 이중으로 처리된다. 수수료 등의 문제 땜에 이렇게 하는 것도 있기도 하고… 뭐 이유는 많은데 이런 건 다중 결제가 가능해야 한다. 그래서 대형 포탈 등에서 써먹기 좋다. 게다가 복수의 결제 시스템을 통합하면서 들어가는 수수료도 만만치는 않을 것이다. 그래서 수수료에 민감하게 굴면 이런 헤괴한 충전 시스템이 나오기도 한다. 중간에 자기들이 미리 충전해둔 것을 환전하는 건 돈이 안들지만 외부 금액이 바뀌는 거에 대해서는 돈이 드니깐. 게다가 직접적으로 돈을 오가는 과정에서 중간에 낀 곳의 경우에는 과정이 단순무식해야 수수료 계산이 쉬워진다. 그리고 은근 수수료 비중을 줄일 수 있는 계기가 되기도 한다. 이건 경영 방침이니 회사마다 다르긴 할텐데…. 중간 마진에 민감해서 바꾼 경우라면 아마 이익하고 연결되어 있는 결정사항이었을 것이다. (그러니 더 이상 설명 안한다.)

솔직히 시스템을 100% 이해하진 못하는 상황에서 이러니 저러니 하는 건 어차피 개소리니 뭐니 하니 잡소리 글로 적었는데…

일단 기업이 손해보고 하는 짓은 아니다. 그 정도는 다 계산한 후에 이루어진 것이다.

요즘 유행하던 FP(함수형 프로그래밍)이던 OOP(객체지향 프로그래밍)이던 절차형 프로그래밍이던, 어떤 것이든 뭐가 좋다 나쁘다 할 것이 이젠 없다. 많이 그리고 정확히 알아두면 좋다.

저것들은 단지 구현을 위한 방법과 그 도구들일 뿐이다. 어떤 방법을 썼을 때 좀 더 간결한 코드를 만들어 쓸 것인지, 좀 더 효율적인 코드를 만들어 쓸 것인지의 차이일 뿐이다.

요즘 개발 환경이 복잡하다는 건 누구나 다 아는 사실이다. 그리고 그를 간단하게 만들기 위해서 여러가지 기법들이 생겨나고 있고, 라이브러리들이 많이 만들어지고 있다. 그 안에 저런 기법, 즉 저런 표현 도구들을 알아서 잘 써먹느냐 아니냐에 따라서도 구현의 질이 달라진다.

함수형 프로그래밍에 대해서 잠깐 공부하면서 봤지만, 실제로 많은 복잡한 내용들을 짧은 코드로 만들 수 있도록 해준다. 그래서 기존에 객체지향으로 했을 때 코드는 복잡해지지만 자료의 구조를 실상에서처럼 잘 구현하고 하던 부분에서 생길 수 있는 복잡함, 그것들을 해결해 줄 수 있는 방법이 되기도 한다. 근데 그건 기존의 개발 패러다임에서도 하나 둘 맞춰서 추가되고 있다. 그것을 그전부터 이해하던 사람들이 보기에는 생소하고 이해하기 어려워서 그렇지.

그리고 각각의 이 도구들과 표현들이 잘 지원되기 위해 서로 공존하는 것 또한 요즘의 환경이다. 윈도우 프로그래밍에서 F#과 C#이 CLR 환경에서 공존하듯, 자바와 스칼라가 JVM에서 공존하듯 하는 것과 같은 이치라고 본다. 그들이 서로 공존하면서 필요에 따라 서로의 패러다임에도 영향을 미친다. 그에 맞게 업데이트도 된다. 도구의 버전이 업데이트 될수록 그 기능들은 개발자들이 익혀서 알아두어야 하는 기능들로 추가가 되고, 언젠가는 쓰일 때가 온다. (어떻게 복잡해질지 몰라서..)

더 많은 이유들이 있긴 하지만, 많이 알아두는 것에 대해서는 나쁠 게 없다. 그리고 그건 원래 개발자들이 가져야만 하는 숙제 같은 것일지도 모른다.

그리고 이제 정확히 알아두는 것. 이건 좀 여러모로 짜증이 많이 났다. 이젠 한번 배워서 써먹었다고 끝나는 시대도 아니고, 지속적으로 업데이트 되면서도 그전에 배운 내용들이 구식이나 이미 없어진 수준의 이야기가 되는 경우도 많다. 근데 이 부정확함만 가지고 지속적으로 나나게 되면… 꼬인다. 제대로 꼬인다. 그렇기에 제대로 알고 덤벼야 한다. 특히나 요즘처럼 처리량도 많고 처리 방법에 대해서도 복잡한 구졸 사용하게 되면 더더욱 정확한 이해와 사용을 요구하게 될 것이다. 요즘 말 많은 빅데이터와 머신러닝 분야도 실제로 코드로 구현하고자 하면 이 복잡한 문제를 해결하려 할 때, 어떤 구조대로 설계를 해봐서 진행해야 하는지를 깊이 생각하는 것이 주고, 그게 코드로 되면 은근 지원되는 거 잘 이용하는 것이 태반인 경우도 많으니…. 정확히 알아두면 그 뒤에 고생은 조금이나마 덜하겠지.

이건 뭐랄까…. 프로그래밍 교육의 실패작이라고 해야 하나..? 아님 대한민국 교육의 실패작이라고 해야 하나…

프로젝트를 하나 구성하려고 하면 거의 열의 아홉은 자바로 하자고 한다. 왜냐고 물으면 여러 답변을 많이 듣는데….

대부분 한번씩은 하는 말이 이거다.

“OOP 다들 배웠으니 OOP대로 하려면 자바로 개발해야지.”

……………….내가 요즘 진짜 수준 낮은 개발자들하고만 주변에 모여서 사나 싶다.
(밖에서 다른 사람들 안만나고 한 죄인가..)

객체지향이니 절차지향이니 요즘 유행하는 함수형이니 하는 건 어차피 가이드라인이다. C++ 환경에서 OOP고 나발이고 그냥 걍 C 스타일로 코딩 쫙 해서 내더라도 제대로 요구사항대로 동작만 한다면 그건 되는 것이다. 요구사항대로 문제를 해결했을 뿐이니깐.

근데 왜 그런 걸 특정 언어와 자꾸 묶는거지? 이해를 못하겠다.

C로 OOP처럼 프로그래밍 한다고 하면 그 코드가 잘못된 코드이고 OOP 적용하려면 자바를 써야 한다는 개소리글을 페이스북에서 본 적이 있어서 혼자서 한번 빡쳤는데… 또 이런 수준의 이야기들이 오고 가는 걸 보니 참….

좋은 기능이다, 유튜브 Red.

유튜브의 기능 확장을 통한 것과 동시에 사업적 수익까지 끌어올 수 있게 되었다.

그러나 없어진 것이 상당히 많다. 특히 나같이 유튜브로 음악 재생하던 사람들은 어제부터 엄청나게 공감을 하고 있을 것이다.

유튜브에는 BGM을 모아서 영상으로 만들어 재생 목록화 시킨 것들이 상당히 많다. 그런 것들 중에 안에 있는 곡 일부가 어디 어디 소속의 작품이라 게시를 할 수 없다거나 저작권으로 인해 중단되었다거나 회원님의 국가에서는 재생할 수 없습니다 등등의 상황이 많이 발생하고 있을 것이다. 즉, 저작권이 강화되었다. 유튜브 뮤직을 보면서 살짝 든 생각이 “유튜브에 있는 음악들에 저작권 적용하려 하는군”이라고 생각했는데.. 단 몇시간되 되지 않아서 저작권으로 짤린 곡들이 상당히 많이 보이고 있다. 한 영상 안에 들어있는 몇 십 곡 중에 단 한곡에 저작권이 걸려서 해당 영상이 완전 짤리는 케이스… 이런 건 Red를 가입한다고 해서 해결되는 것이 아니라는 게 슬픈 상황이다. (Red의 서비스와는 아무 상관없는 시스템적 장치에 의한 거니..)

개인이 직접 만든 곡의 경우에는 걸리지 않으니 뭐 상관은 없겠지만 언제부턴가 자체 창작물의 숫자가 애매해진 유튜브의 경우에는 저작권, 소유권, 국가 제한 등의 제한을 입히면 여러모로 없어질 것들이 많이 있긴 하다. 그 덕에 좋아하는 영상이 많이 없어진다는 것이 좀 슬픈 상황이다.

맨 처음에는 윈도우 8을 가지고 있었고, 작업을 위해 Xubuntu를 설치했었고, 그리고 호기심에 CloudReady를 설치했고, 이제 다시 윈도우 10으로 돌리는 내 바이오…ㅇㅅㅇ

성능이 좋은 녀석도 아니다. 11인치에 AMD APU-E다. 샐러론 수준이다. 램 좀 늘려서 8G에 스스디 500GB 있는 게 장점이랄까..?

이런 성능도 좋지 않은 노트북으로 대체 뭘 하고 싶어서 계속 사용하느냐고 생각한다면…. 걍 일반적인 PC 기능에 가벼운 코드 보고 하는 정도이다. 3D 게임 만들고 하는 건 무리고…(전에 해봤다..)

하지만, 이런 낮은 사양을 사용하다 보면 확실히 느껴진다. 요즘 나오는 운영체제들은 점점 가벼워지고 있다는 걸…

그래서 아까 이 블로그에 Light-weight라는 글 쓰면서 이것저것 가벼워지고 있는 것에 대해서 생각해봤고…

데스크탑 환경이 xfce인 xubuntu도 적절히 최적화 되어 조금 더 가볍게 쓸 수 있어진다는 걸 이 노트북이 가르쳐줬고, 윈도우도 점점 버전 업 되면서 가볍게 사용할 수 있는 운영체제게 되고 있다는 걸 가르쳐준 것도 이 노트북이다.

당분간 윈도우 10으로 고생 좀 해봐라, 바이오. ㅇㅅㅇ

모바일 장치의 성능이 늘었다. 작업을 위해 웹을 주로 이용하는 경우가 증가했다. 씬 클라이언트들이 증가하고 있다. 기존의 프로그램들도 점점 가벼운 프로그램으로 바뀌고 있다. 기능이 많아지면 버려지는 프로그램들도 증가하고 있다. (프로그램의 많은 기능들을 전부 플러그인화 하여 원하는 것들만 설치해서 사용하는 것이라고 보면 쉬울 것이다.)

이것들은 이제 작은 작업에 대해서는 굳이 사양을 따질 필요가 없어지는 것이라고 봐도 될 정도이다. 아직 멀었다고 할 만한 환경들도 많지만 실제로 이용하는 데 있어서의 환경들은 눈에 잘 보이지 않는 환경으로 바뀌고 있고, 점점 가벼운 환경을 원하고 있다. 일단 운영체제부터 많이 가벼워지는 생각이 많이 든다. 사람들이 많이 이용하는 윈도우도 가벼워지고 있고, 맥도 점점 연결하려고 하는 것들에 비해서 약간씩 가볍게 하려는 것이 보인다. (근데 진짜 잘 안보이는 부분에서 작업하고 있다. ㅡㅅㅡ)

다만, 응용 프로그램들의 연구들은 반대로 무거워지는 경우가 많이 보이고 있다. 사실 표현하려고 하는 기능들이나 요즘 유행하는 응용 프로그램들이 점점 고기능의 연산을 하여 무거워지는 것이지, 처리해야 하는 로직이 무겁고 스파게티화 되어있고 한 수준이 아니기 때문에 별 신경 안쓰는 걸지도 모르겠지만… 그런 코드들도 기존의 프로그램들과 같이 무거워지고 꼬일 것이다.이전에 있던 프로그램들도 그 당시에는 잘 만들 것들로 시작했지만 기능이 늘면서 여러모로 꼬이고 꼬인 것이니….

이 제목에 대해서는 지금 잠시 잡소리 같이 되었지만… 중요하게 생각해야 할 문제일지도 모른다. 기회 되면 또 생각해봐야지….

나한테 C#을 배웠던 중딩 녀석이 오늘 아침에 갑자기 나한테 이거 자기가 만든 거라면서 보여줬다. 언리얼로 FPS 게임 하나 만든 거였다.

“흠…..”

이러면서 소스코드 보려고 하는데, 오늘 언리얼에서 제공하는 블루크린트 비주얼 스크립팅을 첨 봤다. ㅇㅅㅇ

이걸 코드로 짜려고 하니 생각보다 많이 어려워서 이걸로 우선 해봤다고 한다. 그러면서 리소스 제작하면서 놀았다고…. (그래. 자사고 가기 전에 놀고싶은 맘은 알겠다만…)

이걸 보니 프로토타입이나 단순한 레벨의 인디 게임은 이런 걸로 우선 만들어보면서 진행할 수는 있겠다는 생각은 들었다. 레벨값 조정이나 그런 걸 위해 단순한 수준이라면 나쁘진 않겠는데.. 만들 때 양쪽 다 병행해서 만들어야 한다는 것이 귀찮긴 하겠다만… 

여러모로 생각이 복잡해졌다. 비주얼 스크립팅이 그대로 설계도가 된다면 이걸로 1차 설계라고 해서 만들어도 될 거 같은데… 그렇게 할 만한 곳이 있을까…./먼산

어떻게 써먹냐에 따른 것이긴 하지만… 비주얼 프로그래밍이 이렇게까지 진행이 잘 되나 해서 그 부분이 더 놀랐다.

하긴, 요즘 스크래치로도 하둡 프로그래밍 하는 시대에 뭘….ㅡㅅㅡ (하둡을 자바로만 해야 한다고 생각하는 ㅂㅅ들만 보다가 저런 거 보면 편하지…)

신문과 뉴스들을 보면 IT라고 말하는 것의 대부분은 딱 잘라 말하면 뻔하다.

• 스마트폰 이야기
• 신제품 출시 소식
• 분기별 회사 수익
• 판매량 정보
• 리뷰어에 의한 분석

그 외에 제대로 된 내용에 대해서 본 적은 거의 없는 듯 하다. 전문지로 가면 확실히 내용들이 좀 충실한 거 같지만, 일반적인 사람들과의 대화에서는 대화가 거의 진행되고 있다고 보여지지 않는다. 과학에 대한 내용도 거의 비실한 정도고, 뭔 기술에 대해서 설명하고자 한다고 한다 해도 틀린 내용이나 초안 쪼금 알고 대충 적는듯한 내용들이 많다.

이런 내용에 대해서는 굳이 IT뿐만 아니라 공학, 과학에 있어서도 마찬가지라고 보여진다. 과학 기술에 대해서 전한다고 해도 그냥 언론에서는 초안에 있는 것이나 어디 유명한 곳에 어떤 기술이 뭐 연구되었다는 기사들을 많이 보지만, 이 내용에 대해서 조금이나마 더 알아서 적으려는 것보다는 그냥 대충 번역만 해서 올리기만 바쁘다. 그래서 욕먹기도 바쁘다.

근데 자신들의 기술들에 대해서 과연 과학자, 공학자, IT 개발자들은 과연 얼마나 언론과 대화를 하고 있을까? 몇몇 기자들이 개발자들을 취재하는 걸 본 적이 있다. 그런데 그들은 거의 전문지에 글을 쓰는 기자들이었다. 그 외에 일반 언론과는 얼마나 대화를 하고 있을까? 특정한 기술에 대해서 제대로 취재하고 하는 쪽은 거의 못 본 거 같다. 기껏 했다고 해도 걍 대기업 홍보팀에서 하는 내용 그대로 베껴 적는 수준으로 끝나고…

일전에 마이크로소프트웨어가 합병되면서 조선일보의 과학 분야가 뭐 좀 더 채워지려나 싶었지만… 실제로 그런 건 없었다. 걍 전문지 하나가 없어졌다. 전문지가 점점 없어지면서 수많은 사람들이 일반적인 언론에서 말하는 과학, 공학, IT 기술들을 접할텐데 그럴 때 접할 수 있는 기술은 과연 얼마나 해당 기술에 대해서 설명할 수 있을지….

이건 과학자, 공학자, IT 개발자들에게만 문제를 물을 수도 없다고 본다. 언론인들도 이 내용에 대해서 한번 제대로 검토해 봐야 한다고 생각한다. 이런 내용들이 우리의 세상을 바꾸는 기술이 되는데, 이런 기술에 대해서 얼마나 잘 전달하여 많은 사람들이 제대로 이해하고 이 기술에 대한 전망이나 미래에 대해서도 제대로 이야기 할 수 있도록 하느냐도 언론의 역할 중 하나가 되고 있다고 생각한다. 이런 부분에 대해서는 눈을 돌리고 광고 대행식의 기사나 자극적인 기술에 대한 기사들을 쓰면서 신기술에 대한 거부감이나 이해도 부족으로 인한 선입관 등을 가지지 않게 하는 것 또한 중요한데, 이런 부분에 대해서 언론이 앞서서 진행하고 있는 것도 있지 않나 생각한다.

적어놓고 보니 결국 어느쪽만의 문제가 아닌 듯 하다. 이런 내용을 진지하게 대화할 수 있는 자리가 있으면 뭔가 더 여러모로 많은 의견이 나올 수 있을텐데 혼자 잡소리로만 적으니 별로 내용이 나오질 않는다..ㅇㅅㅇ;;

이건 진짜 잡소리인데… 좋은 방법일지도 모른다. 진짜로 미친듯이 뜰 것이다.

네이버는 이번에 웨일이라는 웹 브라우저를 냈다. 근데 뭐, 사용기 따윈 이미 흘러 넘칠정도로 많이 있기 때문에 솔직히 걍 검색해 보면 알 것이라 본다. 사용기라기 보다는 광고에 가까운 블로그 글도 있던 거 같은데 그런 건 2차 베타를 써 보시거나 알아서 넘기시길.. (그러니 안쓴다.)

갠적으로는 스페이스 기능인가 그건 요즘 브라우저들 있으면 많이 쓰이긴 하겠단. 단일 모니터로 21:9에 대화면으로 화면 넓게 쓰는 경우도 있는지라 화면 분할 기능이나 그런 거 찾는 분들 많던데, 웹 브라우저로 이것저것 다 하는 곳에서는 저거 쓰면 좀 나을듯.

뭐, 감상은 넘기고…

네이버 웨일은 네이버 페이 이외에도 결제 모듈들과 전자정부 프레임워크 프로그램들을 죄다 품을 생각은 없을까?

진심으로. 이러면 IE와 엑티브 X와 exe 프로그램 까는 걸로 빡돌은 국내 사용자들에게 미친듯한 찬양을 받으면서 브라우저 시장 미친듯이 장악 할 수 있는데…(…..)

이상 미친 잡소리였습니다.

p.s. 올만에 술먹어서 미친 생각 났을 뿐입니다.