본문으로 건너뛰기

· 약 10분
조준철

사람과의 대화는 어렵습니다. 자주 보는 사람이라도 그 사람의 지식, 생각, 경험, 상황, 배려에 따라 의도와는 다르게 예기가 다르게 전달 되거나 오해를 불러 일으키기도 하며, 어쩌다 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 모듈 개발 진행중

· 약 7분
조준철

일반적으로 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 환경설정 배포 기능 테스트
  • 비즈니스 모델 검토

· 약 8분
조준철

S/W를 통한 고객의 문제해결 역량이 모든 기업에게 선택이 아닌 필수인 시대입니다. S/W 경쟁력을 갖춘 제조/유통/서비스 기업이 시장을 주도하고 있으며 어느 기업이든 비즈니스 성장을 위해 반드시 필요한 역량이기 때문입니다.

그런면에서 개발 직군은 앞으로도 중요한 역할을 할 것으로 예상됩니다. 그러나 개발자라는 직업은 어떤 성장과정을 거쳐야 하는지, 어떤 기술을 어떤 순서로 배워야 하는지, 어떤 경험을 쌓아야 하는지에 대한 명확한 가이드라인이 없습니다.

단계별 기술 커리어 패스

소프트웨어 개발자라는 직업의 정점이 무엇인지는 개인마다 차이가 있어 정확히 알 수 없으나 다음과 같이 추구하고자 하는 성향으로 개발자가 원하는 미래를 살짝 엿볼 수 있습니다.

  • 예술가: 독보적인 감각과 창의력을 가지고 개발 하는 사람
  • 엔터테이너: 고객과 동료에게 즐거움을 주는 코딩하는 사람
  • 요리사: 필요한 것을 제공하는데 집중하는 사람
  • 건축가: 시스템을 설계하고 솔루션과 도구를 적극 활용해서 구축하는 사람
  • 직장인: 주어진 일에 충실하고 성실한 사람

개발 직군이 타 직군에 비해 좋은 것은 어떠한 성향이든 기업의 성장 단계별로 직장이 아닌 직업으로서 개발자의 커리어 패스를 만들어가는 것이 가능합니다.

  • 1명 ~ 5명 이하의 S/W 기술자가 있는 기업: MVP를 만들어내는 최소한의 기술력과 전문성을 갖추는데 집중합니다.
  • 5명 ~ 수십명의 S/W 기술자가 있는 기업: 아키텍처 전략 수립과 개발 문화를 정착하기 위해 기술적인 부채를 해결하고 팀원들을 이끌어가는 능력을 갖추는데 집중합니다.
  • 수십명 이상 S/W 기술자가 있는 기업: 조직의 역할과 책임을 분명히 하고 기술에 대한 전략과 비전을 제시합니다.

본인만의 기술 커리어 패스를 만들어가는 것은 주어진 일과 직업의 기본에 충실하되 그 위에 자신만의 경험을 쌓아가는 여정입니다.

하지만 기업은 S/W 경쟁력을 갖추기는 커녕 S/W 개발자를 고용하는 것 조차 쉽지 않습니다. 잘 생각해보면 같은 이유 때문에 개발 직업에 대한 장점과 단점이 있는듯 합니다. 그 이유는 크게 3가지로 다음과 같습니다.

1. S/W 비즈니스 모델이 불확실

S/W 개발 조직을 운영하면 기업의 비즈니스 모델을 구축하고 경쟁력을 확보할 수 있으나 경쟁사간의 우위를 확보할 수 있을지 확신할 수 없습니다. 기업 규모에 상관없이 신규 비즈니스 모델에 대한 가설을 검증하고 증명하는 실패의 과정은 필수적인데 그 비용을 기업은 감수하기 쉽지 않습니다.

2. 개발 업무에 대한 어려운 접근성

S/W 개발의 기본적인 업무들는 코딩이 아닙니다. 개발 업무 정의, 솔루션 확보, 서버/네트워크 인프라 관리, 아키텍트 설계, 데이터 모델 수립, 운영 및 유지보수, 개발, 디자인 등의 업무를 이해하고 있어야 합니다. 그래야 인하우스나 아웃소싱으로 프로젝트를 진행할 때 의사소통이 원할하게 진행될 수 있습니다.

당연히 업무 담당자들은 개발 업무에 대한 어려운 접근성을 가지고 있습니다.

3. CTO 마인드의 부재

개발자들은 다른 직군들에 비해 본인만의 기술 커리어 패스를 만들어가는 것이 중요합니다. 그래서 S/W 경쟁력을 원하는 기업은 이에 대한 교육과 지원을 제공해야 합니다.

개발자는 넘쳐나는데 채용할 만한 사람이 없다는 것은 기업과 개발자 모두 생각해 볼 과제입니다.


이번 주에 2개의 의미있는 개선이 이뤄졌습니다.

  1. Windows 10 이상 운영체제에서 개발/실행 환경에 필요한 설정을 자동화하는 install.bat 설치 스크립트가 추가 되었습니다. (Linux, Mac 용 install.sh는 테스트중 입니다)
  2. HandStack내 화면 개발에 사용중인 오픈소스 55 종을 cdnjs, jsdelivr, unpkg 설치 과정에서 한번에 내려 받도록 개선 되었습니다. (자세한 목록은 libman.json을 참고하세요)

향후 소스 코드를 내려받고 한번 클릭으로 개발/실행 환경에 필요한 S/W 설치와 종속 라이브러리의 버전 업데이트를 자동화하며 배포 프로그램의 파일 크기가 절감됩니다.

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

  • 빠른 시작 문서 개선
  • 기본 modules 소개, 모듈 관련 문서 내용 추가
  • syn.js 라이브러리 syn.domain 추가
  • syn.js 주요 사용법
  • HandStack 개발 환경 설치 스크립트 개발
  • ack 실행 환경 설치 스크립트 개발
  • 클라이언트 라이브러리 CDN 정리

· 약 7분
조준철

