코드를 넘어서 생태계로 — 오픈소스가 만든 변화, 다시 풀어보기이 시리즈를 따라오면서 우리는 꽤 서로 다른 이야기들을 지나왔다. 어떤 것은 대학생의 프로젝트였고, 어떤 것은 기업의 전략이었으며, 또 어떤 것은 필요에 의해 만들어진 도구였다. 처음에는 각각 따로 떨어진 사건처럼 보였을 것이다.그런데 이걸 한 번에 이어서 보면 이상한 느낌이 든다. 이건 단순히 기술이 발전한 이야기가 아니라, 소프트웨어가 만들어지는 방식 자체가 바뀌고 있었다는 신호처럼 보이기 시작한다.그리고 이 지점부터는 질문이 조금 달라진다. “왜 오픈소스가 등장했을까?”가 아니라, “왜 이 방식이 계속 살아남고 확장됐을까?”라는 쪽이 더 중요해진다.우연처럼 보이지만, 반복되는 구조돌이켜보면 시작은 굉장히 소박했다. Linux는 거창한 선..
플랫폼 이전의 모바일 — 완성된 제품의 세계스마트폰 이전의 모바일 세계를 지금의 기준으로 이해하려고 하면 항상 어긋난다. 우리는 이미 “플랫폼”이라는 개념에 익숙해져 있기 때문이다. 하지만 그 시기의 모바일은 플랫폼이 아니라 완성된 제품이었다. 사용자는 기기를 구매하는 순간 이미 기능의 대부분을 함께 구매한 상태였고, 그 이후에 할 수 있는 일은 제한적이었다. 기능은 추가되는 것이 아니라 제공되는 것이었고, 소프트웨어는 확장되는 것이 아니라 포함된 것이었다.이 구조는 자연스럽게 생태계의 성장을 막는다. 개발자는 특정 기기와 특정 OS에 묶인다. 동일한 서비스를 여러 환경에 배포하려면 각기 다른 방식으로 다시 만들어야 한다. 결과적으로 모바일 소프트웨어는 빠르게 진화하지 못하고, 제조사의 의사결정 속도에 ..
검증은 끝나는 것이 아니라, 멈추는 것이다배포가 끝난 직후의 장면은 항상 비슷하다. 팀 채널에는 에러율 그래프가 올라오고, 몇 시간 전까지 반복되던 스파이크가 눈에 띄게 줄어든 것이 확인된다. 담당자는 그 그래프를 근거로 안정화되었다고 말하고, 다른 사람들도 같은 구간을 확대해서 보며 변화가 맞다는 것을 확인한다. 그 순간, “이 정도면 괜찮지 않냐”는 말이 나온다. 이 말은 질문처럼 들리지만 실제로는 결정에 가깝다. 더 이상 어떤 케이스가 사라졌는지 확인하지 않는다. 사라진 에러가 해결된 것인지, 아니면 다른 경로로 이동한 것인지도 따지지 않는다. 확인이 생략된 것이 아니라, 확인하지 않아도 된다는 판단이 내려진다.이 판단은 빠르게 다음 단계로 이어진다. 수정 사항은 “효과 있음”으로 기록되고, 남아 ..
AI가 개발자의 생산성을 바꾸고 있다는 사실은 이제 의심하기 어렵다. 코드 자동 완성은 기본이 되었고, 자연어로 요구사항을 설명하면 동작하는 코드가 생성되는 경험도 점점 익숙해지고 있다. 일부 개발자는 기존보다 몇 배 빠르게 작업할 수 있다고 말하고, 실제로 간단한 서비스나 도구는 이전보다 훨씬 짧은 시간 안에 만들어진다. 이 변화만 놓고 보면 우리는 이미 소프트웨어 생산이 폭발적으로 증가한 시대에 들어온 것처럼 보인다. 그러나 한 발짝 떨어져 보면 이상한 점이 하나 드러난다. 그렇게 많은 코드가 만들어지고 있다면, 왜 우리는 그 결과를 쉽게 발견하지 못하는가. 새로운 라이브러리나 서비스가 눈에 띄게 늘어난 느낌은 없고, 우리가 사용하는 생태계 역시 크게 달라진 것처럼 보이지 않는다. 이 지점에서 질문은..
문법을 바꾸는가, 기능을 채우는가JavaScript 생태계를 처음 깊게 파고들 때 가장 많이 헷갈리는 개념이 바로 Babel과 polyfill이다. 둘 다 “구형 환경에서 최신 JavaScript를 동작하게 만든다”는 공통점을 갖고 있지만, 실제로 하는 일은 완전히 다르다. 이 차이를 이해하지 못하면 번들 사이즈가 불필요하게 커지거나, 예상치 못한 런타임 오류를 만나게 된다.Babel — “코드를 바꿔서 맞춘다”Babel은 컴파일러다. 정확히 말하면 최신 JavaScript 문법을 오래된 환경에서도 실행 가능하도록 다른 문법으로 변환(transpile) 한다.예를 들어 이런 코드가 있다고 보자.const add = (a, b) => a + b;구형 브라우저는 화살표 함수를 이해하지 못한다. Babel은 ..
1. 정의 / 결론nohup은 터미널 종료 시 전달되는 SIGHUP 신호를 무시하여 프로세스를 종료되지 않게 만드는 명령어다.2. 핵심 요약nohup은 터미널 종료와 프로세스를 분리한다.백그라운드 실행(&)과 결합해야 완전히 독립된다.출력은 기본적으로 nohup.out으로 리다이렉션된다.3. 왜 필요한가터미널에서 실행한 프로세스는 기본적으로 해당 세션에 종속된다. SSH로 접속한 환경에서 작업을 수행할 경우, 네트워크 단절이나 세션 종료 시 프로세스도 함께 종료된다.이 구조의 핵심 문제는 프로세스가 OS가 아니라 세션에 묶여 있다는 점이다. 즉, 사용자의 연결 상태가 프로세스 생존 여부를 결정한다.예를 들어 다음과 같은 상황이 발생한다.장시간 데이터 처리 작업 실행SSH 세션 종료작업 중단 및 결과 손실..
shebang은 스크립트 파일의 첫 줄에 작성하여 이 파일을 어떤 인터프리터로 실행할지 지정하는 선언문이다.직접 실행(./script.sh) 시 운영체제가 사용할 실행기를 결정하는 기준이 된다.인터프리터를 명시하지 않고도 실행 가능하게 만든다는 점이 핵심 차이다.핵심 요약#!는 실행 인터프리터 지정 메커니즘이다파일을 직접 실행할 때만 의미를 가진다 (./script.sh)/bin/bash는 고정 경로, /usr/bin/env는 환경 기반 탐색이다왜 필요한가스크립트 파일은 바이너리가 아니다.운영체제는 파일을 실행할 때, 이 파일을 직접 실행할 수 없다.따라서 누가 이 파일을 해석할지 결정해야 한다.문제는 실행 방식에 따라 이 결정이 달라진다는 점이다.bash script.sh이 경우는 이미 bash를 명시..
polyfill은 실행 환경에 없는 기능을 직접 추가해 기존 코드를 그대로 동작하게 만드는 방식이다.ponyfill은 실행 환경은 수정하지 않고 같은 기능을 별도 함수나 모듈로 제공하는 방식이다.차이는 기능 자체보다 환경을 바꿀지, 환경을 우회할지에 있다.1. 정의 / 결론polyfill은 브라우저나 런타임의 부족한 기능을 채워 표준 API처럼 보이게 만드는 코드다.ponyfill은 같은 기능을 제공하지만 전역 객체나 prototype을 수정하지 않는 대체 구현이다.2. 핵심 요약polyfill은 Array.prototype.includes 같은 기능을 환경에 주입한다.ponyfill은 includes(arr, value) 같은 별도 함수를 호출하게 만든다.polyfill은 기존 호출 형태 유지에 유리하..
- Total
- Today
- Yesterday
- 티스토리
- 로컬우선아키텍처
- 프론트엔드
- 도메인설계
- Flutter 앱 개발
- Readium개발기
- 트랜잭션 설계
- 웹디자인
- 온라인신원인증
- 다크모드
- 한국인터넷역사
- AI와인터넷
- 로컬 우선 아키텍처
- NanoClaw
- SQLite 앱 아키텍처
- Readium 개발기
- ChatGPTCodex
- css커스터마이징
- 인터넷문화
- CodexApp
- Windows개발
- 이벤트아키텍처
- 1인 개발
- 오픈소스
- 티스토리스킨
- Idempotent 처리
- 앱 도메인 설계
- WSL개발환경
- Google Play 출시
- 블로그디자인
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |