1. 웹 애플리케이션, WAS, 서버의 기본 구조

웹 서비스는 클라이언트(사용자)의 요청을 받아 처리하고 응답을 보내는 과정으로 이루어집니다. 이 과정에는 주로 클라이언트, 웹 서버(Web Server), WAS(Web Application Server), **데이터베이스(Database)**라는 핵심 구성 요소들이 참여합니다.

1.1. 클라이언트 (Client)

• 역할: 사용자가 서비스를 이용하는 접점으로, 웹 브라우저, 모바일 앱 등이 해당됩니다. 사용자의 요청을 웹 서버나 WAS로 보냅니다.

1.2. 웹 서버 (Web Server)

• 역할:
  • 정적 콘텐츠 제공: HTML, CSS, JavaScript, 이미지 파일 등 고정된(변하지 않는) 파일을 클라이언트에게 직접 전달합니다.
  • 동적 요청 위임: 클라이언트의 요청 중 서버에서 처리해야 할 동적인 콘텐츠(예: 로그인, 데이터 조회/수정 등)는 WAS(Web Application Server)에 전달합니다.
  • 로드 밸런싱: 여러 WAS에 요청을 효율적으로 분산하여 서버의 부하를 줄이고 안정성을 높이는 역할도 수행할 수 있습니다.
• 예시: Apache HTTP Server, Nginx 등

1.3. WAS (Web Application Server - 웹 애플리케이션 서버)

• 역할:
  • 동적 콘텐츠 처리 및 비즈니스 로직 실행: 웹 애플리케이션의 핵심 로직을 수행합니다. 데이터베이스 연동, 복잡한 계산, 사용자 인증, 세션 관리 등 동적인 처리를 담당합니다.
  • 웹 서버 기능 포함: WAS 자체적으로도 정적 콘텐츠를 제공하는 기능이 있지만, 대규모 서비스에서는 웹 서버와 WAS를 분리하여 효율성을 높입니다.
  • 미들웨어: 클라이언트와 데이터베이스 사이에서 애플리케이션의 핵심 기능을 수행하는 중간 소프트웨어입니다.
• 예시: Apache Tomcat, JBoss(WildFly), WebLogic, WebSphere 등 (자바 기반 웹 애플리케이션에서는 '서블릿 컨테이너' 역할을 합니다.)

1.4. 데이터베이스 (Database)

• 역할: 웹 애플리케이션에서 필요한 데이터를 저장하고 관리합니다.
• 예시: MySQL, PostgreSQL, Oracle, MongoDB 등

일반적인 요청 처리 흐름:

1. 클라이언트가 웹 서버로 요청을 보냅니다.
2. 웹 서버는 요청이 정적 콘텐츠인지 동적 콘텐츠인지 판단합니다.
   • 정적 콘텐츠인 경우 웹 서버가 직접 클라이언트에게 응답합니다.
   • 동적 콘텐츠인 경우 요청을 WAS로 전달합니다.
3. WAS는 비즈니스 로직을 수행하고, 필요에 따라 데이터베이스와 연동하여 데이터를 처리합니다.
4. WAS는 처리 결과를 웹 서버로 다시 전달합니다.
5. 웹 서버는 WAS로부터 받은 응답을 최종적으로 클라이언트에게 보냅니다.

2. Spring Boot 구조일 때의 차이점 (표로 설명)

전통적인 웹 애플리케이션 구조와 Spring Boot 기반 웹 애플리케이션 구조는 WAS의 존재 방식과 배포 방식에서 가장 큰 차이를 보입니다.

결론적으로, Spring Boot는 내장 WAS를 통해 애플리케이션을 독립적인 실행 파일로 만들어, 개발과 배포 과정을 획기적으로 간소화하고 생산성을 높여줍니다. 이 점이 전통적인 웹 애플리케이션 구조와의 가장 큰 차이점입니다.

https://blog.alexewerlof.com/p/when-a-team-is-too-big

• 전문가 중심의 대형 팀은 내부 의존성, 전달 오류, 병목, 책임 분산 등으로 인해 생산성과 협업 효율이 급격히 저하됨
• 일일 스탠드업 미팅에서 대부분의 내용이 불필요하거나 지루해지는 등, 팀 규모 증가와 전문화가 소통 단절과 무관심을 불러일으킴
• 기술별(프론트/백엔드) 분리, 임시 피처팀, 외부 컨설턴트 활용 등 여러 실험이 있었으나, 결국 범용적 역할(제너럴리스트)로 전환이 가장 실질적 효과를 냄
• Mob프로그래밍 등 집단 협업은 지식 공유와 자기주도성, 책임감, 동기 부여를 촉진하며, 단일 분야 고집보다 결과 중심의 협업과 성장에 유리함
• 단, 범용화의 부작용(전문성 저하, 번아웃 위험)도 존재하며, 지속적인 실험과 문화적 개선이 필수적임

팀이 너무 클 때의 문제

• 14명 규모의 대형 팀에서 시작된 문제: 스탠드업에서 대부분의 대화가 불필요하며, 업무 전달 누락과 비공식 작업 발생 빈번
• 비동기 스탠드업(Slack 등) 으로 전환해도 핵심적인 대화와 협업 기회가 사라지고 단순 보고서로 변질