HandStack 에서 태넌트 앱을 개발 및 운영하기 위해 checkup 모듈을 개발중입니다. 태넌트 앱은 기업의 비즈니스 앱을 구축하기 위해 고객과 개발자가 원하는 것을 충족시킬 수 있는 방법입니다.

왜냐하면 기업에서 자사 비즈니스 앱을 구축하기 위해 일반적으로 다음과 같은 과정을 진행합니다.

프로젝트 계획 및 목표 설정 > 팀 구성 > 요구사항 분석 및 설계 > 개발 > 테스트 및 배포 > 운영 및 유지보수

그외에도 보안 및 규정 준수나 비즈니스 지원 등의 단계는 개발 단계 이후에도 계속됩니다. 이러한 과정을 거쳐 웹 서비스를 개발하고 운영하는 것은 다양한 기술과 지식이 필요합니다.

다행히도, 클라우드 컴퓨팅과 소프트웨어 개발 기술의 발전으로, 이러한 과정을 보다 쉽게 진행할 수 있는 방법이 많이 개발되었습니다. 그러나, 여전히 개발자와 고객 모두에게 다음과 같은 핵심 문제가 존재합니다.

  • 현실적인 문제 == 비용
  • 고객이 원하는 것은 무엇인가?
  • 개발자가 원하는 것은 무엇인가?

태넌트 앱으로 대안을 찾았습니다

클라우드 컴퓨팅 및 소프트웨어 개발에서 주로 사용되는 "태넌트"라는 용어가 있습니다.

"테넌트(Tenant)"는 일반적으로 독립적인 사용자 그룹 또는 조직을 나타냅니다. 프로그램 관점에서는 동일한 애플리케이션, 하드웨어, 또는 데이터베이스를 공유하지만, 고유한 업무 기능과 데이터는 서로 격리되어 있습니다.

예를 들어, 클라우드 기반 서비스에서는 여러 테넌트가 동일한 서비스를 사용할 수 있지만, 각 테넌트의 데이터는 서로 독립적입니다. 이는 각 테넌트가 자신의 데이터를 안전하게 보호하면서도, 동일한 리소스를 공유함으로써 관리 비용 효율성과 유연성을 높일 수 있게 합니다.

태넌트라는 용어는 인증, 데이터베이스, 보안, 사용자 인터페이스, 비즈니스 로직, 사용자 지원 등과 같은 여러 측면에서 적용될 수 있습니다. 이러한 면에서 태넌트는 독립적인 사용자 그룹 또는 조직을 나타내는 것으로 이해할 수 있습니다.

이러한 태넌트 개념을 기반으로, 별도의 가상화 기술을 사용하지 않고도 여러 사용자 그룹이 동일한 애플리케이션을 공유하면서, 각 사용자 그룹의 고유한 업무 기능과 데이터를 격리하여 사용할 수 있는 애플리케이션을 "태넌트 앱(Tenant App)"이라고 부릅니다.

비용을 절감하고 효율성을 높이는 방법

태넌트 앱은 다음과 같은 디렉토리로 소스를 관리합니다.

tenent-app
├─.managed
│ ├─sqlite
│ └─storage
├─dbclient
│ └─PJT
├─function
│ ├─csharp
│ └─javascript
├─transact
│ └─PJT
└─wwwroot
├─assets
└─view
└─PJT

이번에 배포한 handstack 1.0.0.beta2 에는 태넌트 앱을 개발하기 위한 기초 코드와 화면을 추가하였습니다. 실행 방법과 이번에 개발된 주요 정보들은 차주에 문서로 정리하여 공개 하겠습니다.

스크린 샷

그림) 사용자 로그인 및 프로젝트 선택 화면

그림) 프로젝트 정보 관리 화면

그림) 프로젝트 소스 관리 화면

그림) 프로젝트 미리보기 화면

한 주간의 여정 (2024-02-26 ~ 2024-03-01)

  • handstack 1.0.0.beta2 출시
  • dbclient 태넌트 쿼리 요청 처리 기능 개선
  • 태넌트 앱용 기초코드, 코드도움 화면 개발
  • 파일 추가시 코드도움 데이터 정보 조회 개선
  • $grid checkEmptyValueCol 함수 버그 수정
  • repository MediatR Event 요청 처리 기능 개발
  • repository 태넌트 앱 파일 저장 기능 개선
  • transact MediatR Event 요청 처리 기능 개발
  • transact BearerToken 정보 무결성 확인 개선
  • 데이터 모델 관리 화면 버그 수정
  • board, empty, helloworld, uicontrols forbes 추가 및 개선
  • 태넌트 앱 추가시 메타 데이터 복사 기능 개선
  • 태넌트 앱 인증 기능 개선
  • wwwroot 모듈에 ID, GUID, ClientIP, SHA256Hash 조회 api 추가
  • transact 모듈 Route 환경 변수 로드 기능 개선
  • meta.xml 생성 API 추가
  • handstack CLI 기본값 적용 기능 개선
  • 태넌트 앱 기본 테이블 생성 추가
  • checkup 모듈 로그인 기능 개발
  • HandStack publish 기능 개선
  • 태넌트 앱별 거래 로그 관리 기능 개선
  • 태넌트 앱 삭제 기능 추가
  • 서버 함수 처리 중 HttpContext 접근 버그 수정
  • 태넌트 앱 추가시 메타 정보 복사 기능 개선
  • checkup 모듈 개발
  • checkup 업무 데이터베이스 ERD 초안 설계
  • 운영체제에 따라 배치 스크립트 파일 경로 치환 개선
  • ubuntu-22.04 설치 참조 스크립트
  • handsup 운영 서버 테스트
  • handstack CLI 프로그램 개선
  • 프록시 서버 Forwarded Headers 개선
  • apiService load 기능 개선
  • 서버 배포 bundling CLI 프로그램 view 화면 압축 자동화 적용
  • handsup 운영 서버 테스트

· 약 6분
조준철

