Skip to content

Web development

웹 프로그래밍의 상세 분야

웹 개발(web development)은 인터넷(월드 와이드 웹)이나 인트라넷(사설망)을 위한 웹사이트 개발과 관련된 일을 가리킨다. 웹 개발은 가장 단순한 단일 정적 문서의 플레인 텍스트에서부터 가장 복잡한 웹 기반 인터넷 애플리케이션, 전자 비즈니스, 소셜 네트워크 서비스에 이르기까지 개발 범위가 다양하다. 일반적으로 웹 개발이라 부를 때는 웹 프로그래밍뿐만 아니라 더 포괄적인 작업인 웹 디자인, 웹 콘텐츠 개발, 클라이언트 사이드/서버 사이드 스크립트 작업, 웹 서버 및 네트워크 보안 구성, 전자 상업 개발을 아우른다.

더 큰 조직과 사업 공간에서 웹 개발 팀은 수백 명의 사람(웹 개발자)들을 이룰 수 있다. 크기가 작은 조직은 하나의 영구적인 웹마스터라든지 그래픽 디자이너 및 정보 시스템 기술자 등을 필요로 할 수 있다. 웹 개발은 특정 부서의 분야라기 보다는 부서 간 협업의 노력으로 볼 수 있다.

Category

Concepts

Frontend

Scaffolding

  • Yeoman

Parser

  • jsdom - Node.js와 함께 사용하기 위한 많은 웹 표준, 특히 WHATWG DOM 및 HTML 표준의 순수 자바스크립트 구현입니다.

Bundler

  • Webpack (Module bundler)
  • Browserify
  • RequireJS

Task Runner

Package Manager

Headless

단위 테스트 (Unit Tests)

최소 단위의 util 함수, 커스텀 리액트 hook, 아니면 하나의 컴포넌트를 테스트합니다

Test Launchers

테스트를 실행하면 실행할 수 있는 툴이 있어야겠죠? Test Launcher들은 CLI나 Node.js를 통해 테스트 수행하고, jsdom이나 브라우저상에 테스트실행할 수 있게 합니다

  • jest , mocha , karma , TestCafe , jasmine

Structure Providers

테스트 작성할 때 가득성 좋게 테스트 케이스 조합, 순서를 맞출 수 있도록 global 함수를 제공해 줍니다 (describe(), test(), it())

  • jest , mocha , TestCafe , jasmine

Assertion Libraries

위에 설명한대로 어떤 테스트가 원하는 결과를 받고 있는지 util 함수를 제공해 주는 라이브러리들 입니다.(expect())

  • jest, chai , TestCafe , jasmine

Mocks, Spies, Stubs

  • sinon, jest , jasmine

컴포넌트 렌더링 라이브러리

리액트에서 컴포넌트 렌더하고, 렌더링된 컴포넌트에서 원하는 element를 찾을 수 있도록 selector 제공해 주고, element에서 다양한 이벤트 (onChange, click, 등)를 호출할 수 있습니다 (testing-library는 리액트뿐만 아니라 여러 프레이워크를 지원합니다)

  • enzyme, react-test-renderer, @testing-library, @vue/test-utils

Coverage Reporting

테스트가 총 코드베이스의 얼마 만큼 커버하고 있는지 리포팅하는 것입니다

  • istanbul + (mocha || jest || karma || jasmine)

통합 테스트 (Integration Tests)

어떤 어플리케이션에서 여러개의 요소들이 같이 돌렸을 때 어떻게 동작하는지 확인하는 테스트합니다

End-to-end Tests (E2E)

어떤 사용자가 웹앱을 사용하는 것처럼 시뮬레이션 돌린다 (이때 서버, 인프라, 웹앱 모두 테스트하게 된다)

Load Testing (부하 테스트)

End to End Testing (UI Testing)

CSS extension

Syntax lint

Transfiler

File Minimize

Multimedia

Toolkits

Frontend Toolkit
https://www.fetoolkit.io/
프론트엔드 개발자를 위한 간편한 도구들 모음
  • SVG to TSX/JSX, CSS
  • SVG Optimizer
  • Image Optimizer
  • Format CSS, JS/TS, JSON
  • Colors Converter
  • CSS & SVG Symbols
  • npm Package Size 확인
Code Beautify
JSON Beautifier, XML Viewer, JSON Converters, Hex Converters and More...
https://codebeautify.org/
Tiny Helpers
https://tiny-helpers.dev/
웹 개발자용 단일목적 간단한 도구들 모음
  • Rows To Columns
  • Base64 변환기
  • Carbon - 소스코드 to 이미지
  • CSS 툴 : 커서,그리드 생성기,추출기 등
  • Favicon 생성기
  • 웹폰트 생성기
  • JWT 디버거
  • 메타태그 에디터
  • 정규식 편집기
  • 이미지/SVG 최적화
  • Unicode 및 특수문자 검색/변환기