다양한 분할/운영 실험

• 기술별(Task Force) 분리: 프론트엔드/백엔드로 나눴으나, 즉시 상호 의존성 문제와 추가 스탠드업 참여로 시간 증가
• 임시 피처팀: 특정 기능 구현에 따라 인력 임시 재배치, 유지보수/자원 관리 이슈 발생
• 외부 컨설턴트 투입: 이미 팀이 큰데도 비효율, 상위 경영진의 자원 활용 압박

최종적으로 효과적이었던 해법

• 스페셜리스트 대신 제너럴리스트(범용가) 모델 도입
  • 프론트엔드, 백엔드, QA, DevOps 등 역할 분리 없이 한 목표/제품을 중심으로 전체 스킬셋을 나눠 가짐
  • 지식 공유, 책임 분산 감소, 병목 해소, 더 빠른 전달/고품질 실현
  • Mob 프로그래밍 등 집단 협업으로 소통/자율성/소유권 강화

왜 제너럴리스트가 효과적이었나

• 공통 맥락과 목적: 새로운 분야라도 동일 제품/목표를 기준으로 학습 곡선 완화
• 한정된 필요: 특정 도구(CI/CD 등)만 익혀도 충분, 깊은 전문성보다 생산성·유지보수성을 중시
• 동기 부여 3요소(자율성, 숙련, 목적) 를 모두 충족, 팀의 주인의식과 성장 지원
• Egalitarian 문화: 평등한 접근권, 자율적 지식 습득, 권한과 책임 분산, 집단 학습
• 책임의 3요소(지식, 권한, 책임) 가 명확, 소유권 기반의 빠르고 높은 품질의 결과 도출

부작용 및 한계

• 전문가의 이탈: 범용화가 모든 사람에게 맞지 않음, 특정 인력의 번아웃·리소스 과열 발생
• 전문성의 깊이 부족: 다양한 스택을 얕게 다루는 만큼, 한 분야의 깊은 숙련은 저해될 수 있음

결론 및 교훈

• 일률적 해법은 없으며, 실험과 개선의 문화가 더 중요
• 스페셜리스트 모델의 단점(병목, 소통 단절, 페이크 워크, 맥락 단절)을 제너럴리스트와 집단 협업으로 해소 가능
• 궁극적으로는 목표, 인력, 예산, 제품 특성에 따라 최적화된 모델이 달라질 수 있음
• 핵심은 열린 실험, 피드백, 지속적 개선의 문화

Android에서 Localhost를 이용한 은밀한 웹-앱 트래킹 기법 공개 (localmess.github.io)

https://localmess.github.io/

• Meta(페이스북), Yandex 등 주요 앱이 Android에서 로컬 포트(127.0.0.1)를 사용해 웹 브라우저와 네이티브 앱 간 식별자·쿠키를 비밀리에 공유한 사실이 공개됨
• 웹사이트에 심어진 Facebook Pixel, Yandex Metrica 스크립트가 Android 브라우저에서 네이티브 앱(페이스북, 인스타그램, Yandex 계열 앱)으로 브라우징 세션과 식별자를 직접 전달, 사용자 식별 및 탈익명화가 가능해짐
• 이 방식은 쿠키 삭제, 시크릿 모드, 권한 설정, 광고ID 리셋 등 기존 프라이버시 보호책을 모두 우회하며, 악성 앱이 포트만 맞춰 듣고 있으면 브라우저 방문 이력 수집도 가능함
• 2025년 6월 3일 공개 이후 Facebook 측은 해당 코드를 대부분 제거했으나, 해당 기법이 수년간 전 세계 수억대 안드로이드 기기에서 이용됨. Yandex는 2017년부터 유사한 방식을 지속적으로 사용 중임
• 크롬, 파이어폭스, 브레이브 등 주요 브라우저들은 긴급 차단 조치를 도입했지만, 플랫폼 구조적 한계로 완전한 근본 대책은 미흡, Android IPC와 로컬 네트워크 보안 강화 필요성이 강조됨

https://www.fileformat.info/info/unicode/char/1f389/index.htm

[JQUERY] jquery 이용해서 페이지 내의 a 태그의 href 를 가져와라

$(document).ready(function() {
    // 모든 <a> 태그를 선택합니다.
    $('a').each(function() {
        // 현재 <a> 태그의 href 속성값을 가져옵니다.
        var hrefValue = $(this).attr('href');

        // 가져온 href 값을 콘솔에 출력하거나 다른 방식으로 활용할 수 있습니다.
        console.log("링크 URL: " + hrefValue);

        // 예시: 페이지에 표시
        $('body').append('<p>Link found: ' + hrefValue + '</p>');
    });
});

[python] List of running process using python

import psutil

def listProcesses():
    for proc in psutil.process_iter():
        try:
            pinfo = proc.as_dict(attrs=['pid', 'name'])
        except psutil.NoSuchProcess:
            pass
        else:
            print(pinfo)