고백하건데 저는 1994년도 고등학생때 미래에 프로그래머로서 디지털 노마드의 삶을 막연하게 꿈꿨습니다. 전 세계를 돌아 다니며 어디에서든 자유롭게 일을 하며 다양한 경험을 쌓고 싶었거든요.

철없던 생각이었으나 그때는 일단 체력이 좋았고 자유로운 싱글(?) 이었으며 지금 쌓아두는 개발 지식은 내 인생에 미래 먹거리를 보장 할거라는 단순한 생각이 있었습니다. 물론 디지털 노마드의 삶을 실현하지 못했습니다.

지금은 좀 철도 들고 현실에 맞게 그때의 꿈을 적당히 타협하며 살고 있습니다. 그런데 개발은 지금도 하고 있고 앞으로도 계속 할 것인데 학습을 통해 지식 쌓는 것과 전달하는 것은 전혀 다른 영역이라 제가 가진 지식을 글로 쓴다던가 말로 전 하는게 스스로 생각해봐도 영 만족스럽지 못하네요.

닭이 먼저일까? 알이 먼저일까?

개인 인생에 또는 기업의 먹거리에 대한 미래의 중요한 의사결정을 해야 할 때 무엇을 우선 해야 하는지 고민이 들때가 있습니다.

누구나 인정할 만한 멋지고 일단 사용 해 볼수 있는 제품을 만들 것인가? 비즈니스 모델을 수립하여 가설을 검증하며 그 가능성을 인정받아 투자를 유치할 것인가? 둘 다 하는 방법도 있겠지만 사실 어느 것 하나 쉽지 않습니다.

왜냐하면 이럴 때 마다 쉽게 빠져드는 생존에 직결되는 "먹고는 살아야 할 것 아닌가?"와 "고객이 원하는 것이 아니면 자신의 만족이나 기술을 위한 기술일 뿐" 경제학 개념의 현실적인 고민이 들기 때문입니다. 물론 맞는 생각과 말입니다만 과연 내게 옮은 것이 맞는지는 스스로 따져 봐야합니다.

빠르게 가려면 혼자 해야 할 것 같고 길게 가려면 결국 같이 해야 하는데 사람과의 관계도 쉽지 않고요... 그래도 분명한 것은 ~~

  • 일과 사람에 대한 소통이 없으면 관계도 없을것이고
  • 일과 사람에 대한 존중이 없으면 애정도 없을것이며
  • 일과 사람에 대한 신뢰가 없으면 지속할 이유가 없습니다.

어차피 모두를 만족 시킬수 있는건 사기꾼이거나 독재자만 가능하다고 생각합니다. 보여지는 말과 행동이 어떻게 보여질 지 고민을 적게하세요. 주어진 문제에 대한 우선순위와 해결 방법은 각자가 만들어 가는 것 입니다. 그 과정에서 누군가는 불편할 수 있습니다만 언젠가 시간과 결과가 말해줍니다.

매일마다 잠들기 전에 스스로에게 묻습니다. 자신을 잃지 맙시다.

오늘도 마음에 든 결과가 나타나기까지 포기 하지 않고 나아가는 용기를 유지하였는가? 누가 뭐라해도 내가 추구하려는 본질이 무엇인가?

제가 HandStack 으로 꿈 꾸며 만들어가고 싶은 것은 기업에 필요한 비즈니스 앱을 위해 소스코드와 유지보수를 장소에 구애받지않고 판매와 구매가 가능한 플랫폼을 만드는 것입니다. 그러면 평생 즐겁게 개발 일을 하면서 살 수 있으니까요 ~~

이번에 GitHub에 개인적으로 의미있는 상용 수준의 비즈니스 앱이 개발 하도록 어느 정도 테스트가 진행된 베타 릴리스를 출시 했습니다.

한 주간의 여정 (2024-02-12 ~ 2024-02-16)

  • handstack 1.0.0.beta1 출시
  • Bundling, Minifys, Beautify CLI 프로그램 개발
  • $grid 컨트롤 visibleColumns 함수 업데이트 대응 수정
  • $grid 컨트롤 getPhysicalColText 함수 추가
  • $grid 컨트롤 css 스타일 컬럼 유무에 따라 적용 대응 syn.$w.pseudoStyle 함수 추가
  • easywork 그룹웨어 실행 오류 대응 수정
  • 프로그램 다운타임 최소화 아이디어
  • 데이터 게더링(Gatering)과 바인딩(Binding)
  • In-process / Out-process 메시징
  • 데이터베이스 연동
  • 유용한 자료 링크 추가
  • 기여하기 문서 업데이트
  • repository 모듈 파일 업로드/다운로드 기능 개선
  • syn.loader.js 템플릿 로드 기능 개선
  • codepicker 컨트롤 오류 수정
  • easywork 그룹웨어 실행 오류 대응 수정

· 약 6분
조준철

기본적으로 제품들은 완성된 형태를 가지고 있습니다. H/W로 제작된 제품과 부품 그리고 S/W로 제작된 프로그램이나 라이브러리들 모두 고객에게 친숙한 경험과 가치를 제공을 하는 것이 중요합니다.

그런데 IT 제품들은 조금 개념이 다른 제품군이 있는데 기존 제품의 앞단, 중간, 뒷단에 배치하여 운영되는 솔루션이나 미들웨어 등으로 불리는 S/W 기반 기술이나 네트워크 프록시, 가상화 서비스 등 여러 분야의 제품들이 있습니다.

사용자에 가까울 수록 앞단에, 시스템에 가까울 수록 뒷단에 배치되며 한번 적용되면 교체가 어렵습니다. 그러다보니 B2B 분야에 좀 더 특화된 특성을 가지고 있으며 전문화 된 제품인 만큼 가격도 비싼 편입니다.

최근 IT 기술을 선도하는 핀테크 기업들뿐만 아니라 일상생활 속 다양한 분야로까지 언급되는 AI, 슈퍼앱, 노코드, 로우코드등 다양한 솔루션은 전문화된 B2B 제품이 일반 사용자들이 저렴한 비용으로 좀 더 접근하기 쉽도록 도움을 줍니다.

