Offcanvas

������

칼럼ㅣ깃허브 코파일럿에서 ‘희망’을 보았다

‘깃허브 코파일럿’이 언제나 적절하고 정확하며 실행 가능한 코드를 생성하는 건 아니지만 어느 정도 유용하다는 점은 부인할 수 없다.  컴퓨터 프로그래밍의 종말은 한두 해 된 이야기가 아니다. 하지만 여러 이유로 종말은 아직 오지 않았다. 가장 중요한 이유를 들자면 프로그래밍이 과학이나 공학이기도 하지만 그만큼이나 예술이기도 하다는 것이다.    ‘AI 동료 프로그래머(AI pair programmer)’라고도 부르는 ‘깃허브 코파일럿(GitHub Copilot)’은 인텔리센스(IntelliSense) 등이 제공할 수 있는 수준을 약간 능가하는 프로그래밍 자동화를 지원하고자 한다.  물론 완전히 자율적이진 않다. 코파일럿이 유의미한 코드를 생성하려면 (개발자가) 먼저 의도를 선언(입력)해야 하고, 또한 코파일럿이 불가피하게 궤도를 이탈하면 이를 정상 궤도로 되돌릴 수 있도록 감독해야 한다.  코파일럿은 비주얼 스튜디오 코드(Visual Studio Code), 젯브레인 IDE(예: 인텔리제이 IDEA(IntelliJ IDEA)), 네오빔(Neovim) 인터페이스를 갖춘 클라우드 서비스다(사용자의 컴퓨터에서 실행되거나 깃허브 코드스페이스의 클라우드에서 실행).  그리고 이 클라우드 서비스는 수십억 줄의 공개된 코드를 학습한 언어 모델 ‘오픈AI 코덱스(OpenAI Codex)’로 구동되는 코드 예측 엔진이다.  여기서 코덱스와 코파일럿에 대한 논란이 있었다. 하지만 코파일럿의 잠재적인 저작권 및 프라이버시 침해에 관해 열변을 토하기 전에, 코덱스가 머신러닝 커뮤니티 내에서 공정 이용(fair use)이라고 간주되는 방식에 따라 공개적으로 사용 가능한 코드를 학습했다는 점을 이해해야 한다.  아울러 코덱스는 검색 엔진이 아니라 코드 합성기(code synthesizer)라는 점도 이해해야 한다.  이와 관련해 코파일럿 개발팀은 “이는 새로운 공간이다. (깃허브는) 이에 ...

깃허브 코파일럿 개발자 코드 자동 완성 컴퓨터 프로그래밍 코드 인텔리센스 비주얼 스튜디오 코드 오픈AI 코덱스

2021.11.10

‘깃허브 코파일럿’이 언제나 적절하고 정확하며 실행 가능한 코드를 생성하는 건 아니지만 어느 정도 유용하다는 점은 부인할 수 없다.  컴퓨터 프로그래밍의 종말은 한두 해 된 이야기가 아니다. 하지만 여러 이유로 종말은 아직 오지 않았다. 가장 중요한 이유를 들자면 프로그래밍이 과학이나 공학이기도 하지만 그만큼이나 예술이기도 하다는 것이다.    ‘AI 동료 프로그래머(AI pair programmer)’라고도 부르는 ‘깃허브 코파일럿(GitHub Copilot)’은 인텔리센스(IntelliSense) 등이 제공할 수 있는 수준을 약간 능가하는 프로그래밍 자동화를 지원하고자 한다.  물론 완전히 자율적이진 않다. 코파일럿이 유의미한 코드를 생성하려면 (개발자가) 먼저 의도를 선언(입력)해야 하고, 또한 코파일럿이 불가피하게 궤도를 이탈하면 이를 정상 궤도로 되돌릴 수 있도록 감독해야 한다.  코파일럿은 비주얼 스튜디오 코드(Visual Studio Code), 젯브레인 IDE(예: 인텔리제이 IDEA(IntelliJ IDEA)), 네오빔(Neovim) 인터페이스를 갖춘 클라우드 서비스다(사용자의 컴퓨터에서 실행되거나 깃허브 코드스페이스의 클라우드에서 실행).  그리고 이 클라우드 서비스는 수십억 줄의 공개된 코드를 학습한 언어 모델 ‘오픈AI 코덱스(OpenAI Codex)’로 구동되는 코드 예측 엔진이다.  여기서 코덱스와 코파일럿에 대한 논란이 있었다. 하지만 코파일럿의 잠재적인 저작권 및 프라이버시 침해에 관해 열변을 토하기 전에, 코덱스가 머신러닝 커뮤니티 내에서 공정 이용(fair use)이라고 간주되는 방식에 따라 공개적으로 사용 가능한 코드를 학습했다는 점을 이해해야 한다.  아울러 코덱스는 검색 엔진이 아니라 코드 합성기(code synthesizer)라는 점도 이해해야 한다.  이와 관련해 코파일럿 개발팀은 “이는 새로운 공간이다. (깃허브는) 이에 ...

2021.11.10

깃허브, ‘코파일럿’에 네오빔·젯브레인 IDE 지원 추가

깃허브가 AI 기반 프로그래밍 어시스턴트 ‘코파일럿(Copilot)’에 코드 편집기 및 언어 지원을 추가했다.  현재 기술 프리뷰(Technical Preview) 상태인 ‘깃허브 코파일럿’이 젯브레인 인텔리J 아이디어(IntelliJ Idea)와 파이참(PyCharm)에 초점을 맞춰 네오빔(Neovim)과 젯브레인 IDE를 추가해 편집기 지원을 확장할 예정이다.    코파일럿은 마이크로소프트의 비주얼 스튜디오 코드 편집기의 확장 프로그램으로 지난 6월 말 공개됐다. 비주얼 스튜디오 IDE 지원은 아직 개발 중이다.  또한 깃허브는 코파일럿이 자바, C, C++, C#에서 여러 줄 코드 완성을 지원한다고 발표했다. 멀티라인 지원은 이 서비스가 자체적으로 여러 줄의 코드를 생성할 수 있다는 것을 의미한다. 아울러 코파일럿은 파이썬, 자바스크립트, 타입스크립트, 루비, 고랭을 지원한다. 개발자는 대기자 명단에 등록해 코파일럿을 사용해볼 수 있다.  코파일럿은 함수 이름, 메소드 이름, 클래스 이름, 주석의 컨텍스트를 바탕으로 코드를 생성 및 합성하여 개발자에게 편집기 내의 전체 코드 줄이나 함수를 제안한다.  한편 자유 소프트웨어 재단(Free Software Foundation)은 코파일럿이 “용납할 수 없고 부당하다”라고 비판하면서, 코파일럿을 사용하려면 상용 소프트웨어(마이크로소프트의 비주얼 스튜디오 IDE 또는 비주얼 스튜디오 코드 편집기)가 필요한 데다 깃허브 호스팅 저장소에서 복사한 코드 조각 및 기타 요소를 사용하는 것은 저작권 침해에 해당한다고 지적했다.  --> “깃허브 코파일럿, 용납할 수 없고 부당하다” 자유 소프트웨어 재단 이 밖에 코파일럿은 소프트웨어 라이선스 위반 가능성과 (코파일럿이 작성하는) 코드 품질에 관한 우려를 불러일으켰다. 작업 시 상당한 양의 인적 개입이 필요하다는 의견도 제시됐다.  --> 칼럼 | '미래는 좀...

깃허브 코파일럿 AI 인공지능 프로그래밍 코드

2021.11.02

깃허브가 AI 기반 프로그래밍 어시스턴트 ‘코파일럿(Copilot)’에 코드 편집기 및 언어 지원을 추가했다.  현재 기술 프리뷰(Technical Preview) 상태인 ‘깃허브 코파일럿’이 젯브레인 인텔리J 아이디어(IntelliJ Idea)와 파이참(PyCharm)에 초점을 맞춰 네오빔(Neovim)과 젯브레인 IDE를 추가해 편집기 지원을 확장할 예정이다.    코파일럿은 마이크로소프트의 비주얼 스튜디오 코드 편집기의 확장 프로그램으로 지난 6월 말 공개됐다. 비주얼 스튜디오 IDE 지원은 아직 개발 중이다.  또한 깃허브는 코파일럿이 자바, C, C++, C#에서 여러 줄 코드 완성을 지원한다고 발표했다. 멀티라인 지원은 이 서비스가 자체적으로 여러 줄의 코드를 생성할 수 있다는 것을 의미한다. 아울러 코파일럿은 파이썬, 자바스크립트, 타입스크립트, 루비, 고랭을 지원한다. 개발자는 대기자 명단에 등록해 코파일럿을 사용해볼 수 있다.  코파일럿은 함수 이름, 메소드 이름, 클래스 이름, 주석의 컨텍스트를 바탕으로 코드를 생성 및 합성하여 개발자에게 편집기 내의 전체 코드 줄이나 함수를 제안한다.  한편 자유 소프트웨어 재단(Free Software Foundation)은 코파일럿이 “용납할 수 없고 부당하다”라고 비판하면서, 코파일럿을 사용하려면 상용 소프트웨어(마이크로소프트의 비주얼 스튜디오 IDE 또는 비주얼 스튜디오 코드 편집기)가 필요한 데다 깃허브 호스팅 저장소에서 복사한 코드 조각 및 기타 요소를 사용하는 것은 저작권 침해에 해당한다고 지적했다.  --> “깃허브 코파일럿, 용납할 수 없고 부당하다” 자유 소프트웨어 재단 이 밖에 코파일럿은 소프트웨어 라이선스 위반 가능성과 (코파일럿이 작성하는) 코드 품질에 관한 우려를 불러일으켰다. 작업 시 상당한 양의 인적 개입이 필요하다는 의견도 제시됐다.  --> 칼럼 | '미래는 좀...

