컴퓨터 과학, 컴퓨터 공학, 소프트웨어 공학 : 차이점

이 글은 컴퓨터공학을 선택하거나, 편입하려고 하는 분들에게 쓰는 글입니다.많이들 헷갈려 하거든요. .... 개발자가 되려고 합니다. 컴퓨터 과학, 컴퓨터 공학, 소프트웨어 공학, 정보공학....아, 복잡합니다. 뭔지는 몰라도 저게 다 개발자가 된다는거죠? 흠, 그런데 막상 대학에 입학을 해보면 개발자인듯 아닌 듯.소프트웨어인 듯 아닌 듯, 그런 걸 배우게 됩니다. 사실 이제는 저게 경계선이 없습니다.각 대학의 교수님들이 계속 커리큘럼을 업데이트... Continue Reading →

KT 장애, 개발자가 읽어야 할 포인트

(그림)"유선 통신망은 보안망이라 인터넷에 공개된 무선망 구성도만 추가해봅니다." 이 글은 이제 갓 입문한 초보개발자들이 읽었으면 해서 정리해 보았습니다. 2021.10.25일. 큰 장애가 있었습니다. KT 에서 네트워크 작업을 하다 오류가 났죠. 모바일인터넷, 유선인터넷이 모두 안되었습니다. 피해범위는 전국 규모였습니다. 인터넷 결제가 되지 않으니 음식점이 난리 났구요. 인터넷이 되지 않으니, 카톡도 쓸 수 없었습니다. 다행히 은행은 동작했습니다. 은행은 이런... Continue Reading →

플랫폼을 만들고 싶어하는 개발팀을 위한 안내서

사진. 은하계를 여행하는 히치하이커를 위한 안내서 개발자는 구현을 담당합니다. SI 프로젝트라면 깔끔하게 구축만 고민하면 됩니다.고객이 원하는 것을 '요구사항 명세서'로 옮긴 후, 얼마나 복잡.정교하며 아름답게 만들지 상상하면 됩니다. 하지만, 온라인 사업에 참여한다면 조금 복잡합니다.'요구사항'은 애매하고 가야할 길도 명확하지 않습니다. 회사의 목표가 바로 '플랫폼'이 되는 거라면 상황은 더욱 어렵습니다.청소년이 되지 않고 어른이 되겠다고 선언한 것입니다. 이런 상황에선... Continue Reading →

기업들이 받아들여야 할 소프트웨어 규칙들

1. 개요 "비즈니스가 빠르게 변하다보니 시스템이 금방 레거시화된다. 그러다보니 사업팀과 개발팀이 조직 갈등을 겪고 있다. 경영자는 어떤 판단과 선택을 해야 할까?" 최근엔 이 주제에 관심이 많습니다.프로젝트가 헬로 가버리는 중요한 원인이거든요.잘못된 시스템이 만들어지는 이유가, 나쁜 업체, 나쁜 개발자의 문제로만귀착됩니다. 하지만, 욕한다고 해결되는 건 아닙니다.좋은 업체라고 해서 문제가 없지도 않고요. (ENIAC 프로그래밍을 하는 모습, 이 때는 케이블을... Continue Reading →

스타트업을 위한 서버 안내서

페이스북에서 사용하는 서버종류 5가지. 이 포스트는 완전 초보 개발자를 위한 글입니다. 2013년 Open Community Winter에서 페이스북은 자신들의 IT인프라를 공개했습니다. 그들은 이미 그동안 서버에 1조원 이상을 투자했고 서버대수가 18만대를 넘었다고 합니다. 서버 어플리케이션을 운영하기 위해 5개 종류의 서버를 사용하고 있으며 엔지니어 1명이 약 2만대의 서버를 관리한다고 합니다. 페이스북은 다양한 웹기술로 개발된 것으로 알고 있는데 도대체 이런... Continue Reading →

API 비즈니스, 우리나라에서도 될까?

얼마전에 beSUCCESS에 재미난 글이 올라왔습니다. API = self-serve biz dev. Paul Graham @paulg 폴 그레이엄은 Yahoo! Store 의 전신 Viaweb을 만든 프로그래머이기도 하고,성공적으로 Exit한 후에 실리콘밸리의 스타트업 투자 및 엑셀러레이터로 유명한Y Combinator를 공동창업한 사업가이기도 합니다. ‘스타트업 바이블2’로 유명한 배기홍 대표님이 이 트윗을 보시고'API 비즈니스는 스스로 영업한다.' 라는 포스팅을 해주셨습니다. 저도 이 문장에 관심이 많습니다.실리콘 밸리가... Continue Reading →

데이터 중심의 제품관리

아래글은 지난 "API 중심의 데이터 아키텍쳐"의비즈니스 버전이라고 볼 수 있습니다. 다른 사이트에도 비슷한 글들이 꾸준히 올라와서간단히 번역하고 넘어갑니다.저도 인프라를 만들면서 꽤 겪었던 일인데요.쉽지 않은 일이기도 합니다. 여기서 이야기하는 제품이란 "온라인 비즈니스"입니다."IT 서비스"도 제품으로 접근하는 실리콘밸리의 최근 추세를 알 수 있습니다. "죽음의 덫, 기업용 소프트웨어의 악순환" 사례는다른 서비스도 눈여겨 볼 필요가 있습니다. 많은 기능을 추가하기보다 필요한... Continue Reading →

API 중심의 데이터 아키텍쳐 2

지난 주 글에 이어서 두번째 글입니다. 엔터프라이즈 기업환경에서 고비용의 ETL솔루션을 쓰는 것은 당연한 선택입니다. API, Input Buffer와 RDB등의 기술아키텍쳐는 기존 기술과도 닮아 있어 사실 특별한게 아닙니다. 하지만 트래픽이 많은 사업환경에서 라이센스 비용은 굉장히 큰 부담일 수 밖에 없습니다. Apigee가 만든 nucleus를 살펴보면 앱개발, API 비즈니스 환경이 오픈소스, 대용량 데이터, 다양한 데이터의 수집과 전송에 초점이 맞추어져... Continue Reading →

API 중심의 데이터 아키텍쳐

Apigee에 흥미로운 글이 올라와서 번역해보았습니다.Anant씨는 IBM 정보관리 부문의 CTO였는데,Apigee로 넘어와서 "데이터 전략"을 담당하고 있습니다. 클라우드가 "기반 시스템"이 되자 쌓이는 데이터가 다양해졌습니다.텍스트, 미디어, 사진 등 ... 운영되는 DB도 다양해졌습니다.NoSQL DB, 비정형 데이터 등은, 새로운 고민거리일 수 밖에 없습니다.기술적 복잡성을 증가시키기 때문입니다. "사업제휴"를 하게 되면, 복잡성은 더 증가 합니다.데이터를 주고 받아야 하기 때문입니다. 데이터 연동을 위해 별도의... Continue Reading →

WordPress.com 제공.

위로 ↑