이상선
저는 30년 정도 개발을 해 온 개발자입니다. 수 많은 프로젝을 진행했고 많은 제자들도 가르쳤습니다. 웹이나 앱을 만드는 것이 요즘의 주요한 일입니다.
개발은 자료나 영상을 보면서 강의를 들으면서 배울 수 있지만 한계가 분명합니다. 아무 것도 모를 때 기초적인 지식을 얻는 것엔 의미가 있습니다. 그러나 제대로된 개발자가 되려면 결국 프로젝을 같이 해야 합니다.
제가 개발을 하면서 '아 바로 이 대목을 알려 주고 싶은데' 이런 경우가 있습니다. 너무 아쉽습니다. 특히 요즘은 자바스크립트의 시대입니다. 점점 JS의 힘과 역할이 커지고 있습니다. 라이브러리, 프레임웍 쓰지 않고 깔끔하게 내 실력으로 개발하는 방법을 알려 드립니다.
정말 제대로 개발하는 것을 배우고 싶으면 언제든지 연락 주세요.
이상선
최근에 여러 미팅을 하면서 스타트업 시작하는 사람들과 연결이 되고 있습니다. 오랜 시간 개발을 해 오던 저에게 지난 몇 년 동안 새로운 기쁨이 생긴 것 같습니다. 스타트업을 발굴하고 주로 개발이지만 사업을 진행하는 여러 분야에 대한 멘토링을 하는 것이죠.
주 4일 근무를 원칙으로 해서 한 요일에 하나의 회사씩 섬기려고 하는데 지금 3개의 회사를 섬기고 있습니다. 마지막 한 자리 혹시 필요하시면 연락 주세요.
고맙습니다.
이상선
아무리 개발이 프론트엔드와 백엔드로 나뉘어 졌다 해도 프론트엔드에선 또 개발과 디자인이 부딪치게 됩니다. 프론트의 마크업 파트는 비록 코딩이긴 하지만 디자이너의 영역입니다. 한국에선 많이들 디자이너가 디자인을 하면 그걸 퍼블리셔가 마크업으로 바꾸기도 하지만 비용이나 효율이 문제가 아니라 이렇게 하나를 두 명이 하면 분명 문제가 생깁니다.
어차피 디자이너가 디자인 툴을 이용해서 그림을 그리는 것도 일종의 코딩이니까(비록 키보드를 안 써도) 디자이너가 자신의 디자인 아이디어를 코드로 구현하는 것이 중요하고 이런 디자이너를 찾는 것이 매우 핵심적입니다. 또한, 디자이너들 중 어떤 사람은 코딩을 배우고 싶어 하는 경우도 있을 것으로 생각합니다. 마크업 코딩부터 시작해서 더 도전적이라면 JS 코딩까지요.
코딩은 배울 수 있지만 디자인은 배울 수 없습니다. 그래서 디자인 감각을 가진 전문가가 사소한(?) 코딩을 배우는 것이 옳다고 봅니다. 전 정말 (마크업)코딩하는 디자이너가 필요합니다.
이상선
오랜만에 글을 써 봅니다. 자주 오지는 않지만 가끔 초청을 받으면 또 오게 되고 오면 좋은 글들이 많아요.
저는 글로벌 회사에서 개발자로 일했고 한국에 와서 창업해서 꾸준히 개발을 하다가 최근에는 개발보단 CTO 역할을 더 많이 하고 있습니다. 개발은 개발자가 하는 것이 아니라는 생각을 가지고 제품 개발의 초기부터 기술 관리에 대한 안내를 해 드리고 있지요.
CTO의 역할이 공식적으로 정해진 것은 없지만 보통 개발자 관리, 회사의 기술 정책 관리, 정보 설계 등이 주요한 역할이라고 봅니다. 많이들 좋은 아이디어를 가지고 제품을 구상하고 기획까지는 하지만 막상 개발을 하려면 개발자가 필요합니다. 그래서 외주 개발사나 또는 내부 개발자를 직접 구해서 개발을 맡겨 보면 잘 안 되는 경우가 많지요. 중요한 요소가 빠져서 입니다.
바로 정보와 제품을 설계하고 기술을 리딩할 사람이 없어서이죠. 아마도 이게 CTO의 역할이 아닌가 생각합니다. CTO가 필요하신 분 연락 주세요.
고맙습니다.
이상선
안녕하세요? 가끔씩 글을 올리는 블록체이너리 주식회사의 대표 이상선입니다.
여기에 계시는 분들은 대부분 스타텁을 운영하고 계신다고 보이지만 개발에 특화된 전문적인 대화의 공간은 아닌 것 같습니다. 그런데 지금 어떤 종류의 사업을 하더라도 개발은 꼭 필요한 기능이 되었습니다. 마치 회사에서 인사나 회계처럼요.
그런데 막상 개발을 진행하려면 내부에 팀을 두건 외부에 외주를 맡기건 어려움은 동일하고 결국 말로 듣던 수 많은 실패 사례를 내가 스스로 경험하게 되고 많이들 포기하기도 합니다. 타인의 실패를 내가 반복할 필요는 없죠.
그래서 개발에 대한 말 못 하는 여러 고민들을 가진 스타텁 경영자들을 위한 무료 공개 미팅을 한 번 해 볼까 합니다. 인원이 너무 많으면 다 이야기할 수 없으니 대략 10여분 정도를 모여서 그 슬프고 억울하고 힘들고 고통스러웠던 이야기를 한 번 해 보면 어떤가 합니다. 제가 모든 이야기에 답을 드릴 수는 없어도 많이 들어 드리고 같이 아파하고 혹시 방법이 있다면 제시도 할 수 있을 것입니다.
대충 써 보았는데 이런 거나 비슷한 거에 걸리는 분들 많이 신청해 주세요. 그냥 모여서 개발과 관련된 수다를 떨어 보자는 것입니다. 아래 댓글로 남겨 주시면 일정을 잡아 보겠습니다. 고맙습니다.
이상선
피그마를 디자이너들의 그래픽 툴이라고 생각했었는데 오늘 다시 써 보니 이건 PPT를 위협하는 기획자의 툴이 될 수 있겠다는 생각을 했습니다.
아주 예전의 기획자들은 글로만 보고서를 썼을 것입니다. 그러다가 윈도우와 오피스의 대중화로 90년대 후반부터 마치 PPT가 보고서의 기본처럼 되어 버렸고 디자인이 그만큼 중요한 요소가 되었습니다. 아마 그때부터 디자인 경영이라는 말도 나온 것 같습니다.
얼마전에 이 멋진 피그마가 아도브에 팔린 것을 보고 여러 생각을 했는데 멋지게 안 팔았으면 더 좋았을 수도 있지만 팔려서 그동안의 보상을 받은 것도 다행이라고 봅니다. 피그마는 포토샵이나 일러스트레이터가 순수하게 웹으로 구현될 수 있다는 것을 증명했습니다. 그리고 단순하게 구글 로그인을 도입해서 마치 구글의 서비스 중 하나인 것 같은 착각도 듭니다.
사람만이 둘 것 같은 바둑을 컴퓨터가 두고 이기기까지 해서 인공지능의 대단함과 바둑의 별 것 아님을 증명한 것처럼, 피그마가 그 어려운 디자인 작업을 웹만으로 할 수 있다는 것으 증명하면서 20년전의 구글 닥스를 처음 보았을 때의 충격이나 AWS의 서버리스를 10년전에 처음 보았을 때의 충격만큼의 놀라움을 우리에게 주고 있습니다.
어쩌면 앞으로 발표 자료는 기본적으로 피그마로 만들지도 모르겠습니다. 아니면 피그잼이나요?
이상선
새로 나오는 서비스들이나 조금 유명한 서비스들도 보면 UI도 잘 만들고 여러 가지가 좋은데 가끔 반응 속도가 나쁜 경우가 있습니다. 이건 사용자들의 짜증을 유발하죠. 그래서 좀 관찰해 보면 대부분 backend api의 성능 문제인 경우가 많습니다.
문제의 원인은 여럿이지만 대부분 DB를 잘 못 만져서 생기는 문제입니다. Backend에서 가장 중요한 것은 설계입니다. 특히 자료 구조를 어떻게 설계하는지가 속도에 중요한 관건이죠. 수십개의 시험 자료 넣고 아 잘 되네 이러면 나중에 실제 서비스에서 생기면 별별 희한한 상황에 대응을 못 해요.
결국 이건 오랜 경험이 필요한 것 같습니다. Backend api의 문제를 어디 가서 말도 못 하는 분, 자료 구조와 설계에 도움을 받고 싶은 분 연락 주세요. 정말 진심으로 도와 드리죠.
이상선
제가 이런 모임 같은 거 잘 못 하는데 용기를 내어 보네요.
전 개발자로 오래 일해 오면서 요즘은 직접 개발보단 개발자들을 돕고 키우는 일에 더 관심이 있습니다. 물론 개발도 멈추지 않고요.
간단히 저를 소개하자면 저는 미국 MS에서 윈도우 개발에 참여했던 개발자입니다. 참 오래전 이야기네요. 윈도우 2000, XP 등 개발에 참여했구요. 한국에 와선 여러 중요한 프로젝에 참여했었습니다.
개발자가 되고 싶어하는 사람들, 고민하는 사람들 보면 정말 도움을 드리고 싶고 방향을 제시하고 싶어요. 필요한 질문 있으면 언제든 이야기해 주세요.
선물로 제가 운영하는 기술 블로그를 알려 드리죠.