"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. 업무 모듈로 패키징 및 실행​

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

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

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

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

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

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

• 네임스페이스 변경
• handstack CLI purgecontracts 기능 추가 및 개선
• 컴파일 경고 문구 및 오류 대응 수정
• HandStack 라이선스 v1.0 게시

공공 데이터 포털에 올라온 주요 오픈 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 데이터베이스 지원

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

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

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

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

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

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

• 직장에서 얻는 안정적인 월급은 마약일까?
• 과외 선생님의 던지는 돌직구는 학생을 위한 것일까?
• 누군가를 도와주는 것은 상대가 불편해서일까?

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

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

• 가족이나 친구의 의견 보다 나랑 관계없는 동종 업계의 선배나 커뮤니티가 좋습니다.
• 동종 업계의 다양한 선배에게 본인의 상황을 진솔하게 써서 개인 DM을 보내보세요.
• 컨퍼런스, 세미나, 학회 등 강연자에게 진솔하게 질문을 해보세요.
• 진심을 담아 솔직하게 도움을 구하면 상대방도 가능하면 진심을 담아 답변해 줄 것입니다.
• 상대방이 나의 고민에 대해 시간을 내주었다면 물질로 성의 표시하세요. 금액이 중요한 것이 아니라 감사의 마음이 중요합니다.

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

상대방 관점에서 바라보기​

• 내가 즐겨보는 연예인 광고, SNS 게시글, 유튜브 등등 콘텐츠를 수요자가 아닌 공급자의 관점에 생각해 보세요.
• 아무리 간단해 보여도 대부분 정기적인 콘텐츠는 혼자서 만들 수 없고 대략 3명 이상의 스텝이 참여하게 됩니다.
• 얼마나 많은 사람들이 해당 콘텐츠를 만들었을지 그 사람들의 월급을 역으로 비용 추산해보세요.
• 그만한 비용을 지급하면서 해당 콘텐츠로 공급자가 수요자에게 얻어 가려는 가치는 무엇일까요?

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

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

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

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

• HandStack에 대한 비즈니스 모델 초안 작성 완료
• 데이터베이스를 Open API로 만들어주는 openapi 모듈 개발 진행중 차주 오픈 예정

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

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

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 정리

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 운영 서버 테스트

고백하건데 저는 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 그룹웨어 실행 오류 대응 수정

기본적으로 제품들은 완성된 형태를 가지고 있습니다. 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 그룹웨어 실행 점검

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나 컨소시엄을 만드는 의미 정리하기