#프론트엔드

[clonecoding-ko]

CSS에서 요소 제외하고 스타일링하기: :not() 선택자 활용

이 글은 CSS에서 중요한 역할을 하는 :not() 의사-클래스 선택자를 소개하며, 개발자들이 특정 요소를 제외하고 스타일링하는 방법을 설명합니다. 기본적인 개념부터 시작하여, :not() 선택자가 어떻게 지정된 선택자와 일치하지 않는 요소를 선택하여 스타일을 적용하는지를 설명하고 있습니다. 실제 예시를 통해 어떻게 사용하는지에 대한 설명과 함께 복잡한 디자인에서 어떻게 활용할 수 있는지를 다루고 있습니다.

이 글은 웹 디자이너와 프론트엔드 개발자들에게 매우 유용한 정보를 제공합니다. :not() 선택자를 활용하여 요소를 선별적으로 스타일링하는 방법을 배우고, JavaScript를 사용하지 않고도 요소를 제외하고 스타일을 적용하는 방법을 익힐 수 있습니다. 이 글을 통해 기본적인 사용법부터 복잡한 시나리오까지 다양한 상황에서 :not() 선택자를 활용하여 디자인을 조작하는 기술을 습득할 수 있습니다.

[iamkenlee-blog]

"반년간 챗봇 활용 후기"

챗봇을 작년까진 무시하고 있다가 올해 2~3월경부터 본격 활용 중. 아무래도 챗GPT를 제일 많이 썼고, 코파일럿, 파인드(Phind)를 보조로 사용. 최근 나온 GPT-4o는 자연스러운 대화가 가능하다곤 하지만 어색해서 안 해 봤고, 당분간도 키보드로만 주고받을 듯.

유튜브를 보면 챗봇과 대화할 때 반말 쓰는 인간들이 꽤 많은 거 같다. 아마도 "AI는 사람이 아니다"란 이유이겠으나, 나는 챗봇과 대화를 할 때에도 반드시 경어를 쓴다. 사소한 습관이 누적돼 됨됨이를 만든다고 보기 때문. 예의 바름이나 무례한 태도는 '뇌'를 거치지 않고 무의식중에 나오는 것이다.

암튼 자잘한 거는 생략하고 좋았던 거, 별로인 거 딱 한 가지씩만 얘기하려고.

먼저 좋았던 거. 오로지 챗봇에 의지해서 낯선 컴퓨터 프로그래밍 언어 하나를 익혔다. 구체적으로는 리액트(react)라는 자바스크립트 기반 프론트엔드 프레임웍이다. 입문서는 당연히 안 읽었고, 구글 검색해 무슨 구조로 돼 있는지 대충 파악한 뒤, 챗봇에게 구체적인 기능을 하는 소스를 보여달라고 해서 실무에 복사 & 붙여넣기 해 봄.

처음엔 작동이 잘 안됐지만 온종일 끙끙대다 드디어 길을 연 다음부턴 챗봇에게 또 다른 소스를 보여 달라고 해 붙여넣기를 반복하다 보니 어느 순간 감이 오더만. 물론 내가 여러 가지 프로그래밍 언어에 익숙한 개발자란 요인이 가장 크긴 하겠지만, 과거처럼 구글과 스택오버플로우를 검색해 가며 익히려면 적어도 한두 달은 걸릴 것을 불과 일주일 안에 적응해 버리니 스스로 놀라울 수밖에.

그리고 별로인 거. 요즘 '지구와 바람과 별과 땅고' 후속편 원고를 삽질 중인데, 챗GPT에게 땅고 음악 관련 정보를 물어봤더니 '매우 확신에 찬 완전 엉터리 정보'를 보여주더라고. 처음엔 내가 모르는 얘기가 언뜻언뜻 나와서 '와, 대박이다' 했는데 크로스체크를 해봤더니 전혀 신뢰할 수 없는 소설을 써 놨다. 아마도 땅고가 거의 백 년 전 구식 음악이라 정보 왜곡이 더 심했을 듯? 근미래에 서치GPT가 구글을 능가하려면 꼭 풀어야 할 숙제일 거로 보인다.

하지만 가사 번역은 상당한 도움을 받고 있다. 구글, 파파고, 디플이 평이한 문장 번역은 웬만큼 잘하는 편이지만 가사는 운문이라서 거의 발번역 수준이거든. 그래서 세 번역기에서 각각 한글, 영어를 번역시켜 나온 여섯 개를 대조해 가며 의미를 파악하는 열나 피곤한 삽질을 하곤 했는데, 챗GPT가 거의 다 해결해 줌. 특히 최근 발표한 GPT-4o는 문장의 맥락 이해에 있어선 이미 인간을 뛰어넘었단 연구도 있는 모양인데, 진짜로 실감한다.

[black7375]

프론트엔드 모노레포 빌드에 대한 소고

개인적인 취향이 상당부분 반영되어 있지만 평소 모노레포 빌드/태스크에 대해 가지고 있던 생각을 정리해보았습니다.

1. 프론트엔드 모노레포 빌드/태스크 구조

빌드나 각종 명령어 실행에 있어서 3가지 정도로 나뉠 수 있을 것 같다.

작업 종속성: 분리할 수 있는 작업은 분리하여 실행하거나 병렬적으로 실행한다

작업목적의 차이: 라이브러리냐, 앱이냐? 빌드냐 테스트냐 등에 따라 달라짐

실행환경의 차이: 로컬에서는 빠르게 여러번 실행하고, 서버에서는 최대한 많은 검증을 한다.

작업종속성

패키지 종속성: 패키지만 설치되면 검증 가능한 작업들

타입 종속성: 타입이 빌드되야 검증 가능한 작업들

빌드 종속성: 빌드가 되어야 검증 가능한 작업들

패키지만 설치되면 검증 가능한 작업들로는 패키지 매니저의 lockfile, peerDeps 검증, prettier/eslint와 같은 포매팅과 린팅 작업이 있다.

의외로 타입 검증 작업은 빌드 작업과 별개로 가능하다. 다만 typescript-eslint와 같이 타입이 빌드되야 린트 검증이 가능한 가능한 경우가 있다.

모노레포에서 테스트는 의존한 패키지의 빌드가 되어있어야 실행가능하다.

작업목적의 차이

패키지 목적: 라이브러리 / 앱 / 환경설정 / 테스트

번들러 목적: 빌드 / 개발서버 / 테스트

작업목적에 따라 실행해야할 작업들이 상이하다. 예를 들어 라이브러리는 ESM/CJS 빌드, 타입 빌드 모두가 필요하다. 앱은 빌드 결과물 1개와 타입체크, 환경설정용/테스용은 타입 체크 정도만 필요하다.

또한 똑같이 번들러 작업이 필요하다고 해도, 빌드, 개발서버, 테스트등 작업 따라 필요한 플러그인이 다르다.

실행환경의 차이

로컬에서 개발하며 실행

리모트에서 검증

