프로그래밍

프로그램을 개발하는 행위

* 컴퓨터 관련 정보

||[youtube(HluANRwPyNo)]|| || 사람들이 생각하는 프로그래밍 vs 현실 || 이 영상의 앞부분과 비슷한 일을 하는 사람이 없진 않다. 오퍼레이터 참고. 물론 비상 상황 한정이다.

||[youtube(P12r8DKHsak)]|| || 아폴로 계획 당시의 소프트웨어 제작 영상. 예나 지금이나 노가다다. ||

> 진정으로 능력 있는 프로그래머에게 있어, 코드를 짜는 것은 사고의 부산물에 지나지 않는다. > For a truly gifted programmer, writing code is a side effect of thought.[* 실력있고 경험 많은 프로그래머는 "어떻게 프로그래밍을 할까?"보다 "어떤 프로그램을 만들지?"를 더 많이 생각한다는 뜻.] [* Paul Ford, [비즈니스위크에 기고한 특집 기사에서] ]

Programming

프로그램을 만드는 것을 뜻한다. 그리고 여기에서의 프로그램은 대체로 컴퓨터에서 동작하는 프로그램을 말한다. 따라서 프로그래밍이라고 하면 대개 컴퓨터 프로그래밍을 뜻한다. 기술을 다루는 기술이라고 하기도 한다.

프로그래밍을 하는 도구를 "개발자 도구" 또는 "개발환경"이라고 부르고 (IDE는 그 중 하나이다) 프로그래밍 언어는 프로그래밍을 하는 방식 또는 절차를 말하며 프로그래밍을 하는 사람이 프로그래머다. 개발자라고 해도 되지만 이건 범위가 너무 넓다. 컴퓨터 프로그래머 등 여러 분야에서의 프로그래머 직업이 넘쳐나기 때문이다.

프로그래밍의 프로그래밍인 메타프로그래밍(대표적으로 컴파일러 자체의 프로그래밍, C macro 작성, C++11 template 작성)이 코드를 자동 생성하는 경우를 제외하면, 결국은 사람이 직접 손을 봐야 한다. 심지어 메타프로그래밍도 결국은 사람이 직접 손을 봐야 하므로 프로그래밍은 곧 사람의 일이다. 이론적으로도 그 유명하신 괴델의 ["On Formally Undecidable Propositions of Principia Mathematica and Related Systems"]을 적용하면 결국 프로그래밍의 완전 자동화란 불가능하다는 결론을 내릴 수 있다. 간략히 설명하면, 모든 명제에 대해 완전 자동화된 증명 시스템이 불가능함을 괴델이 보였고, 그러한 증명 시스템 또한 하나의 컴퓨터 프로그래밍에 속하므로, 모든 프로그램을 자동으로 만들 수 있는 컴퓨터는 존재하지 않는다.

예전에는 사람이 수동으로 프로그래밍하던 어셈블리어를 이제는 컴파일러가 자동으로 만들어 준다. 그러나 사람이 할 일은 줄어들지 않았고 그저 능률만 늘었는데, 이는 구현보다 디자인에 더 집중할 수 있게 돼서 더 대규모의 소프트웨어 프로젝트가 가능해졌기 때문이다. 물론 디자인에만 몰두하고 구현은 무시해도 될 정도까지는 아니라 프로그래밍 언어의 세계는 호락호락하지 않은데, 디자인 패턴이라는 것들이 결국은 디자인을 구현으로 옮기는 표준적인 기교들을 소개하고 있다는 것부터가 이를 반증한다.

