*이 글은 외부 필자인 오힘찬님의 기고입니다. 가트너는 2025년까지 새로운 애플리케이션의 약 70%가 노코드/로우코드(NCLC)를 사용할 것이라고 전망했습니다. "By 2025, 70% of new applications developed by organizations will use low-code or no-code technologies, up from less than 25% in 2020" (참조 - No-Code Use Will Nearly Triple by 2025) 대부분 애플리케이션이 NCLC(No-code/Low-code)로 개발될 것이라는 얘기죠. 그럼 NCLC는 무엇일까요? (참조 - Cloud Will Be the Centerpiece) 노코드와 로우코드의 차이 노코드는 프로그래밍 지식이 없어도 적합한 애플리케이션을 개발할 수 있게 돕는 도구를 말합니다. 코드를 작성할 필요가 없죠. 아래는 주요 특징입니다. (1) 시각적 인터페이스 : 사용자들은 드래그 앤 드롭 인터페이스나 시각적인 요소를 조합해서 기능을 구축합니다. (2) 쉬운 접근 : 대부분 비전문가 또는 비개발자도 사용할 수 있게 구성돼 있습니다. (3) 빠른 개발 속도 : 시각적 인터페이스와 쉬운 접근으로 빠르게 프로토타입을 만들어 개발 시간을 단축할 수 있습니다. (4) 부족한 유연성 : 쉬운 사용이 장점인 반면, 맞춤형 또는 복잡한 기능을 구축하는 데에 제한이 있다는 단점이 있습니다. 로우코드는 노코드와 비슷하지만, 개발 작업을 더욱 효율적으로 수행하도록 돕는 것이 목표입니다. 기본적인 코드 작성이 필요하고, 개발자가 작업을 간소화하고 가속화할 수 있습니다. (참조 - How to Create an App)

'MCN' 사업 모델은 유튜브의 성장과 함께 주목받았습니다. 하지만 유튜브와 크리에이터가 성장하는 만큼 해당 산업이 함께 성장하진 못했죠. MCN 업계에서 굵직한 이력은 쌓은 이가 최근 창업에 나섰습니다. 해당 회사의 사업모델은 창업자가 MCN에서 일할 당시부터 떠올렸는데요. 최근 이를 실행에 옮기고 성과를 만들기 시작했습니다. 바로 '벌스워크'의 윤영근 대표 이야깁니다. 윤영근 대표는 다이아TV에서 채널 콘텐츠 제작과 운영 등 전반을 맡아 일하면서 보겸TV, 테스터훈 등 100만 구독자를 만들어낸 인물인데요. MCN의 한계를 느끼고 이를 극복하기 위한 모델을 떠올렸습니다. 그리고 네이버 스노우의 영상 제작 자회사인 세미콜론 스튜디오를 거쳐 창업에 나섰죠. "메스미디어 시절 미디어 흐름의 변화를 읽고 MCN 시장에서 커리어를 쌓던 그가 앞으로를 어떻게 예측하고 사업을 시작한 것일까?!" 너무 궁금한 나머지 직접 찾아뵙고 이야길 들어봤는데요. 콘텐츠 회사? 메타버스 MCN? 게임사? 엔터사..도 아니고.. 벌스워크를 단순하게 어떤 회사라고 정의하기 어려웠습니다. 그 이유는 기존에 없던 시장을 만들어 가고 있기 때문인 것 같아요!