Offline Toolbox for Developers
DevUtil - 개발자용 도구 모음 for macOS
https://devutils.app/
https://github.com/DevUtilsApp/DevUtils-app
  • 종종 웹에서 검색해서 사용하는 도구들을 모아놓은 오프라인 앱
  • 클립보드 내용에 따라 알아서 맞는 도구를 자동 선택
  • 글로벌 단축키 지원
  • Unix Time 변환
  • URL Encode/Decode
  • JSON Formatter/Validator
  • JWT Debugger
  • Base64 Encode/Decode
  • Query String Parser
  • HTML Entity Encode/Decode
  • Backslash Escape/Unescape
CyberChef - The Cyber Swiss Army Knife
https://gchq.github.io/CyberChef/
https://github.com/gchq/CyberChef
The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis

웹 프로그래밍 언어

웹 프로그래밍 언어는 WWW에서 사용되는 프로그래밍 언어들을 통틀어 말한다. 일부는 웹 프로그래밍 언어에 마크업 언어를 텍스트 언어라는 이유로 포함시키지 않지만, 일부는 TeX같이 프로그래밍이 가능한 마크업 언어가 있기 때문에, 마크업 언어를 포함시키기도 한다.

  • 웹 프로그래밍 언어로는 PHP, JSP, ASP, .NET 등이 있다.
  • 마크업 언어로는 SGML 계열과 TeX 계열이 있다.

List of web programming languages

Client-side rendering vs Server-sde rendering

Web Fundamentals

full-stack developer Curriculum

SolutionStack:FullStackDeveloper:Curriculum 항목 참조.

웹사이트 크기가 14kB 미만이어야 하는 이유

다음과 같은 이유가 있다:

  • 15kB 페이지와 16kB 페이지의 로딩 속도 차이는 그리 크지 않는 반면 15kB와 14kB 차이는 특정 상황하에 612ms나 차이가 남
  • 이는 TCP Slow start라는 혼잡 제어 전략 때문
  • 기본적으로 브라우저와 서버가 맨 처음 통신할 때는 그 대역폭을 알 수 없음
  • 10개의 TCP 패킷을 보내보고 그 수를 20개, 40개, 80개로 늘려나감
  • TCP 패킷의 최대 크기는 1500 bytes인데 이 중 40 bytes를 헤더에 사용하므로 남은 1460 bytes * 10 = 약 14.25 kB를 사용 가능
  • 위성 인터넷을 사용하는 경우 1번의 왕복에 612ms나 소요됨
  • 그러니 더 빠른 페이지 로딩을 위해 처음 주고받는 14 kB 데이터에 중요한 리소스를 제공하길 권장
  • HTML 데이터는 압축되어 제공되니 이를 고려하면 약 50 kB라고 고려할 수 있음

HTTP 헤더나 TLS 핸드셰이킹 등을 고려한다면 항상 이 규칙이 들어맞진 않지만 그럼에도 유용한 기준일 것

로딩을 위한 UX 디자인 패턴

로딩 화면은 시스템이 하는 일에 대한 가시성을 제공하여 사용자 경험을 향상 시킬수 있음.

  • 적절한 로딩 화면을 만들기 위해 고려해야 할 사항이 몇 가지 있음.
    • 디자인에 앞서 로딩 시스템을 확인해야 함.
    • 로딩이 사용자의 입력을 차단하는지, 진행률을 알 수 있는지, 얼마나 많은 정보를 불러오는지, 모바일 경험은 어떤지 등.
    • 패시브 로딩(시스템이 미리 불러오는 것)인지, 티브 로딩(사용자의 행동에 따라 불러오는 것)인지 등.
  • 한 번에 보여주는 양에 따른 변화
    • 복잡한 구성 요소의 경우 하나씩 보여주는 게 좋을 수 있음.
    • 비교적 간단한 구성 요소의 경우 로드가 완료된 후 한 번에 표시하는 게 좋음.
    • 구성 요소의 수가 많으면 지연 로딩이 필요함.
      • 무한 스크롤, 더 보기 버튼, 페이징 등의 접근 방식 활용.
  • 빈도에 따른 변화
    • 계속 변경되는 경우, 로딩을 보여주는 UI를 최소화해야 함.
      • 구글 드라이브가 실시간 저장되는 UI를 참고.
    • 가끔 변경되는 경우 즉시 사용자에게 보여주는게 좋음.
      • 보고 있는 콘텐츠가 업데이트 되었으니, 화면을 새로고침 하라는 팝업 등.
  • 소요 시간에 따른 변화
    • 진행률을 명확하게 알 수 있는지, 아니면 불확실한지 먼저 검토해야 함.
    • 0.1초 이하인 경우
      • 즉시 결과를 보여주면 됨.
      • 몇몇 경우에는 가짜 로딩 화면을 보여주는 게 더 좋을 수 있음.
      • 사용자가 느끼기에 중요한 작업이거나 (저장 등), 사용자가 액션을 취할 수 있는 지연 시간이 필요한 경우 (메일 전송의 되돌리기 버튼 등).
    • 0.1초 ~ 1초 사이인 경우
      • 아주 흔한 지연 시간이고, 사용자의 눈에 띄지 않으므로 로딩 화면을 추가하지 않는 게 좋음.
    • 1초 이상인 경우
      • 1초를 넘기는 순간 사용자가 대기 시간을 인지하게 되므로, 적합한 로딩 화면을 추가하는 게 좋음.
      • 로딩되는 구성 요소가 작은 경우 로딩 스피너가 좋은 선택. (파일 업로드 등)
      • 화면이 바뀌는 경우 스켈레톤 로딩 화면이 좋음.
      • 이미지가 핵심 콘텐츠인 경우 주요 색상을 추출하여 흐리게 처리하면 아주 좋음.
    • 2초 ~ 10초 사이인 경우
      • "5초 가량 소요됩니다" 와 같은 시간표시기가 효과적일 수 있음.
      • 진행 표시줄은 항상 좋은 선택임.
      • 몇 가지 단계로 구성된 경우, 해당 단계를 보여주는 것도 방법.
        • 명확한 단계가 없는 경우에도 일반적인 메시지를 사용할 수 있음. (서버 연결 중 등)
    • 10초 이상 걸리는 경우
      • 진행률을 명확하게 알 수 있는 경우 퍼센트와 남은 시간 등을 표시해주는 게 좋음. (파일 업로드의 50% 등)
        • 단 99%에서 멈추는 것은 매우 치명적이므로 이런 경우가 발생할 수 있으면 다른 방법을 사용해야 함.
      • 더 오래 걸리는데 진행률을 명확하게 알 수 없으면, 작업이 완료되면 이메일 등으로 알려주겠다고 하고 사용자가 제어할 수 있도록 하면 좋음.
      • 아예 백그라운드에서 작업이 되면서 사용자의 모든 행동을 방해하지 않는 것도 좋음. (구글 드라이브의 업로드 진행 상태 등)