이러한 흐름은 앞으로의 기업과 개인에게 2가지의 의미를 시사하고 있습니다.

  • 성숙된 인터넷 IT 업계에서 성장하기 위해 제품 프로세스를 반복 개선하고 비용을 통제하며 카피캣이 접근하지 못하도록 비즈니스 시스템(해자(Moat)) 구축
  • 기본적인 IT 및 코딩 지식이 일반 사용자들에게 기본 소양이 되고 개발자들의 전문 분야(Frontend, Backend, Database, Infrastructure, CI/CD)가 기본 스택으로 전환

모든 기업이나 개인에게 반드시 IT 지식이 필요하지 않을겁니다. 그럼에도 IT 지식을 알아야 하는 이유는 IT와 제조업이 결합되는 4차 산업혁명이 진행중이고 실생활의 변화로 인한 비즈니스의 변화가 생기기 때문입니다.

스마트 폰으로 대중화된 시대에 태어난 사용자들이 처음 부터 온라인 세상으로 시작한 소통, 거래, 지식을 실행활 속에서 쌓아왔던 사람들이 밥을 먹을때, 쇼핑을 할 때, 여행을 할때 부딫치는 문제를 해결하는 도구로 IT를 일상처럼 사용하고 있기 때문입니다.

HandStack은 IT 업무를 필요로 하는 기업이 필연적으로 거쳐야 하는 과정에서 도움을 줄 수 있는 방안을 제시하는 것을 아이디어로 시작한 솔루션입니다.

  • 개발 플랫폼 단일화: 개발/운영/유지보수 비용을 절감하려면 파편화된 개발 프로세스를 단일화 해야합니다.
  • 비즈니스 기능 최적화: 기업의 입장에서 고객을 우선으로 제품 개선을 반복하는 과정과 비용을 절감해야 합니다.
  • 플랫폼 기반 다지기: 추가 기능, 커스터마이징을 위한 신뢰할 수 있는 아웃소싱 프로세스를 내재화 합니다.

이러한 시스템이 보편화되면 기업의 비즈니스에 맞춰 커스터마이징이 필요하고 유지보수 문제를 해결하기 위해 기업내 비즈니스 앱을 위한 프로젝트나 제품 구매가 사라지고 하나의 앱 내에서 원하는 소스코드와 유지보수를 구매해 원격에서도 개발과 운영이 가능한 환경을 만들 수 있습니다.

새해 복 많이 받으세요. 2024년도에도 이루고 싶은 목표가 잘 되시길 기원합니다.

한 주간의 여정 (2024-02-05 ~ 2024-02-09)

  • handsup, easywork 모듈 데모 개발
  • gulp 번들러에 tabler 프레임워크를 제외한 base task 추가
  • easywork 그룹웨어 실행 오류 대응 수정
  • $chart, $list, $organization UI 컨트롤 추가
  • 버그 수정 및 기능 개선
  • C# 함수 디버깅하기 문서 추가
  • easywork 그룹웨어 실행 점검

· 약 11분
조준철

2024년 1월 기준 국민연금공단에 가입된 사업장 수는 536,602건 입니다. 국세청에서 조회 가능한 사업장 업종 종류는 다음과 같습니다.

  • 농업, 임업 및 어업
  • 광업
  • 사업시설 관리, 사업 지원 및 임대 서비스업
  • 제조업
  • 정보통신업
  • 수도, 하수 및 폐기물 처리, 원료 재생업
  • 전기, 가스, 증기 및 공기 조절 공급업
  • 건설업
  • 도매 및 소매업
  • 예술, 스포츠 및 여가관련 서비스업
  • 숙박 및 음식점업
  • 교육서비스업
  • 운수 및 창고업
  • 금융 및 보험업
  • 부동산업
  • 협회 및 단체, 수리 및 기타 개인 서비스업
  • 전문, 과학 및 기술 서비스업
  • 보건업 및 사회복지 서비스업

각 업종과 기업 고유에 필요한 업무들은 다양하게 있고 새로운 제품과 규모에 따른 비즈니스는 항상 새로운 앱을 필요로 하게 됩니다. 그래서 각 기업에 표준화 된 개발/관리 시스템 도입을 필요로 하게됩니다.

문제는 비용입니다. 50명 이상의 직원을 지속 가능한 안정적인 수익 모델을 가진 사업장은 전체 사업장의 5% (26,567건) 정도 인데, 여기에 스스로 기업 고유의 비즈니스 앱을 운영하는 사업장은 얼마나 될까요?

기업의 비즈니스 앱을 개발하고 운영하기 위해 다음과 같이 최소한의 인원과 비용을 한국 소프트웨어 산업협회에서 발표한 2023년 소프트웨어 노임단가 평균임금(M/M)기준으로 가정해 보겠습니다.

  • 기획 및 업무분석 담당자: 1명 (11,226,423원)
  • 분석/설계/공통 기능 고급 개발자: 1명 (10,672,530원)
  • 화면 개발자: 1명 (6,003,128원)
  • 서버 개발자: 1명 (6,003,128원)
  • 화면/기능 테스트 담당자: 1명 (4,304,555원)
  • 배포/운영 담당자: 1명 (6,729,052원)
  • UI/UX 디자인 담당자: 1명 (4,487,566원)

한 달에 대략 5천만원(49,426,382원)이 필요합니다. 여기에 하드웨어, 네트워크, S/W 라이선스 등등 운영에 필요한 각종 서비스 요금을 규모에 따라 과금이 이뤄집니다. 이것을 1년 비용으로 환산하면 웬만한 중견 기업도 IT 조직의 비용을 감당하기 어렵습니다.

그래서 대부분의 기업들이 비즈니스에 따라 SI/SM 업무를 소규모로 나눠 아웃소싱 진행을 하거나 최근 노 코드(No Code), 로우 코드(Low-Code) 플랫폼에 관심을 주고 있습니다.