*이 글은 외부 필자인 이진열님의 기고입니다. 지금까지 여러 글을 통해 초기 창업 팀이 성공적으로 외주 개발을 맡기는 방법부터, 개발자 없이 PMF(Product Market Fit)를 검증하는 일련의 방법들을 소개해드린 바 있습니다. (참조 - 창업할 건데 개발자가 없다고요? (꿀팁 알려드림)) 사실 이런 주제로 글을 쓰게 된 것은 다름 아니라 주변에 창업을 준비하는 많은 지인들이 이런 질문을 꼭 한 번씩 했기 때문인데요. 그도 그럴 것이 저와 제 공동창업자가 수년전부터 정말 많은 외주들을 해왔고, 그 과정에서 많은 팀들의 초기 개발 고민을 들어주고 해결해왔거든요. 특히 가장 많이 들은 질문은 이겁니다. "주변에 좋은 외주 개발사 없어?" 답하기가 정말 어렵습니다. 우선 애초에 '좋은 개발사'라는 정의 자체가 어렵습니다. 외주를 맡기는 쪽에서 좋은 개발사란 빠른 시간 안에, 싼 가격으로 내가 생각한 서비스를 그대로 구현해주는 회사일텐데.. 사실 그런 회사는 없거든요. 뿐만 아니라 어떤 개발 언어로, 어떤 서비스를 만들고자 하는지에 따라 '좋은 개발사'의 정의가 달라질 수 있죠. 또 최근 들어선 개발자의 몸값이 하늘을 치솟는 상황이라 단순히 '좋은 개발자'가 모여 있는 '좋은 개발사'를 찾는다는 건 거의 불가능에 가깝습니다. (참조 - '개발자 모시기 전쟁'에서 초기 스타트업이 살아남는 방법) 그래서 개발을 맡기는 입장에서, 특히 극 초기 스타트업들이라면 우선 '좋은 개발사'를 찾기 이전에 내가 가진 예산과 시간을 명확히 규정하고, 그 예산과 시간 안에 개발이 가능한 범위의 기획을 꼼꼼하게 진행하는 것이 선행되어야 합니다. 당연히 그 안에서 우선순위에 대한 고민도 필요하겠죠. 사실 나의 상황과 한계, 니즈를 명확히 하지 않으면 '좋은' 개발사가 무엇인지 정의를 시작할 수도 없습니다.

미국 앱 스토어 무료 앱 시장에 놀라운 일이 벌어졌습니다. 바로 부동의 1위 '틱톡'을 누르고 1위의 자리에 올라선 앱이 등장한 겁니다. '복붙키보드'는 자주 사용하는 상용구를 키보드에 저장해 즉각적으로 입력할 수 있도록 한 앱인데요. 틱톡에서 이 기능이 유용하게 사용되면서, MZ세대를 중심으로 다운로드 수가 폭발한 것입니다. 틱톡이 지난해 4월 이후 1위에서 내려온 적이 없는 터라 국내는 물론 해외에서도 주목하고 있는데요. (참조 - 한국인 개발 '키보드 앱' 미국 10대에 통했다…애플 앱스토어서 '틱톡'도 제쳐) 더 놀라운 사실은 이 앱을 만든 사람이 한국의 1인 개발자라는 것입니다. 과연 그는 누구인가! 아웃스탠딩이 만나봤습니다. 복붙키보드, 이거 뭐지? "안녕하세요! 자기소개 부탁드려요" "네, 안녕하세요!" "저는 현재 다노에서 IOS 개발자로 근무하고 있는 박태진이라고 합니다" "아, 회사원이시군요? 먼저 복붙키보드 이야기를 해보죠" "이 앱 어떻게 만들게 되셨나요?" "예전에 제가 창업을 한 적이 있는데요"

*이 글은 외부 필자인 함영석님의 기고입니다. '발명' 어떤 생각이 드시나요? 누군가 특허를 획득했다는 것과 누군가 어떤 기술을 발명했다는 것이 동일한 의미로 들릴지 모르겠습니다. 'A기업이 세계 최초로 반도체 기술의 특허를 획득했다' 그렇다면, 반도체 기술의 발명은 누가 했을까요? 당연히 A기업의 연구원들 중 누군가 발명을 해 기업이 특허를 획득했을 겁니다. 그런데 발명자란에 내 이름이 들어간 것만으로는 실제 특허출원에서 권리자가 되는 것은 아닙니다. 발명을 한 사람은 특허를 받을 권리가 당연히 생기는 것이지만, 특허를 출원할 때 권리를 받을 사람을 정해야 하는 거죠. 그렇다면 발명자와 출원인은 어떤 관계에 있을까요? 특허기술에 다수의 이해관계인들이 있는 경우는 어떨까요? 한 번 살펴보겠습니다. 발명자와 출원인 먼저 '발명자'는 무엇이고, '출원인'은 무엇일까요?