개발 환경은 모든 환경을 고려하기보다는 빠르게 실행되어 코딩-빌드-테스트 이터레이션을 여러번 돌릴 수 있게 만드는게 합리적이다. 따라서 특히 개발서버는 ESM 환경에서 실행하는 vite, 마찬가지로 vitest 또한 ESM Native를 사용하는 등 가능하면 ESM Only를 전제하고 패키지를 설정해야 한다.

반대로 리모트(PR 시)는 최대한 많은 것을 검증함이 좋다. 위에서 언급된 작업 종속성에 따라 나누고, 모든 검증 태스크를 돌리자. 다만 리모트 작업에서도 검증과 릴리즈는 달라질 수 있다.

예를 들어 라이브러리같은 경우 검증단��에서는 타입 빌드와 JS 빌드가 각각 나뉘어 실행될 수 있지만, 릴리즈시에는 통합적으로 일어나야 한다.

2. 패키지 매니저

프론트엔드 모노레포에서 첫번째로 생각나는 것은 무엇인가? 난 패키지매니저를 뽑고싶다.

여러종류의 패키지를 운영하며, 각 패키지마다 의존성들을 설치하고 관리하는 기능이 필수적으로 들어가기 때문이다.

그 중에서 yarn을 가장 좋아하는 편이다. 다음 글에 나온대로 잘 설계된 아키텍처와 정확성, 성능이 마음에 든다.

패키지 매니저의 과거, 토스의 선택, 그리고 미래

우선 패키지 매니져로서 기본기는 훌륭하다.

안정적인 lockfile 업데이트

lockfile과 pnp.cjs의 conflict 자동해결

간편한 패키지 패치

NPM script를 위한 휴대용 shell 내장과 스크립트 공유

이외에 각종 검증기능이 달려있다.

Hardened Mode: resolution 체크등으로 install시 보안공격 보호

락파일/캐시 변경 감지

Constraints: 패키지와 필드에 대한 검증

Constraints에서는 대체 어떤게 가능한가?

패키지 금지: 쓰지 말아야 할 패키지를 정할 수 있다

동일한 패키지 버전: 모노레포에서 사용할 패키지 버전을 일관적으로 유지 가능

패키지 버전 범위 통제: 패키지의 버전이 특정 범위에 속하는지 제약을 줄 수 있다

워크스페이스 페키지 강제: 워크스페이스에 있는 패키지는 고정버전이 아니라 워크스페이스 프로토콜을 쓰도록 강제가 가능

피어 디펜던시 누락 검증 및 자동추가: 피어 디펜던시가 누락되었는지 체크하고, 에러를 발생시키거나 자동적으로 devDeps/Deps에 누락된 패키지를 추가

package.json의 필드 제약: 예를 들어 패키지 이름에 prefix가 붙어있어야 하는지 검증가능

이 중에서 일부는 PNPM이나 Syncpack을 사용해야 가능하다는 기능을 잠금해제한다. [yarn berry 공식 설정 / yarn-constraints-rules] 예를 들어 동일한 패키지 버전 + 패키지 버전 범위 통제가 가능하고 (물론 yarn-plugin-catalogs라는 플러그인도 존재한다) 피어 디펜던시 설치도 조금의 노력만 들이면 가능하다.

그럼 PNPM에서 가지는 특징적인 기능적 장점은 SideEffect 캐시정도이다. 이것도 아마 플러그인을 만든다면 해결 가능한 이슈로 보인다.

이외에 앞으로 도입될 auto install, yarn run 오버헤드 감소 등의 로드맵도 기대가 된다.

이와 별개로 타입스크립트를 잘 사용하기 위해서는 project reference를 잘 설정하는게 필수인데

���디터 통합: project reference가 잘 설정되어 있어야 workspace root를 에디터로 열어도 패키지의 타입 추론이 가능해진다

적절한 타입추론: App.tsx와 vite.config.ts처럼 환경에 따른 적절한 타입추론을 위해서는 project reference 설정이 필요하다

성능: tsc --build를 통해 빌드하면 토폴로지컬한 증분빌드가 가능하다.

문제는 제대로 설정하기나, 자동으로 설정하기가 어렵다. root, local, package 참조에 따라 모두 설정해줘야 하기 때문이다. 다행히 저도 약간 기여한 @monorepo-utils/workspaces-to-typescript-project-references를 사용하면 해결이 가능합니다. (yarn과 npm만 가능)

현재 남아있는 가장 큰 불만은 Changeset에서 제대로 작동하지 않다는점이다. yarn pack을 먼저 실행하고 publish 하는 방법으로 우회가 가능하긴 하지만..

3. 린트 / 포매팅

파이썬을 사용했을때가 가끔 그리웠던 것 중 하나는 ruff이다. prettier/eslint 분리를 생각할 필요가 없고 에디터에서 거의 즉시 린트와 포매팅이 가능했기 때문이다.

그러한 면에서 Biome가 동일하게 기대된다.

다만 완전히 대체가 가능할지 미지수다. Prettier는 확실히 가능하겠지만, ESLint의 풍부한 플러그인/설정 생태계에 비할바는 아니다.

예를 들어 typescript와 통합에 있어 projectService와 같은 기능이라거나 yaml과 같은 추가적인 lint 기능들이 존재하지 않는다.

따라서 현재로선 lint는 eslint로, formatter는 biome와 함께 쓰는 방향이 합리적이라 생각한다. formatter의 경우도 vue, mdx, yaml, toml과 같은 파일등도 함께 지원해야 한다면 prettier에서 못넘어가지 않을까

4. 빌드

Biome와 동일한 맥락으로 Rolldown이 미래이며, vite에서도 실험적으로는 적용중이지만 안정화에는 1년은 걸리지 않을까?

CSS 후처리 역시 Lighting CSS와의 통합으로 매우 빠른 성능을 달성할 수 있다.

역시 문제는 빌드시 성능 병목인 타입 빌드다. 지금도 일반 빌드는 10초면 끝나지만 타입 빌드는 vite-plugin-dts를 사용하면 1분 넘게 걸린다.

미래에 Typescript Native(Typescript 7.0)가 사용되면 좀 빨라지겠지만 근본적으로 플러그인이 비효율적으로 설계되어 느리다는 생각은 버릴수가 없다.

때문에 vite-plugin-dts-build라는 vite 플러그인을 만들었다. (Type rollup 기능을 제공할 생각이 없어 vite-plugin-tsc-build라고 붙이고 싶었는데 이미 있더라ㅠㅠ)

tsc --build 처럼 증분빌드

분리된 워커에서 병렬 실행

vite의 library mode에서 여러 format이 실행될때 중복으로 실행되지 않음

3번은 직관적으로 이해가 가지 않을 것이다. 부연 설명을 하자면 CommonJS와 ESM을 동시에 지원하려면 각각을 대응하는 package.json export가 필요하며 따라서 각각의 mjs, cjs를 빌드해야 한다. 이때 plugin은 2번씩 실행된다.