최근 소프트웨어 업계에서 발생하는 다양한 현상과 문제들에 대한 해법들이 보여주는 것은 점차 개개인의 능력에 기반하는 주먹구구식의 개발 시대가 끝나가고 프로젝트 납기와 이후 품질의 보장이 필요한 시스템을 확보한 기업이 경쟁력이 시대가 오고 있다는 것을 의미합니다. 이것을 경제학에서는 해자(Moats)라고 표현 하더군요.

기업내 비즈니스 앱은 무엇인가요?

기본적으로 비즈니스는 조직 + 업무 + 고객 3요소로 구성됩니다. 필요에 따라 세분화 될 수 있고 자금과 방법에 따라 동일한 업무도 다르게 관리됩니다.

라면 끓이기를 예를 들어 보겠습니다. 1개를 끓이는 건 쉽습니다. 라면 봉지에 있는 레시피 대로 하면 되니까요. 그런데 1,000개의 라면을 끓여야 한다면? 레시피는 변하지 않지만 1,000명을 위한 장소와 식기, 세척등은 업무에서 제외 하더라도 가용할 수 있는 자원과 비용에 따라 해법들이 달라집니다.

  • 비용 절감을 목표로 한다면 2명으로 1,000개의 라면을 한번에 끓여서 면을 설익은 상태로 먼저 꺼내 놓고 배식할 때 라면에 국물을 부어 전달할 수 있습니다. 물론 늦게 먹는 사람일 수록 불어버린 면발을 먹을 수 밖에 없겠지요.
  • 고객의 만족을 극대화 한다면 전기 인덕션으로 미리 데워진 뜨거운 물을 부어 3분에 1개의 라면을 끓일 수 있으니 20개의 전기 인덕션과 4명의 주방장과 2명의 서빙 인원을 투입해 처음부터 끝까지 동일한 품질의 라면을 전달 할 수 있습니다.

사람이 만들어가는 기업내 필요한 비즈니스 앱이 워낙 방대한 분야라서 범위를 좁히기 위해 업무 문서서식 포털과 B2B 솔루션 분야를 참고해서 다음과 같이 정리 해보았습니다.

  • 업무 문서서식: 경영관리, 인사관리, 시설관리, 재정정보, 투자관리, 실적관리, 예산관리, 재무회계, 전산관리, 경영정보, 전자계약, 생산관리, 의사결정, 재고관리, 리스크 관리, 영업지원, 자재관리, 채권관리, 견적원가, 차세대, 생산공정, 회원관리, 고객관리, 민원관리, 관제시스템, 행정지원, 결산 시스템, 재난관리, 근무관리 등등
  • B2B 솔루션 분야: - IT·컴퓨터, 망분리·망연계, DW, 계정관리, 빅데이터, 성능관리, BI, DLP, OLAP, UI, 사용자인증, APM, DRM, MDM, SSO, 내부정보유출방지, 데이터변환, 백업, 블록체인, 시큐어코딩, 악성코드, 인터넷망, DB 보안, 시스템 보안, 개발보안, 문서보안, 방화벽, 취약점관리, 이상거래탐지, 전자문서, 접근통제, 출력물보안, 통합인증, 파일전송

각 업무 분야에 특화된 표준화된 바로 떠오르는 개념이나 활동, IT 솔루션 제품들은 위와 같은 비즈니스 업무를 처리 하기 위한 것이라고 볼 수 있겠네요. 리서치를 하다보니 생각보다 소프트웨어로 업종이 매우 다양한 것을 알 수 있습니다.

반드시 필요한 비즈니스 앱 3가지

업종과 비즈니스 규모에 상관없이 아웃소싱을 하지 않고 최소한의 기능만 있더라도 기업내에서 스스로 개발/관리를 해야할 기준은 "더 나은 비즈니스를 하기 위한 데이터를 확보 가능 여부"입니다. 필요한 데이터를 언제든 확보 가능하다면 아웃소싱, 노 코드(No Code), 로우 코드(Low-Code) 플랫폼, SaaS 서비스 활용 등등 무엇을 해도 괜찮습니다.

이 기준에 부합되는 비즈니스 앱은 해당 기능들을 메인으로 하여 도메인 업무에 필요한 관리 화면/기능들을 개선하거나 만들어 나갈 수 있는 시스템이 필요합니다.

  • 그룹웨어: 결재문서, 근태관리, 메신저 기능을 메인으로 요청되는 고객과 도메인 업무에 필요한 데이터 확보
  • 쇼핑몰: 서비스, 제품 판매를 위한 브랜드 쇼핑몰을 메인으로 재고, 비용, 영업, 오픈마켓 확장에 필요한 데이터 확보
  • A/S 시스템: 판매한 서비스, 제품들의 A/S 접수, 처리, 완료, 취소 실시간 상황을 파악해 고장 원인 분석 및 품질 개선에 필요한 데이터 확보

HandStack은 HTML5, ASP.NET, Node.js, Docker (HAND)의 업계 표준 기술을 기반으로 기업의 비즈니스 앱을 개발하고 운영하기 위한 과정을 단순화, 표준화 한 개발자와 엔지니어를 위한 솔루션이며 기업에서 상업적으로 무료로 사용 가능한 오픈소스 프로젝트입니다.

한 주간의 여정 (2024-01-29 ~ 2024-02-02)

  • 서버리스 Function 문서 추가
  • easywork 모듈 부트스트레핑
  • UI 화면 디버깅하기 문서 추가
  • ack 및 module 디버깅하기 문서 추가
  • Node.js 함수 디버깅하기 문서 추가
  • 환경설정 가이드 문서 추가
  • 운영 및 변경 관리 항목 정리하기
  • MOU나 컨소시엄을 만드는 의미 정리하기

· 약 9분
조준철

