▲

GN⁺: 저는 로우코드에 대해 회의적입니다

 (nick.scialli.me)
13P by neo 4달전 | favorite | 댓글 6개
  • 로우코드(low-code)에 대한 회의적인 입장임
  • 소프트웨어 컨설팅을 하면서 로우코드의 빠른 개발 시간과 낮은 유지 보수 비용을 약속하는 광고에 이끌린 클라이언트들을 자주 만남
  • 클라이언트들이 만족하지 못하는 몇 가지 이유가 존재함

맞춤형 기능에 대한 한계

  • 로우코드 솔루션은 기업 요구 사항의 약 80%를 충족시키지만, 나머지 20%는 기본 기능으로 해결 불가능
  • 로우코드 도구 마케터들은 나머지 20%를 쉽게 해결할 수 있다고 주장하지만, 실제로는 상당한 맞춤화가 필요하고 때로는 불가능함
  • 기업은 도구의 기본 기능이 충분히 가까운지, 아니면 도구를 해킹하여 정확한 사용 사례에 맞추려고 시도할지 선택해야 함

개발자 풀의 제한

  • 기업들은 때때로 로우코드 도구를 해킹하여 100% 요구 사항을 충족시키려고 시도함
  • 결과적으로 특정 도구나 독점 언어로 많은 맞춤 코드를 작성하게 되어 이해할 수 있는 개발자가 매우 적음
  • 이제 회사는 널리 사용되는 오픈 소스 언어 개발자 풀에서 모집하는 대신, 이 도구에 매우 전문화된 유지 관리자를 찾아야 함

플랫폼 업그레이드의 문제

  • 소프트웨어를 업그레이드하면서 연동되는 것들이 깨지지 않게 하는 것은 어려움
  • 로우코드 도구는 로우코드 도구가 설계되지 않은 사용 사례를 위해 임의의 코드를 처리해야 함
  • 엄격한 API 계약을 통해 이를 수행할 수 있어야 하지만, 실제로는 맞춤 코드가 내부에서 온갖 장난을 치는 것을 많이 봄

데이터베이스 구조의 혼란

  • 정밀한 분석이 필수적인 프로세스에 로우코드 도구를 사용하는 기업을 봄
  • 그러나 기본 데이터 모델을 살펴보면 이해할 수 없는 상태임: user_attribute_47이 무엇을 의미하는지? 애플리케이션의 페이지 1에서 페이지 2로 필드를 이동하면 데이터가 별도의 필드에 있음?

GN⁺의 의견

  • 로우코드는 개발 속도와 유지 보수 비용을 줄일 수 있는 유망한 도구이지만, 실제 사용 시 예상치 못한 문제들이 발생할 수 있음.
  • 특히 맞춤형 기능이 필요한 경우나 특정 로우코드 도구에 의존하는 개발 언어의 사용은 개발자 풀을 제한하고 유지 보수를 어렵게 만듦.
  • 로우코드 도구의 업그레이드와 데이터베이스 구조의 복잡성은 장기적인 프로젝트 관리에 있어 중요한 고려 사항임.
  • 이 글은 로우코드 도구를 사용할 때 주의해야 할 점들을 지적하며, 적절한 사용 사례에 대한 신중한 평가를 권장함으로써 흥미로운 통찰을 제공함.
▲
ats62 4달전  [-]

지금 까지의 노코드의 개념을 특정 분야에서 제한적으로 적용된다 생각합니다.

Llm을 이용한 well made 서비스가 등장하면 노코드의 트렌드? 흐름? 추세? 아무튼 개념이 변화하는게 우선이한 생각이 드네요

답변달기
▲
quack337 4달전  [-]

10년 전 쯤 MS Access를 유용하게 활용한 사례를 알고 있습니다.

조직의 정보시스템에, 비교적 잘 설계되어 MS Sql Server에 구현된 데이터베이스가 있었고,
일상적인 OLTP 작업들도 역시 비교적 잘 구현되어 있었습니다.

그런데 일상적이지 않은 데이터 조회 및 보고서 출력 요구에 대한 IT부서의 느리고 소극적인 대응에 불만이 쌓여 있었습니다.

MS 액셀과 액세스를 잘 다룰줄 아는 업무 부서 직원이, 정보시스템에서 다운로드한 액셀 데이터를 액세스에 import 하여, 필요한 데이터 조회 및 보고서 출력 기능을, 코딩 없이 불과 몇 시간 만에 액세스로 구현할 수 있음을 보여줬습니다.

답변달기
▲
quack337 4달전  [-]

업무 부서는 액세스에서 DB에 바로 연결할 수 있도록 요청했고, IT부서는 정보시스템 DB를 외부 네트워크에 노출하는 것에 반대했습니다. 그렇지만 업무 부서의 요구가 강했기 때문에, 일부 데이터들만 미러링된 DB를 따로 만들어서 노출해줬습니다.

액셀 데이터 기능을 잘 다룰줄 아는 직원들은 며칠 교육만으로 액세스를 업무에 활용하기 시작하더군요.

답변달기
▲
tequila 4달전  [-]

저는 이 글이 공감되네요. 개인적인 생각입니다만,
특수 문법을 사용하는 경우 -> 러닝커브가 필요해지고, 유지보수가 어려워짐
UI로 코드를 단순 대체하는 경우 -> 그냥 코딩하는게 더 편한 경우가 많음
완전한 노코드 도구가 되는 경우 -> 제약이 많고, 유저의 해킹이 유도됨. 의도 외 동작을 하는 유저의 빈도가 크게 늘어남
결과: 아무도 만족할 수 없는 도구가 됩니다.
기획-개발-사용자의 간극이 서로 너무 커서, 생각보다 잘 만들기 어려운 분야같습니다.