2021.11.02

코드씨(CodeSee), 오픈소스 개발자용 코드베이스 온보딩 포털 공개

컨트리뷰터의 온보딩 프로세스를 용이하게 하는 것을 목표로 OSS 포트(OSS Port) 커뮤니티 사이트는 오픈씨 맵(CodeSee Maps)을 활용하여 오픈소스 코드베이스를 시각적으로 워크스루할 수 있도록 지원한다.    코드씨(CodeSee)가 잠재적 컨트리뷰터를 오픈소스 프로젝트와 연결하고 간편한 온보딩 프로세스를 지원하는 커뮤니티 웹사이트 ‘OSS 포트’를 선보였다. 코드씨는 대규모 코드베이스를 시각화하고 이해하는 데 도움을 주는 도구를 개발한다.  회사에 따르면 이 웹사이트는 개발자가 코드를 작성하는 것보다 이를 이해하는 데 더 많은 시간을 소모하는 상황을 해결하고자 한다.  OSS 포트를 통해 소프트웨어 프로젝트 메인테이너는 코드베이스를 시각화하고 실행 흐름을 매핑하는 기술인 ‘코드씨 맵’을 사용하여 코드베이스에 관한 모범 사례, 지침, 인터랙티브 비주얼 워크스루를 제공할 수 있다(참고로 코드씨 맵은 현재 베타 상태다). 이어서 ‘코드씨 맵’은 고(Go), 자바스크립트(JavaScript), 자바(Java), 파이썬(Python) 코드베이스 전체에서 종속성을 표시할 수 있다고 회사 측은 덧붙였다.  한편 코드씨는 지속적인 코드 이해를 목표로 하향식 및 상향식 관점에서 코드베이스 가시성을 제공하고자 한다. 코드씨 맵은 풀 리퀘스트가 병합될 때마다 업데이트된다.  궁극적으로 코드씨는 온프레미스 소프트웨어까지 제공하는 엔터프라이즈 SaaS 회사로 나아갈 계획이다. 깃허브를 통해 OSS 포트에 프로젝트를 나열할 수 있다. 코드씨는 깃허브의 기술 파트너다. ciokr@idg.co.kr  

코드씨 개발자 코드 코드베이스 워크스루 코드 리뷰 오픈소스 컨트리뷰터 메인테이너 깃허브

2021.10.05

컨트리뷰터의 온보딩 프로세스를 용이하게 하는 것을 목표로 OSS 포트(OSS Port) 커뮤니티 사이트는 오픈씨 맵(CodeSee Maps)을 활용하여 오픈소스 코드베이스를 시각적으로 워크스루할 수 있도록 지원한다.    코드씨(CodeSee)가 잠재적 컨트리뷰터를 오픈소스 프로젝트와 연결하고 간편한 온보딩 프로세스를 지원하는 커뮤니티 웹사이트 ‘OSS 포트’를 선보였다. 코드씨는 대규모 코드베이스를 시각화하고 이해하는 데 도움을 주는 도구를 개발한다.  회사에 따르면 이 웹사이트는 개발자가 코드를 작성하는 것보다 이를 이해하는 데 더 많은 시간을 소모하는 상황을 해결하고자 한다.  OSS 포트를 통해 소프트웨어 프로젝트 메인테이너는 코드베이스를 시각화하고 실행 흐름을 매핑하는 기술인 ‘코드씨 맵’을 사용하여 코드베이스에 관한 모범 사례, 지침, 인터랙티브 비주얼 워크스루를 제공할 수 있다(참고로 코드씨 맵은 현재 베타 상태다). 이어서 ‘코드씨 맵’은 고(Go), 자바스크립트(JavaScript), 자바(Java), 파이썬(Python) 코드베이스 전체에서 종속성을 표시할 수 있다고 회사 측은 덧붙였다.  한편 코드씨는 지속적인 코드 이해를 목표로 하향식 및 상향식 관점에서 코드베이스 가시성을 제공하고자 한다. 코드씨 맵은 풀 리퀘스트가 병합될 때마다 업데이트된다.  궁극적으로 코드씨는 온프레미스 소프트웨어까지 제공하는 엔터프라이즈 SaaS 회사로 나아갈 계획이다. 깃허브를 통해 OSS 포트에 프로젝트를 나열할 수 있다. 코드씨는 깃허브의 기술 파트너다. ciokr@idg.co.kr  

2021.10.05

오픈AI, 깃허브 코파일럿 AI 모델의 API 제공한다

AI 기반 코딩 도구 ‘깃허브 코파일럿(GitHub Copilot)’을 공동 개발한 인공지능 R&D 연구소 오픈AI(OpenAI)가 코파일럿을 구동하는 모델의 API 버전을 릴리즈했다.    8월 10일(현지 시각) 오픈AI가 자연어를 코드로 변환하는 AI 시스템 ‘오픈AI 코덱스(OpenAI Codex)’의 개선된 버전을 API를 통해 비공개 베타로 공개했다. 코덱스는 비주얼 스튜디오 코드(Visual Studio Code) 확장 프로그램으로 제공되는 코파일럿을 구동하는 모델이다.  --> 깃허브 코파일럿, 개발자 반응은?··· "놀랍도록 유용"vs"아직 미흡" --> 칼럼 | '미래는 좀처럼 오지 않는다'··· 깃허브 코파일럿을 둘러싼 호들갑 오픈AI에 따르면 코덱스 모델은 12개 이상의 프로그래밍 언어에 능숙하다. 코덱스는 자연어로 된 간단한 명령어를 해석하고 사용자 대신 실행할 수 있어 기존 애플리케이션에 자연어 인터페이스를 구축할 수 있다. 오픈AI 코덱스는 GPT-3의 후속작이다. GPT-3 AI API는 검색, 대화, 텍스트 완성과 같은 애플리케이션에 사용돼 왔다.  오픈AI는 코덱스가 파이썬에 가장 적합하지만 자바스크립트, 고랭, PHP, 루비, 스위프트, 타입스크립트 등에도 능숙하다고 밝혔다. 오픈AI 코덱스는 GPT-3의 자연어 이해도를 갖춘 동시에 작업 코드를 생성한다. 또한 범용 프로그래밍 모델인 코덱스는 기본적으로 모든 프로그래밍 작업에 적용할 수 있다고 연구소 측은 전했다. 오픈AI는 이를 변환뿐만 아니라 코드 설명 및 리팩토링에도 활용할 수 있다고 덧붙였다.  한편 현재 테크니컬 프리뷰 단계에 있는 깃허브 코파일럿은 지난 7월 초 출시된 이후 비판을 받고 있다. 자유 소프트웨어 재단(The Free Software Foundation)은 이 기술을 “용납할 수 없고 부당하다”라면서 반기를 들고 나섰다. --> “깃허브 ...

오픈AI 깃허브 깃허브 코파일럿 인공지능 자연어 코드 코덱스 GPT-3 소프트웨어 개발

2021.08.13