"요즘 개발자가 부족하단 이야기 정말 많이 들려오죠" "사실 눈을 낮추면 개발자를 금방 찾을 수는 있어요" "좋은 개발자 찾기가 힘든 것이죠" "저는 자기 문제를 깊이 파고들 수 있는 사람이 좋은 개발자라고 생각해요" "서비스 런칭 해본 개발자와 안 해본 개발자는 천지 차이란 말도 있죠" "개발자가 되고 싶은 분이라면, 개발 직군 인력난의 수혜를 입으려면 '좋은 개발자'가 되어야 합니다" "개발자 수요는 아직 폭발적으로 늘어나지 않았어요" "현재 개발자가 필요하다고 말하는 회사들을 살펴보면 대부분 IT업계에 한정되어 있습니다" "앞으로는 개발자 수요가 더 늘어날 거라고 생각해요" (팀스파르타 이범규 대표) 스파르타 코딩클럽은 오프라인 교육 서비스로 출발해 빠르게 성장하던 중 코로나 직격탄을 맞았는데요. 이후 온라인 강의로의 전환에 성공! 올해 100억 매출을 바라볼 만큼 안정적인 서비스로 자리를 잡았습니다. 투자도 받지 않고 지금까지 안정적으로 서비스를 성장시킨 비결은 무엇이었을까요? 이런 궁금증을 가지고 팀스파르타의 창업자인 이범규 대표님을 찾아가 봤는데요. 팀스파르타의 창업기와 함께 개발자 인력난, 개발 영역의 미래 등 소프트웨어 개발 관련 이슈에 대한 대표님의 생각을 들어볼 수 있었습니다. 오늘은 이범규 대표와의 대화를 여러분들에게 공유드릴까합니다. 팀스파르타 창업기

*이 글은 외부 필자인 김아영님의 기고입니다. QA. 누군가에게는 생소할 수도 있는 단어이자 영역인데요. QA는 Quality Assurance, 즉 품질 보증을 뜻합니다. 도메인, 산업 등에 관계없이 품질은 제품을 구성하는 필수 요소인데요. 제품의 특성에 따라 품질이 서비스에 대한 인상과 충성도를 좌우하는 만큼 구매력에도 큰 영향을 미칩니다. 당연하게도 이러한 품질의 보증을 위해 현업에서 주야장천 노력하는 사람들이 있습니다. 그들을 바로 QAE (Quality Assurance Engineer), 뭉뚱그려 QA라고 부릅니다. 개발자 직군 중 하나이기도 한데요. (참조 - "개발자라고 다 같은 개발자가 아닙니다" (다양한 직무 이해하기)) 품질에 대한 높은 기대치가 있는 만큼 QA 직군을 둘러싸고도 기대와 오해가 존재하는 것 같습니다. 그래서 오늘은 그 항간의 이야기들을 들여다보려고 합니다. 1. QA는 단순 테스터다? 가장 많이 접했던 오해와 편견이 아닐까 싶은데요. "QA는 누구나 할 수 있는 일 아니냐, 단순 테스터와 뭐가 다르냐, 버그만 잡지"