패러다임 전환은 한 시대 사람들의 견해나 사고를 근본적으로 규정하고 있는 인식 체계 또는 이론적인 틀이 변화한다는 것을 의미합니다. 10년 주기로 우리가 알아야 할 패러다임의 변화가 다음과 같이 진행해 온 것 같습니다.

  • Know How: 1990년대 어떻게 하는 방법을 아는 것
  • Know Where: 2000년대 필요한 것이 어디에 있는 지를 아는 것
  • Know Who: 2010년대 내가 필요한 것을 누가 알고 있는 지를 아는 것
  • Why & Experience: 2020년대 기존 것을 잘 활용하여 필요한 것을 만들 수 있는 것

소프트웨어 개발을 직업으로 살다 보니 IT 에 대한 변화를 직접적으로 느낄 수 있습니다. 요즘은 소프트웨어 개발에 필요한 도구와 환경 그리고 기술들이 상향 평준화가 되어 무언가를 만들게 될 때 처음부터 만드는 게 아니라 레퍼런스를 찾아보는 게 더 좋은 결과가 만들어지는 것 같습니다.

이번에 게시판 예제를 만들면서 많은 오픈소스 들을 활용하며 자동화 된 개발 도구들과 테스트에 필요한 각종 서버들을 즉시 사용 해볼 수 있는 인프라 환경, 예제 코드에 대한 친절한 AI의 도움을 받았습니다. 개발 경험과 생산성이 이전보다 비교할 수 없을 정도로 좋아진 것을 새삼 느낍니다.

그런데 역설적이게도 우리에게 더 많은 일을 요구합니다. 개개인에게 왜 일을 해야 하는 지 이해하고 일에 대한 과정과 결과에 대해 자연스럽게 책임을 지게 만들기 때문에 그 사람만의 대체 불가 한 넓은 시야와 직관과 경험이 필요하게 되니까요. 결국 사람에 따라 납기와 품질이 달라집니다.

"구슬이 서 말이라도 꿰어야 보배"라는 우리나라 속담에 있듯이 아무리 훌륭하고 좋은 것이라도 다듬고 정리해서 쓸모 있게 만들어 놓아야 값 어치가 있습니다.

마이크로소프트의 빌 게이츠는 오래 전부터 문제 해결에 대한 접근 방식으로 "바퀴를 재 발명하지 마세요"라는 개념을 만들었습니다. 시간과 노력을 절약하고, 이미 존재하는 해결책을 활용하여 효과적으로 문제를 해결하는 데 집중해야 한다는 의미일 겁니다.

IT 업계에서는 디지털 전환에 따라 국내외 다양한 No-Code, Low-Code 개발 환경이 등장하여 시장을 만들어가고 있습니다. 솔루션에 따라 다양한 방법으로 해결책을 제시하는데... 기본적으로 비 개발자가 적은 노력으로 어플리케이션을 개발하고 운영을 할 수 있도록 돕습니다.

HandStack 도 Low-Code 개발 환경 분야에 포함되며 일단 개발자와 엔지니어를 대상으로 하는 점에서 출발점이 다릅니다. 판매하려는 제품이 아니라 기술 기반에 가까운 반제품 이니까요. 기존 솔루션 대비 차별화되는 점은 다음과 같습니다.

  • 모든 소스와 문서를 무료로 상업적 사용이 가능한 BSD 오픈소스 라이선스로 공개합니다.
  • HTML5, ASP.NET Core, Node.js, Docker 기반 표준 기술 스택으로 앱을 개발합니다.
  • Windows, Linux, Mac, Cloud, Docker 환경에서 실행 가능한 서버 프로그램을 제공합니다.
  • 메모장으로 풀 스택 개발 및 운영 가능합니다.

특정 도구에 의지하지 않고 편집기 만으로 원하는 기능을 개발 할 수 있다는 것은 불편하지만 많은 확장 가능성을 제시합니다.

게시판 예제는 Microsoft Copilot (ChatGPT v4)를 활용해서 만들었습니다.

게시판 예제는 아마도 기존의 개발 방식과 소스 코드가 생소할 겁니다. 어렵다는게 아니라 "이렇게 어플리케이션을 개발 할 수도 있는거야?" 싶을 정도로 개발 접근법이 조금 다르기 때문입니다.

가볍게 봐주시면 좋겠네요. 자세한 내용은 게시판 프로젝트 시작하기를 참고하세요.

HandStack 확인하기

한 주간의 여정 (2024-01-22 ~ 2024-01-26)

  • 태넌트 앱에서 제한된 거래 요청 검증 기능 추가
  • $textbox english 검증 기능 개선
  • $grid button 타입 스타일 class 기능 개선
  • $grid checkbox 타입 버그 개선
  • 프로젝트 담당자 초대 기능 및 로그인 사용자 표시 개선
  • $grid 스크롤 바 표시 버그 visibility 대응 개선
  • Contracts 예제 파일 경로 개선
  • 게시판 프로젝트 시작하기
  • 가이드 문서 샘플 및 syn.js 최신버전 업데이트
  • $htmleditor 리소스 로드 기능 개선
  • repository storage.json 기본값 변경 및 데이터베이스별 기본 쿼리 추가
  • ack 프로그램 시작시 repository storage.json 기본값 변경 대응 개발
  • 게시판 프로젝트 시작하기 내용 추가
  • monaco, tinymce 등 자체 loader가 필요한 의존성이 없는 라이브러리 로드 방식 개선
  • contract, view 화면을 빌드 디렉토리로 복사하는 스크립트 추가
  • 파일 업로드/다운로드시 설정 파일 위치에 따라 호스트, 태넌트 파일 경로를 구분하도록 개선
  • 프로젝트 참조 패키지 버전 업데이트
  • 파일 업로드시 절대 링크 경로 버그 수정
  • 참조 프로젝트 목록에서 내가 만든 프로젝트가 아닌 경우만 조회되도록 개선
  • 빈 경로에 대한 디렉토리 생성 기능 추가
  • syn.js measureSize(text, fontSize) 기능 개선
  • 태넌트 앱 요청을 수행하는 서버리스 함수(featureMeta.json, featureMain.cs)에 UserWorkID를 하도록 대응 개발
  • 태넌트 앱 UI Assets 디렉토리 조회 기능 개선
  • UI Assets 관리 화면 파일 관리 기능 개선

