조준철

조준철님의 아티클

조준철

조준철

Libman으로 오픈소스 관리하기

Libman(Library Manager)은 인기 있는 라이브러리 및 프레임워크를 클라이언트 라이브러리를 관리하기 위한 CLI 도구로 dotnet 이 실행될 수 있는 Windows, macOS, Linux 를 지원합니다. 지원되는 소스 제공자는 FileSystem 과 CDN은 CDNJS, jsDelivr, unpkg 4 개를 지원합니다.

본래 ASP.NET Core 개발을 위한 도구로 Visual Studio 2022 에 GUI 도구로 포함되어 있던 것을 CLI 버전으로도 제공하게 되어 사실상 개발 기술에 상관없이 본인의 환경에 유용하게 사용 할 수 있습니다.

이것은 특히 웹 개발에서 유용한데, 선택한 라이브러리 파일은 설정에 의해 적절한 위치에 배치됩니다.

이 가이드는 개발자들이 Libman을 사용하여 오픈소스 라이브러리를 효율적으로 관리하는 방법을 소개합니다.

공식문서 - ASP.NET Core에서 LibMan CLI 사용

Libman 설치하기

먼저, Libman을 설치해야 합니다. Visual Studio를 사용 중이라면, Libman은 기본적으로 포함되어 있습니다. Visual Studio Code를 사용 중이라면, 다음 명령어를 통해 Libman CLI를 설치할 수 있습니다.

dotnet tool install -g Microsoft.Web.LibraryManager.Cli

Libman 초기화

프로젝트 디렉토리에서 Libman을 초기화합니다. 이 명령어는 libman.json 파일을 생성하여 라이브러리 관리를 시작할 수 있게 합니다.

libman init

라이브러리 추가하기

Libman을 사용하여 필요한 오픈소스 라이브러리를 추가할 수 있습니다. 예를 들어, jQuery를 추가하려면 다음 명령어를 사용합니다.

libman install jquery --provider cdnjs

이 명령어는 cdnjs 제공자를 통해 jQuery를 다운로드하고, libman.json 파일에 해당 라이브러리를 기록합니다.

라이브러리 업데이트 및 제거

라이브러리를 업데이트하거나 제거하는 것도 간단합니다. 업데이트하려면 다음 명령어를 사용합니다.

libman update jquery

제거하려면 다음 명령어를 사용합니다.

libman uninstall jquery

libman.json 파일 이해하기

libman.json 파일은 프로젝트에서 사용하는 모든 라이브러리를 정의합니다. 예시 파일은 다음과 같습니다.

files 항목을 설정하지 않으면 소스의 모든 파일을 대상 경로로 배치합니다.

{
  "version": "1.0",
  "defaultProvider": "cdnjs",
  "libraries": [
    {
      "library": "jquery@3.5.1",
      "destination": "wwwroot/lib/jquery"
    },
    {
      "provider": "unpkg",
      "library": "bootstrap@4.1.3",
      "destination": "wwwroot/lib/bootstrap/"
    },
    {
      "provider": "filesystem",
      "library": "C:/temp/lodash/",
      "files": [
        "lodash.js",
        "lodash.min.js"
      ],
      "destination": "wwwroot/lib/lodash/"
    }
  ]
}

이 파일을 통해 라이브러리의 버전, 제공자, 설치 경로 등을 관리할 수 있습니다.

Libman의 장점

  • 간편한 설치 및 관리: 명령어 몇 개로 라이브러리를 쉽게 설치하고 관리할 수 있습니다.

  • 다양한 제공자 지원: cdnjs, unpkg, filesystem 등 다양한 제공자를 지원하여 유연하게 사용할 수 있습니다.

  • 프로젝트 일관성 유지: libman.json 파일을 통해 프로젝트의 모든 라이브러리를 일관되게 관리할 수 있습니다.

실습 예제

다음은 Libman을 사용하여 Bootstrap과 Popper.js를 설치하는 예제입니다.

libman install bootstrap --provider cdnjs
libman install popper.js --provider cdnjs

이 명령어를 실행하면 wwwroot/lib 디렉토리에 Bootstrap과 Popper.js가 설치됩니다.

저의 경우도 화면 개발에 필요한 클라이언트 라이브러리에 대한 버전 관리를 다음과 같이 관리하고 있습니다.

https://github.com/handstack77/handstack/blob/master/2.Modules/wwwroot/libman.json

Libman은 개발자들이 오픈소스 라이브러리를 효율적으로 관리할 수 있도록 도와주는 강력한 도구입니다. 잠깐 시간을 투자해서 Libman의 기본 사용법을 익히고, 프로젝트에 적용해 보세요.

1
0
조준철

조준철

handstack.kr 커미터에 참여하세요

이건 제 실수입니다.​

HandStack 오픈소스를 시작할 때, 기술 문서에 대한 https://handstack.kr 웹 사이트를 메타가 만든 Docusaurus 정적 페이지 문서화 도구를 이용하여 GitHub에 같이 오픈하며 지속적으로 글을 작성하고 있었는데, 이 부분이 언급되거나 홍보를 하지 않아 모르시는 분들이 많으시네요.

요약하면 https://handstack.kr 웹 사이트도 GitHub에 올라온 https://github.com/handstack77/handstack-docs 오픈소스입니다. 이 웹 사이트의 모든 컨텐츠는 GitHub에서 관리되며, 누구나 복제 및 출처를 표시하면 사용할 수 있습니다.

또한 웹 사이트에 컨텐츠를 등록하기 위한 커미터로 GitHub에 요청하여 참여하실 수 있습니다.

오픈소스 문서화 프로젝트에 기여하세요.​

HandStack 프로젝트는 개발자와 엔지니어를 위한 앱 개발 환경을 만들어 고객의 IT 과제를 해결하는 도구를 만듭니다. 프로젝트의 문서화 웹 사이트도 오픈소스로 제공되고 있으며, 이를 통해 더 많은 사람들이 프로젝트를 쉽게 이해하고 활용할 수 있도록 돕고자 합니다.

https://handstack.kr 웹 사이트는 정보를 오픈소스로 제공하는 데 목적이 있습니다. 그래서 HandStack을 기반으로 하는 다음과 같은 주제에 대한 글을 작성하고 싶으신 분들은 커미터 요청을 하시거나 handstack77@gmail.com로 요청을 주시면 됩니다. 각 주제에 대한 설명은 다음과 같습니다.

  • 시작하기: HandStack을 처음 사용하는 분들을 위한 기본 가이드입니다. 설치 방법, 초기 설정, 기본 사용법 등을 다룹니다.

  • 참고하기: HandStack을 활용하는 데 도움이 되는 다양한 참고 자료와 예제를 제공합니다. 코드 샘플, 문서 링크, 유용한 팁 등을 포함합니다.

  • 추가정보: HandStack의 고급 기능이나 추가적인 설정 방법에 대한 정보를 제공합니다. 더 깊이 있는 사용법을 배우고 싶은 분들을 위한 내용입니다.

  • 12-Factors: 12-Factor App 방법론을 HandStack에 적용하는 방법을 설명합니다. 이 방법론은 현대적인 애플리케이션 개발의 모범 사례를 제시합니다.

  • 블로그: HandStack과 관련된 다양한 주제에 대한 블로그 글을 작성합니다. 최신 업데이트, 개발자 인터뷰, 사용 후기 등을 포함합니다.

블로그의 경우 체계적으로 분류하고 독자들이 원하는 주제를 쉽게 찾을 수 있도록 태그를 제시합니다. 블로그 커미터 요청을 하시면 컨텐츠에 태그를 다음 중 하나 이상 (tags: [계획, 챌린지]) 입력해주세요.

  • 아이디어: 새로운 프로젝트나 기능에 대한 창의적인 아이디어를 공유합니다.

  • 인사이트: 특정 주제나 기술에 대한 깊이 있는 통찰과 분석을 제공합니다.

  • MVP: 최소 기능 제품(MVP) 개발 과정과 결과를 소개합니다.

  • 성과: 프로젝트나 작업에서 달성한 주요 성과와 성공 사례를 공유합니다.

  • 업데이트: 프로젝트나 제품의 최신 업데이트와 변경 사항을 알립니다.

  • 런칭: 새로운 제품이나 기능의 출시 소식을 전합니다.

  • 배운점: 프로젝트나 작업을 통해 얻은 교훈과 배운 점을 나눕니다.

  • 고민: 현재 직면한 문제나 고민에 대해 이야기합니다.

  • 푸념: 작업 중 겪은 어려움이나 불만을 솔직하게 털어놓습니다.

  • 회고: 프로젝트나 작업을 마친 후의 회고와 반성을 기록합니다.

  • 생각정리: 복잡한 생각이나 아이디어를 정리하여 공유합니다.

  • 의사결정: 중요한 의사결정 과정과 그 이유를 설명합니다.

  • 질문: 독자들에게 묻고 싶은 질문이나 의견을 구합니다.

  • 계획: 앞으로의 계획과 목표를 공유합니다.

  • 챌린지: 도전 과제와 그 해결 과정을 기록합니다.

  • 자기소개: 블로그 작성자에 대한 소개와 개인적인 이야기를 전합니다.

오픈소스 프로젝트에 참여함으로써 얻을 수 있는 보상

​

  • 개인 브랜드 강화: 오픈소스 기여를 통해 자신의 이름을 알리고, 개인 브랜드를 강화할 수 있습니다.

  • 포트폴리오 강화: 오픈소스 프로젝트에 기여한 기록은 본인의 자산이며, 포트폴리오에 추가할 수 있고, 이는 취업이나 프리랜서 활동에 큰 도움이 됩니다.

  • 경험과 기술 향상: 실제 프로젝트에 얻은 실무 경험을 쌓고, 새로운 기술을 배우며 자신의 역량을 공유할 수 있습니다.

  • 네트워킹 기회: 다양한 개발자들과 협업하면서 네트워크를 확장하고, 업계 전문가들과의 인맥을 쌓을 수 있습니다.

  • 인정과 감사: 프로젝트의 공식 문서나 웹사이트에 기여자로 이름을 올리거나, 기여자 페이지에 소개됩니다.

  • 학습 기회: 저와 직접 피드백을 주고 받으면서 프로젝트를 진행하면서 발생하는 이슈나 장애에 대한 지원 및 학습할 수 있는 기회를 제공합니다.

어떻게 기여할 수 있나요?

​

  • 문서 개선: 기존 문서를 읽고, 오타나 잘못되거나 오래된 정보를 수정해 주세요.

  • 새로운 가이드 작성: 프로젝트 사용법, 설치 방법, 팁 등을 포함한 새로운 가이드를 작성해 주세요.

  • 번역: 문서를 다양한 언어로 번역하여 더 많은 사람들이 접근할 수 있도록 도와주세요.

  • 피드백 제공: 문서를 읽고 이해하는 데 어려움이 있었다면, 피드백을 제공해 주세요.

참여 방법​

  • GitHub 저장소를 포크하고, 변경 사항을 커밋합니다.

  • Pull Request를 생성하여 변경 사항을 제출합니다.

  • 리뷰어가 변경 사항을 검토하고, 필요한 경우 피드백을 제공합니다.

작은 기여가 큰 변화를 만듭니다. 함께 더 나은 오픈소스 프로젝트를 만들어 나가요.

1
0
조준철

조준철

성당과 시장 리뷰

모든 사람들이 개발자일 필요는 없지만, 코드를 들여다 볼 줄 알면 적어도 손해 볼 일은 없기 때문에 전공이 아니더라도 소프트웨어 개발 학습을 권장 한다. 코드는 컴퓨터와 소통을 하기 위한 언어이자, 말이 통하지 않는 사람들과 소통할 수 있는 유일한 도구이기 때문이다.

에릭 레이먼드의 성당과 시장은 사회초년생이었던 나에게 많은 영향을 주었다.

어느 정도였냐면 인터넷 기반 기업들의 주가가 급격히 상승하면서 거품이 형성되었던 닷컴 버블 시기에 국내 기업들도 미래 먹거리를 위한 비전과 그에 따른 R&D 보다 단지 눈먼 돈을 벌기 위해 너도 나도 무리한 일정과 기능 검토 없이 프로젝트 수주와 기업 투자를 위한 임직원들의 월화수목금금금이 일상 이었던 2000년 당시 SI 신입 시절 한창 바빴을 시기였다.

연예나 취미도 모르는 집과 회사 밖에 몰랐던 내가 리차드 스톨만이 국내에 방한하여 연세대학교에서 강연한다는 소식에 지금은 아니겠지만 당시에는 업무 시간에 세미나 가는 것이 일반적인건 아니어서 월차내고 무슨 예긴지도 모를 GNU 에 대한 강연을 들으러 찾아 갈 정도 였다.

우리가 알고 있는 모든 직업에는 나름의 역사가 있고, 대부분의 경우 직업군에 필요한 기초, 심화 이론을 정립해둔 공학적 접근방식의 선구자들이 있다. 개인적으로 소프트웨어 공학에서 기억이 남는 선구자는 3명인데 놀랍게도 모두 2025년에도 현역으로 활동중이다.

만약 소프트웨어 개발을 하는 분들중에 다음의 3명의 이름을 처음들어 봤다면, AI와 구글 검색으로 재미있는 일화들을 찾아 볼 수 있을 것이다.

  • Linux 운영체제의 커널과 Git 개발자 "리누스 토발즈"

  • Windows 11 운영체제의 핵심인 NT 커널 개발자 "데이비드 커틀러"

  • GitHub 의 오픈소스 윤리를 공유하는 "리차드 스톨만"

최근 100년 사이에 인류의 문명 발전은 인간에게 적응할 시간도 없이 너무 빠르게 발전하고 있다는 것을 보여주는게 아닐까 싶기도 하고, 앞으로의 세대들이 받아들일 지식의 양이 어마어마 하다는 것은 웬지 안타깝기 까지하다.

이 글은 내가 왜 개발이 재미있고, 오픈소스로 HandStack 을 만들고 공유하고 있는지, 오래전 읽었던 성당과 시장을 글을 다시 읽어보며 아직 읽어 보지 않았던 소프트웨어 개발자 분들에게 공유하고픈 내용과 나름의 첨삭을 해본 잠시 읽어볼 만한 추천글이다.

해커 문화의 짧은 역사

1960년대와 1970년대의 해커 문화를 형성한 프로그래머들은 MIT 인공지능 연구소와 같은 곳에서 활동하며, 유닉스와 같은 초기 운영체제를 개발하고, 아르파넷(인터넷의 전신)을 구축하는 데 기여한 인물들이다.

이 시기의 프로그래머들은 오늘날의 오픈소스 운동의 기초를 다졌다고 할 수 있다. 즉, 해커는 컴퓨터가 대중화되지 않고, 먹고 사는 게 힘들었던 시대에 컴퓨터 시스템을 능숙하게 다루고, 시스템을 개선하거나 혁신하며 얻은 지식들을 별다른 대가 없이 공유하는 소수의 엘리트 그룹을 일컫는 단어이다.

본래 "해킹" 이라는 의미가 해커의 일상적인 문제를 푸는 개인적인 해결책을 찾는 것에서 부터 시작되어, 그 문제가 많은 해커들에게 공감받고 해결책이 널리 퍼지게 되는 것을 미덕으로 생각하는 것으로 받아들여졌던 당시에는 얼마나 아름다운 활동이었는지 생각하게 된다.

해커 문화는 순수한 형태에서 시작되어 많은 프로그래머들에게 영향을 주었으나, 1980년대부터 소프트웨어 산업이 상업화되면서 많은 소프트웨어가 독점적으로 개발되고 배포되었고, 이는 공공의 이익을 위한 해커들이 자유롭게 소프트웨어를 수정하고 공유하는 문화를 약화시켰다.

그래서 몇몇 해커들이 값 비싼 소프트웨어의 정품 라이선스 기능을 무력화하여 재배포하거나 기업의 시스템에 침투하여 데이터를 훔치는 사건이 증가하면서, 정부와 기업들은 보안 강화를 위해 다양한 법적 규제를 만들고 해커 활동을 제한하며 일부를 범죄로 간주하게 만들었다.

그렇게 대중들에게 점차 해커 문화의 순수성이 약화되고, 다양한 목적과 동기를 가진 사람들이 해커 활동에 참여하게 되면서, 인터넷의 보편화와 기술의 복잡성으로 인해 해커 문화는 더 이상 초기의 형태에서 벗어나 다양한 방향으로 변화하게 되었다.

마지막 해커 "리처드 스톨만"

1980년대에 소프트웨어 산업이 상업화되면서 해커 문화가 점차 사라지기 시작했을 때, MIT 인공지능 연구소에서 활동하며 현재 까지도 자유 소프트웨어 운동을 주도하는 인물인 리처드 스톨먼의 해커 정신은 다음과 같이 요약된다. 이로 인해 그는 종종 "마지막 해커"라고 불린다. (성당과 시장의 저자 에릭 레이먼드는 이 표현을 좋아하지 않는듯하다.)

  • 자유 소프트웨어: 소프트웨어가 사용자에게 자유롭게 사용, 수정, 배포될 수 있어야 한다고 주장한다. 이를 위해 그는 GNU 프로젝트와 자유 소프트웨어 재단(FSF)을 설립하고, GNU 일반 공중 사용 허가서(GPL)를 작성했다.

  • 공유와 협력: 소프트웨어 개발자들이 서로의 코드를 공유하고 협력하는 문화를 중요하게 생각한다. 그는 소프트웨어가 독점적으로 사용되는 것을 반대하며, 모든 사람이 소프트웨어의 혜택을 누릴 수 있어야 한다고 믿는다.

  • 해커 윤리: 해커들이 기술적 도전을 즐기고, 창의성을 발휘하며, 시스템을 개선하는 것을 중요하게 여긴다. 그는 해커들이 단순히 시스템을 침해하는 것이 아니라, 시스템을 더 나은 방향으로 발전시키는 역할을 해야 한다고 생각한다.

이러한 해커 정신은 오늘날 오픈 소스 소프트웨어 운동의 기초가 되었으며, 많은 개발자들에게 영감을 주고 있고, 다양한 프로젝트의 기본 사상으로 자리 잡고 있다.

리처드 스톨먼은 2006년 11월에 한국을 방문하여 연세대학교에서 GNU 프로젝트와 자유 소프트웨어, 그리고 GPLv3에 대한 최신 동향을 주제로 강연을 진행했다. 당시 한국 사회에서 강연을 하는 것은 정장이나 격식을 중요하게 생각했었지만, 그는 청바지를 입고 강연을 했다. 그의 편안한 복장과 말투는 자유 소프트웨어 운동의 정신을 잘 반영하는 모습이었다.

그때 강연에 통역도 없고 영어도 몰라서 리차드 스톨만의 강연이 무슨 내용인지 잘은 모르지만 옆에 앉아 있던 외국 개발자가 GNU 를 한국 개발자들이 (지엔유)로 발음하는 것을 (그누~) 로 발음해야 한다는게 기억에 남는다.

초기의 공개 유닉스

1990년 초, 독점적 유닉스를 "해킹" 하려는 10여 년간의 해커 그룹의 노력이 실패로 끝났다는 것이 IT 업계에 공식적인 뉴스로 언급되며, 이제 개인의 기술 영웅주의가 끝났으며, 소프트웨어 산업과 초기 인터넷이 점점 더 마이크로소프트와 같은 거인에 의해 지배된다는 것을 보도했다.