AI 기반 코딩 도구 ‘깃허브 코파일럿(GitHub Copilot)’을 공동 개발한 인공지능 R&D 연구소 오픈AI(OpenAI)가 코파일럿을 구동하는 모델의 API 버전을 릴리즈했다.    8월 10일(현지 시각) 오픈AI가 자연어를 코드로 변환하는 AI 시스템 ‘오픈AI 코덱스(OpenAI Codex)’의 개선된 버전을 API를 통해 비공개 베타로 공개했다. 코덱스는 비주얼 스튜디오 코드(Visual Studio Code) 확장 프로그램으로 제공되는 코파일럿을 구동하는 모델이다.  --> 깃허브 코파일럿, 개발자 반응은?··· "놀랍도록 유용"vs"아직 미흡" --> 칼럼 | '미래는 좀처럼 오지 않는다'··· 깃허브 코파일럿을 둘러싼 호들갑 오픈AI에 따르면 코덱스 모델은 12개 이상의 프로그래밍 언어에 능숙하다. 코덱스는 자연어로 된 간단한 명령어를 해석하고 사용자 대신 실행할 수 있어 기존 애플리케이션에 자연어 인터페이스를 구축할 수 있다. 오픈AI 코덱스는 GPT-3의 후속작이다. GPT-3 AI API는 검색, 대화, 텍스트 완성과 같은 애플리케이션에 사용돼 왔다.  오픈AI는 코덱스가 파이썬에 가장 적합하지만 자바스크립트, 고랭, PHP, 루비, 스위프트, 타입스크립트 등에도 능숙하다고 밝혔다. 오픈AI 코덱스는 GPT-3의 자연어 이해도를 갖춘 동시에 작업 코드를 생성한다. 또한 범용 프로그래밍 모델인 코덱스는 기본적으로 모든 프로그래밍 작업에 적용할 수 있다고 연구소 측은 전했다. 오픈AI는 이를 변환뿐만 아니라 코드 설명 및 리팩토링에도 활용할 수 있다고 덧붙였다.  한편 현재 테크니컬 프리뷰 단계에 있는 깃허브 코파일럿은 지난 7월 초 출시된 이후 비판을 받고 있다. 자유 소프트웨어 재단(The Free Software Foundation)은 이 기술을 “용납할 수 없고 부당하다”라면서 반기를 들고 나섰다. --> “깃허브 ...

2021.08.13

깃허브 코파일럿, 개발자 반응은?··· "놀랍도록 유용"vs"아직 미흡"