· 약 9분
조준철

언젠가 누구나 죽기 때문에 성공, 돈, 명예등 어떠한 목표를 추구하더라도 항상 배우는 자세를 유지하고, 자신이 사랑하는 일을 찾으며, 실패를 두려워하지 않는 것이 중요합니다. - 스티브 잡스

링크) Steve Jobs' 2005 Stanford Commencement Address

어떠한 제품이나 서비스를 이용해서 나의 일에 들어가는 시간을 줄일 수 있다면 합당한 금액을 지불하고서라도 구매하고 싶은 것은 반론할 수 없는 누구나 알고 있는 명제입니다.

시간은 공평하지 않습니다

시간을 줄일 수 있다는 건 수많은 시행착오를 반복 해보고 극복한 경험을 얼마나 갖고 있는가? 아니면 그러한 경험을 가진 사람에게 도움을 받을 있는가? 여기에 핵심이 있습니다. 특히 남들이 해보지 않았던 영역일 수록 해당 분야의 대체 불가한 전문가라고 불리울 수 있는 것이겠지요.

그런데 잘 알려지지 않는 전문 분야일 수록 금액을 지불 해야하는 고객의 입장에서는 합당한 금액에 대한 책정이 참 어렵습니다. 얼핏 내가 해결 할 수 없거나 가능은 할 거 같은데 예정일을 가늠하기 어려운 일이 있을때 해당 전문 분야에 있는 사람이 일을 하면 하루 안에 끝 낼수 있을 경우 비용 책정을 어떻게 해야 할까요?

일반적으로 "인건비 + 제경비 + 교통비 + 기술료" = 비용을 생각하게 됩니다.

최근 지인중에 예전에 고객사의 10년 이상된 VPN 네트워크 장비가 고장이 나서 회사내 인터넷 장애로 인해 업무가 마비되는 일이 생겼습니다. 생각해보니 2년 전에 노후화된 장비 교체에 대한 제안을 했음에도 받아 들여지지 않았던 게 결국 문제가 발생 되었다고 하네요.

결국 VPN 장비를 교체 해야 하는데 동일한 브랜드 제품을 구하기 어려워 새로운 브랜드의 장비로 교체를 진행을 하다보니 기존에 수도권과 지방에 위치한 3곳의 사업장의 총 200대가 넘는 PC의 네트워크 대역 설정을 예전처럼 문제없이 유지하면서 장비 교체를 하기 위해 고민고민 해가며 7일 정도가 걸렸습니다.

일이 끝나고 비용 청구를 해보니 이런 답변을 들었다고 합니다.

  • 장비 교체만 하면 되는 것으로 알고 있는데 1 ~ 2일 이면 충분히 끝날 수 있는 일이라고 생각했다.
  • 하드웨어 비용에 모든 서비스 비용(?)이 포함되어 있는 거 아닌가?
  • 고장에 대해 사전에 인지하게 끔 강하게 고지를 해야한다고 생각한다.

시간을 돈으로 살 수 있는 경우는 생각보다 적습니다

시간을 돈으로 산 다는건 비용이 얼마나, 어떻게, 왜 발생하게 되는지 원리를 이해하고 지불 하는 것이기 때문입니다. 현실적인 청구 비용에 대한 설득으로 고객과의 신뢰를 얻을 수 있었고 이후 발생하는 청구 비용에 대해 의문을 제기하지 않는다고 합니다.

비즈니스의 핵심은 문제의 정의가 아니라 해결의 과정이고 고객과의 파트너간에 어떠한 신뢰 자산을 얼마나 쌓아 두느냐에 있다고 생각합니다. 그 대상이 개인이든 기업이든 말이지요. 물론 오픈소스 프로젝트 같은 예외인 경우도 있는데요.

본질적으로 비즈니스 관점에서는 선한 재능 기부나 공익의 목적으로 새로운 프로젝트를 만들 수는 있지만 지속적인 유지는 매우 어렵습니다. 다양한 문제나 이슈에 대해 적절한 대안을 제시해야하는 전문 인력과 늘어나는 일정 대비 투입되는 비용이 생기기 때문이죠.

성공 유무를 확신 할 수 없는 자신의 비즈니스 모델에 대한 가설을 검증하는 지표를 하나하나 이해당사자들에게 보고하고 설득해가며 만들어가는 거... 비즈니스 모델에 대한 명확한 준비없이 사업을 실행을 하는 경우가 은근 많을겁니다. 사실 사람사는 거 동서고금 어디든 비슷비슷하거든요.

자신의 비즈니스 앱을 구축하고 운영을 하는 것은 적지 않은 도입/학습/유지/개발/운영 비용이 필요합니다. 그래서 HandStack은 오픈소스이고 무료이며 이에 대한 과정을 간소화합니다. 자세한 내용은 HandStack을 사용 해야 하는 이유을 참고하세요.

개발자나 엔지니어 입장에서 이해당사자들간(아마도 기획, 영업, 마케팅, 운영, 관리, 고객 담당자)의 고충을 나누고 적절한 합의를 만들 수 있어 업무를 효과적으로 덜어 낼 수 있는 방안을 생각할 수 있기 때문에 자신의 결과물(제품이나 서비스)이 고객에게 전달되는 과정에서 발생하는 필연적인 업무들에 대한 이해는 본인이 영향을 줄 수 없더라도 반드시 필요합니다.

다음 주에 Hands on Lab 따라하기에 "게시판 만들기 과정 요약"으로 간단한 게시판을 만들어 보면서 HandStack 기반 앱 화면과 기능을 만들어 가는지 확인해보도록 하겠습니다. 감사합니다.