그리고 이런 고차원 언어들의 약진에도 불구, 아직도 수동으로 어셈블리어 프로그래밍을 하는 경우도 있는데 보통은 성능상의 이유나 명령어 수준에서 본인이 의도한 정확한 동작이 필요할 때 부분적으로 쓴다. 가령 특정한 명령어들이 필요할 때 C언어에서 built-in assembly 형식으로 작성하거나, 일부 소스 파일을 어셈블리로 작성해서 C 소스 파일과 링킹하는 것이 그것이다. 물론 이런 짓을 하면 C언어와 assembly어의 간극을 채우기 위한 추가 노력이 들어가야 한다. 가령 C 컴파일러는 컴파일 과정에서 나름 변수와 메모리 주소의 사용 정보를 트래킹하고 있는데, 중간에 assembly가 끼어서 멋대로 이를 바꿔놓으면 컴파일 과정의 정보가 훼손된다. 따라서 inline assembly를 쓸 때는 해당 assembly statement가 건드리는 데이터들을 정확히 명시해서 컴파일러의 정보가 훼손되지 않도록 막아야 하고, 이를 실수없이 해내는 건 오로지 프로그래머의 몫이다. 결국 안 해본 사람은 의외겠지만 생으로 어셈블리 프로그래밍을 하는 것보다 C언어에 일부 어셈블리 명령을 끼워넣는 게 훨씬 어렵다. 그래서 보통은 가능하면 언어 수준에서 원하는 명령어가 나오도록 컴파일러의 작동을 잘 생각하면서 코드를 짜는 게 더 낫다. 하지만 어느 경우든 컴파일러 작동을 예측하는 지식이 필요한 건 변함이 없다. 그나마 이런 예측이 제일 쉬운 게 C언어이고, 그래서 C언어가 여전히 OS처럼 하드웨어와 밀접한 프로그램 작성에는 탁월한 선택이다. OOP가 언어 자체에서 지원되지 않는 건 조금 아쉽지만, 결국에는 struct와 function pointer를 통해서 기본적인 OOP 개념의 구현은 가능하기에 굳이 머리아프게 C++로 갈 이유가 없는 것이다.

간혹 자신이 목표라 하는 시스템의 Instruction Set Architecture (ISA)에 대한 backend가 아직 컴파일러에서 구현되지 않았으면 기계어로 프로그래밍 하는 수밖에 없다. 그러나 제대로 정신머리가 박힌 회사라면 ISA를 새로 정의하면 컴파일러 부분도 본인들이 지원해준다. 안 그러면 애초에 본인들부터 힘드니까. 이건 심지어 목표로 하는 시스템이 컴파일러를 돌리기에 벅찰 정도로 매우 저렴한 시스템이라도 마찬가지다. 시스템 A에서 시스템 B의 실행 파일을 만드는 cross compilation이라고 하는, 이미 임베디드 개발자들이 사용하고 있는 방법이 있기 때문이다.

대부분의 프로그래밍은 라틴 문자를 그 기반에 둔다. 쉽게 말해 유럽의 알파벳(주로 영어 알파벳)이 프로그램에 쓰인다. 일본어나 한글, 한자 등으로 프로그래밍할 수 있는 도구는 극소수에 불과하다. 이 말은 데이터를 뜻하는 게 아니고 코드를 뜻한다. 코드와 데이터는 서로 개념이 다르니 주의. 어느 나라 사람이든지 영어 잘 못 한다고 남이 짠 코드를 못 읽진 않지만, 일본어나 한글, 한자로 코드를 짠다면 재앙은 불보듯 뻔하다.

시험 과목

고등학교 과목 중 하나

1을 익히는 과목이라고 보면 된다. 주로 전문계 고등학교에서 배우나, 일부 전문계 고등학교에선 교재 내용의 난이도를 이유로 일부러 빼기도 한다. 일부 과학고나 영재고에서도 한다고 한다.

2000년대 초반까지는 '정보산업'이라는 과목으로 BASIC언어가 커리큘럼의 주를 이뤘고, 다른 언어들은 차차 맛뵈기 수준으로 추가되는 수순을 밟았다. 당시에도 사실상 거의 의미가 없어져서 유명무실화된 단원. 제6차 교육과정까지는 프로그래밍 과목 교과서에서 코볼(!) 단원이 남아있었다. 물론 나중에 가면 어느 학교에서도 전혀 가르치지 않았다. '그냥 이런 언어가 있다'는 정도로만 알려줄 뿐.