답변달기
▲
xissy 4달전  [-]

그래도 큰 흐름 상에서 no-code or low-code로 더 가지 않을까 싶어요. 발전해야 하는 부분도 많지만요.

답변달기
▲
neo 4달전  [-]
Hacker News 의견
  • 저개발 코드에 대한 다양한 관점

    • 저개발 코드 플랫폼 개발자의 관점

      저개발 코드는 판매하기 쉬움. IT 부서를 문제로 몰고 기존의 불만을 이용하는 전략을 사용. 데모에서는 간단한 작업을 빠르게 보여줌. 하지만 핵심 비즈니스 로직은 저개발 코드에 포함시키지 않는 것이 좋음. 복잡한 작업은 전문 시스템으로 오프로드되는 것을 가정. 큰 기업에서 기술적 지식은 있지만 IT 권한은 적은 팀에게 유용. 저개발 코드는 간단한 도구로 많은 문제를 해결하지만, 확장성이 떨어지고 강력한 중앙 시스템과 협력해야 함.

    • SRE(사이트 신뢰성 엔지니어)의 관점

      저개발 코드에 대해 회의적. 소스 코드 관리가 부족하고, 문서화가 잘 되어 있지 않음. 많은 맞춤 코드가 필요하지만 재사용성이 떨어짐. 독점적인 런타임 요구, 모니터링이 어려움. 실제로 엔지니어가 작업을 수행하고, 비엔지니어가 사용하는 경우는 보지 못함. Looker 같은 도구는 소스 코드 통합이 가능하지만, 여전히 엔지니어가 사용함. 복잡성을 압축하지만 필요에 따라 사용자 정의 및 확장 가능한 플랫폼을 선호함.

    • 마이크로소프트 저개발 코드 플랫폼에 대한 관점

      MS 저개발 코드 플랫폼에 관심이 있었지만, O365와 Azure 위에 복잡하게 구축된 것으로 보임. 사용자 인터페이스가 부실하고, 장기적으로 비용 절감보다 사용성 문제로 인한 손실이 더 클 수 있음.

    • MS-Access 데이터베이스/폼 솔루션을 전환하는 비즈니스 경험

      비개발자/최종 사용자가 IT 부서를 거치지 않고 만든 MS-Access 솔루션을 진정한 .net 클라이언트/서버 애플리케이션으로 전환하는 비즈니스를 구축함. 저개발 코드 솔루션은 일부 문제를 해결하거나 POC를 작동시키는 데 유용하지만, 규모 확장이나 적응이 필요할 때 문제가 발생할 수 있음.

    • SQLPage 웹사이트 빌더 개발자의 관점

      저개발 코드 솔루션은 외부 "고코드" API와 상호 작용할 수 있는 탈출구가 있어야 함. SQLPage에서는 sqlpage.exec를 통해 이를 제공. 저개발 코드 플랫폼의 업그레이드가 맞춤 구현을 깨뜨릴 수 있는 문제가 있음. 대부분의 저개발 코드 도구는 데이터를 인질로 삼지만, SQLPage는 사용자가 여전히 완전히 제어할 수 있는 데이터베이스 위에 레이어를 추가함.

    • 기업 수준의 저개발 코드 도구에 대한 반대 의견

      대기업이 사용하는 저개발 코드 도구에 반대. 대기업은 적절한 개발 팀과 계획, 조직을 감당할 수 있어야 함. 코드가 비용을 발생시키는 것이 아니라, 나쁜 개발자가 나쁜 도구를 사용하여 나쁜 결정을 내리는 것이 비용을 발생시킴.

    • 저개발 코드와 추상화 계층에 대한 관점

      "저개발 코드"는 직접 인터페이스할 수 있는 코드의 표면적이 적지만, 실제로는 많은 코드가 숨겨져 있음. 추상화 계층은 목적에 잘 맞을 때 강력하지만, 누수가 있거나 부적합할 때는 문제를 야기할 수 있음. 일반적으로 저개발 코드는 특정 용도에 맞춰진 코드를 추상화하지만, 실제로는 특정 도메인 경험이 필요함.

    • Bubble/Airtable을 사용하여 MVP를 구축한 경험

      우크라이나 팀으로부터 MVP 구축 견적을 받았지만, 인턴을 고용하여 Bubble/Airtable을 사용해 제품을 두 달 만에 만들고 6개월 내에 유료 고객을 확보함. 거의 두 해 동안 전통적인 스택으로 이동할 이유를 찾지 못함.

    • 저개발 코드 학습 과정 개발의 공포 이야기

      중요한 회사가 저개발 코드 학습 과정 생성 소프트웨어 패키지를 사용하여 마케팅 및 영업 직원을 위한 내부 학습 과정을 개발함. 몇 년 후 과정을 업데이트할 필요가 생겼지만, 개발에 사용된 소프트웨어나 작업을 수행할 수 있는 도구가 없어 문제가 발생함.

    • 저개발 코드 구현의 버전 관리 가능성에 대한 질문

      저개발 코드 구현을 버전 관리에 넣을 수 있는지, 문제가 발생했을 때 문제의 원인을 찾을 수 있는지, 무료 도구를 사용하여 특정 커밋으로 롤백할 수 있는지에 대한 의문 제기. 대부분의 경우 이러한 기능이 없어 심각한 사용에는 적합하지 않음.

답변달기