한 주간의 여정 (2024-01-15 ~ 2024-01-20)

  • 계약 중심 거래 문서 작성
  • 모듈러 모놀리식 아키텍처 문서 작성
  • 문서 내용 업데이트
  • syn.controls 가이드 문서 작성
  • 문서 내용 업데이트
  • 공식 가이드 문서 업데이트
  • 12-Factors 문서 카테고리 추가
  • handsup 모듈 개발자 테스트 진행
  • 처음 사용자를 위한 문서 내용 목차 초안 작성
    • handsup 시작하기
    • 게시판 프로젝트 시작하기
    • 보안 설정하기
    • 외부 HandStack 서버에 배포 하기
    • 파일 업로드/다운로드 기능 설정하기
    • 외부 데이터베이스 연결하기
    • 협업 하기
  • 태넌트 앱 디렉토리 경로 버그 수정
  • 데이터 원본, 파일 저장소 오류 대응 수정

· 약 7분
조준철

기존에 잘 돌아가는 코드를 수정해야 하는 경우가 생겼습니다.

가급적 기존 코드를 수정 만큼은... 특히 구조나 아키텍처까지 건드려야 하는 상황은 정말로 피해야 하는게 당연한데도 다른 사람은 몰라도 개인적으로는 충분히 문제가 예상되기 때문입니다.

오픈 소스를 Github에 올리기로 마음 먹었을 때 제일 걱정인 부분이 이거 였다는 것을 다시 상기하게 됩니다.

소스 코드를 외부에 공개하지 않아도 되는 경우 개발자 만드는 프로그래밍 소스에 대해 자유도나 팀원들 또는 담당자들과 합의 할 여지가 많습니다. 이것은 기업내 프로젝트든 SI든, SaaS든 어떠한 분야에서든 마찬가지 입니다.

간단한 예를 들면 프로그램 실행시 상용 라이선스 정보나 데이터베이스 연결문자열 등 키 정보를 수급하기 위한 정보 관리를 내부 소스 제어 관리를 이용하거나 비밀 키를 관리하는 시스템을 통해서 가져오도록 하는 부분을 모두가 동일하게 공유 해야 하는 공개 소스로 만드려면 어떻게 해야 할까요?

이러한 딜레마는 정말 일부에 불과합니다

  • 업계에 널리 알려진 범용적인 아이디와 패스워드로 변경하여 공개한다
  • 상용 라이선스 키를 마스킹하여 공개한다
  • 키를 수급하기 위한 프로그램을 추가로 만들어 공개한다
  • 민감한 부분은 아예 공개를 안하고 기술 문서로 남겨둔다
  • 공개되더라도 내부 시스템에 적용되지 않으면 문제되지 않으니 그냥 공개한다

물론 정답은 없으며 적정선에서 타협은 봐야겠지만 기본적으로 프로젝트의 성과는 돈을 더 많이 벌게 하거나 (1순위), 일을 편하게 하거나 (2순위), 제품의 가치를 올릴 수 있을때 (3순위) 나타납니다. 즉 지속적인 비즈니스를 운영 해야 하는 관점에서 성과의 기준을 벗어나는 기술 부채에 고민이 드는 것은 어쩔수 없습니다. 사실 누가 알아주는 경우도 많지 않거든요.

품질은 양심인데 하며 손을 대는 상황에서 일이 해결되는 것이 아니라 문제가 점점 커지거나 답이 안나오는 경우에 따라 이런 심리가 반복적으로 생기는 것 같습니다.

  • 어차피 기능적인 결과는 동일한 것을 내가 무슨 영달을 얻으려고 잘 돌아가는 코드를 수정하고 있는지... 번아웃도 가끔 옵니다
  • 구조나 아키텍처까지 건드리면 예상 되어지거나 예상 못했던 사이드 이펙트에 시간이 지연되고 계획해 두었던 일정이 깨지는 스트레스가 옵니다

그럼에도 불구하고 기술 부채들에 대해서 현실적인 고민을 하고 손을 대어 보는 건 충분한 가치가 있습니다.

  • 프로그램 소스 코드에 대한 품질이 높아집니다. 라면 한두개 끓이는 경험과 백개, 천개, 만개를 끓이는 경험은 레시피를 만들때 수준과 깊이가 달라지니까요.
  • 적정선에서 만족스러운 결과를 만들어 냈을때의 성취감은 어제보다 나은 오늘의 나를 만들었다는 자부심을 만듭니다.
  • 어느 순간 나와 비슷한 고민을 해봤던 사람들을 만나게 될때 좀 더 상대방의 겪었던 고충과 이면을 이해하게 되는 시야가 생깁니다.

이번 주에 HandStack 내에서 태넌트 기능을 처리하기 위한 부분을 개선하기 위해 문득 들었던 생각입니다. 읽어 주셔서 감사합니다.

한 주간의 여정 (2024-01-08 ~ 2024-01-12)

  • 회원가입 및 로그인시 UserWorkID, TenantAppRequestPath 사용자 정보 추가하기
  • contract, view 화면을 빌드 디렉토리로 복사하는 스크립트 추가
  • applicationID 를 전달하는 /handsup/api/tenant-app 요청을 수행하는 클라이언트에 UserWorkID를 전달하도록 변경
  • 파일 업로드/다운로드시 설정 파일 위치에 따라 호스트, 태넌트 파일 경로를 구분하도록 개선
  • 프로젝트 참조 패키지 버전 업데이트
  • 파일 업로드시 절대 링크 경로 버그 수정
  • 참조 프로젝트 목록에서 내가 만든 프로젝트가 아닌 경우만 조회되도록 개선
  • 빈 경로에 대한 디렉토리 생성 기능 추가
  • syn.js measureSize(text, fontSize) 기능 개선
  • 태넌트 앱 요청을 수행하는 서버리스 함수(featureMeta.json, featureMain.cs)에 UserWorkID를 하도록 대응 개발
  • handsup 확장 모듈 메뉴 표시, 순서 정리
  • 태넌트 앱 UI Assets 디렉토리 조회 기능 개선
  • UI Assets 관리 화면 파일 관리 기능 개선