API 응답 시간이 짧아지고 서버 사용률이 낮아지면 개발자는 성능이 개선됐다고 말할 수 있습니다. 하지만 그 변화만으로 전력 사용량이나 탄소 배출이 줄었다고 결론 내리기는 어렵습니다. 서버 종류, 데이터센터 전력원, 요청량, 저장·네트워크 비용, 측정 기간이 모두 결과에 영향을 줄 수 있기 때문입니다.GitHub와 Yale Program on Climate Change Communication은 2026년 9월 미국의 GitHub 사용자 1,039명을 대상으로 소프트웨어 효율과 기후 인식을 조사했다고 발표했습니다. 이는 자발적으로 응답한 플랫폼 사용자 표본이며 전체 개발자를 대표하는 확률 표본으로 일반화할 수 없습니다. 조사 결과가 보여 주는 것은 효율 측정에 관심이 있다는 응답과 도구 수요이지, 특정 ..

정적 분석 도구는 문제를 찾고, 자동 수정 기능은 수정 코드를 제안합니다. 여기에 AI가 들어오면 코드의 주변 맥락을 해석해 스캔 결과를 설명하거나 여러 파일의 수정안을 만들 수 있습니다. 편리해 보이는 만큼 “취약점이 해결됐다”는 표시를 곧바로 신뢰해도 되는지 구분할 필요가 있습니다.GitHub는 2026년 10월 15일 pull request용 AI Scan과 코드 스캔 경고의 agentic autofix를 일반 제공한다고 각각 알렸습니다. 일반 제공은 사용 가능 범위가 넓어졌다는 제품 상태를 뜻하지만 모든 계정·저장소에서 동일한 조건이라는 의미는 아닙니다. 이 글은 발표를 바탕으로 검토 절차를 제안하며, 직접 도구를 실행해 효과를 측정한 후기는 아닙니다. AI Scan 공지와 agentic auto..

OpenTelemetry를 처음 붙일 때 애플리케이션에서 로그·메트릭·트레이스를 원하는 백엔드로 바로 보내면 간단해 보입니다. 하지만 백엔드를 바꾸거나 샘플링·필터링을 조정할 때 애플리케이션을 다시 배포해야 합니다.혼자 운영하는 서비스에서도 Collector를 둘 가치가 있는지 판단하기 위해서는 멋진 다이어그램보다 데이터가 어디에서 사라질 수 있는지를 먼저 봐야 합니다. 이번 글에서는 최소 구성의 책임 경계를 정리합니다.세 신호는 서로 다른 질문에 답합니다트레이스는 한 요청이 어디를 지나갔는지 알려 주고, 메트릭은 시스템이 얼마나 바쁜지 보여 주며, 로그는 특정 사건의 맥락을 설명합니다. 셋을 모두 수집한다고 자동으로 장애 원인을 찾을 수 있는 것은 아닙니다.저는 알림에는 메트릭을, 원인 추적에는 트레이..

느리다는 문의를 받고 로그를 열었는데 아무것도 못 찾은 적이 있습니다. 로그에는 요청이 들어왔다는 줄과 응답을 보냈다는 줄이 있었고, 그사이에 무슨 일이 있었는지는 비어 있었습니다. 데이터베이스가 느렸는지, 외부 API가 늦게 답했는지, 제 코드가 오래 걸렸는지 구분할 방법이 없었습니다.로그 도구를 바꾼다고 해결되는 문제가 아니었습니다. 필요한 것은 하나의 요청이 어디를 거쳐 얼마나 걸렸는지 이어 보는 방법이었고, 그게 분산 추적입니다. .NET 11에서는 ASP.NET Core가 OpenTelemetry 태그를 네이티브로 방출하는 방향으로 가고 있어서, 이 부분을 다시 정리해볼 만한 시점이 됐습니다. 아래 .NET 11 관련 내용은 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다.세 축은 각자 답하는 ..