마이크로소프트의 자회사 ‘깃허브(GitHub)’가 ‘오픈AI(OpenAI)’와 함께 자동화된 제안을 통해 코드 작성을 돕는 AI 도구를 개발하고 있다. 여기서는 초기 사용자들의 반응을 살펴본다.  지난 6월 29일 깃허브가 ‘코파일럿(Copilot)’을 프라이빗 베타로 발표했다. (깃허브에서) ‘AI 페어 프로그래머(Pair Programmer)’라고도 부르는 이 도구는 마이크로소프트 비주얼 스튜디오 코드(Visual Studio Code)에서 베타 사용자용 확장 프로그램으로 설치해 사용해볼 수 있다.  코파일럿은 개발자가 코드를 작성할 때 이메일 애플리케이션(예: 지메일(Gmail))의 자동 완성 기능처럼 파이썬(Python), 자바스크립트(JavaScript), 타입스크립트(TypeScript), 루비(Ruby), 고(Go) 등의 프로그래밍 언어로 작성된 코드를 제안한다.  깃허브는 일론 머스크, 샘 알트만 등이 설립하고, 지난해 마이크로소프트가 미화 10억 달러를 투자한 인공지능 연구소 ‘오픈AI’와 협력해 코파일럿을 개발했다. 오픈AI는 코덱스(Codex)라고 불리는 모델을 사용해 컴퓨터 코드에 GPT-3 언어 예측 모델을 적용했다.  물론 뉴럴 네트워크에 코드 작성을 학습시키는 건 새로운 시도는 아니다. 탭나인(TabNine), 카이트(Kite) 등의 스타트업이 비슷한 프로젝트를 하고 있다. 하지만 마이크로소프트라는 빅테크 기업과 오픈AI 간의 긴밀한 협력은 코파일럿이 처음부터 강력한 시장 참여자라는 것을 의미한다.   독일의 사이버보안 회사 드라고스(Dragos)의 수석 프론트엔드 개발자 필립 존 바실은 이러한 AI 코딩 비서 도구들을 사용해 본 적이 있지만 코파일럿은 이미 ‘다른 수준’에 있다고 <인포월드(InfoWorld)>와의 인터뷰에서 말했다.  이번 코파일럿 공개는 확실히 큰 반향을 일으켰다. 단 이틀 만에 ‘해커 뉴스(Hacker News; 오픈소스 개발자들의 소...

마이크로소프트 깃허브 오픈AI 코파일럿 인공지능 코드 개발자 페어 프로그래밍 자동 완성 파이썬 자바스크립트 타입스크립트 루비 고랭 코덱스 소프트웨어 개발

2021.07.12

마이크로소프트의 자회사 ‘깃허브(GitHub)’가 ‘오픈AI(OpenAI)’와 함께 자동화된 제안을 통해 코드 작성을 돕는 AI 도구를 개발하고 있다. 여기서는 초기 사용자들의 반응을 살펴본다.  지난 6월 29일 깃허브가 ‘코파일럿(Copilot)’을 프라이빗 베타로 발표했다. (깃허브에서) ‘AI 페어 프로그래머(Pair Programmer)’라고도 부르는 이 도구는 마이크로소프트 비주얼 스튜디오 코드(Visual Studio Code)에서 베타 사용자용 확장 프로그램으로 설치해 사용해볼 수 있다.  코파일럿은 개발자가 코드를 작성할 때 이메일 애플리케이션(예: 지메일(Gmail))의 자동 완성 기능처럼 파이썬(Python), 자바스크립트(JavaScript), 타입스크립트(TypeScript), 루비(Ruby), 고(Go) 등의 프로그래밍 언어로 작성된 코드를 제안한다.  깃허브는 일론 머스크, 샘 알트만 등이 설립하고, 지난해 마이크로소프트가 미화 10억 달러를 투자한 인공지능 연구소 ‘오픈AI’와 협력해 코파일럿을 개발했다. 오픈AI는 코덱스(Codex)라고 불리는 모델을 사용해 컴퓨터 코드에 GPT-3 언어 예측 모델을 적용했다.  물론 뉴럴 네트워크에 코드 작성을 학습시키는 건 새로운 시도는 아니다. 탭나인(TabNine), 카이트(Kite) 등의 스타트업이 비슷한 프로젝트를 하고 있다. 하지만 마이크로소프트라는 빅테크 기업과 오픈AI 간의 긴밀한 협력은 코파일럿이 처음부터 강력한 시장 참여자라는 것을 의미한다.   독일의 사이버보안 회사 드라고스(Dragos)의 수석 프론트엔드 개발자 필립 존 바실은 이러한 AI 코딩 비서 도구들을 사용해 본 적이 있지만 코파일럿은 이미 ‘다른 수준’에 있다고 <인포월드(InfoWorld)>와의 인터뷰에서 말했다.  이번 코파일럿 공개는 확실히 큰 반향을 일으켰다. 단 이틀 만에 ‘해커 뉴스(Hacker News; 오픈소스 개발자들의 소...

2021.07.12

칼럼ㅣ 노코드와 로우코드 그리고 코딩의 미래는?

‘노코드(No-code)’와 ‘로우코드(Low-code)’ 기술이 갈수록 발전하고 있다. 그렇다면 이제 코딩을 배워야 할 필요가 있을까?    英 IT 채용 전문 업체 CW잡스(CWJobs)는 최근 보고서를 통해 영국에서 비기술직의 절반 이상이 기술직으로의 이직을 고려하고 있다고 밝혔다. 많은 사람들이 기술 세계에서 자신의 위치를 탐색하고 있다는 건 놀라운 일이 아니다. 의료, 금융, 법률, 교육 등을 포함한 산업 전반에 걸쳐 기술 투자가 증가하고 있기 때문이다. 이제 기업이나 산업이 기술에 영향을 받지 않거나 변화되지 않는다고 상상하기 어려울 정도다.    그러나 해당 보고서에 따르면 기술 역량을 배우고 개발하고자 하는 비기술직이 늘어났지만 그렇다고 해서 코딩 기술이 전적으로 필요한 건 아니다. 노코드와 로우코드 덕분이다.  노코드와 로우코드의 등장은 기술 지식이 없는 사람들이 처음부터 다시 배울 필요 없이 기술 분야에서 시작할 기회를 가질 수 있다는 것을 의미한다. 이는 향후 개발자의 역할에 어떤 의미를 가지는가? 코딩을 배울 필요가 없는 미래를 보게 될까? ‘전문 기술의 민주화’가 많은 기회를 제공할 것이다 노코드·로우코드 플랫폼의 가장 큰 이점은 전담 IT팀이 없는 조직이 맞춤형 솔루션을 구축하고 실행할 수 있다는 것이다. 이는 더욱더 빠르고 통합된 방식이기 때문에 직접적인 도움이 된다.  또한 노코드와 로우코드는 개발자에 의존하는 비율, 도입과 관련된 기술적 장벽을 크게 낮춰 애플리케이션 사용을 민주화할 것이다. 물론 초창기에는 이로 인한 비용이 들겠지만 장기적으로 보면 이 솔루션은 전담 데브옵스 팀이 없는 기업에는 더 저렴한 옵션이 될 것이다.  AI 사용 사례 시나리오로 보자면 노코드·로우코드는 본질적으로 AI의 민주화를 가능하게 한다. 사전 구축된 알고리즘과 간단한 드래그 앤드 드롭 워크플로우를 지원하는 AI 개발 플랫폼을 통해 비기술직 인력들이 쉽고 간편하게 기술을 구현...

노코드 로우코드 시민 개발자 코딩 코드 프로그래머 개발자 하이브리드 인력 인공지능 머신러닝 데브옵스 소프트웨어 소프트웨어 개발

2021.01.04

‘노코드(No-code)’와 ‘로우코드(Low-code)’ 기술이 갈수록 발전하고 있다. 그렇다면 이제 코딩을 배워야 할 필요가 있을까?    英 IT 채용 전문 업체 CW잡스(CWJobs)는 최근 보고서를 통해 영국에서 비기술직의 절반 이상이 기술직으로의 이직을 고려하고 있다고 밝혔다. 많은 사람들이 기술 세계에서 자신의 위치를 탐색하고 있다는 건 놀라운 일이 아니다. 의료, 금융, 법률, 교육 등을 포함한 산업 전반에 걸쳐 기술 투자가 증가하고 있기 때문이다. 이제 기업이나 산업이 기술에 영향을 받지 않거나 변화되지 않는다고 상상하기 어려울 정도다.    그러나 해당 보고서에 따르면 기술 역량을 배우고 개발하고자 하는 비기술직이 늘어났지만 그렇다고 해서 코딩 기술이 전적으로 필요한 건 아니다. 노코드와 로우코드 덕분이다.  노코드와 로우코드의 등장은 기술 지식이 없는 사람들이 처음부터 다시 배울 필요 없이 기술 분야에서 시작할 기회를 가질 수 있다는 것을 의미한다. 이는 향후 개발자의 역할에 어떤 의미를 가지는가? 코딩을 배울 필요가 없는 미래를 보게 될까? ‘전문 기술의 민주화’가 많은 기회를 제공할 것이다 노코드·로우코드 플랫폼의 가장 큰 이점은 전담 IT팀이 없는 조직이 맞춤형 솔루션을 구축하고 실행할 수 있다는 것이다. 이는 더욱더 빠르고 통합된 방식이기 때문에 직접적인 도움이 된다.  또한 노코드와 로우코드는 개발자에 의존하는 비율, 도입과 관련된 기술적 장벽을 크게 낮춰 애플리케이션 사용을 민주화할 것이다. 물론 초창기에는 이로 인한 비용이 들겠지만 장기적으로 보면 이 솔루션은 전담 데브옵스 팀이 없는 기업에는 더 저렴한 옵션이 될 것이다.  AI 사용 사례 시나리오로 보자면 노코드·로우코드는 본질적으로 AI의 민주화를 가능하게 한다. 사전 구축된 알고리즘과 간단한 드래그 앤드 드롭 워크플로우를 지원하는 AI 개발 플랫폼을 통해 비기술직 인력들이 쉽고 간편하게 기술을 구현...

2021.01.04

AI 기반 코드 자동 완성 도구 '카이트', 지원 언어 11종 추가

AI 기반의 코드 자동 완성 툴, 카이트(Kite)가 21일(현지 시각) 11종의 프로그래밍 언어 지원을 추가했다고 발표했다.    카이트는 머신러닝 모델을 기반으로 코드 자동 완성 기능을 제공한다. 초창기 해당 솔루션은 파이썬만 지원했다. 그리고 지난 5월 자바스크립트(Javescript) 지원을 추가했다고 밝히면서, 향후 지원 언어를 확대할 계획이라고 회사 측은 전했다.  이번에 추가된 새 지원 언어는 ▲자바(Java), ▲C/C++, ▲코틀린(Kotlin), ▲오브젝티브 C(Objective C), ▲타입스크립트(Typescript), ▲스칼라(Scala), ▲C#, ▲HTML/CSS, 고랭(Golang),▲ 레스(Less)다.  카이트는 머신러닝 모델을 사용해 사용자가 입력하려는 코드를 예측하여 자동 완성 제안을 한다. 또한 다른 사용자가 유사한 상황에서 작성했던 코드를 기반으로 맥락을 파악해 예측을 제안하기도 한다. 회사에 따르면 현재 카이트는 매일 약 175개의 코드 단어를 쓰고 있다.  또한 카이트는 비주얼 스튜디오 코드(Visual Studio Code), 젯브레인 IDE(Jetbrains IDE), 주피터랩(JupyterLab), 서브라임(Sublime), 아톰(Atom) 등을 포함한 대부분의 인기 개발환경을 지원한다.  무료 버전과 유료 엔터프라이즈 버전 두 가지로 제공된다. 무료 버전은 이곳에서 다운로드받을 수 있다. ciokr@idg.co.kr  

인공지능 AI 머신러닝 딥러닝 코드 코드 자동 완성 카이트 프로그래밍 언어 개발 언어 자바스크립트 파이썬 고랭 코틀린 스칼라 비주얼 스튜디오 코드

2020.10.22

AI 기반의 코드 자동 완성 툴, 카이트(Kite)가 21일(현지 시각) 11종의 프로그래밍 언어 지원을 추가했다고 발표했다.    카이트는 머신러닝 모델을 기반으로 코드 자동 완성 기능을 제공한다. 초창기 해당 솔루션은 파이썬만 지원했다. 그리고 지난 5월 자바스크립트(Javescript) 지원을 추가했다고 밝히면서, 향후 지원 언어를 확대할 계획이라고 회사 측은 전했다.  이번에 추가된 새 지원 언어는 ▲자바(Java), ▲C/C++, ▲코틀린(Kotlin), ▲오브젝티브 C(Objective C), ▲타입스크립트(Typescript), ▲스칼라(Scala), ▲C#, ▲HTML/CSS, 고랭(Golang),▲ 레스(Less)다.  카이트는 머신러닝 모델을 사용해 사용자가 입력하려는 코드를 예측하여 자동 완성 제안을 한다. 또한 다른 사용자가 유사한 상황에서 작성했던 코드를 기반으로 맥락을 파악해 예측을 제안하기도 한다. 회사에 따르면 현재 카이트는 매일 약 175개의 코드 단어를 쓰고 있다.  또한 카이트는 비주얼 스튜디오 코드(Visual Studio Code), 젯브레인 IDE(Jetbrains IDE), 주피터랩(JupyterLab), 서브라임(Sublime), 아톰(Atom) 등을 포함한 대부분의 인기 개발환경을 지원한다.  무료 버전과 유료 엔터프라이즈 버전 두 가지로 제공된다. 무료 버전은 이곳에서 다운로드받을 수 있다. ciokr@idg.co.kr  

2020.10.22

'뜻밖의 선물'같은 팁··· '깃(Git)' 고급 명령어 5가지

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

개발자 커밋 디버깅 리포지토리 브랜치 머지 풀 리퀘스트 깃 리베이스 스쿼시 버그 코드 체리픽 서브모듈

2020.06.12

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

2020.06.12

"AI로 파이썬 코드 완성"··· 카이트, 자바스크립트 지원

머신러닝 모델을 기반으로 코드 자동 완성 기능을 제공하는 카이트(Kite)가 자바스크립트를 학습한 머신러닝 모델을 애드온으로 추가했다. 주요 코드 편집기 및 IDE와 통합할 수 있다. 카이트 개발팀이 5월 12일 AI 기반 파이썬용 코드 자동 완성 툴, 카이트(Kite)에 자바스크립트 지원을 추가했다고 발표했다. 이밖에 고급 기능을 추가한 카이트 유료 버전도 함께 선보였다.   카이트는 파이썬과 자바스크립트 코드 각각으로 구축한 머신러닝 모델을 사용해 사용자가 입력하려는 코드를 예측하여 자동 완성 기능을 제공한다. 이는 정적 코드뿐만 아니라 코드로부터 얻은 추상구문트리(Abstract Syntax Tree)를 학습한다. 또한 사용자와 다른 개발자가 유사한 상황에서 작성했던 코드를 기반으로 맥락을 파악해 예측을 제안한다. 카이트는 초창기 파이썬만 지원했지만 카이트 개발팀은 지원 언어를 확대할 계획이라고 밝힌 바 있다. 그리고 자바스크립트가 바로 그 첫 번째 언어다. 이번에 추가된 카이트 머신러닝 모델은 자바스크립트 기반 프레임워크인 리액트(React), 뷰(Vue), 앵귤러(Angular), 노드.js(Node.js)를 포함해 주로 사용되는 자바스크립트 패키지에서 수집된 동작 데이터세트를 기반으로 한다.  비주얼 스튜디오 코드(Visual Studio Code) 및 아톰(Atom)을 포함한 대부분의 주요 개발 환경과 통합해 사용할 수 있다. 해당 툴은 로컬로 설치되며 클라우드 연결이 필요 없다. 모든 예측 기능이 자체 시스템에서 이뤄지고 제공된다.  카이트는 기본적으로 개인적 용도는 물론 상업적 용도에도 무료로 사용할 수 있다. 새로 출시된 유료 버전인 카이트 프로(Kite Pro)는 몇 가지 고급 기능이 추가됐다. 주요 추가 기능에는 데이터 딕셔너리(data in dictionaries), 앨리어스 가져오기(import aliases), 코드 스니펫(code snippets)을 포함한 딥러닝 기반으로 생성된 한 줄(sin...

자바스크립트 자동코드완성 비주얼스튜디오코드 리액트 앵귤러 딥러닝 머신러닝 파이썬 아톰 인공지능 AI 코드 카이트

2020.05.14

머신러닝 모델을 기반으로 코드 자동 완성 기능을 제공하는 카이트(Kite)가 자바스크립트를 학습한 머신러닝 모델을 애드온으로 추가했다. 주요 코드 편집기 및 IDE와 통합할 수 있다. 카이트 개발팀이 5월 12일 AI 기반 파이썬용 코드 자동 완성 툴, 카이트(Kite)에 자바스크립트 지원을 추가했다고 발표했다. 이밖에 고급 기능을 추가한 카이트 유료 버전도 함께 선보였다.   카이트는 파이썬과 자바스크립트 코드 각각으로 구축한 머신러닝 모델을 사용해 사용자가 입력하려는 코드를 예측하여 자동 완성 기능을 제공한다. 이는 정적 코드뿐만 아니라 코드로부터 얻은 추상구문트리(Abstract Syntax Tree)를 학습한다. 또한 사용자와 다른 개발자가 유사한 상황에서 작성했던 코드를 기반으로 맥락을 파악해 예측을 제안한다. 카이트는 초창기 파이썬만 지원했지만 카이트 개발팀은 지원 언어를 확대할 계획이라고 밝힌 바 있다. 그리고 자바스크립트가 바로 그 첫 번째 언어다. 이번에 추가된 카이트 머신러닝 모델은 자바스크립트 기반 프레임워크인 리액트(React), 뷰(Vue), 앵귤러(Angular), 노드.js(Node.js)를 포함해 주로 사용되는 자바스크립트 패키지에서 수집된 동작 데이터세트를 기반으로 한다.  비주얼 스튜디오 코드(Visual Studio Code) 및 아톰(Atom)을 포함한 대부분의 주요 개발 환경과 통합해 사용할 수 있다. 해당 툴은 로컬로 설치되며 클라우드 연결이 필요 없다. 모든 예측 기능이 자체 시스템에서 이뤄지고 제공된다.  카이트는 기본적으로 개인적 용도는 물론 상업적 용도에도 무료로 사용할 수 있다. 새로 출시된 유료 버전인 카이트 프로(Kite Pro)는 몇 가지 고급 기능이 추가됐다. 주요 추가 기능에는 데이터 딕셔너리(data in dictionaries), 앨리어스 가져오기(import aliases), 코드 스니펫(code snippets)을 포함한 딥러닝 기반으로 생성된 한 줄(sin...

2020.05.14

'리팩터링, 린트, 프로필...' 완료된 코드를 추가 개선하는 16가지 팁

작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴...   이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.   그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.   잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.   린트 린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.   프로필 돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. ...

코드 서버리스 리팩터링 린트

2020.03.05

작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴...   이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.   그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.   잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.   린트 린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.   프로필 돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. ...

2020.03.05

‘좋은 걸 어떡해’··· 손이 가는 프로그래밍 일탈 10가지

규칙을 어기면 약간의 스릴을 느낄 수 있다. 때로는 더 좋고 더 효율적인 코드를 작성할 수 있기도 하다.   우리 모두 해본 적이 있다. 엄마가 보지 않을 때 쿠키를 집어 들고, 저녁으로 와인을 좀 많이 마시고, 차를 애매한 곳에 잠깐 살짝 주차하는 것 등등 말이다. 종종 제한속도를 초과하기도 한다.  그리고 맞다, 우리 개발자 모두는 프로그래밍의 기본적인 규칙들을 위반한 적 있다. 모두가 동의하는 규칙들이 걸리적거렸기에 우리 모두는 몰래 그렇게 하는 것을 좋아했다. 나쁜 코드를 입력하기도 하면서 우리는 살아왔다.  그럼에도 불구하고 프로그래밍 신이 번개를 내리지는 않았으며, 데스크톱은 폭발하지 않았다. 사실, 우리 코드는 컴파일된 채 발송됐고, 고객들은 충분히 행복해 보였다. 왜냐하면 나쁜 프로그래밍은 예를 들어, 전기 울타리를 핥거나 호랑이의 꼬리를 잡아당기는 것과 같지 않기 때문이다. 대부분의 경우 잘 작동된다. 규칙은 방침이나 양식상의 제안인 경우가 더 많지, 반드시 따라야 하거나 죽음이 수반되는 융통성 없는 지침이 아니다.  물론, 당신의 코드가 비웃음을 살 수도 있고, 어쩌면 공개적으로 조롱당할 수도 있다. 하지만 당신이 규칙을 어기고 있다는 사실은, 근엄한 사회적 관행을 살짝 뒤집는다는 유쾌한 스릴을 더해주기도 한다. 규칙을 어기는 것이 더 나은 경우도 있다. 코드가 더 깔끔하게 나온다. 심지어 더 빠르고 더 간단할 수도 있다. 규칙은 보통 너무 광범위한데, 숙련된 프로그래머라면 규칙을 어김으로써 코드를 개선할 수도 있다. 상사에게 자랑할 정도는 아닐지라도 가끔은 당신 방식대로 코딩하는 게 말이 된다.  다음은 사람에 따라 도저히 납득할 수 없겠지만, 우리들 중 대부분이 성공적으로 그리고 즐겁게 자주 어기는 규칙 10가지다. 나쁜 프로그래밍 습관 No. 1 : 베끼기(Copying)  학교에서는 분명히 금지된 행동이다. 단 직장에서는 그리 분명하지 않다. 차용하지 말아야 할 코...

코드 작성 프로그래밍 코딩 개발 언어

2020.01.06

규칙을 어기면 약간의 스릴을 느낄 수 있다. 때로는 더 좋고 더 효율적인 코드를 작성할 수 있기도 하다.   우리 모두 해본 적이 있다. 엄마가 보지 않을 때 쿠키를 집어 들고, 저녁으로 와인을 좀 많이 마시고, 차를 애매한 곳에 잠깐 살짝 주차하는 것 등등 말이다. 종종 제한속도를 초과하기도 한다.  그리고 맞다, 우리 개발자 모두는 프로그래밍의 기본적인 규칙들을 위반한 적 있다. 모두가 동의하는 규칙들이 걸리적거렸기에 우리 모두는 몰래 그렇게 하는 것을 좋아했다. 나쁜 코드를 입력하기도 하면서 우리는 살아왔다.  그럼에도 불구하고 프로그래밍 신이 번개를 내리지는 않았으며, 데스크톱은 폭발하지 않았다. 사실, 우리 코드는 컴파일된 채 발송됐고, 고객들은 충분히 행복해 보였다. 왜냐하면 나쁜 프로그래밍은 예를 들어, 전기 울타리를 핥거나 호랑이의 꼬리를 잡아당기는 것과 같지 않기 때문이다. 대부분의 경우 잘 작동된다. 규칙은 방침이나 양식상의 제안인 경우가 더 많지, 반드시 따라야 하거나 죽음이 수반되는 융통성 없는 지침이 아니다.  물론, 당신의 코드가 비웃음을 살 수도 있고, 어쩌면 공개적으로 조롱당할 수도 있다. 하지만 당신이 규칙을 어기고 있다는 사실은, 근엄한 사회적 관행을 살짝 뒤집는다는 유쾌한 스릴을 더해주기도 한다. 규칙을 어기는 것이 더 나은 경우도 있다. 코드가 더 깔끔하게 나온다. 심지어 더 빠르고 더 간단할 수도 있다. 규칙은 보통 너무 광범위한데, 숙련된 프로그래머라면 규칙을 어김으로써 코드를 개선할 수도 있다. 상사에게 자랑할 정도는 아닐지라도 가끔은 당신 방식대로 코딩하는 게 말이 된다.  다음은 사람에 따라 도저히 납득할 수 없겠지만, 우리들 중 대부분이 성공적으로 그리고 즐겁게 자주 어기는 규칙 10가지다. 나쁜 프로그래밍 습관 No. 1 : 베끼기(Copying)  학교에서는 분명히 금지된 행동이다. 단 직장에서는 그리 분명하지 않다. 차용하지 말아야 할 코...

2020.01.06

'그 전제는 틀렸다'··· 프로그래머들의 흔한 착각 리스트업

프로그래머들이 가지는 자부심에는 근거가 있다. 데이터베이스에 접근해 현실을 변화시킬 힘을 갖고 있는 이는 프로그래머밖에 없다. 세상이 돌아가는데 컴퓨터가 더 많이 개입될수록 프로그래머의 힘도 커진다. 그렇지만 교만은 패망의 지름길이다. 프로그래머는 분명히 힘을 갖고 있지만, 절대적인 힘과는 거리가 멀다. 또 공허한 때도 많다. 완벽한 코드란 없다는 점을 감안하면, 어쩌면 항상 공허할지 모른다. 또 컴퓨터가 실수를 저지르기 때문에 한계를 정해 놓아야 하는 때도 있다. 컴퓨터는 오류에 빠지기 쉽다. 우리는 이런 경험을 너무 많이 해서 아주 잘 알고 있다. 그렇지만 프로그래머들이 옳지 않은 가정을 설정함으로써 초래되는 문제들도 많다. 때론 맞지만, 항상 맞는 것은 아니기 때문에 이런 일이 일어난다. 이와 관련, 마크 트웨인은 “우리가 곤경에 빠지는 것 무언가를 몰라서가 아니다. 무언가를 확실히 알고 있다라는 우리의 착각과 오판,자만 때문이다”라는 명언을 남겼다. 프로그래머들이 맞다고 종종 확신하지만, 사실은 빈번히 그렇지 않은 ‘착각’들을 이야기한다.   프로그래밍 언어는 특별하다 일과 후 술집에서 테이블을 내려친다. ‘긴 선언문’을 쓴다. 상사에게 이번에야말로 이 새로운 언어가 모든 것을 바꿀 것이며, 키보드가 저절로 엄청난 소프트웨어를 만들어내, 모든 프로젝트가 마감 기한 한 달 전에 끝날 것이라고 장담한다. 그러나 결국은 변수에 발목이 붙잡히고, ‘if(조건)’ 논리로 테스트를 하게 될 것이다. 프로그래머는 자신의 코드에서 구조(체계)를 들여다보고, 여기에서 비효율성을 모두 없애는 것을 꿈꾼다. 그래서 공중 누각인 ‘프레임워크’,’스캐폴딩’, ‘플랫폼’, ‘아키텍처’를 상상하고, 모든 것이 몇 줄의 멋진 명령으로 구현될 때까지 현재 당면한 문제만 해결할 정도로 힘을 쏟으면서 씨름을 한다. 그런데 유감스럽게도 다음 과업에는 적용되지 않는다. 결국에는 이 모든 것이 기만이고 언어적인 치장에 불과하다. 컴퓨터는 트랜지스터로 만들어진다. 제아...

오해 코드 거짓말 프로그래머 착각

2019.10.30

프로그래머들이 가지는 자부심에는 근거가 있다. 데이터베이스에 접근해 현실을 변화시킬 힘을 갖고 있는 이는 프로그래머밖에 없다. 세상이 돌아가는데 컴퓨터가 더 많이 개입될수록 프로그래머의 힘도 커진다. 그렇지만 교만은 패망의 지름길이다. 프로그래머는 분명히 힘을 갖고 있지만, 절대적인 힘과는 거리가 멀다. 또 공허한 때도 많다. 완벽한 코드란 없다는 점을 감안하면, 어쩌면 항상 공허할지 모른다. 또 컴퓨터가 실수를 저지르기 때문에 한계를 정해 놓아야 하는 때도 있다. 컴퓨터는 오류에 빠지기 쉽다. 우리는 이런 경험을 너무 많이 해서 아주 잘 알고 있다. 그렇지만 프로그래머들이 옳지 않은 가정을 설정함으로써 초래되는 문제들도 많다. 때론 맞지만, 항상 맞는 것은 아니기 때문에 이런 일이 일어난다. 이와 관련, 마크 트웨인은 “우리가 곤경에 빠지는 것 무언가를 몰라서가 아니다. 무언가를 확실히 알고 있다라는 우리의 착각과 오판,자만 때문이다”라는 명언을 남겼다. 프로그래머들이 맞다고 종종 확신하지만, 사실은 빈번히 그렇지 않은 ‘착각’들을 이야기한다.   프로그래밍 언어는 특별하다 일과 후 술집에서 테이블을 내려친다. ‘긴 선언문’을 쓴다. 상사에게 이번에야말로 이 새로운 언어가 모든 것을 바꿀 것이며, 키보드가 저절로 엄청난 소프트웨어를 만들어내, 모든 프로젝트가 마감 기한 한 달 전에 끝날 것이라고 장담한다. 그러나 결국은 변수에 발목이 붙잡히고, ‘if(조건)’ 논리로 테스트를 하게 될 것이다. 프로그래머는 자신의 코드에서 구조(체계)를 들여다보고, 여기에서 비효율성을 모두 없애는 것을 꿈꾼다. 그래서 공중 누각인 ‘프레임워크’,’스캐폴딩’, ‘플랫폼’, ‘아키텍처’를 상상하고, 모든 것이 몇 줄의 멋진 명령으로 구현될 때까지 현재 당면한 문제만 해결할 정도로 힘을 쏟으면서 씨름을 한다. 그런데 유감스럽게도 다음 과업에는 적용되지 않는다. 결국에는 이 모든 것이 기만이고 언어적인 치장에 불과하다. 컴퓨터는 트랜지스터로 만들어진다. 제아...

2019.10.30

블로그 | 멀쩡한 코드가 프로덕션만 가면 느려지는 5가지 이유와 해결 방법

애정을 담아 공들여 만든 애플리케이션이 배치 이후 느리게 실행되고 있는가? 개발 장비에서는 잘 작동하던 코드가 프로덕션 환경에서는 완전히 망가지는 5가지 일반적인 이유가 있다. 물론 소프트웨어가 프로덕션 환경에서 잘 동작하지 않는 데는 다른 이유들도 있다. 하지만 개발자들이 “내 장비에서는 잘 동작했다”고 항변하다가 규모가 커지면 규모만큼이나 큰 책임이 따른다는 것을 뒤늦게 깨닫는 경우, 이 5가지가 필자가 본 가장 중요한 이유들이다. 원인 1. 한 개의 커다란 쓰레드가 있다 Node.js 같은 일부 최신 프레임워크는 개발자 대신 쓰레드를 처리해준다. 작업을 처리하러 가기 위해 적절한 시점에 올바른 논블로킹(Nonblocking) 입출력 호출을 수행하고 코드의 주요 부분이 수많은 까다로운 작업을 처리하도록 하는 것은 개발자의 몫이다. 이렇게 하지 못하면, 시스템의 실제 쓰레드를 고갈될 수 있다. 이런 문제가 있다면, 몇 가지 의문을 가져야 한다. 가장 기본적인 의문은 Node.js에서 실행중인 어떤 자바스크립트 내부에서 주요 알고리즘을 수행하고 있는 경우, Node.js 그리고 자바스크립트가 여기서 사용하기에 적합한 기술인가? 반드시 사용해야 한다면, Node.js가 동시성(Concurrency)을 어떻게 처리하는지 그리고 이벤트 루프 차단(Blocking)을 회피하는 방법에 대해 공부해야 한다. 대신 워커풀(Workerpool)에 작업을 제출하는 방법을 배워야 한다. 더 나가서는 쓰레드에 대해 배워야만 할 수도 있다. 원인 2. 사용 중인 데이터베이스가 정말 XX같다 데이터베이스가 망가질 수 있는 이유는 아주 많다. 첫 번째 그리고 가장 명백한 이유는 인덱스 부재다. SQL 데이터베이스를 사용하는 경우, 인덱스 동작 원리를 알아야만 한다. 3개의 키/값 쌍(Key/Value Pair)이 있는 where 절이 있고 서로 다른 값을 사용해서 반복해서 그 절을 실행하고 있다면, 그것이 인덱스이다. 다음 예제는 ...

데이터베이스 성능 코드 설정 메모리 프로덕션 쓰레드

2018.06.05

애정을 담아 공들여 만든 애플리케이션이 배치 이후 느리게 실행되고 있는가? 개발 장비에서는 잘 작동하던 코드가 프로덕션 환경에서는 완전히 망가지는 5가지 일반적인 이유가 있다. 물론 소프트웨어가 프로덕션 환경에서 잘 동작하지 않는 데는 다른 이유들도 있다. 하지만 개발자들이 “내 장비에서는 잘 동작했다”고 항변하다가 규모가 커지면 규모만큼이나 큰 책임이 따른다는 것을 뒤늦게 깨닫는 경우, 이 5가지가 필자가 본 가장 중요한 이유들이다. 원인 1. 한 개의 커다란 쓰레드가 있다 Node.js 같은 일부 최신 프레임워크는 개발자 대신 쓰레드를 처리해준다. 작업을 처리하러 가기 위해 적절한 시점에 올바른 논블로킹(Nonblocking) 입출력 호출을 수행하고 코드의 주요 부분이 수많은 까다로운 작업을 처리하도록 하는 것은 개발자의 몫이다. 이렇게 하지 못하면, 시스템의 실제 쓰레드를 고갈될 수 있다. 이런 문제가 있다면, 몇 가지 의문을 가져야 한다. 가장 기본적인 의문은 Node.js에서 실행중인 어떤 자바스크립트 내부에서 주요 알고리즘을 수행하고 있는 경우, Node.js 그리고 자바스크립트가 여기서 사용하기에 적합한 기술인가? 반드시 사용해야 한다면, Node.js가 동시성(Concurrency)을 어떻게 처리하는지 그리고 이벤트 루프 차단(Blocking)을 회피하는 방법에 대해 공부해야 한다. 대신 워커풀(Workerpool)에 작업을 제출하는 방법을 배워야 한다. 더 나가서는 쓰레드에 대해 배워야만 할 수도 있다. 원인 2. 사용 중인 데이터베이스가 정말 XX같다 데이터베이스가 망가질 수 있는 이유는 아주 많다. 첫 번째 그리고 가장 명백한 이유는 인덱스 부재다. SQL 데이터베이스를 사용하는 경우, 인덱스 동작 원리를 알아야만 한다. 3개의 키/값 쌍(Key/Value Pair)이 있는 where 절이 있고 서로 다른 값을 사용해서 반복해서 그 절을 실행하고 있다면, 그것이 인덱스이다. 다음 예제는 ...

2018.06.05

좋은 코드를 작성하고 있다는 징후 11가지

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

코드 문서화 디버깅 로그 프로그래머블 네트워크 멱등적

2018.04.17

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

2018.04.17

모바일 앱 개발자 주의 사항 '백엔드 보안 확보'

개발자는 애플리케이션 코드에 보안을 적용하고 애플리케이션에서 데이터를 처리하는 방법을 보호해야 하지만, 이른바 하스피털가운(HospitalGown) 보안 문제가 보여주는 것처럼 백엔드 서버와 데이터 저장소가 어떻게 구성됐는지도 알아야 한다. 애플리케이션 보안은 단순히 개발자의 문제가 아니다. IT인력과 보안팀도 인프라 및 구축 및 보안 제어 이행에서 실행할 역할이 있다. IT관리자가 앱의 백엔드 서버를 위한 보안 기본 사항을 잊으면 개발자의 훌륭한 보안 결정을 갉아먹게 된다. 모바일 보안기업 앱소러티(Appthority)의 연구원들은 최근 (기업 IT에서 제공하고 관리하는 모바일 기기뿐 아니라 BYOD 시나리오의 개인용 장치를 포함하여) 기업 기기에 설치된 앱을 분석하고 백엔드 서버에 보안 통제가 없어서 데이터가 노출되고 있는 1,000개 이상의 앱을 발견했다. 수집된 데이터를 마이닝하고 분석하기 위해 사용자 데이터와 분석 툴을 저장하는 데이터베이스를 관리하는 서버는 방화벽이 없었고 인증이 필요 없었으며 인터넷에서 공개적으로 접근할 수 있었다. 앱소러티의 보안 연구 책임자 세스 하디에 따르면, 앱소러티는 1,000개의 앱이 2만 1,000개 이상의 개방된 엘라스틱서치(Elasticsearch) 서버에 연결돼 있었으며 약 43TB의 데이터가 노출됐다. 노출된 데이터에는 비밀번호, 위치, 이동 및 결제 세부사항, 이메일과 전화번호 등의 기업 프로필 데이터, 유통사 고객 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있었다. 연구원들은 분석 보고서에서 이러한 유형의 정보는 사기 및 크리덴셜 기반 공격에 사용하거나 피싱 등의 2차 공격에 사용할 수 있다. 데이터는 여전히 구멍이 난 서버에 있었고 ‘승인되지 않은 당사자들이 복사하거나 다운로드할 위험에’ 여전히 노출되어 있었기 때문에 사용자가 장치에서 앱을 삭제한다 하더라도 데이터 노출은 끝났지 않았다고 밝혔다. 승인되지...

CSO 카우치DB 엘라스틱서치 MongoDB CouchDB 카우치베이스 농기계 하스피털가운 HospitalGown 앱소러티 레디스 Redis 랜섬웨어 사물인터넷 마이닝 데이터베이스 피싱 개발 MySQL CISO 코드 BYOD 몽고DB 랜섬 마이SQL CouchBase

2017.06.14

개발자는 애플리케이션 코드에 보안을 적용하고 애플리케이션에서 데이터를 처리하는 방법을 보호해야 하지만, 이른바 하스피털가운(HospitalGown) 보안 문제가 보여주는 것처럼 백엔드 서버와 데이터 저장소가 어떻게 구성됐는지도 알아야 한다. 애플리케이션 보안은 단순히 개발자의 문제가 아니다. IT인력과 보안팀도 인프라 및 구축 및 보안 제어 이행에서 실행할 역할이 있다. IT관리자가 앱의 백엔드 서버를 위한 보안 기본 사항을 잊으면 개발자의 훌륭한 보안 결정을 갉아먹게 된다. 모바일 보안기업 앱소러티(Appthority)의 연구원들은 최근 (기업 IT에서 제공하고 관리하는 모바일 기기뿐 아니라 BYOD 시나리오의 개인용 장치를 포함하여) 기업 기기에 설치된 앱을 분석하고 백엔드 서버에 보안 통제가 없어서 데이터가 노출되고 있는 1,000개 이상의 앱을 발견했다. 수집된 데이터를 마이닝하고 분석하기 위해 사용자 데이터와 분석 툴을 저장하는 데이터베이스를 관리하는 서버는 방화벽이 없었고 인증이 필요 없었으며 인터넷에서 공개적으로 접근할 수 있었다. 앱소러티의 보안 연구 책임자 세스 하디에 따르면, 앱소러티는 1,000개의 앱이 2만 1,000개 이상의 개방된 엘라스틱서치(Elasticsearch) 서버에 연결돼 있었으며 약 43TB의 데이터가 노출됐다. 노출된 데이터에는 비밀번호, 위치, 이동 및 결제 세부사항, 이메일과 전화번호 등의 기업 프로필 데이터, 유통사 고객 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있었다. 연구원들은 분석 보고서에서 이러한 유형의 정보는 사기 및 크리덴셜 기반 공격에 사용하거나 피싱 등의 2차 공격에 사용할 수 있다. 데이터는 여전히 구멍이 난 서버에 있었고 ‘승인되지 않은 당사자들이 복사하거나 다운로드할 위험에’ 여전히 노출되어 있었기 때문에 사용자가 장치에서 앱을 삭제한다 하더라도 데이터 노출은 끝났지 않았다고 밝혔다. 승인되지...

2017.06.14

프로그래머들이 스스로에게 하는 9가지 거짓말

프로그래머들은 자부심을 갖고 있다. 나쁘게 말하면 교만하다. 그도 그럴 것이 다른 사람들에게는 데이터베이스에 손을 뻗어 현실을 바꿀 힘이 없다. 세상이 작동하는 방식을 정립하기 위해 컴퓨터에 더 많이 의지할수록 프로그래머의 영향력도 커진다. 그러나 '교만'은 '나락'의 선봉이다. 우리 모두가 공유하는 힘은 진짜이다. 그러나 절대적인 힘은 아니며, 때론 공허하다. 사실 항상 공허하다. 완벽한 코드란 존재하지 않기 때문이다. 때론 행운을 빌고, 한계를 정한다. 컴퓨터는 실수를 하기 때문이다. 컴퓨터에 지나칠 정도로 많은 오류가 발생할 수 있다. 우리 모두 직접 경험해 잘 알고 있는 사실이다. 물론 프로그래머들의 잘못된 가정이 초래한 문제는 정말 많다. 프로그래머의 가정은 보통 한 때는 진실이지만, 언제까지나 진실인 것은 아니다. 마크 트웨인은 "뭔가를 몰라서가 아니라, 뭔가를 확실히 안다고 착각해 곤경에 빠진다."고 말했다. 케빈 델디케(Kevin Deldycke)가 기트허브(GitHub)에 올린 '프로그래머들이 철석 같이 믿는 착각' 목록은 사이버공간과 현실이 얼마나 동떨어져 있는지 보여준다. 이는 다른 사람들이 계속 추가하면서 항목이 계속 늘어날 그런 목록이다. 'Remember, Caesar, thou art mortal(황제여, 당신도 필멸의 존재라는 점을 명심하라!)'에 해당하는 수 많은 사례를 멋지게 정리한 목록이다. 필자가 가장 좋아하는 항목은 전화번호에 대한 착각이다. 특정 전화번호를 저장하는 것이 7자리 또는 10자리의 번호를 데이터베이스에 입력하는 간단한 일이라고 생각할지 모르겠다. 그러나 이는 착각이다. 국가 코드, 사용하지 않는 번호 등 전화번호를 계속 기록하는 것을 어렵게 만드는 요소가 10여 개에 달한다. 작은 검은색 책자에 전화번호를 적어놓는 러다이트(Luddite)는 얼굴에 만족스러운 미소를 짓고 있을 것이다. 프로그...

코드 프로그래밍 거짓말 유니코드

2017.04.03

프로그래머들은 자부심을 갖고 있다. 나쁘게 말하면 교만하다. 그도 그럴 것이 다른 사람들에게는 데이터베이스에 손을 뻗어 현실을 바꿀 힘이 없다. 세상이 작동하는 방식을 정립하기 위해 컴퓨터에 더 많이 의지할수록 프로그래머의 영향력도 커진다. 그러나 '교만'은 '나락'의 선봉이다. 우리 모두가 공유하는 힘은 진짜이다. 그러나 절대적인 힘은 아니며, 때론 공허하다. 사실 항상 공허하다. 완벽한 코드란 존재하지 않기 때문이다. 때론 행운을 빌고, 한계를 정한다. 컴퓨터는 실수를 하기 때문이다. 컴퓨터에 지나칠 정도로 많은 오류가 발생할 수 있다. 우리 모두 직접 경험해 잘 알고 있는 사실이다. 물론 프로그래머들의 잘못된 가정이 초래한 문제는 정말 많다. 프로그래머의 가정은 보통 한 때는 진실이지만, 언제까지나 진실인 것은 아니다. 마크 트웨인은 "뭔가를 몰라서가 아니라, 뭔가를 확실히 안다고 착각해 곤경에 빠진다."고 말했다. 케빈 델디케(Kevin Deldycke)가 기트허브(GitHub)에 올린 '프로그래머들이 철석 같이 믿는 착각' 목록은 사이버공간과 현실이 얼마나 동떨어져 있는지 보여준다. 이는 다른 사람들이 계속 추가하면서 항목이 계속 늘어날 그런 목록이다. 'Remember, Caesar, thou art mortal(황제여, 당신도 필멸의 존재라는 점을 명심하라!)'에 해당하는 수 많은 사례를 멋지게 정리한 목록이다. 필자가 가장 좋아하는 항목은 전화번호에 대한 착각이다. 특정 전화번호를 저장하는 것이 7자리 또는 10자리의 번호를 데이터베이스에 입력하는 간단한 일이라고 생각할지 모르겠다. 그러나 이는 착각이다. 국가 코드, 사용하지 않는 번호 등 전화번호를 계속 기록하는 것을 어렵게 만드는 요소가 10여 개에 달한다. 작은 검은색 책자에 전화번호를 적어놓는 러다이트(Luddite)는 얼굴에 만족스러운 미소를 짓고 있을 것이다. 프로그...

2017.04.03

"웹과 앱의 경계 없어진다" 웹어셈블리가 약속하는 차세대 앱 환경

모질라 파이어폭스 팀이 최근 파이어폭스 52를 출시했다. 이번 버전에는 일반적인 버그 수정과 최적화도 포함되어 있지만 가장 눈에 띄는 점은 웹어셈블리(WebAssembly) 지원 추가다. 웹어셈블리는 사람들이 디바이스와 웹을 사용하는 방법을 아예 바꿔놓을 잠재력을 가지고 있는 기술이다. 이렇게 말하니 뭔가 대단해 보이긴 하는데, 대체 뭘까? 현재 웹어셈블리에 관한 문서는 대부분 개발자를 대상으로 하기 때문에 최종 사용자는 읽어봐도 무슨 내용인지 이해하기 어렵다. 웹어셈블리는 도대체 무엇인가? 웹어셈블리는 브라우저 또는 브라우저 외부에서 실행 가능한 애플리케이션을 위한 사전 컴파일된 이진 어셈블리 형식이다. 플래시(진작에 사라졌어야 함)와 달리 웹어셈블리는 브라우저 내에 구축되므로 플러그인이 필요 없다. 현재 자바스크립트가 기본적으로 지원되는 경우와 비슷하다고 보면 된다. 컴파일이라는 말의 의미를 모르는 사람을 위해 설명을 하자면, 예를 들어 파이어폭스와 같은 일반적인 데스크톱 프로그램은 소스 코드를 컴파일해서 얻은 수많은 0과 1의 모음이다. 소스 코드는 C 또는 C++와 같은 언어로 작성된다. 그러나 PC는 (일반적으로) C/C++ 코드를 직접 실행하지 않으므로 위에서 말한 0과 1로 이루어진 언어로 컴파일해야 한다. 웹어셈블리는 모든 컴퓨터에 통용되는 이진 어셈블리 언어(0과 1로 된 언어가 되기 전의 중간 형태 언어)다. 웹어셈블리 코드가 다운로드되면 PC는 이것이 프로그램임을 바로 인지한다. 이후 PC는 아키텍처와 운영 체제에 맞추어 최적화해서 코드를 어셈블링(어셈블러는 일종의 컴파일러)한다. 자바스크립트가 아니다 현재 대부분의 웹 애플리케이션은 자바스크립트를 사용해서 브라우저 내에서 실행된다. 자바스크립트는 오랜 시간 동안 사용됐고 그 사이 브라우저 최적화와 하드웨어 개선 덕분에 속도도 상당히 빨라졌다. 그러나 자바스크립트는 어디까지나 인터프리트(Interprete) 언어다. 즉, 컴퓨터(또는 스마트폰)가 코드 구...

파이어폭스 코드 웹어셈블리 컴파일

2017.03.22

모질라 파이어폭스 팀이 최근 파이어폭스 52를 출시했다. 이번 버전에는 일반적인 버그 수정과 최적화도 포함되어 있지만 가장 눈에 띄는 점은 웹어셈블리(WebAssembly) 지원 추가다. 웹어셈블리는 사람들이 디바이스와 웹을 사용하는 방법을 아예 바꿔놓을 잠재력을 가지고 있는 기술이다. 이렇게 말하니 뭔가 대단해 보이긴 하는데, 대체 뭘까? 현재 웹어셈블리에 관한 문서는 대부분 개발자를 대상으로 하기 때문에 최종 사용자는 읽어봐도 무슨 내용인지 이해하기 어렵다. 웹어셈블리는 도대체 무엇인가? 웹어셈블리는 브라우저 또는 브라우저 외부에서 실행 가능한 애플리케이션을 위한 사전 컴파일된 이진 어셈블리 형식이다. 플래시(진작에 사라졌어야 함)와 달리 웹어셈블리는 브라우저 내에 구축되므로 플러그인이 필요 없다. 현재 자바스크립트가 기본적으로 지원되는 경우와 비슷하다고 보면 된다. 컴파일이라는 말의 의미를 모르는 사람을 위해 설명을 하자면, 예를 들어 파이어폭스와 같은 일반적인 데스크톱 프로그램은 소스 코드를 컴파일해서 얻은 수많은 0과 1의 모음이다. 소스 코드는 C 또는 C++와 같은 언어로 작성된다. 그러나 PC는 (일반적으로) C/C++ 코드를 직접 실행하지 않으므로 위에서 말한 0과 1로 이루어진 언어로 컴파일해야 한다. 웹어셈블리는 모든 컴퓨터에 통용되는 이진 어셈블리 언어(0과 1로 된 언어가 되기 전의 중간 형태 언어)다. 웹어셈블리 코드가 다운로드되면 PC는 이것이 프로그램임을 바로 인지한다. 이후 PC는 아키텍처와 운영 체제에 맞추어 최적화해서 코드를 어셈블링(어셈블러는 일종의 컴파일러)한다. 자바스크립트가 아니다 현재 대부분의 웹 애플리케이션은 자바스크립트를 사용해서 브라우저 내에서 실행된다. 자바스크립트는 오랜 시간 동안 사용됐고 그 사이 브라우저 최적화와 하드웨어 개선 덕분에 속도도 상당히 빨라졌다. 그러나 자바스크립트는 어디까지나 인터프리트(Interprete) 언어다. 즉, 컴퓨터(또는 스마트폰)가 코드 구...

2017.03.22

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.8