다행히 1993년 후반에서 1994년 사이에 언론과 해커 들 사이에서 눈에 띄지 않고 진행된 작은 일이 해커 문화를 아주 다른 방향으로 이끌고 생각지도 못한 성공을 거두게 되는데, 그것이 현대 대부분의 IT 시스템의 근간으로 사용되는 리눅스이다.

1991년에 헬싱키 대학생 리누스 토발즈는 자유 소프트웨어 재단의 도구를 이용해 386 기계를 위한 공개 유닉스 커널을 개발하기 시작했고, 완전히 자유롭고 재배포 가능한 소스로 구성된 유닉스인 리눅스를 개발하는 것을 중점으로 진행했다.

당시 해커 들은 운영체제처럼 복잡한 소프트웨어는 비교적 작고 잘 구성된 엘리트 모임에 의해 주의 깊게 조정되며 개발돼야 한다고 믿고 있었는데, 리눅스는 처음부터 인터넷에 의해서만 조정되는 수많은 자원자에 의해 우연히 해킹되었다.

품질은 엄격한 표준이나 독재로 이루어지지 않았으며, 매주 릴리스 되었고 며칠 안에 수백 명의 사용자(개발자)들로 부터 피드백을 받았고, 리누스 토발즈도 훗날 당시 주요 커널 소스코드를 이메일로 주고 받으며 수작업으로 일일이 코드를 병합했던게 제일 힘들었다고 언급하니 당시 그의 개발 방법은 기존 개발 방식과는 완전히 다른 방식으로 발전한 것을 알 수 있다.

그런 면에서 리눅스의 가장 중요한 특징은 기술적인 것이 아니라 사회적인 것이었다. 당시 국내와는 다르게 초기 리눅스는 찰스 다윈의 진화론에서 중요한 개념인 다윈주의적 적자생존의 선택을 할 수 있게 하는 단순하지만 파격적인 전략에 의해 개발자들이 지속해서 변화를 관리했다. 이에 대한 것은 에릭 레이먼드도 동의하는 글을 쓰며 리눅스의 성공을 설명했다.

성당과 시장

성당과 시장은 리눅스의 역사가 제시한 놀라운 소프트웨어 공학 이론을 신중히 검토해 보려고 진행한 페치메일 오픈소스 프로젝트의 경험을 바탕으로 작성한 에릭 레이먼드의 개발 이론이다.

그의 이론은 근본적으로 서로 다른 개발 방식의 용어로 사용되는데, 상업용 소프트웨어의 독점적 개발 방식인 "성당" 모델과 오픈소스 기반의 규칙과 제한이 없는 "시장" 모델을 가리킨다.

페치메일 오픈소스 프로젝트의 기회를 얻기 위한 에릭 레이먼드가 무에서 유를 만드는 게 아닌 기존의 오픈소스 프로젝트에서 본인의 니즈와 가장 가까운 프로젝트를 이어 받기 위해 언급한 교훈은 현대 사회에서 개발 중인 개발자 들에게도 크게 다르지 않게 적용될 수 있을 것 같다.

  • 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (소프트웨어 개발자들은 너무나 자주, 단지 돈 때문에 그들이 필요하지도 않고 좋아하지도 않는 프로그램을 만드는 데 시간을 쓰고 있다. '내가 원하는 것과 가장 가까운 프로그램은 무엇일까?')

  • 좋은 프로그래머는 어떤 프로그램을 만들어야 할지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할지 그리고 재사용해야 할지 안다. (위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 완전한 무에서 시작하는 것보다는 부분적으로나마 좋은 해결책에서 시작하는 게 대부분 더 쉽다.)

  • 갖고 있는 것을 버릴 계획을 세우라. 언젠가는 버리게 될 것이다. (프레더릭 브룩스, 『맨먼스 미신』 11장 중에서)

  • 적절한 태도를 갖고 있으면, 흥미로운 문제가 당신을 찾아갈 것이다.

  • 프로그램에 흥미를 잃었다면, 프로그램에 대한 당신의 마지막 의무는 능력 있는 후임자에게 프로그램을 넘겨주는 것이다. (한 가지 문제는 후임자가 적임자라는 것을 어떻게 입증할 수 있느냐 하는 것이었다.)

  • 사용자를 공동 개발자로 생각하면 코드가 다른 어떤 방법보다 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.

  • 일찍 발표하고 자주 발표하라. 그리고 사용자의 소리에 귀를 기울여라.

  • 충분하게 많은 베타 테스터와 공동 개발자가 있으면, 거의 모든 문제는 빠르게 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.

  • 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대 경우보다 훨씬 잘 작동한다.

  • 베타 테스터를 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다.

  • 좋은 아이디어를 생각해 내는 것 다음으로 중요한 일은 사용자가 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다.

  • 종종 가장 충격적이고 혁신적인 해결책은, 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못돼 있다는 것을 깨닫는 것에서 나온다.

  • 설계에서 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다.

  • 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다.

  • 재미있는 문제를 풀어보고 싶다면, 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라. (가장 뛰어난 해킹은 해커의 일상적인 문제를 푸는 개인적 인 해결책부터 시작된다.)

에릭 레이몬드는 리누스 토발즈의 가장 영리하고 중요한 해킹은 리눅스 커널을 만든 것이 아니라 리눅스 개발 모델을 만든 것이라고 평가한다.

성공적인 시장 방식 개발을 위한 선행 조건은 프로젝트가 공개되는 시점에 메인 개발자의 자질과 코드가 어떤 상태인지가 중요하다. 처음부터 시장 방식으로 개발할 수 없다는 것은 자명하다. 테스트, 디버깅, 개선은 시장 방식으로 할 수 있다. 하지만 프로젝트를 시장 방식으로 시작하기는 매우 어렵다.

프로젝트에 합류를 하는 개발자는 어느 정도 기본적인 수준의 설계와 코딩 기술은 물론 필요하지만, 시장 방식 프로젝트를 시작하려고 심각하게 생각하는 사람이라면 그런 정도는 적어도 넘어섰으리라고 기대한다.

개발 시장은 다른 직업에 비해 분명히 다른 점이 있는데 개발자들 사이에 평판에 대한 미묘한 압력을 사람들에게 가한다. 그래서 지속적으로 따라갈 경쟁력이 없는 사람은 개발 프로젝트를 시작하지 않게 된다. 이것은 그때나 지금이나 잘 들어 맞는 것 같다.

반드시 개발자 공동체가 초기에 실행하고 테스트할 수 있는 장난감이 필요하다. 공동체를 만들기 시작할 때 제시해야 하는 것은 그럴듯한 장래성이다.

프로그램이 특별히 잘 동작할 필요는 없다. 조잡하거나, 버그투성이여도 되고, 완성되지 않고 문서가 형편없어도 상관없다. 하지만 한 가지 확실하게 해야 할 것은 잠재적인 공동 개발자들에게 이것이 머지않은 미래에 정말 괜찮은 무언가로 진화할 수 있다는 것을 이해시키는 일이다.

더 많은 이야기

이 글의 성당과 시장의 일부를 언급한 내용이다. 성당과 시장은 무료 도서이며 다음의 URL 에서 epub, pdf 문서를 다운로드 할 수 있다.

https://www.oss.kr/oss_guide/show/64be57d5-5919-4069-9643-13827b7c69c3

1
0
조준철

조준철

2024년 회고와 2025년 만드라트 계획

2024년 회고

인생이 계획대로 되는 일은 거의 없다고 생각해서 개인적으로 장기적인 목표를 세우고 계획을 만드는 것을 즐겨하는 편은 아닙니다. 단기적인 목표를 세우고 그것을 달성하는 것을 즐기는 편이지요.

어찌보면 주먹구구식으로 사는 듯한데, 올 해가 을사년이다보니 (제가 뱀띠라 웬지 반갑...) 작년 동안 사이드 프로젝트로 시작해서 메인 프로젝트로 진행 중인 HandStack 에 대한 여정으로 2024년을 회고하고 2025년 계획하는 것으로 시작 해 봅니다.

GitHub 릴리즈 v1.0.0 ~ v1.1.3

HandStack 1.0.0 기점으로 1.1.3 릴리즈를 배포할 때 까지 381 건의 커밋과 803 건의 파일 변경하며 대략 1년 정도의 여정 동안, 다양한 버그 수정과 안정성 및 기능 개선이 이뤄졌습니다.

GitHub 전체 변경 내역

개인적인 성취

작년에는 개략적으로 "HandStack === 클라우드 네이티브 앱 개발 및 관리 SDK" 컨셉을 명확하게 하는 일에 몰입했습니다. 뒤돌아 정리해보니 100% 기준으로 개발 70%, 문서 20%, 커뮤니케이션 10 % 비율로 크게 3 가지로 요약이 가능하더군요.

작년 초까지 혼자 모든 것을 담당하고 있었고, 지금은 각각 다른 분야에서 활동중인 4 명이서 개발, 확장, 컨설팅 영역으로 나누어 진행중입니다.

주요 진행 성과

  • GitHub 에 HandStack 오픈소스 공개 및 개선

  • 앱 개발 및 설정, 배포 자동화를 지원하는 CLI 프로그램

  • https://handstack.kr GitHub 에 문서 사이트 오픈소스 공개 및 문서 추가

  • https://www.youtube.com/@handstack-kr 유튜브 채널 오픈 및 컨텐츠 게시

  • HandStack 기반 메인 소스코드 관리 filehub 확장 모듈 진행 중

이외에 소소하게 HandStack 기반으로 상업적인 프로젝트를 진행 중이고

  • HandStack 기반 기업 그룹웨어 easywork 확장 모듈 개발 완료 및 안정화 진행중

  • HandStack 기반 개발 소스코드 공유 플랫폼 handsup 확장 모듈 진행중

추가적으로 향후 로드맵에 포함되어 있는 상업용 확장 모듈 계획중입니다.

  • mojito 모듈 개발 (브랜드 쇼핑몰)

  • collabic 모듈 개발 (사내교육관리)

  • engineering 모듈 개발 (모니터링 & 변경관리 기능)

  • operations 모듈 개발 (작업 스케줄링)

도전 과제 인지

2024년에는 향후 비즈니스를 위한 Vertical 기술 영역을 중점적으로 활동하다보니, 일방적인 소통 방식에 대해 개선의 필요성을 고민하게 되네요.

S/W 는 크게 일반적인 용도의 업무 사용자를 대상으로 하거나 전문적이고 특정 분야의 사용자를 대상으로 코어 역할을 담당하는 솔루션/프레임워크/라이브러리로 구분할 수 있는데요.

HandStack 은 개발자와 엔지니어가 적은 비용으로 앱 개발과 운영에 도움을 주는 영역을 담당하고 있다보니 도입 초기에 어려움이 있다는 의견이 있었습니다. 그래서 올해에는 기술적인 부분보다 Horizontal 업무 영역에서 다양한 활동들을 계획해야 하는 필요성을 인지하게 되었습니다.

2025년 만드라트 계획

2025 Plan.png

개인적으로 올해 달성해야 할 목표를 "HandStack 기반으로 진행하는 상업적인 IT 서비스 프로젝트를 100 개를 실행" 하기 위해 개발자들과 개발 전문업체와 네트워킹을 진행하며 진행과정을 기록 해보려고 합니다. 연말이나 내년 초에 정리해서 공유하겠습니다.

HandStack 은 동일한 환경에서 경쟁과 성장을 원합니다.

이제 S/W 를 통한 고객의 문제 해결 역량이 모든 기업에게 선택이 아닌 필수인 시대가 되었다는 것은 누구나 알고 있고, S/W 경쟁력을 갖춘 기업이 시장을 주도할 것이기 때문에 디지털 전환 시대의 흐름에 따라 효율적인 시스템 구축 역량을 확보하는 방안을 고민하게 될 것입니다.

개인적으로 핵심 기술은 모두가 동일하게 공유하고 특화되는 업무 영역에서 경쟁과 성장을 유도하는 점에서 에릭 레이먼드의 "성당과 시장" 모델을 추구합니다.

HandStack 소스코드가 인터넷을 통해 일반에 상업적 사용에 제한이 없는 공개된 상태로 개발이 진행되어, 많은 개발자들이 자유롭게 참여하고, 다양한 피드백과 기여를 통해 소프트웨어가 발전하기를 기대합니다.

누가 HandStack 에 관심을 가져야 할까요?

IT 업계가 시스템 구축에 필요한 개발과 운영을 별도 업무로 여기기 때문에 개발 결과물에 대한 Q/A 만 통과하면 사실상 개발자의 역할이 종료되는 것을 당연하게 생각합니다. 그래서 개발 업무 프로젝트의 마지막 단계는 납품인 경우가 적지 않았고 운영 업무에 개발자가 영향을 줄 수 없는 경우가 있었는데요.

전통적인 패키지 제품 개발에서 클라우드와 서비스형 소프트웨어(SaaS)를 구축하기 위한 IT 기술의 발전으로 인해, 개발과 운영의 경계는 희미해져 지금의 운영 문제는 전통적인 운영 부서가 해결할 수 있는 수준이 아닙니다.

관리자는 비용 효율적인 시스템 구축 역량을 어떻게 유지할 수 있는 지에 대한 기술 선택과 인력 운영에 대한 고민과 개발자는 업무와 시스템 운영의 문제를 이해하고 이에 준비된 소프트웨어를 만들 어야 하는것이 필수적입니다.

HandStack 은 프로젝트 규모에 상관없이 동일한 환경에서 개발, 보안, 확장이 가능한 방안을 제공하기 때문에 이에 대한 관심이 있으신 분들에게 적합합니다.

개발자와 엔지니어에게 제공하는 가치