내용은 C언어가 나오고, 마지막에 C++가 잠깐 나온다. 여기서 만드는 프로그램(예제)들은 그렇게 어렵지 않은 간단한 프로그램이지만, 시중에 나오는 C언어 관련한 책에서 나오는 것과 다르게 내용이 다른 교과서처럼 난해하게 쓰여져 있어, 선생님의 도움을 받지 않는 이상은 극소수를 제외한 대부분은 절대로 읽지 못한다. 아니 교과서를 한 번 읽어봐도 어떤 내용인지 감이 잡히지 않는 경우가 대부분이다. 어떤곳은 비주얼 베이직을 배우기도 한다.

여기서 주로 사용하는 프로그램은 Turbo C. 그렇다, 도스시절에 쓰던 구닥다리 16비트 C 컴파일러이다. 워낙 프로그램이 오래된 구식이다보니, 윈도 XP에서 구동하는 방법까지 친절하게 책에 언급되어있다. 사실 우리가 쓰는 컴퓨터들이 CPU의 발전에 따라 32비트이나 64비트 환경으로 바뀌었고 이제 주 개발환경은 64비트와 멀티 코어 및 멀티 스레드가 되었지만, 교과서에선 아직도 16비트 컴파일러를 고집하는 것은 컴파일러와 CPU의 종류에 구애받지 않는 프로그래머를 육성하려는 교육과학기술부(교육과정 수립 당시에는 교육인적자원부)의 의지가 있기 때문인 듯하다. 실은 가장 기초적인 것이고 국내를 제외하면 어디나라든 갈수 있다는 장점하에 어떤 컴퓨터를 사용할지 모르니 그점을 염두한 것이라고...... 명분은 있다.

2015 개정 교육과정부터 SW교육 강화라는 명목으로 코딩이 필수로 배워야 하는 정보과목에 포함된다고 하는데 인프라의 부족으로 인해 제대로 자리잡을지는 미지수다.

대학수학능력시험 직업탐구 영역의 과목 중 하나

2의 과목으로 출제하는 수능 시험이다.

응시생이 별로 없고, 기본적인 문제들은 프로그래밍을 실전으로 해본 학생들이라면 코웃음을 치면서 풀 수 있다. 그러나, 프로그래밍을 처음 접하는 학생들에게는 높은 난이도로 유명하다.

앞부분의 문제는 기본적인 상식을 요구하거나 간단한 논리 연산을 요구하는 경우가 많지만 뒤로 가면 프로그램 코드를 내면서 출력 결과를 묻게 된다. 어떤 알고리즘이 나올지 예측할 수 없기 때문에 외운다고 되는게 아니고 수리영역과 같은 방식으로 공부해야 한다. 응시 인원도 참담하기 때문에 프로그래밍 경험이 없는 학생은 이 과목에 매달리면 위험하다.

정보올림피아드 대회를 어느정도(비록 예선 탈락 할 수준일지라도) 준비했다면 그다지 어려움을 느끼지 못한다. 실제로 직업탐구 영역 프로그래밍 과목은 1~2문제만 틀려도 2등급이 나올 정도로 쉬운 사람에게는 한없이 쉬운 영역이다.

문제를 푸는 방법

컴퓨터 프로그램이 생겨나기 전에, 프로그램이라는 단어는 알고리즘과 비슷하게 문제를 푸는 방법이라는 의미였다. 대표적인 예가 경제학의 무차별곡선 등에서 사용되는 [| 리니어 프로그래밍 (선형 계획법)].

오픈 소스 도둑질 기업 티맥스 소프트

티맥스 소프트에서 파는 제우스(JEUS) 등 각종 소프트웨어 사실 오픈 소스 소프트웨어 훔쳐다가 껍데기만 다시 만들어서 파는건데.

JEUS 초기 버전 오류 메시지들은 톰캣(Tomcat)과 동일했음. 나중에 걸리니까 오류 메시지 전부 수정함.

한번은 은행인가 하여튼 고객사에 설치된 해외 상용 프로그램 소스 코드 훔쳐다가 비슷한 프로그램 만들어서 팔다가 재판까지 가서 그 프로그램 제작사랑 합의 봄.

뼛속까지 도둑질 근성이 박힌 회사지.