타입도 그에 맞추어 ESM버전과 ModuleKind.CommonJS 및 ModuleResolutionKind.Node10를 사용해야 한다. 그래서 dts 세팅을 2번해줘야 문제없도록 export를 할 수 있다.

문제는 위와 같이 세팅이 된 경우 총 4번이 실행이 되기 때문에 락을 걸어 각 dts 플러그인 설정은 한번씩만 실행되도록 보장했다.

추가) Are the types wrong?을 사용하면 타입이 잘 export되었는지 체크가 가능하다.

예를 들어 vite-plugin-dts는 👺 Masquerading as ESM 문제가 있다. (근데 위 문제를 제대로 처리하는 라이브러리들이 생각보다 적은것 같다...)

이외에 TypeScript 빌드를 더 빠르게 만들 방법도 있는데 일반적이지는 않다.

assumeChangesOnlyAffectDirectDependencies: 영향을 받은 파일들은 재검사/재빌드 하지않고, 변경된 파일과 직접 import한 파일만 재검사/재빌드되므로 정확도가 내려간다

isolatedDeclarations: 병렬적으로 타입을 빌드하거나 검사할때 도움이 되지만, 명시적으로 각 타입들을 코드 단위에서 변경하는게 요구된다

5. 태스크 러너

현재 가장 빈공간이 많은 툴이라 느껴진다.

Yarn의 휴대용 shell + Vercel의 Turborepo의 설정이 정말 간결해서 편하다.

Root와 워크스페이스의 NPM script 공유

Turbo Repo의 증분/병렬실행과 Remote caching

복잡한 스크립트가 필요한 경우는 단순히 NPM script에 쓰이는 스크립트가 아니라 JavaScript (혹은 TypeScript)로 쓰인 태스크 매니저를 원하게 될 것이다.

이를테면 Grunt나 Gulp 같은 것들 말이다.

이 중에는 Gulp의 Task 사용법이 가장 합리적이라 여겨진다.

Gulp의 문제라 한다면, Turborepo와 같은 토폴로지/증분/병렬 실행 기능이 부족하기 때문이다. 패키지 단위의 위상적 실행은 원래 지원하지 않았고, 증분에서는 lastRun이라는 함수가 있지만, 프로세스가 꺼지면 정보가 사라진다. 병렬에서는 parallel이라는 함수가 있지만, 내부에서 사용되는 now-and-later라는 패키지의 코드를 읽어보면 실제 병렬이라기보다는 동시성 기능에 가깝다.

Turborepo의 JavaScript interface를 사용할 수 있다면 참 좋겠지만, 불행하게도 Node와의 인터페이스는 존재하지 않으므로 만약 제작하게 된다면 Microsoft의 Rush(lib)를 사용하는게 현실적이지 않을까? Turborepo의 편안한 인터페이스는 빌리더라도 말이다.

모든 워크스페이스의 태스크, vitest와 같은 것들까지 최적의 실행시간을 보장하려면 위임하여 처리할 수 있는 글로벌 워커 풀 / 프로미스 풀이 구현되는 것도 필요하지 않나 싶다.

이 정도가 Frontend Monorepo에서 당장 생각나는 요구사항들 같다. 만약 다른 언어까지 포함된 backend까지 합쳐진 형태라면 bazel 쓰는게..ㅋㅋ

[tomokoshin]

20250520

요즘 느끼는 순조로움에 대해

회사에 들어와서 처음 느껴보는 순조로움과 성취감

그동안은 왜 안되었을까

좋은 사람들(열정이 있는 사람)을 뽑았으나 제자리가 아니었던것 같다.

논리적이고 영어와 어휘력이 뛰어났지만 제품에 대해 알지 못해서 겉핡기식 브랜딩을 했던 사람

논리적이고 열정은 있으나 기획을 못하고 센스없이 기능 나열만 했던 사람

이런 사람들이 빠지면서 업무 프로세스가 간소화 되었고

손이 빠른 프론트엔드, 책임감있는 백엔드가 붙어주고

기술에 대해 잘 아는 PO가 프로젝트를 관리하고

기술에 대해 잘 모르는 서당개는 UX writing으로 빠지니깐

합이 잘 맞는다

그리고 꼼꼼하게 인터랙션을 구상하는 전직 프론트엔드 엔지니어가 홈페이지를 구현하니깐 일주일 만에 웹이 나옴

아........

사람을 정말 잘 뽑아야하는구나

좋은 사람을 뽑는것보다 그 자리에 맞는 사람을 뽑는게

엄청 중요하구나

이렇게 정화가 되는데 3년이 넘게 걸림ㅠ 너무 힘들었다

이 순조로움이 얼마나 지속될지 모르겠다

그리고 이 순조로움이라도 경험할 수 있어서 다행이다

[enterweek]

스마일게이트, 미래 개발자 양성 프로그램 ‘2025 데브 캠프(Dev Camp)’ 참가 개발자 모집

스마일게이트는 미래 개발자 양성 프로그램 ‘2025 데브 캠프(Dev Camp)’에 참가할 대학생 및 취업 준비생을 오늘부터 12월 4일까지 모집한다고 12일 밝혔다. 모집 분야는 웹 백엔드/프론트엔드, 모바일(iOS, Android) 애플리케이션 서비스이다. 데브캠프는 미래의 개발자를 꿈꾸는 이들이 역량을 강화할 수 있는 프로그램을 제공하기 위한 목적으로 실시된다. 참가자들은 12월 27일부터 내년 2월 28일까지 열리는 데브캠프 기간 내 팀을 구성, 개발 프로젝트를 ��행하게 된다. 지원 희망자는 스마일게이트 채용 홈페이지에서 온라인 지원서를 작성해 기한 내 제출하면 된다. 지원서는 프로젝트 참여 경험을 바탕으로 개발 과정에서 문제를 어떻게 정의했고, 어떤 방식으로 해결했는지 등을 중점적으로 작성하면…

[bebeanko]