화면과 기능을 분리하여 HTML5, SQL, 서버함수(C#, Node.js, Python [올해 예정]) 만으로 앱을 만들 수 있고, 일정한 패턴과 품질로 코드가 구성되어, 개발자라면 쉽게 코드를 파악 가능하여 유지보수에 이점으로 적용할 수 있습니다.

이에 따라 프로젝트 갯수가 늘어나고 담당 일이 점점 많아져도 새로운 직원들과의 협업과 인수인계에 도움을 줍니다.

CTO 또는 관리자에게 제공하는 가치

  • 공개 SW 기반 비 독점적 비용 구조로 부담없이 기업 내 도입을 검토할 수 있습니다.

  • 개인 또는 여러 팀원에게 시스템 구축에 필요한 업계 표준의 개발/업무 지식을 공유 가능합니다.

  • 업무 규모에 따라 모놀리식, 마이크로서비스 아키텍처 기반의 시스템 인프라를 자유롭게 구성 가능합니다.

  • 특정 운영체제와 통합 개발 도구에 의존하지 않는 앱 개발이 가능합니다. (Windows, macOS 에서 선호하는 개발 도구에서 개발하고 Linux 서버에 배포 가능)

  • 확장을 위한 GitHub의 다양한 상용/공개 SW 와 nuget, npm 패키지 활용 가능합니다.

2025년, 개발자와 엔지니어 분들의 성공과 성장이 가득하길 바랍니다! 🚀🎉

2024년의 성과와 도전 과제를 돌아보며, 2025년에는 더욱 큰 성장을 이루시길 바랍니다. HandStack의 여정이 많은 개발자와 기업들에게 영감을 주고, 함께 성장하는 기회가 되기를 기대합니다. 새로운 해에는 더욱 많은 프로젝트와 협업을 통해 목표를 달성하도록 노력하겠습니다.

읽어 주셔서 감사합니다.

https://github.com/handstack77/handstack

1
0
조준철

조준철

IT 기술 창업 톺아보기 (2)

글을 쓰다가 갑자기 현타가 왔습니다. 이번 글에서 창업 전략에 대한 내용을 다룰려고 했는데, 어느정도 글을 써보니 결국 지금은 사업을 잠시 중단하고 다시 직장 생활을 하고 있는데 아무리 전에 고민을 한 주제라고 해서 제가 이야기를 하는 것이 적절하지 않은 것 같아 창업 전략에 대한 검색 키워드 정도만 언급하고 사업 아이템에 대한 경험담 위주의 글로 정리하려고 합니다.

창업 전략 주제 키워드

  • 투자를 받기 위해

  • 네이밍과 브랜딩

  • 메일주소는 온라인 명함

  • 누구와 함께 해야 하는가?

  • 개발자를 구하고 유지하는 법 (신입 vs 경력)

  • 비즈니스의 가치가 만들어 지려면

  • 전시회, 박람회를 최대한 활용해서 홍보

  • 조직운영, 직함 체계 정하기

  • 대표병을 조심하자

  • 창의력을 죽이는 나쁜 습관

  • 돈의 흐름 이해하기

  • 투자유치자료(Inverstor Relations) 작성법

  • 미션(Why), 핵심가치(How), 비전(What)

지난 글에 이어서…

저와 같이 기술 기반 실무지식을 바탕으로 창업을 생각 하고 계시는 경우 다음 질문에 답을 해야 합니다.

내가 제일 잘하는 일로 팔릴만한 제품이나 서비스 또는 컨텐츠를 3개월 내에 보여 줄 수 있는가?

왜냐하면 잘하다 보면 재미가 있어서 오래할 수 있는 동기가 붙기 때문이고, 십원 짜리던 백만원 짜리던 팔릴 만하다는 것은 가치 있는 것을 만들 수 있으며, 3개월내 보여줄 수 있는 것은 그 동안 해당 분야의 전문 지식을 꾸준히 쌓으며 준비 해왔다는 것을 의미하기 때문입니다.

기업의 본질은 수익 모델을 만드는 것인데, 뛰어난 기술만 가지고 섣부르게 사업을 시작하면 남의 일만 해주는 용역 서비스를 하는 것과 차이가 없게 되어버려서, 이럴 때는 사업보다 프리랜서로 전향하여 다양한 프로젝트에 참여하여 경력과 고객을 확보해두는 것이 장기적으로 더 나은 선택이 될 수 있습니다.

회사 소유권 이해하기

현재 회사를 다니고 있다면 회사 업무시간에 만들어낸 모든 저작물과 도구는 기본적으로 회사 소유라고 생각해야 합니다.

특히 IT 분야의 경우 내가 만들어낸 기획, 캐치 프레이즈, 디자인, 캐릭터, S/W, 프로그램 소스 코드, 기술 알고리즘 등등 복제가 쉽기 때문에 업무 시간내에 만들어 낸 저작물들과 외주를 받아 만들어낸 결과물에 대한 모든 권리는 기본적으로 회사에 있습니다.

이것은 모든 국가에서 공통적으로 영업비밀보호법에 의하여 보호되고 있는 회사의 권리인데, 본인의 노력으로 얻어진 결과를 본인의 것이라고 생각하기 쉽습니다.

그래서 창업을 하기 위해 직장인의 경우에는 동종 업계에서 유사한 기술 기반 사업 아이템을 만들게 되면 보편적으로 널리 알려진 기술인것을 입증하거나 특허, 저작권, 회사 규정에 문제가 있는지 검토해야합니다.

이 부분은 본인의 사업에 직원을 채용하게 되면 동일하게 적용하게 됩니다. 저는 이것을 염두해서 기술은 투명하게, 제품과 서비스로 승부하기 위해 사이드 프로젝트로 진행중인 HandStack 을 오픈소스로 공개하고 회사의 프로젝트에 적용하고 있습니다.

MVP 이후의 고민…

본인의 아이디어를 믿고 묵묵히 실행하면 결과가 만들어진다는 믿음으로 사업 아이템을 만들면 MVP 까지는 만들게 되는데 어느 선에서 부터 정체가 발생합니다.

이쯤에서 아이템의 기능을 더 개선하고, 완성도를 높여야 할 것인지, 현재 상태에서 고객층을 확보하고 시장에 진입을 할 것인지 고민을 하게 되었는데, 이때 부터 1인 기업의 한계가 크게 다가오기 시작 했습니다.

일단 개발중인 MVP 수준의 아이템을 지인중에 IT 분야를 잘 모르는 공무원, 비슷한 수준의 개발자, IT 솔루션 컨설턴트 세 명에게 시연을 해서 피드백을 받게 되었는데 공통적으로 알게된 것은 사업 아이템이 B2B 시장에 적합한 것으로 보여지고, 회사에 납품을 하기 위해서 MVP나 베타 버전과 같은 수준이 아니라 기능이 적더라도 확실한 수행을 할 수 있는 정식 버전과 이에 대한 제품의 브랜딩, 상업적 라이선스에 대한 것을 준비해야 하는 것 이었습니다.

회사 대표의 미션 세 가지

위에서 언급한 IT 솔루션 컨설턴트 지인과는 20년 넘는 인연으로 같이 개발 업무로 시작해서 여러 프로젝트를 같이 하며 서로의 장단점을 잘 알고 있는 사이입니다.

그에게 MVP를 시연하고 식사를 하며 받은 조언이 “지금 너에게 중요한 것은 만드는 게 아니라 브랜딩” 이고, 주어진 역할 마다 반드시 해내야 할 미션들이 있는데 그 중에서 대표이사의 주요 미선은 “고객, 투자자와 커뮤니케이션” 이라며 사업 아이템에 적합한 회사 대표님들과의 미팅을 주선을 해 주었습니다.

회사 대표님들과의 미팅에서 얻은 인 사이트는 다음과 같이 세 가지로 요약할 수 있습니다.

  • 사람 잘 모셔오고, 잘 내보내기

  • 사업 자금(대출, 투자, 매출) 구해오기

  • 고객, 투자자, 팀원 커뮤니케이션

IT 분야는 직업 특성상 직장 생활을 오래 하더라도 다양한 사람들을 만나기가 쉽지 않은데 그러다보면 "나"를 기준으로 상황을 판단하다가 "너"를 기준으로 주변을 돌아 보게 되는 것을 조금 늦게 알게 되나봅니다. 그동안 내가 맡은 일에 대해서 결과로 보여준다는 자부심을 가지고 해왔었는데…

회사 대표님들과의 미팅 자리가 지인 소개가 아닌 콜드 메일, 콜드 전화로 얻은 자리였다면 같은 분위기에서 좋은 피드백을 받을 수 있었을까요?, 좋은 성과를 내기 위한 커뮤니케이션 스킬은 단순한 대화 기술이 아니라 인간 관계에서 시작되는 것을 의미하는 것을 알게 되면 내향적인 성향은 사업하기 쉽지 않다는 것을 느끼게 합니다.

쫄지 말고, 번아웃을 주의하기

규모를 떠나 안정적인 수익 모델을 확보하고 있는 회사 대표님들과 만나게 되니 공통점을 하나 발견했는데 비즈니스는 인간 관계로 시작해서 "돈을 다루는 사람"의 이해 관계를 따라 흐른다는 것을 각자 분야에서 자신만의 방식대로 터득을 하게 되었다는 겁니다.

대부분 사업을 시작하고 안정화 될 때 까지의 고생 했던 이야기를 듣다보면 앞으로 다가올 내일 같이 느껴져서 생각이 많아지게 되었는데요.

이 시점에서 짧은 기간이지만 심리적으로 앞으로 해야 할 것들에 대한 부담이 되기도 하고, 지금 사업 아이템에 대한 방향성을 확실히 정하지 못한 상황에서 예상하지 못했지만 내가 부족한 부분을 채우지 못한채 앞만 보고 달려가는건 아닌거 같아 이도저도 못하다가 번아웃을 겪게 되는데…

몇 일 정도 정말 멍 하게 있다가 슬슬 멍하게 있는게 지겨워져서 생각을 길게 하지 않고 당장 눈 앞에 있는 내가 할 수 있는 일들을 하나하나 체크리스트로 만들어 그냥 하게됩니다.

그래서 기술 창업으로 사업화는 잠시 묻고 지금 하고 있는 일들이 누구를 위한 일이며, 왜 하는지에 대한 물음과 그것에 대한 실마리를 되새기며 사이드 프로젝트로 시작했던 것을 여기까지 유지하면서 만들어 낸 것을 어떻게 효과적으로 피벗을 할 수 있을까?에 집중하게 됩니다.

사업 성공의 핵심은 끈기

학연, 혈연, 지연으로 만남의 기회를 만든다는 이라는 것이 공정성인 측면에서 부정적인 의미로 들릴 수 있겠지만 내 기준에서 비 합리적인 것이나 말도 안된다고 생각하는 것도 업계에 관례로 있다면 나름 그만한 이유가 있을겁니다.

그래서 기존의 방식을 내려놓고 어느정도 “유” 해져야 하는데 그게 말처럼 쉽지는 않네요.

사업에서 성공하기 위해서는 다양한 사람들과의 만남이 필수적입니다. 새로운 기회는 종종 예상치 못한 만남에서 비롯되며, 이러한 만남을 통해 MOU를 맺으며 사업의 방향이 결정되기도 합니다.

사람들과의 소통에서 중요한 것은 텍스트나 전화 음성으로 전달하는 단순한 말이 아니라, 대면 상에서 이뤄지는 눈빛, 말투, 몸짓을 통해 상대방에게 중요한 존재로 여겨진다는 느낌을 전달하는 것입니다. 상대방의 이야기에 진심으로 귀 기울이고, 공감하는 태도를 보이는 것이 중요합니다.

저의 경우 여기까지 생각을 정리하고 사업으로 성공하는 사람들을 다시 보니 이러한 비언어적 소통으로 신뢰를 쌓고, 깊은 인간관계를 형성하는 데 자연스럽고 익숙하다는 것이 보이기 시작 했습니다. 같은 말이어도 표현 방법과 단어의 선택이 평소 그 사람의 지식 수준과 인성으로 느껴질때 부럽기도 하면서 부끄럽기도 합니다.

지금은 직장을 다니면서 사이드 프로젝트로 HandStack 를 유지하고 있는데 문서화나 예제에 대한 컨텐츠에 대해 늘 부족한게 많다고 느껴지지만 당장의 결과에 조급해지지 않도록, 매일 100 정도의 활동양이 필요하다고 하면, 120 이 아니라 10 이라도 꾸준하게 하는 것을 목표로 하고 있습니다.

이번 글에서 요약

저에 대한 장점은 주관적이라 생략하더라도 약점에 대해 정리를 하다보니 개인적으로 제 성향 자체가 창업에 적합하지 않다는 것을 깨닫게 되어 개선해야 할 부분을 다음과 같이 세 가지로 정리 했습니다.

  • 베타 버전을 떼고 제품의 완성까지의 시간과 비용을 계산하지 못하는 것

  • 사업의 성공은 누군가가 나를 좋아해주는 성공적인 인간 관계에서 시작됨

  • 기술 기반 사업을 통해 혁신을 이끄는 사람들과 네트워킹 부재

읽어주셔서 감사합니다.

2
0
조준철

조준철

IT 기술 창업 톺아보기 (1)

저는 2000년 IT 버블이 시작되었던 때 개발 직업으로 사회생활을 시작했습니다.

직장 생활을 하면서 언젠가 나만의 회사를 가지고 싶다는 생각으로 창업에 대한 관심을 가지게 되었고, 직장 생활 3년 차에 지인 3명과 함께 조그맣게 사업을 시작했지만, 1년도 안 되어 문을 닫게 되었습니다. 이후 한참 동안 회사 일에 집중하다 보니 어느새 결혼도 하고 아이도 생겼네요.

최근에는 창업에 대해 더 늦기 전에 다시 한번 도전해보고 싶어서 회사를 다니며 틈틈이 준비하다 보니, 창업이 나에게 너무나 어렵다는 것을 느끼고 있습니다. 현실적인 문제나 제 의지의 문제는 어떻게든 해보겠는데, 개인적으로 제 성향 자체가 창업에 적합하지 않다는 것을 작년 중순쯤 깨닫게 되었습니다.

그래서 창업을 시도하는 방법을 꼭 사업자를 내고 시작하는 것이 아닌, 개발자로서 내가 잘할 수 있으면서 꾸준히 할 수 있는 일을 만드는 방법을 찾아가는 중입니다. 이번 글에서는 저와 생각이 비슷한 개발자이면서 "창업"에 고민하시는 분들을 위해 IT 기술 창업에 대해 약간의 경험을 추가해서 세 개의 글로 톺아보고자 합니다.

창업 아이템 구분​

창업은 크게 문화, 서비스, 기술 분야로 구분하면 내가 추구하고자 하는 대략적인 비즈니스를 이해하는 데 도움이 됩니다.

  • 문화: 대중문화 콘텐츠를 기반으로 한 문학, 그림, 공연, 애니메이션, 음악 등과 다양한 브랜드와 협업을 통해 사업을 확장하고 수익을 창출합니다.

  • 서비스: 기존의 낡은 서비스를 혁신하거나 새로운 서비스를 창출하는 것으로, 전화 주문 배달 서비스를 모바일 앱을 통해 주문과 배달을 하거나, 기존의 유료 서비스를 무료로 대체하며, 다양한 부가 서비스를 통해 수익을 만드는 플랫폼을 만듭니다.

  • 기술: 경쟁 제품이나 서비스를 더 저렴하게 만들거나, 더 비싸더라도 가치 있는 제품을 만들어내는 것을 목표로 합니다. 예를 들어, 전기차를 기존 내연기관차보다 더 효율적이고 안전하게 만들거나, 최근 화제가 된 우주 탐사를 더 저렴하게 만들기 위해 재사용 가능한 로켓을 개발하는 것 등이 있습니다. 고가의 프리미엄 제품을 통해 사용자들에게 높은 가치를 제공하며, 충성도 높은 고객층을 확보합니다.

국내 스타트 업에 등록된 회사가 대략 20,710개가 되는데 이중에서 IT 기술 창업 분야의 비중은 100 을 기준으로 대략 문화: 10, 서비스: 70, 기술: 20 정도로 예상하는데, 저의 사업 아이템의 경우도 서비스에 해당합니다.

창업가의 출신 배경​

일반적으로 회사를 다니며 얻은 업무적, 기술적 전문 지식과 경험을 바탕으로 창업을 시작합니다. 직장인의 경우 비즈니스와 개인의 성향에 따라 자신만의 커리어를 구축하게 되는데, 그러다 보니 시간이 지날수록 자연스럽게 익숙해지는 업무 스킬과 성향이 있을 수밖에 없습니다.

  • 개발자, 연구소 출신: 기술적 전문성을 바탕으로 문제를 인식하여 새로운 기술이나 기존 기술을 혁신하여 해결을 시도합니다.

  • 영업인 출신: 고객과의 소통 능력과 시장 이해도를 바탕으로 비즈니스 모델을 혁신하거나 새로운 시장을 개척합니다.

  • 인문대 출신: 다양한 시각과 창의적인 사고를 바탕으로 문제를 이해하여 제품 디자인과 사용자 경험 향상에 중점을 둡니다.

저도 직장에서 오랜 기간 개발 업무를 하다 보니 일상 생활에서도 같은 방법으로 논리적으로 상황과 문제를 인식하고 해결하려는 것이 가끔 불편한 상황을 초래하는 경우가 있습니다. 주어진 환경과 맥락에 맞게 적절하게 대응해야 하는데, 직장 생활이 길어지고 나이가 40 대를 넘어가면 알게 모르게 쓸데없는 고집이 생겨나게 되어서인가 봅니다. 이것을 40대에서는 "곤조" 라는 일본어로 일에 대한 카리스마와 고집을 묘하게 섞은 말로 표현하고 하는데요.

제가 가진 사업 아이템에 대해 지인들과 이야기를 나누었을 때 한 지인이 "너는 곤조가 강해서 사업하면 안 된다"라는 말이 인상 깊게 남아 있습니다.

단순하게 사람을 상대할 때 "유" 해지라는 게 아니라, 직장을 다닐때는 "곤조"가 필요하지만 사업을 하기 위해서는 기존의 방식을 벗어나서 자신만의 방법으로 "스스로에게 사업의 존재 이유가 무엇인지 되새기고, 상대방이 원하는 것이 무엇인지 알아내기 위한 번뜩이는 질문을 던지는 실행력이 있어야 하며, 실패를 하더라도 문제의 원인을 찾아 해결책을 만들어내는 방법을 찾는 과정을 제시해야 하는 것"을 토대로 사업을 시작하는 마인드를 가져야 한다는 것을 의미합니다.

직장인과 창업가를 구분짓는 것이 특정 분야의 도메인 전문가가 아니라 출신에 상관없이 모든 분야에 관심을 갖고 배우는 자세가 필요합니다.

사업의 본질은 수익 모델​

기업의 가장 중요한 본질은 수익 모델입니다. 당연한 말인데 그게 경험이 없다보니 어렵습니다.

저의 경우 정부지원사업의 초기창업패키지를 활용하여 시작하려고 준비하다가 떨어진 경험이 있는데, 나중에 곰곰이 생각해보니 내가 사업 계획서의 내용이 "사업 아이템이 아니라" 상용화를 위한 기술 개발을 조건으로 "유의미한 성과"를 아이템으로 준비했었던 거구나 라는 깨달음을 얻을 수 있었습니다.

수익 모델이란 기업이 어떻게 돈을 벌 것인지에 대한 구체적인 비즈니스 모델을 의미합니다. 특정 분야의 기술만 가지고 사업을 시작하면 남의 일만 해주고, 연명하는 용역 서비스의 길에서 쉽게 빠져나오기 힘들기 때문에, 사업 아이템에 대한 로드 맵은 생존을 위한 아이템이고 두 번의 기회는 없다는 의지가 필요합니다.

지식재산권, 특허, 브랜드 등 사업 아이템을 지킬 수 있는 핵심 역량 보유는 기본이어야 해서 시행착오를 줄이기 위해 가장 잘할 수 있는 분야에 집중했더니 기존 용역 서비스와 크게 다르지 않는 것을 아이템으로 추친을 하고 있었습니다.

적어도 내가 그려나가는 아이템을 제품의 완성까지의 시간과 비용을 계산해서 시장의 규모와 함께 형성되는 시기를 예측하는 지혜가 필요했습니다.

이때부터 직장인이 1인 기업이나 소수의 인원으로 스타트 업을 한다는 게 얼마나 많은 시행착오를 견뎌야 하는 여정인지 감이 오기 시작했습니다.

사업계획서는 필수 문서​

사업계획서는 투자자들에게 사업의 가능성을 설득해서 투자를 받기 위한 문서라고 생각 했었는데, 그게 아닙니다. 창업의 성공을 위해 필수적으로 만들어야 하는 문서입니다.

제한된 일정과 자금의 압박속에 많은 시행착오를 견뎌야 하는 여정은 번아웃을 겪게 만들어 줍니다. 사업계획서는 그 와중에도 사업 아이템의 계획과 마일스톤을 체계적으로 정리하여 방향성을 명확히 하기 위한 스스로를 위한 문서이기도 하고, 언제든 힘든 여정에 함께 하는 팀원들이 사업의 목표와 전략을 이해하고 공감할 수 있는 문서이기 때문입니다.

사업계획서는 생각보다 간단하게 만들어도 됩니다. 대부분 엘리베이터 스피치나 커피챗과 같이 가볍게 아이템을 주제로 이야기를 할 수 있는 내용으로 작성해두고 언제든 업데이트가 편하게 유지하는 것이 좋은데, 향후에 다양하게 활용하기 위해서 다음의 항목만은 정리해두는 것이 좋습니다. 저의 경우 Markdown 으로 작성해서 OneDrive 에 개인 디렉토리로 보관해두어 집과 직장의 PC와 노트북으로 필요할 때 마다 언제든 내용을 업데이트 합니다.

  • 문제: 고객이 해결하고자 하는 문제를 명확히 정의합니다.

  • 아이템: 문제를 해결할 수 있는 제품이나 서비스를 설명합니다.

  • 고객 비전: 고객이 제품이나 서비스를 통해 얻을 수 있는 가치를 설명합니다.

  • 수익 모델: 아이템으로 어떻게 수익을 창출할 것인지 설명합니다.

  • 보유 기술: 사업에 필요한 핵심 기술과 고유한 강점을 설명합니다.

  • 팀의 능력: 제품이나 서비스 개발과 운영을 위한 팀원들의 역량과 역할을 설명합니다.

  • 경쟁사: 주요 경쟁사와 그들의 강점 및 약점을 분석합니다.

  • 시장 크기: 목표 시장의 규모와 성장 가능성을 평가합니다.

  • 자금 계획: 필요한 자금과 그 사용 계획을 상세히 설명합니다.

  • 로드맵: 사업의 주요 단계와 목표를 시간 순서대로 제시합니다.

  • 브랜딩: 브랜드 전략과 마케팅 계획을 설명합니다.

  • 예상 수익: 예상되는 수익과 그 근거를 제시합니다.

재능 있는 창업가 vs 사업을 만들어 낼 팀​

창업을 하기 위해 만드는 비즈니스 모델과 사업계획서는 준비 과정에 불과합니다.

실제로 사업을 성공적으로 수행하기 위해서 개발과 업무 모두 풀 스택으로 모든 것을 다할 수 창업가가 1인 기업으로 어디까지 사업 확장이 가능할까요?

제품이나 서비스 개발, 마케팅, 고객 지원 등 다양한 역할을 최대한 간소화 해서 어느정도 수행할 수 있지만, 아직 수입 모델이 없고, 사업이 성장함에 따라 일이 양이 많아지게 되면 분명 한계에 부딪히게 되는 시점이 옵니다.

그래서 사업 초기라면 당장은 괜찮을 수 있지만 최소 기능 제품(Minimum viable product: MVP) 이후 이러한 한계를 극복하기 위해서는 팀을 구성하는 것이 필요합니다. 투자자들 사이에서는 "팀원이 없다면, 아무리 훌륭한 계획도 한 편의 소설에 불과할 수 있습니다." 라고 합니다.

IT 제품이나 서비스는 특성상 기업(Business)을 대상으로 하는 B2B와 소비자(Consumer)를 대상으로 한 B2C를 대상으로 하게 되는데 창업을 하면 고객에서 보여줄 수 있는 최소 기능 제품 개발 이후 시점에 고객에게 어필 할 수 있는 사업자를 설립하고 최소한의 브랜딩 작업을 한 다음 하나의 선택을 해야 합니다.

B2C를 대상으로 제품을 만들었다면 스타트 업 관련 대회에 참여하거나 투자를 받아야 하는 것을 적극적으로 고려를 해야합니다. 이때부터 창업투자회사의 모태펀드의 조합, 출자방식을 이해하고 투자자들을 대상으로 IR (Investor Relations) 활동을 해야하거나 이것이 가능한 팀 원을 반드시 영입을 해야합니다.

B2B를 하게 되면 고객이 관심을 가질만한 제품이나 서비스를 탄력적인 가격으로 고객과 대화를 하기 위해 학연, 지연, 혈연을 포함하여 주위의 모든 네트워킹을 활용하여 영업을 해야하거나 제품을 이해하고 고객과의 원활한 소통이 가능한 팀 원을 반드시 영입을 해야합니다.

저의 경우 HandStack을 최소 기능 제품 수준으로 개발하고 난 이후 이 시점에서 주변 지인들에게 데모로 보여주며, 향후 로드 맵을 구상을 했었는데 이때 얻은 결론은 사업 아이템의 계획과 방향성을 명확히 하는 데 많은 도움을 얻었습니다.

이번 글에서 요약​

직장을 다니다가 IT 기술 창업에 대한 저의 경험과 생각을 공유해 보았습니다. 비즈니스 모델과 사업계획서는 준비 과정에 불과합니다. 실제로 사업을 성공적으로 수행하기 위해서는 현실적으로 이를 실행할 수 있는 팀이 필요합니다.

그래서 IT 기술 창업을 준비 중이시라면 사업자를 내고 시작하는 것이 아니라 지금 다니고 있는 직장에서 회사와 학연, 지연, 혈연을 포함하여 주위의 모든 네트워킹을 활용하여 주변 지인들과 윈윈할 수 있는 방안으로 진행을 하고, 어느정도 수익 모델이 확보가 되었을 때 사업자를 내시는 것을 권장합니다.

다음 글에서는 구체적인 창업 전략에 대해 이야기를 다루겠습니다. 감사합니다.

https://github.com/handstack77/handstack

2
0
조준철

조준철

개발자는 코드로 말합니다

저는 개발자에게 중요한 능력이 코드, 협업, 전달 세 가지에 있다고 생각합니다. 어떤 우선순위를 정하든, 개발자는 항상 코드에 많은 가치를 두어야 한다는 점은 변하지 않습니다.

코드는 단순한 도구를 넘어섭니다.

개발자들의 사고방식과 작업 방식을 반영하는 중요한 요소이기 때문인데 다음과 같은 이유들로 인해 개발자들은 코드로 말하는 것을 선호합니다.

  • 명확성과 정확성: 자연어는 모호할 수 있지만, 코드는 명확한 규칙과 구조를 가지고 있어 오해의 여지가 없습니다. 개발자는 코드를 통해 자신의 의도를 정확하게 전달할 수 있습니다.

  • 효율성: 복잡한 개념이나 로직을 코드로 표현하면, 이를 이해하는 사람들은 빠르게 그 내용을 파악할 수 있습니다. 이는 개발자들 뿐만 아니라 특정 도메인 전문가 간의 협업을 원활하게 하고, 문제 해결 속도를 높입니다.

  • 재사용성과 유지보수성: 잘 작성된 코드는 수정하기 용이하기 때문에 다른 프로젝트나 업무에서도 재사용될 수 있으며, 개발자들이 효율적으로 작업할 수 있도록 도와줍니다.

  • 자동화와 도구 활용: 예를 들어, 코드 가이드 준수, 번들링, 테스트 등등 개발 업무에 도움을 주는 도구와 함께 사용하면 코드의 품질을 높일 수 있습니다. 이는 개발자들이 더 나은 코드를 작성하고, 오류를 줄이는 데 도움을 줍니다.

  • 글로벌 커뮤니케이션: 개발자들은 서로 다른 언어를 사용하더라도, 코드를 통해 의사소통할 수 있는 전 세계적으로 통용되는 언어입니다. 이는 다양한 배경을 가진 개발자들이 함께 일할 수 있도록 합니다.

  • 문제 해결 능력 향상: 코드를 작성하는 과정은 문제를 분석해서 구조화하고, 단계별로 해결하는 과정입니다. 개발자들은 코드를 통해 문제 해결 능력을 향상시키고, 더 나은 솔루션을 찾습니다.

개발자들은 코드를 통해 새로운 아이디어를 구현하고, 독창적인 솔루션을 만들어낼 수 있습니다. 하지만 함께 고객과 일하는 사람들을 위해 코드와 제품을 공유할 때 그 가치는 더욱 의미가 있습니다. 이는 개발자들에게 큰 만족감을 줍니다. 제가 HandStack 프로젝트를 만들고 유지하는 이유입니다.

공유함으로써 얻는 가치는 중요합니다.

프로젝트의 성공 가능성을 높이기 위해 개발자들이 더 나은 협업 환경을 쉽게 조성하고, 동일한 목표로 함께 일하는 것은 매우 중요한 요소입니다. 다음은 그 이유들을 설명한 내용입니다.

  • 협업과 팀워크 향상: 새로운 프로젝트를 시작할 때, 기술적인 부분에 대한 공감대를 먼저 형성하면 팀원들이 서로의 작업을 이해하고, 더 잘 협력할 수 있습니다. 이는 프로젝트의 진행 속도를 높이고, 더 나은 결과물을 만들어내는 데 도움을 줍니다. 팀원들은 각자의 강점을 발휘하여 문제를 해결하고, 더 나은 솔루션을 찾을 수 있습니다.

  • 코드 품질 향상: 표준화된 소스코드 가이드라인은 다른 개발자들이 작성한 코드를 참조하고 리뷰하거나 코드의 품질을 일관되게 만들며, 버그를 줄이는 데 도움을 줍니다.

  • 지식 공유와 학습: 지식 공유는 팀 전체의 역량을 높이는 데 중요한 역할을 합니다. 새로운 기술이나 방법론을 배우고, 이를 실제 프로젝트에 적용할 수 있습니다.

  • 유지보수와 확장성: 여러 개발자가 코드를 이해하고 수정할 수 있기 때문에, 특정 개발자에게 의존하지 않고도 프로젝트를 지속적으로 발전시킬 수 기회가 열려있습니다. 이는 프로젝트의 안정성과 유지보수와 확장성이 향상됩니다.

  • 투명성과 신뢰성: 프로젝트의 투명성이 높아집니다. 팀원들은 프로젝트의 진행 상황을 명확하게 파악할 수 있고, 이는 신뢰성을 높이는 데 도움을 줍니다. 투명한 코드는 팀원들 간의 신뢰를 구축하고, 더 나은 협업 환경을 조성합니다.

  • 문제 해결 속도 향상: 문제를 빠르게 해결할 수 있습니다. 여러 개발자가 동시에 문제를 분석하고 해결책을 제시할 수 있기 때문에, 문제 해결 속도가 빨라집니다. 이는 프로젝트의 진행을 원활하게 하고, 일정 준수를 가능하게 합니다.

  • 창의성과 혁신 촉진: 다양한 아이디어와 관점이 반영될 수 있습니다. 팀원들은 서로의 아이디어를 바탕으로 새로운 접근 방식을 시도하고, 창의성과 혁신을 촉진하며 더 나은 결과물을 만들어낼 수 있습니다.

의도와 내용을 전달하는 방법을 알아야 합니다.

협업을 원활하게 하고, 코드의 품질을 높이는 데 중요한 것은 자신만의 루틴을 만들고 공유하는 겁니다. 다음과 같이 개발자들은 코드의 의도와 내용을 효과적으로 전달할 수 있습니다.

  • 주석 작성 최소화: 주석을 통해 코드의 목적, 동작 방식, 사용된 알고리즘 등을 설명할 수 있습니다. 개인적으로는 주석은 선호하지 않습니다. 주석보다 다른 개발자들이 코드를 이해하는 데 간결하고 명확하게 작성하는 것과 미사용되는 코드를 삭제하는 것이 중요합니다.

  • 명확한 변수 및 함수 이름 사용: 변수와 함수의 이름을 약어를 사용하지 않고 명확하게 짓는 것은 코드의 의도와 내용을 전달하는 데 큰 도움이 됩니다. 의미 있는 이름을 사용하면, 코드의 목적과 동작 방식을 쉽게 이해할 수 있습니다. 예를 들어, calculateTotal이라는 함수 이름은 함수가 총합을 계산하는 역할을 한다는 것을 명확히 전달합니다. 변수와 함수는 하나의 기능을 담당하도록 개발합니다.

  • 코드 구조화: 함수나 클래스를 적절하게 분리하고, 코드 블록을 논리적으로 배치하면, 코드의 가독성이 높아집니다. 이는 다른 개발자들이 코드를 이해하고 유지보수하는 데 도움을 줍니다.

  • 문서화: 코드와 함께 문서를 작성하는 것도 중요한 방법입니다. 문서에는 코드의 전체적인 구조, 주요 기능, 사용 방법 등을 설명할 수 있습니다. 특히, API 문서나 사용자 가이드는 다른 개발자들이 코드를 이해하고 사용하는 데 큰 도움이 됩니다. 특히 MarkDown 문법은 개발자에게 문서화에 들어 가는 많은 시간을 절감 시켜줍니다.

  • 코드 리뷰: 코드 리뷰는 다른 개발자들과 코드를 공유하고 피드백을 받을 수 있는 좋은 방법입니다. 코드 리뷰를 통해 코드의 의도와 내용을 명확하게 전달하고, 개선점을 찾을 수 있습니다. 이는 코드의 품질을 높이고, 개발자들 간의 협업을 촉진하기 위해 정기적인 업무 문화로 만드는 것이 필요합니다.

  • 테스트 코드 작성: 테스트 코드를 통해 코드의 동작 방식을 검증하고, 예상되는 결과를 확인할 수 있습니다. 이는 코드의 안정성과 신뢰성을 높이는 데 중요한 역할을 합니다. 개인적으로 단위 테스트 케이스 보다 기능 테스트를 위해 반복적으로 요청을 재현하고 검증하는 테스트 코드를 만드는 것을 선호합니다.

  • 코드 컨벤션 준수: 일관된 스타일과 포맷을 사용하면, 다른 개발자들이 코드를 이해하고 유지보수하는 데 도움이 됩니다. 코드 컨벤션은 팀 전체의 코딩 스타일을 통일하고, 협업을 원활하게 합니다.

  • 예제 코드 제공: 예제 코드를 제공하면, 코드의 사용 방법과 동작 방식을 쉽게 이해할 수 있습니다. 예제 코드는 많은 문서화 보다, 다른 개발자들이 코드를 활용하는 데 도움을 줍니다. 이는 특히, 라이브러리나 프레임워크를 개발할 때 유용합니다.

코딩 능력은 개발자의 핵심 업무입니다.

개발자의 가치는 설득이 아니라 증명입니다. 이는 바로 결과를 보여줄 수 있는 직업으로, 실질적인 성과를 만들어냅니다. 코드가 바로 개발자가 가장 중요하게 생각해야 할 부분이라고 할 수 있습니다.

협업은 팀원 간의 소통을 통해 더 나은 결과물을 만들어낼 수 있게 도와줍니다. 프로젝트를 진행하면서 다른 개발자와 의견을 나누고, 문제를 함께 해결하는 과정은 필수적입니다. 코드, 협업, 전달의 균형을 맞추는 것이 중요합니다. 그래야만 최상의 결과물을 만들어낼 수 있습니다.

약간 극단적으로 표현하면 코드 스킬은 본인의 주 업무이고 협업, 전달 능력은 다른 사람을 위한 부 업무라고 볼 수 있기 때문에, 개발 성향이 강한 개발자는 코드에 집착하며, 관리 성향이 강한 개발자는 코드보다 협업, 전달에 우선순위를 둡니다.

시간이 지남에 따라 본인의 커리어를 위해 다양한 선택을 해야 할 때, 지금까지 무엇에 가치를 두었고 앞으로 무엇에 더 가치를 둘 것인지 항상 생각하는 것이 좋습니다.

Marp와 OBS Studio를 활용하여 HandStack을 처음 사용하는 개발자들을 대상으로 동영상 자료를 만드는 중입니다. 아쉽게도 개인 사정상 정기적으로 컨텐츠를 올리기 어렵지만 꾸준히 올리도록 하겠습니다.

1
0
조준철

조준철

신입 개발자를 위한 온보딩 업무 팁

어떻게 하면 신입 개발자가 조직에 온보딩을 잘 할 수 있을까? 저의 경험을 바탕으로 한 조언을 3개를 정리 했습니다. 이 사람은 이랬었구나 하며 읽어 주시면 좋을 듯 합니다.

프로젝트를 진행하면 늘 제한된 자원과 상황에 놓이며 최종 기한에 쫓기며 살게 됩니다만, 적당한 스트레스는 업무 효율을 높이는 데 긍정적인 영향을 미칠 수 있습니다. 다양한 연구 결과와 사례도 많이 있습니다.

프로젝트에서 충분한 일정과 자원이 주어지면, 업무를 끊임없이 조정하고 다듬으며 “완벽한” 해결책을 찾기 위한 완벽주의의 함정에 빠지기 쉽습니다.

이를 잘 설명한 것이 파킨슨의 법칙(Parkinson’s Law)입니다. 영국의 시릴 노스코트 파킨슨(Cyril Northcote Parkinson)이 1955년에 제안한 개념으로, 업무를 마치는 데 걸리는 시간은 할당된 마감 시간만큼 늘어난다는 법칙입니다.

예를 들어, 프로젝트 단위 기능 개발이 2주 안에 완료되어야 하면, 그 작업은 2주 동안 계속 늘어질 수 있습니다.

무엇이 중요한가?​

제가 3년 차일 때, 대기업의 Java, Oracle 기반 회계 프로그램을 .NET 2.0, SqlServer로 전환하는 프로젝트에 투입되었습니다. Typed DataSet이라는 ORM 초기 개념의 기술을 활용하여 Winform을 개발하는 프로젝트였는데, 10명 정도가 1년 동안 진행한 제법 큰 프로젝트였습니다.

문제는 제가 Java, Oracle 기술은 어디서 들어본 수준밖에 되지 않았고, 차변 및 대변의 의미를 모를 정도로 회계 업무에 대한 이해가 전혀 없었다는 점이었습니다. 업무와 기술이 부족하면 현실적으로 야근과 철야를 반복할 수밖에 없었습니다. 가진 것은 책임감과 체력이었으니까요. 물론 지금은 배포/운영 장애 상황이 아니면 야근하지 않습니다.

스트레스를 하나도 받지 않고 살 수는 없습니다. 그래서 스트레스를 어떻게 관리하느냐가 중요한데, 저의 경우 해본 적이 없는 새로운 업무에 대해 제 전공과 경력을 활용할 수 있는 상황이라면 다음과 같이 긍정적으로 생각합니다.

  • 레퍼런스가 있는가? 아주 좋아요! 검증된 가이드라인이 있다는 것은 업무에 대한 보고와 설득의 시간을 줄여주며, 완료 시기를 가늠하며 기승전결을 구상할 수 있습니다.

  • 레퍼런스가 없는가? 아주 좋아요! 누구도 해보지 못했던 경험을 나보다 잘 아는 사람이 많아지도록 업무에 대한 보고와 설득할 수 있는 권한이 생겼습니다.

부당하게 받아들일 수 있는 업무를 통해 새로운 기술이나 학습과 성장 기회를 습득할 수 있는 기회가 있는지 확인합니다. 내가 업무를 주도할 수 있는 기회는 흔하지 않습니다. 이는 본인에게 장기적으로 도움이 될 수 있습니다.

내 능력으로 할 수 없는 일은?​

최종 기한은 일에 대한 우선순위와 실용적인 결정을 내리는 것에 대해 나를 위한 것인지, 조직을 위한 것인지, 고객을 위한 것인지 선택하도록 강제하는 효과가 있기 때문에 어렵고 힘이 듭니다. 하지만 반대로 일의 진행을 위한 주변의 반론을 줄이며 마일스톤을 찍을 수 있는 명분을 만들어주는 강력한 힘이 있습니다.

결자해지(結者解之) "맺은 자가 그것을 풀고, 일을 시작한 자가 마땅히 끝까지 책임져야 한다"는 의미를 마음에 품는 편인데, 10명 중 9명은 그것을 해내기 어렵고, 이것이 나의 강점으로 생각하기 때문입니다. 예전엔 이런 마음이 좀 먹혔던 것 같은데, 지금은 좀 달라진 것 같네요.

그래서 고객의 요청을 정리해서 팀원들에게 보고/설득/전달할 때와 직접 요청을 받아 기능의 추가/개선을 하기 위해 개발 일을 하기 전에 한 번 더 고민해봅니다.

  • 누구에게 꼭 필요한 기능인가?

  • 개발/납기 일정을 스스로 가늠할 수 있는가?

  • 협업 또는 위임이 나을 수 있는가?

  • 더 나은 다른 방안이나 솔루션은 없는가?

  • 결과로 인한 향후 추가 업무의 가능성은?

여건이 되지 않아 일을 마무리 짓기 어렵다면 위의 내용과 함께 보고/공유에 내가 아니더라도 이 작업을 완료하기 위해 필요한 내용을 추가해야 합니다. 예를 들면 다음과 같습니다.

  • 마무리에 필요한 지원 또는 조건 항목을 정리

  • 가능한 해결책을 명확하게 정리

부끄럽게도 제가 신입 개발자 때에는 업무를 뭉개거나, 모르는 체하거나, 파고들 생각을 못한다는 예기를 자주 들었습니다.

최종 기한은 3개로 나누는 게 좋습니다.​

IT 프로젝트에서 흔하게 언급되는 단어로 마감일, 마지노선, 데드라인이 있는데, 각 단어의 유래를 찾아보면 사람이 하는 일들은 어디든 비슷비슷하다는 것을 알게 됩니다.

세 가지 용어 모두 어떤 작업이나 과제를 완료해야 하는 마지막 시점을 의미합니다. "최종 기한"이라고 표현할 수 있습니다. 일정에 대한 얘기는 생각보다 입장이나 역할에 따라 오해의 여지가 많아서 3개 정도로 구분해서 소통하는 게 좋습니다.

프로젝트를 하다 보면 흔히 하는 말들 중에 오해를 부르는 말이 있습니다.

  • XXX 이거 언제까지 완료할 수 있나요?

  • XXX 이건 언제까지 가능합니다.

두리뭉실한 이해당사자들 간의 프로젝트 일정에 대한 명확한 커뮤니케이션을 위해 다음과 같이 나누어 할 수 있습니다. 이렇게 구체적인 업무와 일정을 명시하면 오해를 줄이고, 각 업무 단계별로 필요한 업무 단위를 공유할 수 있습니다.

  • 개발 작업은 [날짜]까지 완료될 예정입니다.

  • 품질 검증 및 문서화 작업은 [날짜]까지 완료될 예정입니다.

  • 운영 적용은 [날짜]까지 완료될 예정입니다.

대부분의 경우 역할이 다른 이해당사자들은 서로의 업무가 어떻게 진행되는 지 잘 모르고, 입장이 다르기 때문에 개발을 하기 전과 하고 난 후에 일어날 일의 양에 대한 예측을 하고 공유하는 것이 좋습니다.

현재 HandStack 프로젝트를 기반으로 레퍼런스를 만들어 가는 중입니다. 이에 대한 개발 경험을 공유하기 위해 자료를 수집하고 정리 중입니다. 그래서 개발자들에게 효율적으로 지식을 공유하기 위해 동영상 강의와 문서화를 연계하는 방안을 고려하고 있습니다. 이를 위해 Marp와 OBS Studio의 사용법을 학습 중인데, 조만간 HandStack을 처음 사용하는 개발자들을 대상으로 자료를 공유하겠습니다.

4
0
조준철

조준철

IT 프로젝트 패러다임의 변화

은 탄환은 없다. (No Silver Bullet)라는 표현을 아시나요?

이 표현은 소프트웨어 엔지니어링 분야에서 널리 사용되며, 1986년에 튜링상 수상자 프레드 브룩스가 쓴 논문 "No Silver Bullet Essence and Accident in Software Engineering"에서 처음 언급되었습니다.

이는 복잡한 문제를 한 번에 해결할 수 있는 완벽한 해결책(즉, 은 탄환)이 없다는 개념을 나타내는데, 해결해야 할 문제를 두고 자신이 잘 아는 솔루션이나 기술에 대해 은 탄환이라는 고정관념을 버리고 다양한 시각으로 문제에 접근해야 함을 의미합니다.

10년 주기 IT 프로젝트 패러다임의 변화

소프트웨어 공학 관점에서 1980년대 이후 10년 주기로 IT 프로젝트 패러다임의 변화는 다음과 같습니다

  • 1980년대: 제조업 중심의 전사적 품질 관리와 활동 기반 원가 관리에 초점을 맞추었습니다. 업무 프로세스의 지속적인 점진적 향상을 유도하면서, 업무를 담당하는 개인에 의한 투명한 성과 관리를 겨냥했습니다.

  • 1990년대: 비즈니스 프로세스 관리(BPM)의 도입으로 IT를 통해 완전히 업무를 자동화하거나 지원하는 것을 목표로 비용 효율을 추구했습니다.

  • 2000년대: 씬 클라이언트와 클라우드 컴퓨팅의 등장과 함께 IT 패러다임이 크게 변화했습니다. 이 시기에는 PC 중심의 패러다임이 점차 모바일과 클라우드 기반으로 이동했습니다.

  • 2010년대: 스마트폰의 보급으로 인해 PC 중심에서 모바일 중심의 새로운 비즈니스 기회가 창출되었고, ICT 기업들은 컴퓨팅 부문의 혁신을 주도하였습니다.

  • 2020년대: 코로나19 이후 하이브리드 및 멀티 클라우드 기반의 ChatGPT와 같은 LLM 기술의 발전과 보급으로 인해 디지털 전환 시대를 만들어 가는 중입니다.

IT 프로젝트 패러다임의 변화는 기술의 발전, 시장의 변화, 그리고 사용자의 요구에 따라 계속 진화하고 있습니다.

2030년대 IT 프로젝트 패러다임은 어떻게 다가올까요?

개인적으로 프로젝트의 본질적인 목적은 "돈을 벌기 위해서"라고 생각합니다. 그래서 부수적으로 “비효율적인 업무를 자동화” 또는 "개발 또는 운영 업무 비용을 절감"하기 위해 프로젝트가 만들어지고 유지된다고 보는 편입니다.

이러한 관점에서 최근 유행하고 있는 다양한 AI 기술과 로우 코드 기반의 솔루션들이 IT 업계에 얼마나 영향을 주고 있는가를 생각해보면 "도구"로서 개인의 IT 업무에 대한 도움이 되어 가는 것은 분명한데, 이것을 공식적으로 수치화해 보려고 하니 조금 까다롭습니다. 수치화해야 객관화를 할 수 있고, 사업성을 따져봐서 사업계획서나 제안서를 만들 수 있기 때문입니다.

IT 프로젝트 성공을 위한 주요 요소들을 살펴보면 다음과 같습니다.

  1. 인건비: 개발자, 디자이너, 프로젝트 매니저 등 다양한 전문가들의 인건비가 포함됩니다. 특히, 프로젝트의 복잡성과 요구되는 기술 수준과 일정에 따라 인건비가 크게 달라질 수 있습니다.

  2. 기술 스택: 사용되는 기술 스택에 따라 비용이 달라집니다. 예를 들어, 오픈 소스 기술을 사용하면 비용을 절감할 수 있지만, 독점 기술이나 최신 기술을 사용하면 라이센스 비용이나 전문 지식의 필요성으로 인해 비용이 증가할 수 있습니다.

  3. 프로젝트 관리: 프로젝트의 계획, 자원 할당, 위험 관리 등을 포함한 프로젝트 관리 비용도 중요한 부분입니다. 특히 IT 프로젝트의 경우 복잡성을 낮추고 성공률을 높이기 위해 업무를 작은 단위로 잘게 나누어 예측할 수 있는 일정으로 관리하는 전략이 필요합니다.

  4. 품질 보증(QA): 소프트웨어의 신뢰성과 안정성을 보장하기 위한 테스트와 버그 수정 비용이 포함됩니다. 이는 수동 테스트, 자동 테스트 등 다양한 방법론에 따라 달라질 수 있습니다.

  5. 인프라 비용: 하드웨어, 네트워킹, 호스팅 비용 등이 포함됩니다. 특히, 고가용성이나 높은 계산 자원이 필요한 프로젝트의 경우 인프라 비용이 커질 수 있습니다.

  6. 기술 부채: 최적이 아닌 결정을 내린 결과로 발생하는 장기적인 비용입니다. 이는 코드 리팩토링, 팀 교육, 효율적인 개발 방법론 사용 등을 통해 완화할 수 있습니다.

이 외에도 프로젝트의 범위와 복잡성, 개발 방법론, 지리적 위치, 아웃소싱 모델 등 다양한 요인들이 프로젝트의 성공에 영향을 미칩니다. 이러한 배경을 염두에 두고 앞으로의 IT 프로젝트 패러다임 변화의 예상을 해보면 다음과 같습니다.


전문 지식에 대한 비용이 크게 낮아지고 있습니다.

IT 기술들은 2010년대 이후 상향 평준화되어 가는 중이며, ChatGPT와 같은 LLM 기술의 발전과 보급으로 인해 전문 지식에 대한 접근성이 크게 향상되었습니다. 이는 IT 프로젝트를 수행하는 데 필요한 지식과 기술을 습득하는 비용을 크게 낮추었고 개발자들이 새로운 기술을 빠르게 배우고 적용할 수 있게 하여 IT 프로젝트의 효율성과 효과성을 높이는 데 기여하였습니다.

우리나라의 제조업 분야뿐만 아니라 IT, 영화, 음악, 예술, 학술 분야에서도 마찬가지로 저비용으로 다품종 소량생산이 가능한 시대가 오고 있음을 보여주고 있습니다.

일자리에서 일거리의 시대로 이동하고 있습니다.

디지털화와 자동화의 확산으로 인해 IT 업계는 전통적인 '일자리’에서 프로젝트 기반의 '일거리’로 변화하고 있습니다. 이는 개발자들이 특정 회사에 속하는 대신 다양한 프로젝트를 수행하며 경력을 쌓는 방식을 의미합니다. 이러한 변화는 IT 프로젝트의 유연성을 높이고, 개발자들이 다양한 경험을 쌓고 기술을 활용할 기회를 제공합니다.

이러한 변화의 가장 큰 이유는 프로젝트 개발 및 운영 비용은 매우 비싼 편이기 때문입니다. 기본적으로 IT 프로젝트의 개발과 운영은 큰 비용이 필요합니다. 이는 개발자의 시간, 하드웨어와 소프트웨어 자원, 테스트 및 유지보수 비용 등 다양한 요소를 포함합니다. 따라서, IT 프로젝트의 성공은 이러한 비용을 효과적으로 관리하고 최소화하는 데 크게 의존합니다.

특정 기술에 종속적으로 되느냐 아니냐가 중요한 것이 아닌 IT 프로젝트 성공을 위한 주요 요소들에서 필연적으로 발생하는 문제들을 해결하는 경험을 확보해야 합니다.

도구는 도구일 뿐 본질은 희소하며 가치가 필요합니다.

IT 프로젝트에서 사용하는 도구와 기술은 중요하지만, 이들은 결국 도구일 뿐입니다. 프로젝트의 성공은 이러한 도구를 효과적으로 사용하는 능력, 그리고 복잡한 문제를 해결하는 데 필요한 창의성과 전략적 사고 등의 '본질’에 크게 의존합니다. 이러한 본질은 희소하며 가치가 있으며, 이를 키우고 발전시키는 것이 IT 프로젝트의 성공을 위해 중요합니다.

의사결정자 입장에서 중요한 것은 ROI (Return on Investment)입니다. 정리하면 다음과 같습니다.

  • IT 기술들은 2010년대 이후 상향 평준화되었습니다.

  • 전문 지식에 대한 비용이 크게 낮아지고 있습니다.

  • 일자리에서 일거리의 시대로 이동하고 있습니다.

  • IT 분야에 저비용으로 다품종소량생산이 가능한 시대가 오고 있습니다.

  • 향후 IT 프로젝트 패러다임은 비용 최적화에 중점을 두고 있습니다.

  • 기업 고유의 IT 프로젝트 성공을 위한 각 주요 요소에 대해 개선을 고민하는 경험이 필요합니다.

결국 개인적인 판단일 뿐이에요. 위에 언급한 내용 외에도 분명 IT 프로젝트의 성공과 실패는 다양한 요인에 의해 좌우됩니다. 각 프로젝트는 고유한 문제와 목표를 가지고 있으며, 이를 해결하고 달성하는 방법은 프로젝트의 특성, 팀의 역량, 사용할 수 있는 자원 등에 따라 달라집니다. IT 프로젝트의 성공은 개인적인 판단과 수행사의 경험에 크게 의존합니다.

10
0
조준철

조준철

고객 사용자를 위한 IT 프로젝트의 화면/기능에 대한 도움말은 어떻게 만들고 계신가요?

IT 프로젝트에서 문서화의 품질은 이해당사자 간의 합의, 즉 프로젝트 관련자들이 문서화의 필요성과 중요성에 대해 동일한 이해를 하고 있는지가 중요합니다.

문서화는 시간과 비용이 많이 소요되는 작업이기 때문인데, 이들이 문서화의 목표와 방향에 대해 합의하면, 문서화의 품질과 정보 공유의 만족도가 좋아질 가능성이 높아집니다.

작성하게 되는 문서 분류는 크게 세 가지 주요 그룹을 대상으로 구성되어 있습니다.

  • 첫 번째 그룹은 고객 사용자들로, 제품이나 서비스에 대한 이해를 돕고, 고객의 요구사항을 충족시키는 데 초점을 맞추고 있습니다. 이러한 문서는 사용자 설명서, FAQ, 제품 사양서 등을 포함할 수 있습니다.

  • 두 번째 그룹은 운영 업무를 담당하는 사람들로, S/W, H/W, N/W 아키텍처, 내부 프로세스, 시스템 구조, 환경설정 문서화 등에 대한 정보를 제공하는 데 중점을 두고 있습니다. 이러한 문서는 운영 업무에 필요한 기술 사양서, 시스템 아키텍처, 프로젝트 관리 문서 등을 포함할 수 있습니다.

  • 세 번째 그룹은 개발 업무를 담당하는 사람들로, 이들에게 제공되는 문서는 주로 소프트웨어 개발, 시스템 아키텍처, 소스코드, 데이터 정보, 배포 관리 등에 대한 정보를 제공하는 데 중점을 두고 있습니다. 이러한 문서는 개발 가이드라인, 코드 문서화, 시스템 아키텍처 문서 등을 포함할 수 있습니다.

제가 주로 풀 스택으로 웹 개발을 하다 보니 웹 분야에 중점을 둔 내용이긴 합니다만, 이 중에서 개발자의 관점으로 첫 번째 그룹인 고객 사용자들을 위한 도움말을 어떻게 저비용으로 고효율을 만들고 유지할 수 있을까? 생각해 보았는데, 그 이유는 고객 사용자들과 직접적인 합의가 어렵기 때문입니다.

대부분은 IT 프로젝트의 문서화에 대한 지침이 없으므로, 먼저 IT 프로젝트에서 특정 화면이나 기능에 대한 도움말 문서를 작성해야 할 때 따라 할 수 있는 주어진 상황에 따라 적용할 수 있는 간단한 기준을 만들어봤습니다.

  • 읽는 대상 요구 파악하기: 누가 이 문서를 사용하게 될지 파악하고, 가능하다면 당사자의 요구를 확인하고 그것에 맞게 문서를 조정하는 것이 지름길입니다.

  • 튜토리얼 또는 레퍼런스를 작성하기: 사용자가 기능을 더 잘 이해하거나 사용하는 데 도움이 될 수 있는 추가 정보와 함께 화면/기능에 대한 사용 방법을 명확하게 설명하는 상세한 단계별 튜토리얼 또는 참조 가이드를 만듭니다.

  • 단순하게 만들기: 대부분은 문서가 길어지면 안 봅니다. 의도적으로 명확한 고객이 이해할 수 있는 전문 용어를 사용하세요. 필요한 경우에만 자세한 설명을 제공하세요.

  • 검색할 수 있게 만들기: 검색하기 쉬운 방식으로 문서를 정리하세요. 기능과 관련된 키워드를 사용하고 관련 주제나 기능에 대한 링크를 제공하세요. 사용자가 필요한 정보를 빠르게 찾을 방법이 필요합니다.

  • 최신 상태로 유지하기: 화면/기능이 추가 되거나 개선함에 따라 문서도 반영되어야 합니다.

문서의 품질은 사용자가 기능을 인식하고 사용하는 방식에 도움을 주기 때문에 시간을 들여 일관성 있고 명확하며 사용자 친화적인 도움말 가이드를 작성하는 것이 좋습니다. 약간의 노력이 필요할 수도 있지만 그만한 가치가 있습니다.

제가 고객 사용자를 위해 작성해 본 정보 형식은 워드나 파워포인트 파일을 PDF로 제공하는 문서 외에 고객 만족도가 좋았던 기능들은 다음과 같습니다.

  • HTML/Markdown 에디터로 만든 내용을 링크

  • 주요 입력 항목에 움직이는 애니메이션 placeholder 제공

  • 화면 내 주요 항목에 툴팁 제공

  • 화면 내 하드 코딩된 도움 문장을 보여주거나 숨기기

  • 화면 내 단계별로 동작하는 가이드 팝업

이 기능들을 위해 사용하는 오픈소스는 다음과 같습니다.

다른 웹, CLI/GUI 응용 프로그램, 기타 IT 프로젝트에서 고객 사용자를 위한 IT 프로젝트의 화면/기능에 대한 도움말은 어떻게 만들고 계시는지 궁금하네요.

2
0
조준철

조준철

오류투성이지만 코드 공유 프로젝트 Qrame을 소개합니다

지난 글을 올린지 한달이 되었네요. HandStack 개발 프레임워크를 작년 12월에 Github에 공개한 후 지속적으로 업데이트 하면서 좀 더 접근성이 좋게 만들 필요성을 느껴서 이런게 있으면 좋겠다~ 싶은 아이디어를 오픈 가능한 수준으로 만들기 위해 열심히 만드는 중입니다.

사이드 프로젝트로 진행하다보니 문서화도 안되고, 정리도 안되고, 버그나 예기치 못한 이슈에 대한 대응도 늦지만 중요한 건 하나하나 꾸준히 진행되고 있습니다.

HandStack 프로젝트는 한마디로 클라우드 네이티브 앱 개발 및 관리 SDK 입니다. 특화된 영역의 개발자를 대상으로 하다보니 초기 설정에서 부터 활용하기 까지 접근성이 높지만 이것을 기반으로 그룹웨어, 쇼핑몰 솔루션 개발과 회사 SI 프로젝트에 적용중이고, 지인 개발 회사에서도 도입하고 있는 오픈소스입니다.

그래서 HandStack 을 셀프 호스트로 세팅하지 않고 웹 브라우저로 바로 개발 경험 해 볼수 있는 방안을 고민하다가 HandStack SaaS 서비스 플랫폼이라는 아이디어를 오류투성이지만 코드 공유 프로젝트로 소개합니다.

  • HandStack === 클라우드 네이티브 앱 개발 및 관리 SDK

  • Qrame === HandStack 으로 개발된 SaaS 서비스 플랫폼

Qrame 서비스의 목표는 원래 HandStack 으로 할 수 있는 것을 UI 도구화 하는 것입니다. 여기에서 만들어진 코드는 셀프 호스트에서도 동작합니다. Qrame 서비스의 핵심 가치는 다음과 같습니다.

  • 코드 공유하기

  • 코드 검색하기

  • 코드 연계하기

  • 코드 협업하기

  • 코드 배포하기

이 가치를 기준으로 HandStack 을 이용하여 지속적인 기능 개선을 진행하고 있습니다. 제가 예전에 만든 게시판 예제는 다음에서 확인 할 수 있습니다. 게시판 소스코드에 대한 설명은 여기를 참조하세요.

https://qrame.kr 에 방문하시면 회원가입 없이 이메일로 시작 페이지를 발송하며, 구글 메일로 로그인 할 경우 바로 시작 페이지로 이동하게 됩니다. 처음 로그인하면 이름, 직급, 회사명과 같은 부가정보는 협업할 때 공유되므로 적절하게 입력하시면 됩니다.


한 달간의 여정 (2024-05-22 ~ 2024-06-22)

  • LoadModuleConfig 검증 추가

  • 클라이언트 모듈 설정 지원 추가

  • dark 모드 라이브러리 추가

  • 버그 수정 및 기능 개선

  • HTML 요소의 기본 type을 text로 고정

  • BearerToken 정보가 훼손되거나 확인 할 수 없을 때 문구 추가

  • 템플릿 내용 수정

  • 레이블 기본 마진값 변경

  • 버그 수정 및 기본 스크립트 변경

  • notifier.css 기본 추가

  • notifier 리소스 변경

  • 리소스 로드 기능 개선

  • Http 프록시 헤더 전달 및 로깅 기능 추가

  • Node.js 기반 checkip 서버 추가

  • ip 주소 조회 기능 개선

  • clientip 조회 Uri 개선

  • Referer 처리 기능 개선

  • 불 필요한 코드 삭제

  • 고유 ID 생성 확인 기능 추가

  • 터미널 명령 실행후 성공 종료 코드를 설정하도록 개선

  • base64 url 인코드, 디코드 기능 추가

  • moment 한국어 로케일 추가

  • moment.js 번들 추가

  • 빌드 설정 변경

  • 경로 오류 수정

  • 웹 폰트 적용

  • css bundle 대응 기본 경로 개선

  • 한줄문구 변경

  • bash 스크립트 캐리지 리턴 변경

  • handstack CLI 컴파일시 게시 디렉토리로 복사 추가

  • Forbes 앱 ID 부여 버그 수정

  • 참조 라이브러리 버전 업데이트 대응 문법 수정

  • 처음 실행시 checkup 실행 경로 로그 추가

  • dispose 앱 정리 버그 수정

  • task.bat, task.sh 업무 스크립트 개선

  • 태넌트 앱 > Forbes 앱 명칭 변경

  • 참조 라이브러리 버전 업데이트

  • 거래 로그 기록 개선

  • 로그 파일 기록 기능 및 UI 컨트롤 기능 개선

  • 공통 기능 개선 및 버그 수정

  • 캐시, 로그 경로 개선

  • 공통 기능 개선 및 버그 수정

  • 파일 동기화 대기시간 추가 및 버그 수정

  • AUIGrid 컨트롤 기능 추가

  • AI 메시지 영역 height을 100% 처리

1
0
조준철

조준철

시맨틱 커널 기반 prompter 모듈 추가

최근 프롬프트 엔지니어링에 대한 관심이 생겨 마이크로소프트의 Semantic Kernel(시맨틱 커널)을 사용해서 HandStack 프로그램에서 생산성에 도움이 될 만한 다양한 문법을 테스트 해보고 있었습니다.

이를 통해 HandStack 프로그램에 적용할 수 있는 방법을 고민해보았고, 이에 대한 경험을 공유하는 게 의미가 있을 것 같아 이 글을 작성하게 되었습니다. 시맨틱 커널로 닷넷 기반 프로그램에 프롬프트 엔지니어링을 도입하는 방법을 고민하시는 분들에게 도움이 되었으면 합니다.

시맨틱 커널은 LLM 기반의 생성형 AI 기능을 프로그램에 적용하기 위한 C#, Java, Python 언어를 지원하는 프레임워크로, 특정 업무에 대한 프롬프트를 사전에 템플릿화 하여 실행하는 데 사용됩니다. 이를 통해 사용자의 요청에 대한 응답을 생성하거나, 또 다른 프롬프트를 실행하는 데 사용됩니다.

아마 Python, Typescript 등의 언어로 개발된 프로그램에서는 LangChain(랭체인)을 많이 사용하실 거라 생각합니다. 간단하게 시맨틱 커널은 C#, 랭체인은 Python 기반의 프로그램에 사용되는 프롬프트 엔지니어링 프레임워크입니다.

C# 기반의 프로그램에서 시맨틱 커널을 사용하는 방법에 대한 정보는 랭체인에 비해 상대적으로 부족한 편입니다. LLM 분야가 워낙 빠르게 발전하고 있는데다, 시맨틱 커널의 릴리즈가 거의 1주일에 한 번씩 이루어지다보니 구글 검색이나 ChatGPT 에 물어보는 정보는 대부분 호환성이 없는 불 필요한 정보들 뿐입니다.

이해가 되는 부분인 것이 LLM 분야는 춘추삼국시대와 같이 오픈 AI GPT, 메타 라마, 구글 제미나이를 중심으로 혼란스러운 시기에 있으면서 학술적으로도 많은 연구가 이루어지고 있습니다. 핵심 기능 자체가 외부 종속성을 기본적으로 가지고 있는 특징을 가지다보니 시맨틱 커널을 사용하는 방법에 대한 최신 정보가 부족한 것이 당연한 것이라 생각합니다.

LLM 분야는 미국에서 정부, 민간 차원에서 하드웨어, 소프트웨어, 학술적으로 주도하고 있기 때문에, 한국에서는 이에 대응하여 더 많은 정보를 얻을 수 있는 특화된 분야의 연구가 이루어지고 있습니다.

시맨틱 커널 시작하기

시맨틱 커널을 사용하기 위해서는 먼저 공식 문서를 참고하는 것이 가장 좋습니다.

LLM 분야가 빠르게 발전하는 중이어서 영어로만 공식 문서를 제공하고 있으니, 문서를 읽는 것이 부담스러우시다면, DeepL를 설치하여 번역을 참고하시면 됩니다.

공식 문서의 내용은 큰 그림이나 개념을 설명하는 데 중점을 두고 있어, C# 개발 언어에 익숙하지 않더라도 LLM 기능을 프로그램에 적용하기 위한 개념을 학습하는데 도움이 됩니다. (랭체인의 문서를 보는데도 도움이 됩니다.)

하지만 실제로 프로그램에 적용하기 위해서는 공식 문서보다도 Github의 예제 코드를 직접 참고하는 것이 더 도움이 됩니다.

시맨틱 커널의 C# 소스 코드는 거의 매일 업데이트 되고 있으며, 이에 대한 예제 또한 같이 업데이트가 되고 있어서 로컬에 git clone을 통해 소스 코드를 다운로드 받아서 사용하는 것이 좋습니다.

# git clone을 통해 소스 코드를 다운로드 받을 수 있습니다.
git clone microsoft/semantic-kernel

# git pull을 통해 최신 소스 코드를 받아올 수 있습니다.
git pull

# samples 해당 디렉토리로 이동하여 예제 코드를 확인할 수 있습니다.
cd \microsoft.semantic-kernel\dotnet\samples

개인적으로 Visual Studio 2022 통합 개발 도구를 설치해서 SK-dotnet.sln 실행하여 소스 코드를 확인하고, 예제를 확인 하는 것이 가장 편리하다고 생각합니다. 그 이유는 다음과 같습니다.

  • 주요 기능에 대한 단위 테스트가 포함되어 있어서, 소스 코드를 수정하거나, 새로운 기능을 추가할 때 테스트를 통해 검증할 수 있습니다.

  • 공식 문서에는 언급되지 않는 추가적인 내용이 많아서, 소스 코드를 확인하는 것이 더 도움이 됩니다.

  • 공식적으로 Open AI, Azure Open AI를 지원하지만 내부적으로 Google, HuggingFace, MistralAI, Onnx 등의 다양한 API를 사용 할 수 있도록 개발되고 있는 것을 알 수 있습니다.

  • 빠르게 변경되는 소스 코드에 대한 안정적인/실험적인 기능을 확인 할 수 있습니다. 실험적인 기능들은 다음 버전에 사라질 수 있으니 사용에 주의해야 합니다.

시맨틱 커널에 대한 문서는 많이 부족하지만, 소스 코드를 통해 확인하면서 이해하는 것이 가장 빠르게 프로그램에 적용하는 방법이라고 마이크로소프트 시맨틱 커널 개발팀이 말하고 있는듯 합니다.

프롬프트 엔지니어링

시맨틱 커널을 학습 하기 전에는 개인적으로 프롬프트를 작성하여 Copilot 이나 ChatGPT 에게 어떻게 하면 효과적인 질문을 할 수 있을지 고민하고 있었습니다.

그러나 개인(사람)이 아닌 프로그램에서 프롬프트를 작성하고, 더 효과적인 질문을 할 수 있게 하는것은 개인보다 더 상호 보완적인 관계를 가지고 있습니다.

프롬프트 엔지니어링은 사용자의 요청에 대한 응답을 생성하는 데 사용되는 기술로, 크게 다음과 같이 분류할 수 있습니다.

  • 사전 정의 프롬프트 템플릿

  • RAG (Retrieval Augmented Generation) 기반 프롬프트

  • Memory (Storage & Indexing) 기반 프롬프트

시맨틱 커널을 학습 하면서 느낀것은 RAG와 Memory는 의도적으로 안정화 되기 전까지 도입하기 힘들겠다는 것이었습니다. 그 이유는 RAG와 Memory는 LLM AI와 VectorDB 핵심 기능에서 주요 변경 사항이 있거나 새로운 기능을 추가할 때 시맨틱 커널에서 영향을 받을 경우 변경 가능성이 높은 기능들이기 때문입니다.

RAG를 지원하기 위해서는 적어도 로컬 또는 원격에서 오피스 문서, PDF 와 같은 파일들을 읽어와 임베딩을 생성하는 기능이 필요하고, Memory를 지원하기 위해서는 VectorDB 기반의 임베딩된 데이터를 인덱싱, 검색 기능이 필요합니다.

이러한 기능들은 시맨틱 커널에서 지원하는 기능이 아니라 별도의 라이브러리를 사용해야 하기 때문에 시맨틱 커널을 사용할 때 당분간은 프롬프트 템플릿을 활용하는 방법에 집중하는 것이 좋다고 생각합니다.

시맨틱 커널 소스에 RAG, Memory 기능을 사용하는 예제 코드가 있지만, 아직 실험적인 기능이 많기 때문에 안정화 되기 전까지는 사용에 주의해야 합니다.

사전 정의 프롬프트 템플릿

사전 정의 프롬프트 템플릿은 미리 정의한 문장에 사용자의 요청을 더해 응답을 생성하는 데 사용되는 기법으로, 특화된 업무에 따라 사용자의 요청에 대한 응답을 생성하는 데 사용됩니다.

예를 들면 "건강을 위해 칼로리 맞춤 요리 추천"을 위해 다음과 같은 프롬프트 템플릿을 사용할 수 있습니다.

너는 맛있는 음식을 쉽게 만들어 먹을 수 있는 레시피를 개발하는 요리 연구가야.
나는 1,800 칼로리 수준에서 맛있는 음식을 만들어 먹고 싶어.
매일 만들어 먹을 수 있는 5가지 초보 요리사를 위한 요리 레시피를 참고해서 제안해줘.

${UserMessage}

여기 ${UserMessage} 부분에 사용자의 질문을 더해 응답을 생성하는 데 사용됩니다. 예를 들어 사용자가 이렇게 질문을 요청합니다.

  • 나는 30대 남자이고 조금 살쪘어 어떤 요리가 좋을까?

  • 다이어트를 하는중인데, 여성을 위한 칼로리가 적은 음식을 추천해줘

어떠한 질문이든 사용자의 질문을 기반으로 맛있고 건강한 성인 남자 기준 하루 권장량인 1,800 칼로리 이내의 요리 레시피를 제안해 줍니다.

프롬프트 텍스트를 작성하는 기법은 다양하게 있습니다만 기본적으로 원칙을 준수하는 게 필요합니다. LLM 을 데이터베이스라고 생각하고 프롬프트 기법을 SQL 문법이라고 생각하는게 좋습니다.

구체적 지시 > 명확한 단어 > 맥락을 제공 > 응답 구조를 정의 > 일관성 유지

예시로 제공된 “건강을 위해 칼로리 맞춤 요리 추천” 텍스트는 제로샷(Zero Shot) 기법이고, 개인적으로 선호하는 방법은 다음과 같습니다.

  • Few Shot: 기본적이고 핵심적인 내용에 대한 예시를 제공하는 방법

  • 역할 지정: AI 모델에 특정한 역할을 부여하는 방법

  • 마크다운 활용: 텍스트를 구조화하여 질문을 생성하는 방법

  • 단락 구분 기법: 요청, 제약, 입력, 출력 등등 단락을 구분하여 질문을 생성하는 방법

  • 변수 활용: 프롬프트를 변수를 활용하여 동적으로 질문을 생성하는 방법

  • Q&A 기법: AI 모델이 질문에 대한 답변을 유도하여 생성하는 방법

  • 응답 형식 지정: 자연어 응답이 아닌 Json, Xml, Csv, Markdown 등등 특정 형식으로 템플릿 기반 응답을 생성하는 방법

구글 검색으로 각각의 키워드에 대해 알아보시면 다양한 정보를 확인할 수 있을겁니다. 다만 프롬프트에 대한 기법은 정답이 없습니다. 동일한 질문에 대해 GPT-3, GPT-4 모델과 매개변수 (TopP, Temperature, PresencePenalty, FrequencyPenalty) 설정에 따라 다른 결과를 생성할 수 있습니다. 이에 대한 것은 본인의 경험을 통해 효과적인 프롬프트를 작성하는 방법을 찾아보시길 권장합니다.

프롬프트 템플릿은 영어로 작성하는 게 더 좋은 결과를 만들어냅니다. 그 이유는 영어의 기본 흐름인 대화의 5형식을 기반으로 학습 데이터들이 제공되었기도 하지만 한국어만의 맛깔스러운(?) 뉘앙스를 영어로 번역하는 데 한계가 있어 다양한 질문을 번역되는 와중에 요청 의도와는 다른 응답을 생성하는 데 사용될 수 있기 때문입니다.

프롬프트 템플릿은 영어로 작성하고 질의는 한국어로 해도 어느정도 만족스러운 결과를 만들어냅니다. 그러나 한국어로 작성한 프롬프트 템플릿은 한국어로 질의하는 경우에만 사용하는 것이 좋습니다.

예제로 만든 프롬프트 템플릿

HandStack 프로그램에서 생산성에 도움이 될 만한 예제로 만든 프롬프트 템플릿은 gpt-3.5-turbo 를 기반으로 작성되었습니다. 프롬프트 템플릿 작성 참고용으로 봐주시면 좋을듯합니다. 여기에 있는 템플릿은 단일 대화 기능입니다.

프롬프트 엔지니어링에서 좀 더 실용적인 기능을 구현하기 위해서는 프롬프트를 실행하기 전에 도메인 데이터를 활용하여 동적으로 Few Shot을 구성하는 것과 이전 대화의 이력을 유지하는 것이 중요합니다. 이에 대한 예제는 다음에 작성하도록 하겠습니다.

prompter 모듈 시작하기

appsettings.json LoadModules 설정에 prompter 추가

dbclient, function 과 같이 이번에 추가된 prompter 모듈은 시맨틱 커널 기반으로 Open AI와 같은 LLM AI 연동 기능을 위해 프롬프트 템플릿 문법을 그대로 사용할 수 있도록 설계되었습니다. 이를 통해 다음과 같은 장점을 가집니다.

  • 클라이언트 요청에 전달되는 값은 프롬프트 템플릿내의 값 치환과 매개 변수로 매핑 둘다 가능합니다.

  • Open AI, Azure Open AI 등등 서비스를 지원합니다.

  • FewShow, History 기능을 지원합니다.

  • 프롬프트 템플릿을 동적으로 구성 가능하도록 설계되었습니다.

prompter 모듈을 활성화하기 위해 ack 서버 프로그램이 있는 디렉토리에 있는 appsettings.json 파일을 열고 LoadModules 설정에 prompter 추가합니다.

{
    "AppSettings": {
        ......
        "LoadModules": [
            "wwwroot",
            "transact",
            "dbclient",
            "function",
            "repository",
            "logger",
            "checkup",
            "prompter" <-- ack 서버 프로그램 실행시 로드할 모듈 추가
        ],
        ......
    }
}

prompter module.json LLMSource 설정에 OpenAI ApiKey 추가

prompter 모듈내 Open AI을 API를 사용하기 위해 modules/prompter 디렉토리에 있는 module.json 파일을 열고 LoadModules 설정에 prompter 추가합니다.

{
    "ModuleConfig": {
        ......
        "LLMSource": [
            {
                "ApplicationID": "HDS",
                "ProjectID": "*",
                "DataSourceID": "LLM1",
                "LLMProvider": "OpenAI",
                "ApiKey": "[sk-proj-API...키]", <-- Open AI에서 발급한 API Key 추가
                "ModelID": "gpt-3.5-turbo",
                "IsEncryption": "N",
                "Comment": "OpenAI 프롬프트 API"
            }
        ]
        ......
    }
}

업무 프로그램에 필요한 프롬프트 템플릿에 대한 분류는 다음과 같이 정리했습니다.

  • Classification (CLS): 사용자의 의도를 분류하고 파악하는 역할을 합니다. 질문이나 요청을 적절한 카테고리로 분류하여 적절한 응답을 생성하는 데 도움을 줍니다.

  • Grounding (GRD): 질문의 맥락을 이해하고, 그에 따라 엔터티를 추론하는 역할을 합니다. 이를 통해 대화가 자연스럽고 일관성 있게 이어질 수 있습니다.

  • Generater (GEN): 새로운 계획, 아이디어, 변환 등을 생성하는 역할을 합니다. 사용자의 요청에 따라 창의적인 아이디어를 제시하거나, 특정 문제에 대한 해결책을 제안하는 데 사용됩니다.

  • Coding (COD): 개발 관련 질문에 대한 예제나 소스 코드를 생성하는 역할을 합니다. 사용자가 요청하는 코드를 작성하거나, 특정 코드에 대한 품질을 올리는 데 사용됩니다.

  • Summarize (SMZ): 회의록, 요약, 대화 주제 등을 생성하는 역할을 합니다. 긴 대화나 문서를 요약하여 핵심 내용을 간략하게 전달하는 데 사용됩니다.

  • Writer (WTR): 보고서, 문서 등을 생성하는 역할을 합니다. 사용자의 요청에 따라 특정 주제에 대한 보고서나 문서를 작성하는 데 사용됩니다.

프롬프트 템플릿은 서로 다른 역할을 가지고 있지만, 함께 작동하여 사용자의 다양한 요청에 대응하고, 효과적인 대화를 위해 필요한 기능들을 제공합니다.

prompter 모듈 데모

prompter에 등록된 XXXXXX.xml 파일은 화면 및 모듈에서 사용됩니다. 다음은 화면에서 prompter 모듈을 사용하는 데모입니다. 화면 소스는 다음과 같습니다.

CLS010: 문장 대화의 의도를 파악

1330×936 47.4 KB

CLS020: IT 시스템 장애 등급 수준을 파악

1330×936 48.8 KB

GRD010: 지정된 주제와 관련된 엔티티를 추출

1330×936 99 KB

GEN010: 제로샷 프롬프트 확인

1330×936 49.8 KB

GEN020: 국가 언어 번역기

1330×936 46.4 KB

GEN030: 회의 전 스몰 토크 주제 생성

1330×936 74.2 KB

COD010: 소스 코드 버그 수정 및 개선

1330×936 91 KB

COD020: 소스 코드 주석 추가

1330×936 91.1 KB

COD030: 데이터베이스 SQL 생성

1330×936 78.3 KB

SMZ010: 회의록 요약 정리

1330×936 69.7 KB

WTR010: 당신의 명언 또는 인용구

1330×936 44.2 KB

WTR020: 프롬프트 엔지니어링을 위한 한국어 문장 영어 번역

1330×936 76.1 KB


한 주간의 여정 (2024-05-13 ~ 2024-05-22)

  • 프롬프트 템플릿 추가

  • prompter 모듈 추가

  • 버그 수정 및 기능 개선

  • 공통 기능 개선 및 DataSource에 LLM 서비스 정보 추가

  • 문법 개선

  • 오류 처리 개선

  • 처리 되지 않은 오류를 전역 변수에 기록

  • 거래 응답 결과를 DataSet 으로 변환 기능 추가

  • 소스 코드 정리

  • 변수명 변경

  • 함수 설정 값 타입 변경

  • 테스트 기능 개선

  • CSharp, Javascript 함수 테스트 호출 기능 개선

  • 거래 로그 삭제 주기 개선

  • DummyFile 데이터로 transact 응답을 내려줄 수 있는 기능 추가

  • 종속 패키지 버전 업데이트

2
2
조준철

조준철

개발자에게 필요한 툴민의 논증 모델

개발자는 코드를 작성하거나 문제를 해결할 때 숙고하며 알고리즘을 구상하는 논리적인 사고에 익숙합니다. 그래서 특정 주제를 가지고 사람들 앞에서 발표하거나 회의에서 자신이 주장하는 내용에 유연한 사고를 해야 하는 상황을 어려워하는 경우가 있습니다.

여기에는 여러 가지 원인이 있겠지만 이때, 툴민의 논증 모델을 활용하면 주장을 더 명확하게 표현하고, 그 주장을 지지하는 증거와 논거를 제시하며, 반론을 예상하고 대응할 수 있습니다.

툴민의 논증 모델은 영국의 철학자인 스티븐 툴민이 개발한 논증법으로, 어려운 내용은 제쳐두고 당장 써먹을 만한 실용적인 논증법을 제시합니다.

핵심은 주장하고자 바의 설득력을 높이려면 단순히 근거를 몇 개 제시하기보다는 자신이 제시한 정당한 이유를 반박하는 반론을 본인이 구상하고 그것을 재반박해서 얻게 된 결론이 설득력을 얻게 된다는 겁니다.

개발자의 숙고하며 논리적인 사고에 익숙한 장점을 활용하여 발표나 회의 전에 주제에 대해 미리 생각해 보고, 툴민의 논증 모델을 활용해 보세요. 그러면 주장을 더 명확하게 표현하고, 그 주장을 지지하는 증거와 논거를 제시하며, 반론을 예상하고 대응할 수 있습니다.

툴민의 논증 모델은 다음과 같이 6개의 구성 요소로 이루어져 있습니다.

  • 주장 (Claim): 주장은 논증의 목표로, 증명하려는 주제나 판단입니다.

  • 증거 (Data/Frame/Evidence): 증거는 주장을 지지하는 사실이나 정보입니다.

  • 논거 (Warrant): 논거는 주장과 증거 사이의 논리적 연결고리입니다.

  • 보강 (Backing): 보강은 논거를 지지하는 추가적인 정보나 설명입니다.

  • 조건 (Qualifier): 조건은 주장의 힘을 약화하거나 한정하는 역할을 합니다.

  • 반론 (Rebuttal): 반론은 주장이나 논거에 대한 예외 사항이나 반대 의견을 제시하는 것입니다.

논증 모델은 크게 기본구조 (4) + 보조구조 (2)로 구성합니다. 기본구조는 (주장, 증거, 논거, 보강)으로 이루어져 있고, 보조구조는 (조건, 반론)으로 이루어져 있고, 상황에 따라 필요한 구성 요소를 추가하거나 수정해서 사용하면 됩니다.

논증의 구성 요소에 대한 주요 흐름을 이렇게 구성하면 좋습니다. & (AND) | (OR) 는 각 구성 요소를 구분하기 위한 구분자입니다.

  1. 주장 (Claim)

  2. 근거 - 증거 (Data/Grounds/Evidence)

  3. 왜냐하면 - 논거 (Warrant) & 때문에 - 보강 (Backing)

  4. 그래서 So (So) | 어쩌면 - 조건 (Qualifier) | 예외로 - 반론 (Rebuttal)

  5. 주장 (Claim)

주요 흐름에 대한 예시를 들면 다음과 같습니다. 본인 성향에 따라 필요한 구성 요소를 추가하거나 수정해 보세요.

  1. 나는 우리 반 학생들이 모두 A 학점을 받을 것이라고 믿는다. "주장 (Claim)"

  2. 왜냐하면 우리 반 학생들은 모두 열심히 공부했기 때문이다. "증거 (Data/Grounds/Evidence)"

  3. 우리 반 학생들은 좋은 시험 성적을 거두었으며, 과제물에서도 좋은 평가를 받았다. "논거 (Warrant)" & 시험성적과 과제물 점수가 높은 학생은 학칙에 따라 좋은 점수를 부여하게 되어 있다. "보강 (Backing)"

  4. 그래서 "So (So)" | 어쩌면 대부분의 학생은 "조건 (Qualifier)" | 따라서 시험에서 부정을 저지르거나 수업시간에 불성실한 태도를 보인 경우가 아니라면, "반론 (Rebuttal)"

  5. A 학점을 받게 될 것이다 "주장 (Claim)"

한두 번만 활용해 보면 동료들에게 더 명확하게 주장하고 설득하는 사람으로 인지되어, 향후 예상하지 못한 돌발 상황에서는 좀 더 생각해 보고 다시 예기할 수 있는 상황을 만들 수 있습니다.


한 주간의 여정 (2024-05-06 ~ 2024-05-10)

  • 프로젝트 빌드에 필요한 시간을 줄이는 MSBuild 옵션 추가

  • 종속 패키지 버전 업데이트

  • 변수명 변경

  • Node.js 함수 테스트 기능 개선

  • 스크립트 로더 기능 개선

  • 공통 리소스 BindingAction (Replace, Append, None) 옵션 추가

  • 배치 스크립트 디렉토리명 변경

  • 디자인 개선

  • LoadOptions 중복 방지를 위해 시스템에서 부여하는 키에 '$' 접두어 사용

  • 거래 실행시 접근 권한 정보를 dbclient, function 모듈에 전달하도록 개선

  • JSON 데이터 쿼리 및 변환 라이브러리 jsonata 추가

  • C# 서버리스 함수 개발 테스트 API Controller 추가

  • Node.js 서버리스 함수 개발 테스트 서버 추가

2
0
조준철

조준철

본인의 칼은 본인이 갈아야 한다

살다 보면 가끔 내적인 이유든 외적인 이유던지 간에 가볍게 또는 진지하게 그냥 막막하거나 무엇이 맞는 것인지, 어떻게 시작해야 할지 도저히 모를 때가 있는 슬럼프가 찾아옵니다.

그럴 때 용기와 희망을 주는 의미를 담고 있는 자기관리 명언이나 책들을 보면 머리로는 이해가 되는데 생각보다 내 상황에 도움이 되지 않는 데 그 이유는 대부분 "성공"이라는 목표를 가지고 있기 때문입니다.

성공이라는 목표를 가지고 있으면 그 목표를 달성하지 못했을 때 좌절하게 되고, 그 좌절로 인해 더 막막해지고, 무엇을 해야 할지 모르게 힘든 시기를 겪게 되는데, 이를 극복하고 성장하는 과정을 통해 더 강해지고 성숙해질 수 있습니다.

“본인의 칼은 본인이 갈아야 한다” 라는 말은 지인이 제게 자주 하는 말입니다. 성공의 기반이 되는 것은 자신의 노력과 끈기로 경험을 통해 얻는 것들을 말 합니다만, 여기에는 좀 더 생각 해볼 만한 철학적인 의미를 가지고 있습니다.

내 경험을 쌓기 어려운 시대

예전에는 “젊어서 고생은 사서 한다.” 라는 속담이 있을 정도로 경험을 쌓기 위해 노력하고 경험을 통해 성장하는 과정을 거쳤지만, 현재는 인터넷과 스마트폰, 결정적으로 AI 기술이 발달하면서 정보를 얻기 쉬워졌습니다. 이 말은 이러한 정보를 통해 얻는 지식은 경험을 통해 얻는 지식보다 덜 가치가 있다는 것일까요? 아니요. 그렇지 않습니다. 사실에 근접한 정보는 가치에 우위가 있을 수 없습니다.

문제는 경험을 쌓기 위해 노력하고 성장하는 과정의 기회가 점점 줄어들고 있다는 것입니다. 학습(지식을 습득)을 한다는 것은 누군가 잘 정리해둔 정보를 받아들이는 것이지만, 경험을 통해 성장한다는 것은 그 정보를 받아들이고, 이를 토대로 자신만의 결과와 지혜를 만들어내는 것입니다. 분명히 아는 것과 전달 하는 영역은 다릅니다.

습관적으로 미디어, 책, 강의 등을 통해 정보를 얻는 것만 한다면 그 정보를 토대로 자신만의 지혜를 만들어내는 것은 뇌과학적 으로도 어렵습니다. 사람은 본능적으로 시각 + 청각 적인 자극에서 80% 에 가까운 집중력을 보인다고 합니다. 문제는 새로운 자극을 받아들이기 위해 수많은 정보들은 잊혀집니다. 그래서 본인의 칼을 만들어야 합니다.

성공이 아닌 성장을 목표로 삼는 것

한번 쯤은 내가 성공했을 때의 모습을 상상해보았을 것입니다. 그리고 그 상상을 통해 당신이 어떤 사람이 되고 싶은지, 어떤 모습을 가지고 싶은지 생각해보았을 것입니다. 그리고 그 모습을 향해 나아가기 위해 노력하고 있을 것입니다.

그런데 성공을 하면 그 이후에는 무엇을 할 것인가요? 성공을 위해 칼을 갈고, 닦고, 쓰고, 다시 갈았는데, 성공을 하고 나면 그 칼은 더 이상 갈 필요가 없어집니다. 그리고 그 칼을 버리고 새로운 칼을 만들어야 할 지 모릅니다.

먹고 사는 것은 기초적인 삶을 위해 기본적으로 필요한 것이지만, 그 이상의 삶을 살기 위해서는 좋아 하는 일, 해야 하는 일, 할 수 있는 일을 찾아내고, 그것을 통해 좀 더 편하게 해낼 수 있는 본인의 칼을 갈아야 하는 과정을 자연스럽게 해야 합니다.

나를 만들어가는 것

그런데 제일 어렵고 중요한 것은 칼을 버릴 줄 알아야 하는 것입니다. 칼은 성장을 위한 도구이지 무기가 아닙니다. 그래서 성장에 더 도움이 된다면 더 많은 칼을 만들고 사용할 수 있도록 언제든 본인의 칼을 버릴 수 있어야 합니다.

칼을 바꾸거나 버린다는 것은 어떤 이에겐 자신이 그동안 해온 것들을 부정하는 것 같아 더욱 쉽지 않습니다. 그래서 평생 한 직장에서 근무한 직장인이나 스포츠 선수들이 전성기를 지나 은퇴 이후에는 무엇을 할지 고민하는 것은 당연한 일입니다.

칼을 버린다는 것은 당신이 성공하지 못했다는 것이 아닙니다. 오히려 칼을 무기로 생각한다면 내가 나의 칼로 다칠 수도 있다는 것입니다.

사람들은 나의 칼을 보고 신기해 하거나 부러워 할 수 있어도 그것 만으로 알아주거나 인정하지 않습니다. 오히려 크기에 상관없이 그 사람만이 할 수 있는 결과나 능력 또는 고민하지 않고 믿고 맡길 수 있는 신뢰를 쌓아야 합니다.

증명하거나 설득할 필요 없이 작더라도 하나씩, 하나씩 자신만의 더 나은 내일을 만들기 위해 노력하는 당신은 이미 성공한 사람입니다.


한 주간의 여정 (2024-04-29 ~ 2024-05-03)

  • 환경설정 자동화 기능 개선

  • 배치 스크립트 호출 후 로그 출력을 콘솔, 파일로 출력하는 기능 추가

  • 운영체제에 따라 사전에 정의된 배치 스크립트 업무를 수행 기능 추가

10
1
조준철

조준철

프로그램 설치 스크립트 만들기

최근 HandStack 을 실행하기 위한 필수 프로그램 설치 및 종속 라이브러리를 다운로드 하고 번들링을 구성하는 install 배치 스크립트에 버그가 있다는 피드백을 받고 이번 기회에 버그도 잡을 겸, 다음의 클린 설치 운영체제에서 설치 스크립트 점검하고 개선되었습니다.

  • Windows 10

  • Windows 11

  • Ubuntu 22.04

  • macOS 11 (Big Sur): Intel CPU

  • macOS 14 (Sonoma): Arm CPU

개발 환경과 실행 환경에 필요한 필수 프로그램과 도구를 설치하는 과정은 각 운영 체제의 관리 정책과 버전에 따른 보안 수준에 따라 설치 프로그램을 만들 때 각 운영 체제의 특성과 설치 절차를 이해하는 것을 필요로 합니다.

사실 제공되는 install 설치 스크립트는 설치 프로그램 이라기 보다 매뉴얼 작업에 가까운 설치 과정인데, Windows, macOS, Linux에 따라 인스톨러를 개발하는 것은 시간과 비용 면에서 부담스럽고 좀 더 동일한 설치 경험을 제공해야 향후 유지 보수에 도움이 될 거라는 판단이 들었습니다.

Linux 서버를 다루는 분들은 패키지 매니저를 사용하는 CLI (Command-Line Interface) 명령으로 필요한 프로그램을 설치하는 것이 익숙하실 겁니다. Windows나 macOS 에서는 GUI (Graphical User Interface) 방식의 설치 관리자를 이용한 설치가 편하실 거구요.

그런데 점차 Windows, macOS 에서도 업무에 필요한 대부분의 프로그램을 패키지 매니저를 사용하여 설치 하는 것이 일반화 되고 있습니다.

Windows에서는 winget, macOS에서는 Homebrew, Linux에서는 apt-get 와 같은 CLI 명령으로 자동화된 설치 프로세스를 수행하게 되는데 한번 적응되면 편리하게 사용할 수 있습니다.

제가 Windows 기반에서 HandStack 을 개발하는 데 필요한 개발 및 도구 프로그램을 설치하는 스크립트를 추가로 정리했습니다. 매번 공식 웹 사이트가 가서 프로그램을 받고 설치하고 하는 과정 없이 명령 프롬프트에서 동일한 프로그램을 빠르게 설치합니다. 자세한 내용은 Winget 추천 개발 도구 설치하기 문서를 확인하세요.

개선된 프로그램 설치 스크립트는 빠른 시작에서 확인 가능합니다.


한 주간의 여정 (2024-04-15 ~ 2024-04-19)

  • 의미 없는 alpha, beta 릴리즈 삭제

  • publish, install 설치 스크립트 기능 개선

  • 버그 수정 및 안정성 기능 개선

  • 화면 개발 프로젝트 템플릿 추가

  • libman.json 에 정의된 파일을 압축 파일로 제공

  • 번들링 기본값 변경

  • HandStack CLI 기능 개발자 문서 추가

  • publish 과정에 HandStack CLI 추가

  • assetsCachingID 적용 기준 수정

  • 공통/화면 브라우저 캐시 적용 기능 분리

2
0
조준철

조준철

비즈니스 SW의 핵심 과제

"Simple is Best" 라고 문장을 쓰니, "But, it's not easy. It's HardCore." 라고 AI 가 제안을 해주네요...

ChatGPT 의 대부분의 학습 데이터가 영어권으로 되어 있는 걸 생각해보면 Simple is Best 에 대한 생각은 동서고금 비슷한가 봅니다. ^^;

제품이나 서비스를 사용자가 고민하지 않고 사용 가능하도록 직관적으로 만드는 것. 그것이 진정한 간단함이라고 생각합니다.

비즈니스 SW의 경우 꼭 필요한 개인화 된 기능을 선택 옵션을 제거하면 어느정도 간단하게 만드는 것이 가능합니다. 다만 이러한 다품종 소량 개발 방식은 여러가지 이유로 개발 비용이 비싸지고 확장성은 나빠질 가능성이 높습니다.

HandStack 을 만들어야 겠다고 생각 했을때 우선적으로 고려했던 것은 기존 운영중인 프로그램에 고객의 신규 요구를 반영하는 시간을 어떻게 하면 더 줄일 수 있을까? 였습니다.

비즈니스 SW의 큰 특징은 고객의 요구를 반영한 추가/변경에 있기 때문에 VOC (Voice of Customer) 처리를 줄이는 것이 중요하다고 생각했습니다.

모놀리식 기반의 패키지 SW나 웹 서비스들은 배포 과정에서 아무리 신중하게 스테이징 테스트를 하더라도 다양한 운영 상황에 따라 장애가 발생시 장애 등급에 따라 프로그램 다운타임이 필연적으로 길어지기 때문에 장애로 인한 비용 보상에 민감한 프로젝트 일수록 고객 요구를 반영하는 작업은 기본적으로 어렵습니다.

거기에 최근 마이크로서비스 아키텍처를 지향하는 클라우드 네이티브 기반의 서비스들과 SaaS 제품들은 이러한 문제를 더욱 복잡하게 만들었다고 생각합니다.

그래서 HandStack 은 다른 솔루션에는 없는 차별화된 3개의 방안을 제시합니다.

1. 개발과 배포 과정을 단순화​

복잡한 코딩 및 배포 과정을 단순화해서 적은 학습 비용으로 업무 화면을 개발 가능하게 합니다. 이러한 방식은 개발 및 유지보수, 인수인계에 유리하며 일반적인 비즈니스 SW를 업무를 처리하는 데 적합합니다.

화면 개발 > 쿼리 개발 > 무중단 배포 > 변경 항목 즉시 확인

2. 업무 모듈로 패키징 및 실행​

비즈니스 앱에 필요한 모든 설정과 소스는 다음과 같이 구성됩니다.

|디렉토리|설명|

|---|---|

|dbclient|데이터베이스 SQL을 XML 문서로 관리|

|function|C# 또는 Node.js 기반 Function 개발 기능 관리|

|repository|단일, 다중, 이미지, 첨부파일 등등 파일 업로드/다운로드 관리|

|transact|거래 요청 검증 및 접근 제어 관리와 요청 정보를 dbclient, function 등등 module로 라우팅 기능 관리|

|wwwroot|웹 공통 static assets 및 화면 단위 소스 호스팅 관리|

위와 같은 소스코드 구조 단위 묶음으로 업무 모듈을 패키징하고 실행할 수 있습니다. 예를 들어 회원관리, 제품관리, 주문관리, 배송관리 등등 업무 비즈니스 SW들을 기능 단위로 모듈화하여 업무 규모에 따른 스케일링이 가능하도록 서버를 구성해서 가용성, 확장성 보장할 수 있습니다.

3. 특화 요구사항이 반영되는 확장 서비스​

제조, 설비 실행에 필요한 하드웨어 연계, 다양한 네트워크 통신 프로토콜에 특화된 전문 처리 기능을 2번 방식과 동일한 방식으로 모듈화하여 기존 프로그램을 수정하지 않고 기능을 확장 가능하며 사전에 제작된 프로젝트 템플릿 기반의 업무 화면들을 만들어 적용 가능합니다.

최근에 피드백을 받아 HandStack 을 기반으로 필수 프로그램 설치 및 종속 라이브러리를 다운로드 하고 번들링을 구성하는 install 배치 스크립트에 버그가 있는 것을 확인했습니다. Windows 10, 11 클린 설치 기반에서 테스트 후 GitHub에 커밋 하겠습니다.


한 주간의 여정 (2024-04-08 ~ 2024-04-14)

  • 네임스페이스 변경

  • handstack CLI purgecontracts 기능 추가 및 개선

  • 컴파일 경고 문구 및 오류 대응 수정

  • HandStack 라이선스 v1.0 게시

https://github.com/handstack77/handstack

2
0
조준철

조준철

SQL만으로 Open API 생성하기

공공 데이터 포털에 올라온 주요 오픈 API에 대한 프로토콜 문서를 학습하는 도중에 공공 분야 뿐만 아니라 의미 있는 데이터를 제공하는 쪽 입장에서 가지고 있는 정보를 간단하게 Open API 형태로 서비스 할 수 있는 기능이 있으면 좋겠다는 생각이 들었습니다.

그래서 본래 예정에 없었던 도메인의 데이터베이스의 정보를 Open API 형태로 서비스 할 수 있는 openapi 모듈을 개발했습니다.

openapi 모듈로 별도의 개발 없이 다양한 포맷(JSON, XML, SOAP, RSS 2.0, ATOM 1.0)들을 지원하는 Endpoint를 관리 할 수 있는데 별도의 개발 없이 5개의 테이블의 정보를 구성하여 간단하게 Open API 서비스를 구성 가능합니다.

요약하면 다음과 같습니다.

  • Open API 서비스 개발 인력 없이 단기간에 구축이 가능합니다.

  • SqlServer, Oracle, MySQL, PostgreSQL, SQLite DBMS의 SQL을 사용하여 도메인 데이터를 외부에 노출합니다.

  • Open API 서비스 설정 변동 시 무중단 으로 실시간으로 반영됩니다.

  • OWASP 10대 취약점에 대응하여 안전하게 운영이 가능합니다.

Open API 서비스를 관리하기 위해 테이블의 데이터를 추가하거나 변경해야 하는데 웹 기반의 UI는 향후 forbes 로 제공됩니다.

그 전까지는 데이터 엔티티 정보와 초기 데이터 SQL을 참고하여 데이터를 직접 관리해야 자신만의 Open API를 관리 가능합니다.

openapi 모듈은 SqlServer, SQLite 데이터베이스에서 테스트 했으며 Oracle, MySQL, PostgreSQL에서 운영 동작은 확인이 필요 할 수 있습니다.

좀 더 자세한 내용은 SQL만으로 Open API 생성하기를 참고하세요.


한 주간의 여정 (2024-04-01 ~ 2024-04-05)

openapi 주요 기능

  • API 서비스 관리

  • 회원 정보 관리

  • 서비스 키 발급

  • 접근 권한 제어

  • API 메타 정보 캐시 관리

  • 로깅 및 거래 횟수 업데이트

  • 거래 제한 조건 적용

  • Json, Xml, Soap, Rss/Atom 출력 포맷 지원

  • 필수 매개변수 및 기본 매개변수 적용 확인

  • 공개, 비밀 키, IP 주소 접근 제어

  • 기간 내 호출 수 제한 및 제한 조건 일별/월별 자동 갱신

  • 응답 결과 캐싱

  • 시간 단위 API 사용 통계 수집

  • SqlServer, Oracle, MySQL, PostgreSQL, SQLite 데이터베이스 지원

4
0
조준철

조준철

좋은 경험과 나쁜 경험 구분하기

SNS에 올릴 만한 나를 위한 플렉스나 행운은 좋은 경험인가요? 자신에 대한 부당한 처우, 열정 페이를 강요 받는 것은 나쁜 경험인가요?

논증의 여지가 있고 관점을 바꾸면 같은 경험도 다르게 받아들여 집니다.

같은 경험도 사람들의 개인적인 관점에 따라 다르게 해석될 수 있습니다. 이는 우리가 각자의 생각, 감정, 경험, 가치관 등을 가지고 있기 때문입니다. 이러한 다양성은 우리가 세상을 이해하고 해석하는 방식을 풍부하게 만듭니다.

서로 다른 관점을 이해하고 존중하면서, 자신의 견해를 명확하게 표현하고 논리적으로 논증하는 것은 대화와 의사소통에서 중요한 역할을 합니다. 물론 사람은 감정의 동물이기 때문에 감정적인 부분을 배려하면서 대화를 이어가는 것도 중요합니다.

그러나 반론의 여지가 없거나 적다면 좋은 것은 좋은 것이고 나쁜 것은 나쁜 것이라는 사실은 변하지 않기 때문에 현실을 정확하게 인식하고, 사실에 기반한 결정을 내릴 때 후회할 일이 적어집니다.

현 상황을 객관적인 시각을 유지하면서도 다양한 관점을 고려하는 습관을 길러야 하는 이유입니다. 특히 주입식 교육에 익숙하고 현장 경험이 적은 사람일수록 다음과 같은 의문에 대해 연습 삼아서 생각해 볼 수 있습니다.

  • 직장에서 얻는 안정적인 월급은 마약일까?

  • 과외 선생님의 던지는 돌직구는 학생을 위한 것일까?

  • 누군가를 도와주는 것은 상대가 불편해서일까?

생소한 질문에 대해 객관적인 시각을 가지기 어렵다면 개인적으로 2개의 방법으로 시작 해보는 것을 권장합니다.

의문에 대해 제삼자에게 도움을 구하기

  • 가족이나 친구의 의견 보다 나랑 관계없는 동종 업계의 선배나 커뮤니티가 좋습니다.

  • 동종 업계의 다양한 선배에게 본인의 상황을 진솔하게 써서 개인 DM을 보내보세요.

  • 컨퍼런스, 세미나, 학회 등 강연자에게 진솔하게 질문을 해보세요.

  • 진심을 담아 솔직하게 도움을 구하면 상대방도 가능하면 진심을 담아 답변해 줄 것입니다.

  • 상대방이 나의 고민에 대해 시간을 내주었다면 물질로 성의 표시하세요. 금액이 중요한 것이 아니라 감사의 마음이 중요합니다.

저의 경우 익명성의 다양한 의견을 받을 수 있는 커뮤니티에 질문을 올리는 것 보다, 직접적인 대화를 통해 의견을 듣는 것을 선호합니다.

상대방 관점에서 바라보기

  • 내가 즐겨보는 연예인 광고, SNS 게시글, 유튜브 등등 콘텐츠를 수요자가 아닌 공급자의 관점에 생각해 보세요.

  • 아무리 간단해 보여도 대부분 정기적인 콘텐츠는 혼자서 만들 수 없고 대략 3명 이상의 스텝이 참여하게 됩니다.

  • 얼마나 많은 사람들이 해당 콘텐츠를 만들었을지 그 사람들의 월급을 역으로 비용 추산해보세요.

  • 그만한 비용을 지급하면서 해당 콘텐츠로 공급자가 수요자에게 얻어 가려는 가치는 무엇일까요?

저의 경우 “콘텐츠를 보며 웃고 있다면 그 웃음을 만들어주는 사람에게 좋은 것이고, 심각하거나 진지해진다면 그게 내 예기이기 때문이다.” 라고 생각합니다.

제가 생각하는 좋은 경험은 내가 이겨내야 할 시련에서 얻을 수 있다고 보입니다. 다른 사람들은 쉽게 쉽게 하는 것 같은데 나는 일 복이 많아서인지 매번 어렵고 힘든 과정이 많다고 느껴진다면, 이것을 자신만의 경제학 개념의 "해자"를 쌓아가는 삶의 여정이라고 생각해 보세요.

그러므로 나에게 나쁜 경험을 피하고 적절한 스트레스 해소 방법을 찾아서 좋은 경험을 만드는 것이 중요합니다.


한 주간의 여정 (2024-03-25 ~ 2024-03-29)

  • HandStack에 대한 비즈니스 모델 초안 작성 완료

  • 데이터베이스를 Open API로 만들어주는 openapi 모듈 개발 진행중 차주 오픈 예정

https://github.com/handstack77/handstack

1
0
조준철

조준철

ChatGPT와 대화를 잘하는 법

사람과의 대화는 어렵습니다. 자주 보는 사람이라도 그 사람의 지식, 생각, 경험, 상황, 배려에 따라 의도와는 다르게 예기가 다르게 전달 되거나 오해를 불러 일으키기도 하며, 어쩌다 1 년에 한번 만나더라도 어제 만났던 것 처럼 스스럼 없이 편하게 대화를 나눌 수도 있습니다.

대화의 핵심은 관심과 존중에 있습니다. 상대방에게 관심을 가지고 그 사람의 말을 경청하며, 그 사람의 의견을 존중하며 대화를 나누는 것이 중요합니다. 그러나, ChatGPT와 대화를 나눌 때는 어떨까요? ChatGPT는 사람이 아니기 때문에 관심과 존중을 가지지 않습니다.

다만 ChatGPT는 몇가지 규칙을 준수하면 좀 더 나은 대화를 나눌 수 있습니다. 우리가 로마에 가면 로마의 법을 따라야 하듯, 데이터베이스에 저장된 정보를 조회하기 위해 SQL 문법을 사용하는 것처럼, ChatGPT와 대화를 나누기 위해서는 ChatGPT가 이해할 수 있는 방식으로 대화를 나누어야 합니다.

ChatGPT와 대화를 잘하는 법​

한글로 대화하면 알아서 번역해서 찾아주고 한글로 응답합니다.​

저의 경우 한국어로 대화를 하는 것이 더 편리하고 자연스러워서 한국어로 대화를 나누고 있습니다. 아시다시피 ChatGPT는 주로 영어로 된 지식을 학습합니다. 그래서 영어로 대화를 하는 것이 더 정확한 답변을 받을 수 있습니다.

그러나, 한국어로 대화를 하면 ChatGPT가 영어로 번역해서 답변을 해줍니다. 그러니까, 한국어로 대화를 해도 ChatGPT가 영어로 번역해서 답변을 해줍니다.

언어 보다도 다음과 같이 간단한 규칙을 적용하는 것이 더 나은 결과를 얻을 때도 있었습니다. 아직 ChatGPT를 사용해보지 않았거나 규칙을 적용해보지 않았다면 다음 예시 문장을 응용해서 질문을 해보세요.

저의 경우 https://copilot.microsoft.com/ 에서 대화 스타일 선택에서 "보다 정밀한"을 선택하고 있습니다. 이렇게 하면 ChatGPT가 더 정확한 답변을 제공할 수 있습니다.

1. 역할을 부여하기

​

조금 더 시간이 걸리더라도 대화의 빌드업을 구성한다고 생각하면서 ChatGPT에게 대화를 시도하기 전에 다음과 같이 역할을 부여할 수 있습니다.

내가 지금 영어를 초급 레벨로 독학을 하고 있는데 네가 강사 역할을 해주면 좋겠어~

내가 제주도 여행을 가려고하는데 네가 한국 전문 여행사의 직원 역할을 해주면 좋겠어~

지금부터 네가 초등학생을 대상으로 과학을 가르치는 선생님 역할을 해주면 좋겠어~

C# 언어를 배우려고 하는데 네가 .NET Core C# 언어 전문가 역할을 해주면 좋겠어~

ChatGPT에게 역할을 부여하면 ChatGPT가 더 정확한 위한 준비를 합니다.

2. 정보와 예시 제공하기

​

"문장 예시", "URL 참고 링크 주소", "이미지 링크 또는 파일", "markdown 문법 테이블", "CSV 데이터" 를 참고해서... 식으로 정보를 제공하면 ChatGPT가 더 정확한 답변을 제공할 수 있습니다. 예를 들면 다음과 같이 정보를 제공할 수 있습니다.

"https://news.hada.io/topic?id=13903" URL 에서 전달하려고 하는 내용을 발표 자료 용도로 요약 해줘

응답된 결과는 5 장의 슬라이드로 구성하기 좋은 내용이라고 생각합니다. 이 내용을 발표 자료로 활용하면 좋을 것 같습니다.

또는 TAB 으로 구성된 CSV 데이터를 제공하면 ChatGPT가 더 정확한 결과를 만들어 줍니다.

"FieldID FieldName DataType IsKey IsIndex IsUnique IsNullable IsAutoIncrement Length MemberNo 회원NO String String 1 0 0 0 0 36 EmailID 이메일ID String String 0 1 0 1 0 256 EmailVerifyAt 이메일확인일시 DateTime DateTime 0 0 0 0 0 8 Celluar 핸드폰번호 String String 0 0 0 0 0 20 CelluarVerifyAt 핸드폰확인일시 DateTime DateTime 0 0 0 0 0 8 MemberName 회원명 String String 0 0 0 0 0 100 PositionName 직위명 String String 0 0 0 0 0 100 DepartmentName 부서명 String String 0 0 0 0 0 100 CompanyName 회사명 String String 0 0 0 0 0 100 Roles 역할 String String 0 0 0 0 0 200 BirthDate 생년월일 String String 0 0 0 0 0 10 JoinAt 가입일시 DateTime DateTime 0 0 0 0 0 8 RetireAt 탈퇴일시 DateTime DateTime 0 0 0 0 0 8 Address 주소 String String 0 0 0 0 0 510 AddressDetail 상세주소 String String 0 0 0 0 0 100 Gender 성별 String String 0 0 0 0 0 1 TermsOfServiceConsentYN 서비스 이용약관 String String 0 0 0 0 0 1 PersonalInformationUseConsentYN 개인정보 이용동의 String String 0 0 0 0 0 1 ThirdPartyProvisionConsentYN 제3자 제공동의 String String 0 0 0 0 0 1 CreatedUserNo 생성사용자NO String String 0 0 0 0 0 36 CreatedAt 생성일시 DateTime DateTime 0 0 0 0 0 8" 로 구성된 Member 테이블 정보로 SqlServer 데이터베이스의 DDL 을 생성해줘

물론 상세한 데이터 유형과 제약 조건 및 인덱스를 고려해서 다듬을 필요가 있지만 테이블 명이나 생성하고자 하는 데이터베이스 대상을 좀 더 구체적으로 명시하거나 응용 해서 INSERT, SELECT, UPDATE, DELETE 등의 SQL 문을 생성해 줄 수 있습니다.

핵심은 비유나 은유 사용하지 말고 명확한 맥락을 가지고 주어, 목적어, 기간을 포함하는 질문하는 것이 좋습니다.

3. 응답 대상의 역할을 부여하기

​

동일한 결과에도 응답 대상에 따라 다르게 응답을 해야 할 때가 있습니다. 이럴 때는 다음과 같이 응답 대상에 대한 정보를 제공하면 ChatGPT가 더 정확한 결과를 제공할 수 있습니다.

... 초등학생이 이해 할 수 있게 요약 해줘

... 초보 개발자가 이해 할 수 있게 예시를 들어가면서 자세하게 설명 해줘

... 직장 상사에게 보고서를 전달하기 위해 전문가의 근거 자료를 제공해서 이해 할 수 있게 자세하게 설명 해줘

4. 결과를 기준으로 다시 물어보기

​

한번에 원하는 답을 얻는 건 생각보다 어렵습니다. 답변을 받은 후에 결과를 기준으로 다시 물어보면 생각치 못한 새로운 정보를 추가로 얻을 수 있습니다.

"위의 결과에서~" 시작하여 1,2,3 질문 다시하기

ChatGPT 를 이용해서 HandStack 기반 화면과 기능을 개발 하기 위해 만족할 수준은 아니더라도 단순 반복 작업을 줄이고, 효율적으로 개발을 진행할 수 있는 아이디어를 생각중인데 원하는 결과를 얻기 위해 머신러닝 학습 모델을 만드는 느낌이 드네요.


한 주간의 여정 (2024-03-18 ~ 2024-03-22)

  • ChatGPT 기반 소스 생성기를 만들 아이디어를 간단한 POC를 진행

  • 데이터베이스를 Open API로 만들어주는 openapi 모듈 개발 진행중

https://github.com/handstack77/handstack

2
0
조준철

조준철

개발자 관점에서 본 비즈니스 앱의 변화

일반적으로 100 명 정도의 기업내 동시 사용자가 사용하는 비즈니스 앱의 경우 모놀리식 아키텍처로 개발합니다. 대부분의 중소기업에서 사용 가능한 수준입니다.

소프트웨어는 변경하지 않고 1,000명 ~ 10,000 명 정도의 동시 사용자가 사용하게 하려면 서버 CPU, RAM, DISK, NETWORK 자원을 비용을 지불하여 높이면 됩니다. 이것을 스케일 업이라고 합니다. 스케일 업 방법은 업그레이드 성능 대비 비용 지출이 급격하게 증가하는 한계점이 있습니다.

비즈니스 업무를 작은 서비스 단위로 분리하여 마이크로서비스 아키텍처로 개발 한 다음, 자원 소모가 큰 부분을 골라내어 병렬로 서비스를 운영합니다. 이것을 스케일 아웃이라고 합니다. 스케일 아웃은 초기 비싼 운영 비용과 각 서비스간의 의존도로 인한 관리 운영 비용이 추가로 발생합니다.

인건비와 관리 운영 비용을 탄력적으로 지불하기 위해 클라우드 기반으로 비즈니스 앱을 개발하고 적용하는 것을 고려하게 되는데 일정 규모의 성능을 보장 받으려면 온프레미스라는 자체 서버 운영 비용 대비 매우 비쌉니다. 그리고 클라우드 업체의 일방적인 가격 인상에 동의하기 어려운 부분이 많습니다.

그래서 하이브리드 방식의 온프레미스와 클라우드를 혼합한 개발 방식을 선택하게 됩니다. 이것을 멀티 클라우드라고 합니다. 멀티 클라우드는 클라우드 업체의 가격 인상에 대한 대응이 가능하고, 서비스의 안정성을 높일 수 있습니다.

비즈니스 앱의 변화의 핵심은 "비용"이며 비용은 눈에 잘 보이지않는 서버 호스팅 방식, 개발, 배포, 유지보수의 담당 주체, 소프트웨어와 데이터의 소유권과 사용 방식에 따라 결정됩니다.

SaaS (Software as a Service)나 로우코드 솔루션과 같이 기업이 IT 리소스를 효율적으로 활용하고, 비용을 절감하며, 비즈니스 요구 사항에 더욱 유연하게 대응할 수 있도록 돕는 도구들을 도입하는 비용에 대해 공급자와 수요자 관점에 바라보는 시야가 필요합니다.

슈퍼앱: SoD (Software on Demand) 시대​

비즈니스 앱 분야는 넷플릭스와 멜론과 같은 플랫폼에서 원하는 영화나 음악을 구매하거나 구독하는 것 처럼 소프트웨어를 공급자 중심에서 수요자가 필요에 의해 하나의 앱에서 여러 가지 기능을 이용할 수 있는 혼합 구동 방식의 앱으로 변화 할것으로 예상합니다.

슈퍼앱이라는 용어는 블랙베리 창업자인 마이크 라자리디스가 2010년에 처음 주창했습니다.

일종의 앱 분야의 폐쇄된 포털로 이해할 수 있으며, 슈퍼앱 안에 들어있는 수많은 '미니앱(Mini app)'이 바로 사용자들에게 별도의 앱 다운로드 및 설치 없이도 다양한 기능을 제공할 수 있게 해주는 핵심 요인입니다.

"SoD (Software on Demand)"와 "SaaS (Software as a Service)"는 비슷한 개념이지만, 몇 가지 중요한 차이점이 있습니다.

  • 제 3자가 아닌 기업의 온프레미스나 클라우드를 선택하여 인프라를 관리합니다.

  • 필요에 따라 소프트웨어를 사용하며 사용자 당 추가 비용과 라이선스를 구매할 필요가 없습니다.

  • 소프트웨어와 데이터의 소유권이 제 3자가 아닌 기업에게 있습니다.

슈퍼앱은 미니앱을 담고 통합하는 컨테이너로 작동해야 하기 때문에 미니앱이 원할히 작동하고 이들을 통합하기 위한 플랫폼이 갖춰져 있어야 합니다. 비즈니스, 개발, DevOps, 플랫폼 엔지니어 조직이 협업하여 플랫폼을 개발해야 합니다.

국내 대표적인 사례로 네이버, 카카오, 토스, 신한은행이 있습니다.

생성형 AI 로 인해 소프트웨어 개발, 학습, 운영 비용이 크게 절감되고 있습니다. 이러한 변화는 개발자의 관점에서 보면 J 커브의 곡선을 따라가는 것과 같습니다. 초기 접근성은 높지만, 시간이 지날수록 접근성이 낮아지고, 비용이 저렴해지며, 효율성이 높아지는 것을 경험하게 됩니다.


한 주간의 여정 (2024-03-11 ~ 2024-03-15)

  • HandStack 기능 테스트

  • Forbes 앱 템플릿 자동화 기능 개발

  • HandStack CLI 환경설정 배포 기능 테스트

  • 비즈니스 모델 검토

https://github.com/handstack77/handstack

5
0