Documentation

[추천] Learning Patterns - 웹 앱 설계를 위한 패턴들 - (잘못된 정보도 간혹 있는 듯 ... - 확인 필요)
Learning-patterns-by-lydia_hallie_and_addy_osmani-v1.1.pdf
디자인 패턴 및 웹 컴포넌트 패턴 설명을 웹 사이트 및 무료 e북으로 제공 (435p PDF)
  • 바닐라 자바스크립트 & React
  • CodeSandbox를 이용한 실전 예제
  • 애니메이션으로 패턴 설명
  • 패턴들
    • Design Patterns : Singleton, Proxy, Provider, Prototype, Observer, Module, Mixin, Hooks, Factory, Compound, Command,..
    • Rendering Patterns : CSR, SSR, Static, Incremental Static Generation, Progressive Hydration, Streaming SSR, Islands Architecture,..
    • Performance Patterns : Static/Dynamic Import, Import on Visibility/Interaction, Route Based Splitting, Bundle Splitting, RPRL, Tree Shaking, Preloadk, Prefetch, List Virtualization,..

See also

Favorite site

MDN (Mozilla Developer Network)

Guide

  • 프론트엔드 체크리스트
  • [추천] Naver D2 - 네이버 메인 페이지의 트래픽 처리 3
  • Frontend Fundamentals
    • 토스 프론트엔드 챕터에서 생각하는 좋은 프론트엔드 코드의 기준에 대해서 소개하는 사이트를 게시했습니다.
    • 프론트엔드 개발자들이 주로 사용하는 TypeScript를 기반으로 설명
    • 가독성/예측 가능성/응집도/결합도의 4가지 관점에서 best practice를 제시함
    • 실제 프론트엔드에서 자주 사용하는 라이브러리를 활용하는 예시 제공
    • 4가지 기준
      • 가독성(Readability)은 코드가 읽기 쉬운 정도를 말해요. 코드가 변경하기 쉬우려면 먼저 코드가 어떤 동작을 하는지 이해할 수 있어야 해요.
      • 예측 가능성(Predictability)이란, 함께 협업하는 동료들이 함수나 컴포넌트의 동작을 얼마나 예측할 수 있는지를 말해요. 예측 가능성이 높은 코드는 일관적인 규칙을 따르고, 함수나 컴포넌트의 이름과 파라미터, 반환 값만 보고도 어떤 동작을 하는지 알 수 있어요.
      • 응집도(Cohesion)란, 수정되어야 할 코드가 항상 같이 수정되는지를 말해요. 응집도가 높은 코드는 코드의 한 부분을 수정해도 의도치 않게 다른 부분에서 오류가 발생하지 않아요. 함께 수정되어야 할 부분이 반드시 함께 수정되도록 구조적으로 뒷받침되기 때문이죠.
      • 결합도(Coupling)란, 코드를 수정했을 때의 영향범위를 말해요. 코드를 수정했을 때 영향범위가 적어서, 변경에 따른 범위를 예측할 수 있는 코드가 수정하기 쉬운 코드예요.

Tutorials

Article

References

  1. Asfirstalways.tistory.com_-_Client-side_rendering_vs_Server-sde_rendering.pdf ↩

  2. Why_CSS_has_become_difficult_to_understand_through_CSS_history.pdf ↩

  3. Handling_traffic_on_the_Naver_main_page.pdf ↩