*이 글은 외부필자인 이진열님의 기고입니다. 창업을 준비하는 지인들이나 이미 사업을 하고 있는 대표님들께 가장 많이 받는 부탁 중 하나가 '좋은 외주 개발사 추천'입니다. 그러면서 묻죠. "외주 개발로 서비스 만들면 유지보수가 어렵고 실패할 확률이 높다는데 정말 맞나요?" "제가 만들려고 하는 건 얼마에 만들 수 있을까요? 외주 개발비는 어떻게 책정되나요?" 외주 개발은 실패할 확률이 높을까 먼저 외주 개발로 서비스를 만들면 유지보수가 어렵고 실패할 확률이 높을까요? 당연히 '그렇지 않습니다' 쉬운 말로 케바케입니다. 이런 오해는 외주를 통해 개발 프로젝트를 진행하는데 있어 전략이 없었기 때문에 생긴건데요. 그렇다면 어떤 전략으로 외주 개발을 진행해야 할까요? 1. 가장 먼저 하실 일은 이 기술개발과 그 결과물이 우리 비즈니스에 얼마나 중요한지 냉정하게 판단해보는 것입니다. 쉽게 말해 한 번 만들고 업데이트를 계속 하지 않으면 우리 회사 망할까? 판단해보시면 되는데요. 만약 우리 비즈니스의 핵심이고 앞으로의 성장에도 핵심이라면 '개발의 용이성'을 중심으로 생각해 외주 개발을 맡기면 됩니다. 즉 용역이 끝나고 외주를 맡기든, 개발자를 뽑든 계속 업데이트 해나갈 예정이라면 애초에 외주 개발사를 선택할 때 고려해야 할 것은 2가지입니다. 첫째, 개발자를 구하기 쉬운 언어로 개발하는 곳을 선택하는 것. 둘째, 소스코드에 주석을 잘 달아주고 인수인계가 용이한 방향으로 코딩을 진행하도록 요청하는 것. 만약 개발사에서 이렇게 하면 시간이 더 들어 비용이 늘어난다 하더라도, 또 초기 개발 기능이 줄어들 수 있다고 하더라도! '개발의 용이성'은 외주 개발 첫 의사결정에서 가장 중요한 요소입니다.

“커뮤니케이션을 잘 하려면, IT지식이 필요합니다" "IT 소프트웨어는 짧은 주기로 개발해서, 검증, 수정을 반복하죠" “방향 전환이 잦으니 개발자도 기획, 사업 얘기를 알아들어야 합니다. 비개발자도 개발 이야기를 깊게 해야하고요" "커뮤니케이션을 위해선 C나 파이썬 코딩을 배울 게 아니라, 큰 그림을 봐야 해요" "API 문서를 보고 서비스 구조를 직접 분석해보면 좋아요" "API를 이해할 수 있는 수준만 공부해도 커뮤니케이션 수준이 상당히 높아질 거예요" "안녕하세요. 자기 소개 부탁드립니다" "안녕하세요. IT지식 강사 최원영입니다. 저를 설명하는 키워드는… ‘중간자’가 아닐까 싶어요 ㅎㅎ" "제가 학생 때였는데요. ‘통섭’이라는 책을 감명깊게 읽었습니다" "그때 이런 믿음이 생겼어요. ‘앞으로는 여러 분야를 융합, 연결할 수 있는 사람이 문제를 해결할 거야' "그러다보니 학교 다닐 때도 들으라는 수업 안 듣고 정말 다양한 수업을 들었어요"

“요즘 뭐가 가장 고민이세요?” 제가 스타트업 대표님들을 만나면 자주 묻는 질문입니다. 가장 많이 듣는 답이 뭘까요? 아마 독자 분들도 어느 정도 예상하실 텐데요. 제가 가장 많이 들은 답은 이겁니다. “개발자 구하기가 너무 어려워요!” 네.. 맞습니다. 돈, 아이디어보다 개발자 구하는 것이 훨씬 어렵다고... IT서비스 개발에 대한 수요는 폭발적으로 늘고 있는 반면, 숙련된 개발자의 공급은 그렇게 빨리 늘지 않기 때문입니다. 개발자에 대한 초과수요가 발생하고, 개발자 몸값도 계속 오르는 추세입니다. 늘어나는 외주 개발 수요 이런 상황이다 보니, 외주 개발 수요도 자연스레 증가합니다. 당장 개발이 필요한데, 개발자를 못 구하면 외주를 맡기는 수밖에 없죠. 외주개발은 꼭 개발자를 못 구해서가 아니어도, 일시적 개발 수요에 대응하거나, 개발이 회사의 주 업무가 아니거나, 보유하지 않은 기술을 사용해야할 때 등 다양한 상황에서 꼭 필요한 서비스이기도 합니다. 그런데 아직까지 ‘외주 개발’이라는 말에는 부정적 인식이 있는 게 사실입니다. '외주 개발 맡겼다가, 품질이 안 좋아서 결국 다시 개발했다더라' '스타트업은 외주 맡기면 망한다'