티맥스 윈도우랑 TmaxOS도 처음에는 100% 자체 개발이라고 우기다가 나중에 걸리니까 리눅스랑 BSD 소스 코드 사용한거 실토하고.

티맥스 소프트 박대연 회장이 원래 은행원 하다가 나중에 프로그래밍 배워서 오픈 소스 가져다가 소스 코드 짜집기가 몸에 깊숙히 배어있음.

티맥스 제품은 전부 오픈 소스 도둑질.

웹투비(WebtoB)는 아파치 HTTP 서버(Apache HTTP Server) 소스 코드 훔쳐다 만든거고.

제우스(JEUS)는 아파치 톰캣(Tomcat) 소스 코드 훔쳐서 만들고, 디자인은 오라클 웹로직(WebLogic) 베껴서 만들고.

티베로(Tibero)는 핵심 기능은 마이SQL(MySQL) 소스 코드 훔쳐서 만들고, 디자인은 오라클 데이터베이스 베껴서 만든거다.

티맥스 윈도우, 티맥스OS(TmaxOS), 티맥스 리눅스도 죄다 리눅스, 비에스디(BSD) 유닉스, 크로미엄(크롬), 리브레 오피스, 와인(Wine) 등에서 소스 코드 훔쳐다가 만든거고. 그래놓고 100% 자체 개발한 국내 기술이라고 뻥치다가 걸려서 망신 당함.

예전에 상용 소프트웨어 회사 소스 코드 도둑질로 소송도 여러번 당하고.

http://c2djzrn6qx6kupkn.onion/res/42906.html

큐로컴, 티맥스와 지적재산권 소송서 이겨

2009-06-09

큐로컴(대표 김동준)은 호주의 FNS사와 함께 티맥스소프트(대표 문진일)를 상대로 제기한 컴퓨터 프로그램복제 등 금지에 대한 항소심 재판에서 실질적인 승리를 이끌어 냈다고 9일 밝혔다.

서울고등법원 민사4부(재판장 최성준)는 지난 5월 27일 항소심 판결에서 “티맥스소프트의 ‘프로뱅크(Probank)와 프로프레임(Proframe)’은 큐로컴의 ‘뱅스(Bancs)’를 불법으로 개작한 것”이라며, 해당 프로그램에 대한 배포를 금지하라고 판결한 것.

https://www.boannews.com/media/view.asp?idx=16575

끊이지 않는 티맥스의 저작권 분쟁…왜?

2011.06.23

국내 대표적인 소프트웨어 기업인 티맥스소프트는 아마 가장 많은 저작권 분쟁에 시달리는 소프트웨어 업체일 것입니다. http://ddaily.co.kr/news/article.html?no=79447

Weblogic vs 제우스

2010/03/09

JEUS 초기버전에서

에러메시지가.... WebLogic 에러메시지가 나왔었죠... ㄷㄷㄷㄷ

http://www.slrclub.com/bbs/vx2.php?id=free&no=9319487

티베로db 문법이 오라클과 거의 동일한대 라이센스 받아서 만든건가요??

2017-11-17

음..그렇군요. 이것도 제우스 맹들때 처럼 마이sql 이나 뭐 오픈 소스 참고해서 만들었을까요..? 독자적으로 만들지는 못하는거 같던대..말이죠.

제우스도 웹로직 가져다 만든 sul 있습니다.

https://okky.kr/article/425818

현재 티맥스가 살아나고 있는 이유를 설명해 드리자면 -

2012-08-17

티베로 말씀하시는 것 같은데... 오라클이 맘먹고 소송 걸면 한방에 훅 가기 딱 좋아 보이는데 말이죠...ㅎㅎ 티베로가... 오라클을....ㅂ...ㄲ....(위험한 발언은 여기까지만...ㅋㅋ)

다 알려진건데요 버전 8 을 ㅂ..ㄲ... 뭐 참조했다죠.. 아키텍쳐를... 그리고 티맥스 출신들로 들은바는 국내 특허법으론 오라클이 소송 못건다고도 하더군요.. 그리고 워낙 시장이 작아서 오라클이 상대를 안한다고 하더군요. 그나저나 남의꺼 베끼는 회사는 좀 망했으면좋겠어요 ⓗ