깜빡하고 Branch를 안만들고 방금 작업을 그냥 Commit을 해버렸다면! (1) 먼저 새로운 Branch를 생성해 줍니다. git branch (2) 해당 Branch로 변경합니다. git checkout (3) 방금전 한 Commit 내용이 있는지 확인해 봅니다. 만약 Commit한 내용이 없다면 가장 최근 커밋을 가져옵니다. git cherrypick HEAD (4) 이제 다시 원래 브런치로 돌아옵니다. git checkout (5) 마지막 커밋을 삭제합니다. git reset --hard HEAD~1 (6) 새로운 브런치로 이동하여 작업을 시작합니다. git checkout

이번에 새롭게 합류하게된 회사에 프로젝트를 받아 실행하는 과정에서 다음과 같은 오류를 마주하게 되었습니다. CloudHospital.IdentityServer.STS.Identity 프로젝트의 IIS Express를 구성하려고 할 때 다음과 같은 오류가 발생했습니다. 파일 이름: redirection.config 오류 : 구성파일을 읽을 수 없습니다. 이와 관련된 문제해결을 위해 IIS Express를 검색하면, 대부분 환경설정 파일을 삭제하라고 나오는데, 프로젝트 실행시 프로필 지정을 잘못해도 위와 같은 오류가 발생할 수 있습니다. 물론 정확히 말해서, 기본값으로 설정된 IIS Express에 commandLineArgs 값 때문에 발생한 오류로 유추되기 때문에, 프로필 지정을 잘못했다고 나온 오류는 ..

Gradle 기본셋팅 (1) C:\Gradle 폴더를 만든다. (2) https://gradle.org/releases/ 에서 바이너리 파일을 다운로드 한다. (3) 다운로드한 파일을 C:\Gradle 폴더로 복사한 후 압축을 푼다. (4) 압축이 풀린 경로내 bin 폴더를 환경변수에 추가한다. 예) C:\Gradle\gradle-{Version}\bin (5) cmd 창을 열어 gradle -v 명령어로 설치여부를 확인한다.

1. cmd 명령으로 명령창을 실행시킵니다. 2. netstat -ano | findstr :80 과 같이 원하는 포트를 findstr 다음에 입력합니다. 3. 표시된 내용에 제일 끝부분이 PID 입니다. 4. 해당 PID를 tasklist /FI "PID eq {해당 PIC}" 를 실행합니다. 5. 해당 프로그램이 뭔지 이미지 이름 란에 표시됩니다.

소스코드가 수정되고 나서 도커에 재배포하는 순서를 확인해 보자. 먼저 ps 명령어로 현재 동작중인 도커를 확인해 준다. docker ps 이제 맨앞에 있는 컨테이너 id를 확인했으니, 다음 명령으로 중지시켜 보자. docker stop 정상적으로 종료되면 하단에 container-id가 한번더 출력된다. 물론 docker desktop에서도 가능하며, 상태도 확인할 수 있다. 이제 rm 명령어로 기존 소스코드로 배포된 내용의 컨테이너를 먼저 삭제해준다. docker rm -f node:18 또는 Docker Desktop에서 휴지통 아이콘을 눌러 삭제할 수 있다. 마찬가지로 소스코드가 배포된 image를 삭제해 준다. docker rmi -f node:18 삭제가 되었다면 도커를 다시 빌드해 주자. do..

먼저 프로젝트 루트에 Dockerfile 이란 파일을 만들어주자. (사실 파일이름은 아무렇게나 해도 상관없다.) 그런 다음 다음에 오는 내용을 작성해 주자. FROM node:18 WORKDIR /usr/src/app COPY package*.json ./ RUN npm install COPY . . RUN npm run build EXPOSE 3000 CMD [ "npm", "start" ] From은 사용할 이미지다. node:18 이미지 사용을 지정했다. 이미지 내에서 사용할 작업 폴더는 WORKDIR로 지정한다. COPY 명령을 통해 먼저 package.json 과 package-lock.json을 WORKDIR로 복사한다. 다음에 RUN 명령으로 npm install 명령어가 실행된다. 이제 C..