학점은행제 컴퓨터공학과 한 학기 만에 끝내는 '필수 요건' 3년제 정보통신공학 또는 컴퓨터공학과 관련으로 졸업한 경우라는 필수 요건 필요합니다. 물론 2년제 졸업자도 단기간에 학점은행제 학사학위 취득을 할 수 있으나, 전적대 활용할 수 있는 범위 측면에서 3년제가 훨씬 유리하며, 다른 거 병행하지 않더라도 한 학기(15주) 면 끝낼 수 있기에 따로 봐야 됩니다. ​어떻게 한 학기 만에 대졸 학력을 만들 수 있는지 살펴보기 전에 '전공'에 대한 감각부터 정리해야 될 것 같습니다. 뼈가 되고 살이 되는 교육 정보 시작합니다! 정보통신공학, 컴퓨터공학과 관련 전공이란? 요즘 다들 어딜 가든 IT 얘길 합니다. 나도 한 번쯤 코딩 공부를 해볼까 뭐 그런 얘기부터 시작해서 진로를 프론트엔드 개발자로 전향할까까지 IT는 우리 삶에 뿌리 깊이 자리 잡았습니다. ​그럼 컴퓨터공학에선 무엇을 배울까요? 기본적으로 컴퓨터 조금 딱딱한 표현으로는 전산 과정을 이해하는 것입니다. 하드웨어, 소프트웨어라는 큰 틀에서 접근하죠. ​하드웨어와 관련된 용어(또는 전공 명에 들어가는)으로 디지털논리회로, 아키텍쳐, 임베디드, 디지털시스템, 네트워크, 통신, 장치 드라이버를 들 수 있습니다. 소프트웨어는 프로그래밍, 컴퓨터시스템, 인공지능, 개발, 보안, 암호, 컴퓨터과학 등을 들 수 있습니다. 물론 이 둘을 두부 자르듯 양분할 수 없다는 점을 알아야 됩니다. ​전공자에겐 익숙할 겁니다. 그런데, 대학의 학과 명이라는 게, 특히 전문대는 꼭 컴퓨터공학과로 통일되지 않다 보니 자신이 학점은행제로 학사학위를 취득할 때 컴퓨터공학으로 진행해야 유리한지 감이 없는 경우가 많아요. 나름대로 정리해 봤습니다. 왼쪽 전공은 보통 4년제 대학에서 개설하는 대중적인 학과이며, 학점은행제에 개설된 것이기도 합니다. 오른쪽은 전문대 중에서도 해당 명칭이 들어간 전공이라면 관련 학과로 인정될 것입니다. ​예컨대, 소프트웨어학과 3년제를 졸업했다면 학점은행제 학사학위 컴퓨터공학과를 15주 만에 끝낼 수 있을 가능성이 매우 높습니다. 정보통신 같은 경우 별다른 파생(?) 된 명칭이 거의 없다 보니 본인이 스스로 이미 알고 있을 겁니다. 정보통신공학 계열이라는 것을 학점은행제 컴퓨터공학과 15주인 이유 대학도 한 학기를 15주간 진행하죠. 학점은행도 마찬가지랍니다. 그것도 온라인으로 말이죠. 그렇다고 학은제가 모두 온라인으로 진행되는 건 아니에요. 대학부설로 운영되는 곳들은 대부분 오프라인으로 수업을 운영합니다. A대학교 사회교육원, B대학교 전산원 이런 곳들 말이죠. 직장인이라면 온라인 교육기관을 선호할 텐데, 컴퓨터공학, 정보통신공학은 비대면으로 충분히 가능하니 걱정 마세요. 학사학위를 한 학기만에 끝낼 수 있는 이유는 바로 학점인정에 관한 법률에 나와 있습니다. 전문대 졸업자 그중에서 2년제 졸업자는 80점, 3년제는 120점을 가져올 수 있습니다. 일반 대학으로 치면 편입 같은 거죠. ​다만, 120학점을 가져오더라도 그게 무턱대고 모두 인정되는 건 아닙니다. 위 사진에 아래 그림을 보면 전필, 전선, 교양, 일선 이런 식으로 학습 구분이 됩니다. 학사학위를 받으려면 전공 60, 교양 30을 충족해야 됩니다. 그중에서 컴퓨터공학과는 전필이 18, 정보통신공학은 21학점입니다. (아래 사진 참조) 여기서 전공자가 빛을 발합니다. 3년제 그중에서도 컴퓨터공학 관련된 것으로 졸업했다면, 전공은 거~의 그대로 전공으로 인정됩니다. 쉽게 말해 120학점을 '온전히' 사용할 가능성이 높다는 것이죠. ​보통 IT 계열 종사자는 국가자격증 하나 정도 갖고 있는 경우가 많더군요. 그렇다 하더라도 한 학기는 수업을 수료해야 됩니다. 학점은행제 컴퓨터공학과 2년제 졸업자는 1년 앞서 살펴본 대로 2년제 전문대졸자는 80학점을 가져올 수 있습니다. 이번엔 정보통신공학 기준으로 말씀드려볼게요. 맥락은 같습니다. ​정보통신, IT 소프트웨어융합, 스마트 IT 등 요즘 트렌드를 반영한 명칭들이 많다 보니 잘 모를 수 있는데요. 아무튼 학사학위 취득에 관심 있다면 1년 정도는 투자해야 됩니다. ​앞으로 60점을 모아야 되므로, 국가자격증 1개 내지 2개는 취득해야 됩니다. 정보처리기사, 컴퓨터 활용능력 자격증이 전필로 인정되므로 기간 단축 및 등록금 절약에 활용할 수 있습니다.   [visual-link-preview encoded="eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0Ijo5LCJwb3N0X2xhYmVsIjoi7Y6Y7J207KeAIDkgLSDtlZnsoJDsnYDtlonsoJwg66y066OMIOyDgeuLtOyEvO2EsCIsInVybCI6IiIsImltYWdlX2lkIjo5MDMsImltYWdlX3VybCI6Imh0dHBzOi8vYmViZWFua28uY28ua3Ivd3AtY29udGVudC91cGxvYWRzLzIwMjQvMDEvMjAyNC05OTB4NTEwLnBuZyIsInRpdGxlIjoi7ZWZ7KCQ7J2A7ZaJ7KCcIOustOujjCDsg4Hri7TshLzthLAiLCJzdW1tYXJ5IjoiMjAyNCDtlZnsoJDsnYDtlonsoJwg66y066OMIOyDgeuLtOyEvO2EsOyXkOyEnCDtlIzrnpjrhIgg67mE7JqpIO2VtOqysO2VmOyEuOyalC4g7ZWZ7KCQ7J2A7ZaJ7KCcIO2UjOuemOuEiOuKlCDtlZnsg50g7KCA66eI64ukIOuqqe2RnOyXkCDrp57ripQg6rKw6rO8KOyghOusuO2VmeyCrCwg7ZWZ7IKs7ZWZ7JyEIOy3qOuTnSwg64yA7ZWZ7JuQIOynhO2VmSwg7Y647J6FLCDqta3qsIDsnpDqsqnspp0g7Leo65OdIOuTsSnsl5Ag64+E64us7ZWgIOyImCDsnojrj4TroZ0g64+E7JmA7KSY7JW8IOuQqeuLiOuLpC4g4oCL64+E7JmA7KSA64uk64qUIOqxtCDsl6zrn6wg7J2Y66+466W8IOuLtOqzoCDsnojsirXri4jri6QuICIsInRlbXBsYXRlIjoic3BvdGxpZ2h0In0="]   학점은행제 학사학위 하면 많이 나오는 정보는 주로 경영학, 심리학, 사회복지학, 아동학 이런 것입니다. 공학 계열은 개설된 곳이 드물다 보니 관련 내용을 찾기 어렵습니다. 그래서 사이버대학을 찾을 텐데요. 그럴 필요 없다는 점을 오늘 내용으로 충분히 아셨길 바랍니다! 이어가기 좋은 연재글 (클릭) [visual-link-preview encoded="eyJ0eXBlIjoiaW50ZXJuYWwiLCJwb3N0Ijo5MjMsInBvc3RfbGFiZWwiOiLquIAgOTIzIC0g6rOg7KG4IO2VmeygkOydgO2WieygnCDtlIzrnpjrhIggMToxIOq0gOumrOuwm+qzoCAg7JW86rCE64yA7ZWZ7JuQIOynhO2Vmeq5jOyngCIsInVybCI6IiIsImltYWdlX2lkIjo5MjQsImltYWdlX3VybCI6Imh0dHBzOi8vYmViZWFua28uY28ua3Ivd3AtY29udGVudC91cGxvYWRzLzIwMjQvMDEv7ZWZ7KCQ7J2A7ZaJ7KCcLeu5hOyaqS05OTB4NTEwLnBuZyIsInRpdGxlIjoi6rOg7KG4IO2VmeygkOydgO2WieygnCDtlIzrnpjrhIggMToxIOq0gOumrOuwm+qzoCAg7JW86rCE64yA7ZWZ7JuQIOynhO2Vmeq5jOyngCIsInN1bW1hcnkiOiLqs6Dsobgg7ZWZ7KCQ7J2A7ZaJ7KCcIO2UjOuemOuEiCDsnpjrp4zrgpjshJwg65Oc65SU7Ja0IOuniOyngOuniSDtlZnquLAhIFMg7ZWZ7IOd7J2AIOygle2Zle2eiCDrp5DtlZjrqbQg64yA7ZWZ6rWQIOyekO2HtOyYgOyKteuLiOuLpC4gMe2VmeuFhCAy7ZWZ6riw6rmM7KeAIOydtOyImO2VnCIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0a

W5ncyJ9"] 학점은행제 블로그 ▲클릭하면 이동합니다.▲ 9년차 학습플래너에게 바로 카톡상담받기 ▲클릭하면 이동합니다.▲

[bellisajean]

개발자 종류?

개발자 분야는 다양하고 광범위하며, 기술 발전에 따라 계속해서 새로운 전문 영역이 생겨나고 있습니다. 여기 몇 가지 주요 개발자 유형과 그들의 역할에 대해 설명드리겠습니다:

프론트엔드 개발자: 웹사이트나 웹 애플리케이션의 사용자 인터페이스를 개발합니다. HTML, CSS, JavaScript 등의 기술을 사용하여 사용자가 보고 상호 작용하는 웹 페이지를 디자인하고 구현합니다.

백엔드 개발자: 서버, 데이터베이스, 애플리케이션의 백엔드 로직을 담당합니다. Python, Ruby, Java, Node.js 등과 같은 서버 사이드 언어와 데이터베이스 관리 시스템을 사용합니다.

풀스택 개발자: 프론트엔드와 백엔드 모두를 아우르는 개발을 담당합니다. 웹 개발의 전반적인 측면을 이해하고, 전체 시스템을 구축할 수 있는 능력을 가지고 있습니다.

모바일 개발자: iOS, Android 등의 모바일 운영 시스템을 위한 애플리케이션을 개발합니다. Swift, Kotlin, React Native 등의 언어와 프레임워크를 사용합니다.

게임 개발자: 컴퓨터, 모바일, 콘솔 게임 개발을 담당합니다. Unity, Unreal Engine과 같은 게임 엔진과 C++, C# 등의 프로그래밍 언어를 사용합니다.

데이터 과학자 / 머신 러닝 엔지니어: 데이터 분석, 머신 러닝 모델 개발에 초점을 맞춥니다. Python, R 같은 데이터 분석 언어와 TensorFlow, PyTorch 같은 머신 러닝 라이브러리를 사용합니다.

임베디드 시스템 개발자: 하드웨어와 밀접한 소프트웨어를 개발합니다. 임베디드 시스템, 마이크로컨트롤러 등을 위한 프로그래밍을 담당하며 C, C++ 언어를 주로 사용합니다.

DevOps 엔지니어: 개발(Dev)과 운영(Ops)을 연결하는 역할을 합니다. 코드 배포, 자동화, 시스템 인프라 관리 등을 담당하며, Docker, Kubernetes, Jenkins 같은 도구를 사용합니다.

보안 개발자: 애플리케이션의 보안 측면을 담당하며, 보안 취약점을 찾아내고 해결합니다. 암호학, 네트워크 보안 등의 지식을 필요로 합니다.

클라우드 개발자: 클라우드 기반의 애플리케이션과 서비스를 개발합니다. AWS, Azure, Google Cloud Platform 등의 클라우드 서비스를 활용합니다.

각각의 분야는 특정 기술과 도구에 대한 깊은 지식을 필요로 하며, 지속적인 학습과 기술 업데이트가 중요합니다. 개발자의 경로는 다양하며, 개인의 관심과 기술에 따라 선택할 수 있는 분야가 많습니다.

[happybono]

[Arduino] HTTP 프로토콜과 다양한 동작 방식

프로토콜이란? 프로토콜 (Protocol) 은 컴퓨터 내부 혹은 사이에서 데이터의 교환 방식을 정의하는 규약입니다. 기기 간 통신 시 교환되는 데이터의 형식에 대해, 상호적인 합의를 요구하는데요. 이러한 형식을 정의하는 규칙의 집합을 프로토콜이라고 합니다. HTTP (Hypertext Transfer Protocol) 는 프론트엔드 서버와 클라이언트 (브라우저 혹은 앱) 간의 통신에 사용되며, 백엔드와 프론트엔드 서버 간의 통신에도 사용됩니다.　 HTTP 프로토콜의 특징 HTTP 프로토콜은 상태가 없는 (stateless) 프로토콜 입니다. “상태가 없다” 의 의미는 데이터를 주고 받기 위한 각각의 데이터 요청이 상호간에 독립적으로 관리가 된다는 의미인데요, 이전에 데이터를 요청했던 것과 다음…

[sanghuich94]

삼성생명을 다니던 보험아줌마가

엄마한테 붙어서 보험을 팔았고

엄마가 자식들 앞으로 교육보험을 들었는데

이상하게 만기가 2018년이었다.

아줌마 이름은 오씨로 추정.

누구 소개로 받았는지 1억짜리 오피스텔을 분양받은 것도 2018년. 대출 8,000만원 끼고 ㅋㅋㅋ ㅅㅂ

임대 사업자 10년에 인천 광주은행 신탁끼고

( 개빡쳐서 회사 그만 둠 ㅋㅋㅋ 니가 갚아라 ? )

내 엄마지만 병신 같은 뇬임

월세 들어온 놈은 삼성생명 다닌다고 ㅋㅋㅋㅋㅋㅋㅋ

여기다가 오수하 개병신 같은 년 붙어서

구글이랑 LGU+랑 잘 해처먹음ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

회사를 다니다가 처음 건강검진을 받은 건 2016년 하반기.

2016.11 삼성바이오로직스 유가증권시장 상장

• 2019년 Facebook HwaSunLee

“생일축하드립니다”

• 2023년 삼성물산 외국인 채용공고 ㅋㅋㅋㅋ

• 2025년 삼성바이오로직스 ESG

이래도 삼성 다니고 싶냐 ?ㅋㅋㅋㅋㅋ

이제 삼성그룹은 직물도매업 ㅋㅋㅋㅋ ㅅㅂ

심장 도매업으로 바꿔야되는거 아냐?

현대자동차는 대한적십자사 ㅋㅋㅋ

2022년 한화커넥트는

시발 피 빨아먹고 오래오래 살려고 ㅋㅋㅋㅋㅋㅋㅋㅋ

언니 친구 고등학생 때 안양천에서 남자친구랑 라브라브하다가

통수맞고 ㅋㅋㅋㅋ

그래서 계속 내 계정에 92년생인 것처럼 붙이고

lg랑 양천구시설관리는 대가리에 섹스밖에 없는 놈들임

[brainshare-m-blog]

#css#flex#css배우기#flex배우기#개발자#프로그래머#코딩#html#웹#웹디자인#웹개발자#프론트엔드#프론트엔드개발자

[clonecoding-ko]

CSS에서 요소 제외하고 스타일링하기: :not() 선택자 활용

이 글은 CSS에서 중요한 역할을 하는 :not() 의사-클래스 선택자를 소개하며, 개발자들이 특정 요소를 제외하고 스타일링하는 방법을 설명합니다. 기본적인 개념부터 시작하여, :not() 선택자가 어떻게 지정된 선택자와 일치하지 않는 요소를 선택하여 스타일을 적용하는지를 설명하고 있습니다. 실제 예시를 통해 어떻게 사용하는지에 대한 설명과 함께 복잡한 디자인에서 어떻게 활용할 수 있는지를 다루고 있습니다.

이 글은 웹 디자이너와 프론트엔드 개발자들에게 매우 유용한 정보를 제공합니다. :not() 선택자를 활용하여 요소를 선별적으로 스타일링하는 방법을 배우고, JavaScript를 사용하지 않고도 요소를 제외하고 스타일을 적용하는 방법을 익힐 수 있습니다. 이 글을 통해 기본적인 사용법부터 복잡한 시나리오까지 다양한 상황에서 :not() 선택자를 활용하여 디자인을 조작하는 기술을 습득할 수 있습니다.

[iamkenlee-blog]

네스트(nest).js 잠깐 써 본 썰

아주 가끔 올리는, 먹고 살기 위해 삽질한 얘기.

'자바 스크립트'는 따따따(www) 태동기 때 등장한 '넷스케이프' 웹브라우저가 내장한 언어였던 거로 앎. 출발부터 임시방편의, 불완전한 프로그래밍 언어란 인식이 있었기 때문에 개발자 사이에선 은근 왕따, 무시를 당했다. 물론 엄청 잘 다루면 얘기가 달랐지만 그런 경지에 다다른 사람은 드물었고.

근본이 없다 보니 변수 할당도 문자, 숫자를 딱히 안 가리고 뒤섞어 쓸 수 있을 뿐만 아니라, 다른 언어에선 명백한 버그임에도 사용 가능하질 않나, 심지어 this 키워드가 가리키는 객체가 왔다 갔다 헷갈리는 등 구조적 모순까지. 그래서 이를 보완해 조금은 근본 있게 만들자는 취지에서 '타입스크립트'라는 언어가 등장한 거로 앎.

또 하나 치명적 문제점은 웹브라우저를 벗어나면 쓸 수 없단 거. 그런데 '노드(node).js'라고, 마징가의 제트스크랜더 같은 놈이 나옴. 그 결과 자바스크립트를 서버에서도 쓸 수 있게 됐고, 웹개발자는 이거 하나로 프론트엔드 및 백엔드 프로그래밍을 다 할 수 있단 점에서 큰 인기를 끌기 시작. 더는 무작정 깔볼 수만은 없는 단계로까지 성장했다.

그럼에도 나는 이거에 딱히 관심이 없었는데, 우선 한국에서 돈이 되는 개발은 '자바 + 스프링 프레임웍'이 대세로 굳은지 오래라 아무리 노드.js가 편리하고 좋다고 한들 일감이 많지 않았기 때문.

그러나 외국에선 노드.js 인기가 날로 더해 이를 기반으로 익스프레스, 뷰(vue).js, 리액트(react).js 넥스트(next).js 등등 뭐가 뭔지조차 헷갈리는 변종이 많이 나와 활용되고 있더라고.

네스트(nest).js도 그중 하나. 개인적으로 이거에 주목한 이유는 다른 노드.js 변종과 달리 자바 스프링 판박이라서, 나처럼 오랜 세월 스프링 프레임웍으로 먹고 산 사람에겐 너무도 익숙한 MVC(=Model - View - Controller) 구조라 절반은 그냥 먹고 들어가겠더라고.

그래서 기본 중의 기본인 DB에 접속해 읽기, 쓰기, 수정, 삭제 기능을 연습해 봤는데 비록 간단한 거긴 했어도 불과 2~3일만에 익힘.

삽질하는 동안 또 하나 놀랐던 거. 자바 스프링에선 뷰(view)에서 보통 jstl을 이용해 프론트엔드 코딩도 함께 했다면, 네스트.js은 뷰를 제이손(Json) 형식의 레스트(Rest) API로 보여줄 뿐 프론트엔드 코딩 자체를 안 하는 거 같았다.

다시 말해 요즘 개발 추세가 프론트엔드와 밴엔드를 완전히 분리하는 쪽으로 이동하고 있음을 늦게나마 앎. 그 결과 백엔드 개발자는 프론트엔드가 웹인지 앱인지 또 다른 뭣인지 상관치 않고 요건대로 내부 로직만 짜서 결과값을 제이손으로 되돌려주기만 하면 되는 거. 왜 진작 이렇게 할 생각을 못 했을까. 자바 스프링, 파이썬 장고도 조만간 이런 추세를 따르지 않을까 싶다.

[black7375]

프론트엔드 비젼

프론트엔드에 있어 앞으로 2~3년 내에 행하여 개선하고 싶은 주제로 5개정도가 존재한다.

모노레포 툴링: 모노레포 / 패키지 / 빌드 관련으로 어떻게하면 신뢰성이 있으면서도 빠르게 체크할 수 있는지에 관심이 있다

스타일링: HTML(JSX)를 평정한 리엑트와 다르게 스타일링은 마땅한 관리 시스템이 없다. 어떻게 해야 내용-표현, 형식-실체를 잘 관리할 수 있는가?

레이아웃: 단순한 플렉스박스, 그리드만으로는 레이아웃을 나타내기 충분하지 않다. 또한 디자이너의 시각보정, 사용자의 커스텀, QA하기 쉬운 레이아웃 구조는 어떤것인가?

상태: 이벤트 스트림을 잘 관리할 수 있는 상태 시스템, 빌드타임 CSS와의 상태 상호운용, 커스텀에 열려있는 상태와 컴포넌트 구조. 네이티브까지 포함하면 signal-stream-ecs-store-statechart까지 모두 포괄하는 시스템

문서: 디자인시스템에 최적화된 문서화 시스템. 파운데이션-유틸-컴포넌트-패턴을 모두 다루어야 하며, 디자인/개발 가이드 및 레퍼런스 관리, A/B 시스템 통합등

가능하다면 조금씩 풀어가보자 한다. 아마 만들다가 부딛치는 것들 그때그때 가지 않을까

[tonyaround]

Digital PO(Product Owner)는 어떻게 되는가?

[e-Book] Digital PO(Product Owner)는 어떻게 되는가?

콘텐츠 소개 ‘Digital Product Owner(PO)로 살아가기’는 빠르게 변화하는 디지털트랜스포메이션 (Digital Transformation: DX)과 4차산업 혁명의 시대에서 현재 떠오르고 있는 Digital PO(Product Owner: 디지털 플랫폼 혹은 서비스 책임자)가 어떤 역할을 하고 있고 왜 중요한지 그리고 더 나아가 Digital PO가 되기 위해서 어떤 역량을 가져야 하는지 등의 콘텐츠들을 경험과 사�� 및 트렌드를 기반으로 소개하고 지속적으로 연재하고자 합니다. 목차 보이지 않는 트렌드와 수 많은 질문들 앞서 설명 드린대로 현재 디지털 수요는 시장에서 폭증하고 있습니다. 비대면 중심의 사회가 되면서 사실상 디지털이 없으면 비즈니스 자체가 안되는 상황까지 왔다고 볼 수…

[aetywork1]

[pignose-barn]

Angular 2 그리고 웹 프론트엔드 (1/2)

한동안 마무리 지어야 하는 일때문에 정신이 없다가 이제서야 정리를 할 시간이 오게 되었다..

이 포스트에서는 Angular가 무엇인지 모르는 분들을 위해 Angular를 설명하는 내용을 채울까 한다.

Angular 2 그리고 웹 프론트엔드 (1/2) - 현재 글

Angular 2 그리고 웹 프론트엔드 (2/2)

Angular는 구글에서 만든 자바스크립트 프레임워크이다.

프레임워크이기 때문에 일반적으로 여러분이 아시는 jQuery, underscore, lodash 보다 규모가 큰 프로젝트다. (지원되는 기능의 폭도 넓으며 채택한 의존 라이브러리들도 많다.)

한글 발음으로 “앵귤러 제이에스"라고 발음하면 되며 여기서 Angular는 “앙상한" 이라는 단어를 가지고 있는데,

아무래도 뼈대를 갖춰주는 프레임워크라는 의미로 사용했을 것이라고 생각된다.

Angular 공식페이지에 기재된 워딩이  “One framework” (하나의 프레임워크)인데, 이는 Mobile까지 대응하겠다는 Angular의 목표가 깃들어있다.

Angular에 대해서 대체 무슨 프레임워크인가, 어떤 목적과 장점을 가지고 있는가에 대해서 궁금증이 많으실 것이라 생각된다.

사실 이 물음을 풀어드리기 위해서는 앞서 웹 프론트엔드 개발 동향을 먼저 설명해야 할 것 같다.

웹 프론트엔드의 변화

현재 웹 프론트엔드 개발에서 사용되는 툴이 많다! 너무 많다! (그리고 많아지고 있다!!)

(필자는 이 사진에 보여지는 앱보다 많은 앱을 사용했음에도 전체에 비해서는 절반도 채 되지 않는다.)

일부 개발자는 전통적인 프론트엔드 개발 방식대로 html과 javascript 그리고 css를 개발하고,

javascript 엘리먼트를 쉽게 찾을 수 있는 jQuery와 jQueryUI를 연동하여 서비스를 완성 했을 것이다 그리고 그렇게 개발하는 방법에 큰 불편함이 없었을 것이다.

결과적으로 오늘에서 이렇게 개발을 도와주는 앱이 많아진 것은 ECMA 5에서 ECMA 6로 자바스크립트 표준이 변경되고 있는 상황과,

Node.js 보급으로 인해 백엔드 서버 개발자가 점점 javascript를 사용하게 되면서 백엔드 기술 프론트엔드와의 경계가 허물어지고 있는 점.

그리고 거대한 웹 서비스 벤더사(구글, 페이스북)에서 프론트엔드 프로젝트에 기여를 하고 있는 점 이것들이 뭉치면서 아래와 같은 결과를 내었다.

웹 프론트엔드 개발에 백엔드 개발에서 요구되던 기능이 추가되고 있다.

ECMA6의 지원을 위한 서브 툴이 생겨나고 있다.

많은 모바일기기 지원으로 보다 빠른 웹을 시장이 원하고 있다.

많은 기존 자바스크립트 라이브러리들이 최신 기술을 수용하고 있다.

(웹 프론트엔드 개발자들은 공부할 것이 엄청나게 늘어나 버렸다.)

또한 이러한 변화가 프론트엔드의 러닝커브를 늘렸으며,

기존 개발 환경에 익숙하여 최신 동향을 살펴보지 않는 개발자들은

자리를 위협받는 상황이 오지않았나 조심스럽게 추측해본다.

웹 프론트엔드 도구들

그러면 아까 사진에 보여드린 수많은 앱 들이 도대체 무슨역할을 하나?

그리고 그것이 반드시 필요한가에 대해서도 설명을 드릴까 한다.

상당히 지루하고 딱딱한 내용이 될 것 같아 많은 링크와 사진을 첨부했다.

   1. npm, bower, yoman, yarn

이 4가지 서비스는 Pakcage Manager(패키지 매니저)라고 부르는 서비스다.

(yoman은 정확히 말하면 스캐폴딩(Scaffolding - 실제 작업을 하기 전 철골을 덧대듯이 작업에 필요한 최소한에 구조를 만들어주는 단계)만 해주는 서비스.)

쉽게 풀어보자면 프로젝트에 사용할 라이브러리를 직접 찾아 해당 파일을 원격지에서 다운받아 로컬 파일에 옮기지 않아도, 간단한 명령어로 추가/수정/삭제를 지원하고 의존성(Dependency)을 관리해주는 서비스들을 의미한다.

또한 라이브러리 배포와 호스팅/빌드/테스트 스크립트 정의도 가능하다.

      2. Typescript, Flow

타입스크립트는 자바스크립트에서 발생할 수 있는 문제(타입 검증)를 해결해주는 동시에 ECMA6의 스펙을 포함하여 지원하고 있으며 Microsoft와 Google이 협력하여 개발하고 있는 언어이다. Typescript를 통해 개발을 진행하게되면 런타임 단계에서 발생할 수 있는 오류를 미연에 방지할 수 있고 OOP 지향한 개발과 Dependency Injection(DI)등의 패턴을 구현할 수 있게 된다. React 프로젝트의 Flow또한 타입 검증을 지원해준다.

      3. Reactive Programming

과거에는 웹 페이지 이동 (빈 화면에서 로딩이 걸리고 새로운 페이지가 보여지는) 없이 데이터를 업데이트 하는 사이트는 드물었지만 지금은 웬만한 서비스에서 이 기술을 적용하고 있다. 이러한 비동기 통신은 콜백함수를 통해 전달이 되어야 했으며 이 때문에 콜백지옥이 발생하기도 했다. RX(ReactiveX) 프로젝트는 이러한 문제를 해결해주며, 옵저버 패턴을 제공하여 서로다른 컨텍스트에 데이터를 동시적으로 제공해줄 수 있다.  Redux, Flux 서비스는 이러한 데이터를 효율적으로 대상에게 전달할 수 있다. 참고로 AngularJS 2는 RxJS를 포함 할 수 있다.

     4. grunt, gulp, webpack

여러분이 만약 반복되는 작업을 조금이라도 재활용하여 효율적인 프로그래밍을 원했다면 CSS의 작성이 굉장히 피곤하게 느껴졌을 수 있다, LESS와 SASS, Stylus와 같은 기술은 이러한 반복되는 작업을 없애주고 더불어 색상 코드를 특정 % (밝게, 어둡게)와 같은 편의 함수를 제공한다. 다만 결국 브라우저는 CSS 문서만을 인식하기 때문에 .less .sass와 같은 확장자는 빌드단계에서 변경이 이루어져야 한다, 그 밖에도 빌드 단계에서 진행되야 하는 작업들 (ECMA6 파일을 ECMA5 파일로 변경, 문서 최적화, 코드 테스트, 카피라이팅 삽입, 문서 문법 검증, 번들링 등)을 도와주는 도구가 grunt, gulp, webpack과 같은 도구이며 이는 다시 npm등의 패키지 매니저 도구와 연동하여 사용하거나 IDE(통합 개발환경)에서 연동하여 빌드과정을 일관화 시킬 수 있다. 이렇게 되면 파편화 되있는 JS, CSS, HTML 문서를 하나로 합쳐주며 표준코딩을 지향하게 되며 하위 호환 여부 검토가 수월하고 예기치 못한 버그와 사이드이펙트를 미연에 방지 할 수 있게 된다.

     5. RequireJS 그리고 CommonJS와 AMD(Asynchronous Module Definition)

Node.js의 영향 중 하나라고 필자는 생각한다.

네이버 D2에서 작성한 글이 보기 좋아 링크를 공유한다.

웹 페이지에서 서비스를 개발할 때 여러 Javascript 라이브러리를 합쳐 하나의 완성된 서비스를 만든다. 이때 이 라이브러리를 하나의 모듈로 볼 때 그 모듈에 대한 표준이 없다는 것이다. 따라서 각각의 라이브러리들은 서로다른 라이브러리 제공방식을 사용하고 있고 이를 이용하는 개발자는 각각의 라이브러리마다 다른 방식의 사용법 (같은 라이브러리라도 버전마다 달라지기도 한다.)을 이용해야하고 또 이러한 부분은 굉장히 비효율적으로 이용된다. (케익 한조각을 먹기위해 케익 전체를 사야하는 상황)

이를 해결하기 위해 나온 모듈 제공 방식이 CommonJS와 AMD이다.

각각의 사용형태가 다른 모듈들을 제공하는 하나의 표준을 만들어 그것을 지향하면 라이브러리 추가와 확장이 훨씬 쉬워지며 이는 큰 프로젝트에서도 모듈의 관리가 용이하며 효율적이다. 하지만 이 방식을 사용해도 마찬가지로 브라우저에서는 지원하지 않기 때문에 (다만 ECMA6는 import 키워드를 제공한다.) 이를 번들링 하기 위한 systemjs, Jspm, Rollup.js, Webpack등의 서비스가 존재한다

      6. jasmin, chai, mocha

규모가 큰 프로젝트 일수록 소스관리가 중요하여 자칫 하나의 수정사항이 사이드이펙트(다른 비즈니스 로직에 직/간접적으로 영향이 가는 것)가 발생 할 수 있다.

이는 라이브서비스에 커다란 이슈이며 이를 해결하기 위해 QA와 테스트케이스가 존재한다. 다만 규모가 크고 지원하는 플랫폼이 넓으며 수많은 페이지와 버그가 발생하는 환경을 시연하기 어려운 요소가 발생되면 이러한 테스트는 사람이 직접하기 어렵고 특히 애자일 방법론을 사용하는 개발 환경에서는 이러한 과정이 거의 불가능에 가깝다. 결국 이를 해결하기 위해서는 자동화된 개발 테스트 환경이 필요하다.

프론트엔드 개발도 마찬가지로 유닛 테스트를 지원하는 서비스가 있다. 가상의 DOM Mock에 라이브러리의 모든 케이스를 테스트해보고 결과적으로 테스트의 결과를 확인할 수 있게 제공하여 서비스 배포이전에 모든 기능에 안전성을 검토 할 수 있다.

      7. istanbul, blanket, JSCoverage

이전에 말한 유닛테스트는 서비스 되고있는 소스코드의 얼마나 많은 부분을 테스트 해주는지에 대한 부분이 상당히 중요하다. (많은 부분이 자동화 테스트를 지원할 수록 서비스는 안정적이고 신뢰를 보장하기 때문) 하지만 얼마나 많은 부분의 소스코드에 테스트를 지원하는지 사람이 알기에는 어렵다고 볼 수 있다. 이 때문에 얼마나 많은 부분이 테스트가 되었는지, 다시말해 얼마나 코드가 커버(Cover)되었느냐는 커버리지(Coverage)라는 용어를 사용하여 지표를 결정한다. 유닛 테스트 도구와 연동하여 커버리지 도구를 사용하게 되면 커버리지 지표를 리포트로 제공받게 된다.

      8. JSDoc

JSDoc은 javascript 모듈에서 사용되는 각각의 클래스, 함수들에 대한 정의를 JSDoc에서 정의한 표준 주석양식에 맞춰 작성하게 되면 그에따른 자동화된 개발 래퍼런스 문서가 만들어지게 된다. 마크다운 문서로 래퍼런스 문서를 제공하여 gitbook 같은 호스팅 서비스에 등재하게 되면 하나의 인쇄물로서 출력도 가능하다. 이러한 방법은 개발자가 일일히 래퍼런스 문서를 만들지 않아도 래퍼런스 문서를 만들 수 있는 이점이 있으며 표준화된 주석 사용으로 협업 및 인수인계가 원할하게 된다. 사실 다른 Doc 툴도 있지만 해당 서비스가 가장 유력하다.

AngularJS 2에 대한 설명을 위한 포스팅이었으나, 최근들어 웹 프론트엔드 개발 동향이 많이 변하고 있어 그 부분을 중점적으로 정리해보았다.

다음시간에는 Angular 2와 Angular 1 그리고 ReactJS를 주제로 중점적으로 다뤄보는 시간을 가져보도록 하자. 아디오스!