티베로 살짝만 디스어셈블 해도 오라클한테 넙죽 업드려야 되는거 아닌가요?? 오라클에서 미국에 소송하러 오는 차비벌때까지 그냥 놔두는 상황 인거 같은데...

근데 정말 궁금해지네요. 오라클에서 베낀걸 소송걸고 넘어지면... 다 팔아치워야하나 =_=??

티베로 jdbc드라이버 리버싱하면......알듯

2. 근데 티베로는 더 문제라고 생각합니다. 태생적으로 오라클 카피라, license 이슈 생기면 결국 다 오라클로 바꿔야 합니다. 어찌보면 나라에서 쓸데없는 돈 들여가며 Oracle 엔트리버전(?)을 키우는 거라고 보이네요.

https://www.clien.net/service/board/park/3143744

EFM 네트웍스 GPL 위반 논란

GPL 라이선스 위반 문제는 한국의 많은 소프트웨어 업체들이 들키지 않으면 상관 없다는 식으로 암암리에 위반되고 있는 라이센스이다. 예를 들면 티맥스 윈도우, 엘림넷과 하이온넷 사건 등.

EFM 네트웍스 역시 소스코드 미공개로 인한 GPL위반 논란을 2007년부터 받아왔는데, 2017년 8월 30일 기준으로 10년만에 일부 제품[* 공유기에 한해서 웬만한 제품은 다 공개되어 있는 듯하다. NAS는 아직 공개된게 없다.]에 대해서 [코드][* 사이트가 iptime NAS1Dual로 돌아가고 있다. 가끔씩 접속이 안될때가 있는데, ping 때리면 잘 응답한다. 웹서버가 뻗어 버렸을 가능성이 있다. 제품 홍보 차원에서 바람직하지 못하다고 본다. 소스공개를 멈춘게 아니기 때문에, 홈페이지나 고객센터에 연락하면 해결해 준다.] 가 공개되었으며 위반논란은 반쯤 해결되었다. 반쯤이라고 되어 있는 이유는 GPL 약관 상, GPL 라이센스를 적용받는 소스코드를 사용한 바이너리를 배포하는 경우 해당 소프트웨어가 GPL임을 명시함과 소스코드를 제공받을 수 있는 방법을 함께 제공하거나 명시적인 문서 등을 함께 제공해야 하기 때문. 게다가 NAS의 경우 아예 공개되지 않았다.

공개된 GPL 코드에는 컴파일에 필요한 툴체인도 제공하고 있으며 빌드될 수 있도록 환경파일도 포함되어 있으며, 컴파일된 코드는 타켓보드(공유기)에 맞춰 적용할 수 있다. 사소한 문제로 빌드 실패할 수 있으나, 대체로 쉽게 수정 가능하다. 빌드 후 약간 구버전이지만 완전한 펌웨어가 만들어지며, 잘 동작한다.

엘림넷과 하이온넷 사건

엘림넷과 하이온넷 사건은 엘림넷의 직원이 GPL로 배포되는 오픈 소스 소프트웨어의 소스 코드로 만든 제품을 하이온넷으로 이직하면서 소스 코드채로 들고가면서 저작권 분쟁이 일어난 사건이다. GPL에 따르면 GPL을 수정하여 만들어진 파생물은 GPL에 따라 소스 코드를 공개해야하며 이를 어길 시 GPL에 의해 주어진 이용 권리가 무효가 된다. 이는 CCL과 유사한 조항이다.(GPL 자체가 CC BY-SA와 유사하다.) 위의 사건은 GPL로 배포되는 소스 코드를 사용하면서 자신이 수정한 프로그램의 소스 코드를 공개하지 않아 문제가 된 경우이다.

GPL 관련 소송 : 엘림넷 대 하이온넷 사건 - KLDP 토론 https://kldp.org/node/55839
항소심 판결 http://glaw.scourt.go.kr/wsjo/panre/sjo100.do?contId=2035335
상고심 판결 http://glaw.scourt.go.kr/wsjo/panre/sjo100.do?contId=2060892

프로그래밍

Contents