자바 리플렉션을 검색해보면 "객체가 원본이고, JVM 메모리에 로드된 클래스 정보가 거울에 비친 상(reflection)이다" 같은 비유를 자주 보게 됩니다.

틀린 설명은 아닙니다. 다만 저는 이걸로 "그래서 그게 왜 필요한데?"라는 의문이 풀리지 않았습니다. 비유는 리플렉션이 무엇인지는 알려주지만, 왜 존재하는지는 알려주지 않으니까요.

그래서 이해 자체를 목표로, 제 방식대로 다시 정리해보기로 했습니다.

한 줄 정의

컴파일 시점에 어떤 클래스인지 몰라도, 런타임에 클래스·필드·메서드를 알아내고 조작하는 기능.

핵심은 "컴파일 시점에 몰라도"입니다. 이 조건이 왜 중요한지가 이 글의 전부입니다.

컴파일 타임에 아는 코드 vs 모르는 코드

우리가 평소에 쓰는 코드입니다.

UserRepository repo = new UserRepository();
repo.findName();

컴파일러는 이 시점에 "이건 UserRepository다"라는 사실을 이미 알고 있습니다. 그래서 findName()이 실제로 존재하는지도 컴파일 시점에 검증됩니다. 없는 메서드를 호출하면 컴파일 자체가 되지 않습니다.

같은 일을 리플렉션으로 하면 이렇게 됩니다.

Class<?> clazz = Class.forName(className);
Object obj = clazz.getDeclaredConstructor().newInstance();
Method m = clazz.getMethod("findName");
m.invoke(obj);

훨씬 장황하고, 타입 안전성도 없고, 오타가 나도 컴파일러가 잡아주지 않습니다.

여기서 눈여겨볼 건 className이 String이라는 점입니다. 클래스 이름이 문자열이라는 건, 그 값을 설정 파일에서 읽어오든 스캔 결과에서 가져오든 상관없다는 뜻입니다. 즉 코드를 작성하는 시점에 그 클래스가 세상에 존재하지 않아도 된다는 겁니다.

이렇게 위험한 기능을 대체 왜 쓰는걸까요?

익숙한 Spring 코드를 봅시다.

@Component
public class UserRepository {
    public String findName() { return "hello"; }
}

@Component
public class UserService {
    @Autowired
    private UserRepository userRepository;   // ← 여기를 꽂아줘야 함

    public void print() {
        System.out.println(userRepository.findName());
    }
}

만약 리플렉션이 없다면 이 코드는 어떻게 될까요?

컴파일은 됩니다. @Component도 @Autowired도 어노테이션일 뿐이라 컴파일러는 아무 불평도 하지 않습니다. 실행도 됩니다. 대신 이렇게 터집니다.

NullPointerException: Cannot invoke "UserRepository.findName()"
                      because "this.userRepository" is null

당연합니다. 우리는 userRepository에 값을 넣는 코드를 어디에도 쓴 적이 없으니까요. new UserRepository()를 호출한 줄이 우리 프로젝트에 단 한 줄도 없습니다. @Autowired라는 글자만 적어놨을 뿐입니다.

그런데 이 코드를 Spring 위에서 돌리면 콘솔에 "hello"가 찍힙니다.

어떻게 가능한걸까?

@Autowired는 마법이 걸린 키워드가 아닙니다. 컴파일 결과물에 남는 메타데이터 딱지입니다. 딱지는 그 자체로 아무 일도 하지 않습니다. 누군가 읽어야 의미가 생깁니다.

그 "누군가"가 Spring이고, 읽는 도구가 리플렉션입니다.

애플리케이션이 뜰 때 Spring은 이 일을 순서대로 합니다.

1. 클래스패스를 뒤져서 @Component가 붙은 클래스를 찾는다 → UserRepository, UserService 발견
2. 찾은 클래스를 리플렉션으로 생성한다 → clazz.getDeclaredConstructor().newInstance()
3. 각 객체의 필드를 훑어서 @Autowired가 붙은 걸 찾는다 → UserService.userRepository 발견
4. 필드 타입(UserRepository)에 맞는 객체를 찾아서 꽂는다

코드로 줄여보면 이 정도입니다. 먼저 1~2번, @Component를 읽고 객체를 만드는 부분입니다.

Map<Class<?>, Object> container = new HashMap<>();

for (Class<?> clazz : classes) {                       // 클래스패스에서 긁어온 목록
    if (clazz.isAnnotationPresent(Component.class)) {  // ← @Component 딱지 확인
        Object bean = clazz.getDeclaredConstructor().newInstance();
        container.put(clazz, bean);                    // 타입 → 객체로 보관
    }
}

이 시점에 UserRepository와 UserService 객체가 만들어져 컨테이너에 들어갑니다. 다만 UserService의 필드는 아직 null입니다.

이어서 3~4번, @Autowired를 읽고 값을 꽂는 부분입니다.

for (Object bean : container.values()) {
    for (Field field : bean.getClass().getDeclaredFields()) {
        if (field.isAnnotationPresent(Autowired.class)) {    // ← @Autowired 딱지 확인
            field.set(bean, container.get(field.getType())); // ← 타입으로 찾아서 꽂는다
        }
    }
}

이제 꺼내 쓰면 됩니다.

UserService service = (UserService) container.get(UserService.class);
service.print();   // "hello"

생성과 주입이 두 단계로 나뉜 이유가 있습니다. UserService에 값을 꽂으려면 UserRepository 객체가 이미 만들어져 있어야 하기 때문입니다. 그래서 일단 전부 만들어놓고, 그다음에 서로 연결합니다. Spring도 같은 순서로 움직입니다.

우리가 쓰지 않은 new UserRepository()를, 우리가 붙여둔 딱지를 보고 Spring이 대신 실행해준 겁니다.

여기서 어노테이션의 정체가 정리됩니다.

어노테이션 = 표식, 리플렉션 = 그 표식을 읽고 실제로 뭔가 하는 손

@Transactional, @Entity, @GetMapping 전부 같은 구조입니다. 우리가 표시를 남기고, 프레임워크가 리플렉션으로 그 표시를 찾아 동작합니다.

왜 굳이 런타임에?

한 가지 의문이 남습니다. 왜 굳이 런타임에 클래스패스를 뒤져야 할까요? 컴파일 타임에 하면 타입 안전성도 챙기고 오타로 인한 오류도 막을 수 있을 텐데요. Spring 소스 어딘가에 그냥 이렇게 적어두면 안 되는 걸까요?

UserService service = new UserService();   // spring-context 안에?

결론부터 말함녀 불가능합니다. 이 코드가 컴파일되려면 컴파일러가 UserService 타입을 알아야 하는데, spring-context jar가 빌드되던 순간 우리 클래스는 세상에 없었습니다. 프레임워크는 언제나 응용 코드보다 먼저 컴파일되니까요.

즉 Spring은 자기가 모르는 타입을 다뤄야 하는 처지입니다. 이름조차 모르는 클래스를 찾아내고, 생성자가 뭘 요구하는지 알아내고, 인스턴스를 만들어야 합니다. 컴파일 타임에 존재하지 않던 정보를 실행 시점에 알아내는 것 — 이게 정확히 리플렉션이 하는 일입니다.

그래서 이 거래는 남는 장사일까

리플렉션은 공짜가 아닙니다. 정적 타입 시스템의 안전망을 반납하고 유연성을 사는 거래입니다.

반납하는 쪽은 꽤 구체적입니다. getMethod("getNmae") 같은 오타를 컴파일러는 잡아주지 않습니다. IDE의 "사용처 찾기"에도 걸리지 않으니, 아무도 안 쓰는 줄 알고 지운 메서드가 운영에서 사고를 냅니다. 필드 이름을 리팩터링해도 문자열은 따라오지 않습니다. 컴파일러가 지켜주던 것들이 전부 실행 시점으로 미뤄지는 겁니다.

그런데도 프레임워크가 이 거래를 하는 이유는, 프레임워크에겐 그 유연성이 곧 존재 이유이기 때문입니다. 모르는 타입을 다루지 못하는 프레임워크는 프레임워크가 아닙니다. 반대로 우리가 짜는 애플리케이션 코드에서는 대부분 손해입니다. 잃는 안전성에 비해 얻는 게 없으니까요. 서비스 코드 한복판에 getDeclaredField가 등장한다면, 대개는 설계를 다시 볼 신호입니다.

마무리

처음의 비유로 돌아가봅시다. 객체가 원본이고, 클래스 정보가 거울에 비친 상이라는 설명.

이제 보면 그 비유는 틀린 게 아니라 다른 질문에 답하고 있었습니다. "리플렉션이 무엇을 보여주는가"를 설명할 뿐, "그걸 왜 봐야 하는가"는 말해주지 않았던 거죠.

우리가 필요했던 답은 이겁니다. 컴파일러가 모르는 것을 다루기 위해서.

우리 코드는 프레임워크보다 나중에 태어납니다. 먼저 컴파일된 쪽은 나중에 올 클래스의 이름을 적어둘 수 없습니다. 그래서 이름 대신 약속을 남겨둡니다. @Component를 붙여두면 찾아주겠다, @Autowired를 붙여두면 꽂아주겠다는 약속. 그 약속을 실행 시점에 이행하는 도구가 리플렉션입니다.

최근에 기존 외부 CS 서비스를 대체하기 위해 AI 기반 사내 CS 응대 자동화 봇을 직접 구축하는 프로젝트를 진행했습니다. 고객이 채팅을 보내면 Claude가 상담 초안을 생성하고, 상담원이 승인하면 고객에게 발송되는 구조입니다. 처음으로 프론트엔드까지 직접 맡아 전체 서비스를 구축한 프로젝트였습니다.

그런데 실제 커밋 로그는 60개 남짓이지만, 그 안의 코드를 한 줄씩 읽고 "이게 맞다"고 판단하며 넘긴 비율은 솔직히 절반도 되지 않습니다. 웹소켓 재연결 로직이나 훅의 의존성 배열, 백오프 계산 같은 것들은 코드를 완전히 이해했다기보다 실제로 동작하는 것을 확인하고 넘어간 경우도 많았습니다.

이것이 요즘 코드를 작성하는 방식의 실제 모습이라고 생각합니다. AI를 활용하면 구현 속도는 크게 빨라지지만, 그만큼 작성된 코드의 모든 동작을 완전히 이해하는 것은 더 어려워지는 게 현실입니다.

그렇다면 AI를 사용하는 것을 지양해야 할까요?

저는 절대 그렇게 생각하지 않습니다. 이미 AI는 개발 과정에서 빼놓기 어려운 도구가 되었고, 굳이 그 흐름을 거스를 이유도 없습니다. 저 또한 AI가 없었다면 백엔드뿐 아니라 프론트엔드까지 포함한 전체 서비스를 기한 내에 혼자 구축한다는 것은 시도조차 하지 못했을 것입니다. 아마 아직도 개발 중이었을 것이고, CS 응대 역시 여전히 휴먼 리소스에 의존하고 있었겠죠.

이처럼 현재 소프트웨어 엔지니어링에서 AI가 가져다주는 생산성은 AI가 가진 단점들을 상쇄시킬 만큼 압도적입니다. 그렇기에 결국 중요한 것은 AI를 사용하지 않는 것이 아니라, AI가 만들어낸 코드를 어떻게 다룰 것인가 에 존재합니다.

그래서 태도를 바꿨습니다. AI가 만들어준 코드를 모두 이해하려고 하기보다, 이해하지 못한 코드가 포함되어 있더라도 실제로 문제가 발생했을 때 확실하게 검증할 수 있는 방법을 만드는 것에 집중하기로 했습니다.

1. 무엇을 검증할 것인가 — 코드가 아니라 동작

소프트웨어가 제대로 동작하는지 판단해야 할 때, 가장 큰 확신을 주는 것이 바로 E2E 테스트 입니다. — Ham Vocke, "The Practical Test Pyramid", martinfowler.com (2018)

코드를 읽는 것만으로는 판단할 수 없는 것들이 있습니다. 아래 코드는 실제로 저희 프로젝트에 있던 웹소켓 재연결 부분입니다.

// 지터가 없으면 서버가 살아날 때 모든 클라이언트가 같은 순간에 몰린다
const wait = Math.min(1000 * 2 ** attempt++, BACKOFF_MAX_MS) * (0.8 + Math.random() * 0.4);

솔직히 말씀드리면 이 줄은 처음에 읽고도 무슨 말인지 몰랐습니다. 지터가 무엇인지, 백오프가 무엇인지도 몰랐습니다. 그러나 이 코드를 이해하기 위해 관련 개념을 찾아보는 과정에서 생각보다 많은 것을 배웠는데, 이 이야기는 글의 마지막에서 다시 하겠습니다.

의도는 주석 덕분에 짐작할 수 있었지만, 코드만 봐서는 그게 실제로 지켜지는지는 읽어서 알 수 없었습니다. 또 다른 예시로는 다음과 같은 것들이 있습니다.

• 재연결이 실제로 몇 초 뒤에 일어나는가
• 브라우저 탭이 백그라운드에 있다가 돌아왔을 때, 소켓이 정상적으로 복구되는가

이건 코드가 아니라 브라우저가 대답할 문제입니다.

못 읽은 코드가 절반인 상태에서 "이게 맞다"고 말하려면, 그 근거는 코드가 아니라 실제 동작에서 나와야 했습니다.

즉, 유닛 테스트를 먼저 작성하기보다 E2E 테스트에 우선순위를 두었습니다. 제가 확인하고 싶었던 것은 개별 함수가 예상대로 동작하는지가 아니라, 여러 시스템이 연결된 상태에서도 서비스가 브라우저 상에서 제대로 동작하는지였기 때문입니다. 개별 함수를 아무리 꼼꼼히 검증해도, 시스템 간 연결 지점에서 생기는 문제는 유닛 테스트만으로 잡아내기 어렵습니다.

테스트를 진행하기 위해 가장 먼저 한 일은 검증 범위부터 좁히는 것이었습니다. 실제 위험 구간은 아래 네 지점이 맞물리는 곳에 있습니다.

Lambda ↔ DynamoDB ↔ API Gateway WebSocket ↔ React

위의 네 가지 컴포넌트가 정상적으로 맞물려 동작하는지는 다음과 같은 질문 하나로 검증할 수 있었습니다.

고객이 보낸 메시지가 빠짐없이 상담원 화면에 순서대로 뜨는가?

검증할 것은 그 외에도 많았지만, 첫 번째 E2E 테스트는 이 질문 하나면 충분했습니다.

2. 어떻게 검증할 것인가 — 실제 사용자 흐름을 재현하기

검증 대상이 브라우저에서 발생하는 실제 동작까지 포함하고 있었기 때문에 Playwright를 사용했습니다.

API를 직접 호출해서 응답이 정상인지 확인하는 것만으로는 부족했습니다. 제가 확인하고 싶은 것은 고객의 메시지가 서버를 거쳐 WebSocket으로 전달되고, 최종적으로 상담원 화면에 표시되는 전체 흐름이었기 때문입니다.

테스트의 시작점은 개별 함수가 아니라 사용자의 행동입니다. 검증해야 하는 흐름 자체는 단순했습니다.

고객이 메시지를 보내고, 서버에서 이를 처리한 뒤, WebSocket을 통해 상담원 화면에 전달합니다. 그리고 마지막으로 실제 브라우저에서 해당 메시지가 화면에 나타났는지를 확인합니다.

이렇게 하면 함수 하나가 정상적으로 실행됐는지만 확인하는 것이 아니라, Lambda ↔ DynamoDB ↔ API Gateway WebSocket ↔ React까지 여러 컴포넌트가 연결된 상태에서 사용자가 기대하는 결과가 실제로 발생했는지를 검증할 수 있습니다.

여기서 중요한 원칙이 하나 있습니다.

** 테스트는 내부 구현을 몰라도 됩니다. 사용자가 보는 결과만 알면 됩니다. **

예를 들어 이런 것들은 테스트가 알 필요가 없습니다.

• 메시지를 전달하는 과정에서 내부적으로 어떤 함수를 호출하는가
• React에서 어떤 상태(state)를 업데이트하는가

테스트가 확인할 것은 하나뿐이었습니다.

고객이 보낸 메시지가 빠짐없이 상담원 화면에 순서대로 뜨는가?

검증 대상을 이렇게 사용자 행동과 결과로 제한했습니다.

그리고 실제로 테스트를 실행해보니, 코드만 읽었을 때는 보이지 않았던 문제들이 하나씩 드러나기 시작했습니다.

3. 문제는 코드에 있지 않았습니다

첫 번째 E2E 테스트를 실행했습니다.

고객이 메시지를 여러 개 빠르게 보내자 처음에는 상담원 화면에 정상적으로 표시됐습니다.

그런데 페이지를 새로고침하자 결과가 달라졌습니다.

처음에는 프론트엔드에서 메시지 순서를 잘못 처리하고 있는 문제라고 생각했습니다. 그런데 새로고침 전후의 데이터를 비교해보니, 화면이 임의로 순서를 바꾸고 있는 것이 아니었습니다.

새로고침하면 서버에서 메시지를 다시 받아오고 있었고, 그때 전달되는 메시지 자체의 순서가 처음 화면과 달랐습니다.

원인을 따라가 보니 고객이 메시지를 보낸 순서와 서버가 메시지를 처리하는 순서가 달라질 수 있다는 것이 문제였습니다.

서버리스 환경에서는 여러 요청이 각각의 Lambda에서 병렬로 처리될 수 있습니다. 따라서 고객이 msg1 → msg2 → msg3 순서로 메시지를 보내더라도, 서버에서는 다른 순서로 처리될 수 있었던 것입니다.

결국 낙관적 UI에서는 클라이언트가 보낸 순서대로 보이지만, 새로고침하면 서버가 처리한 순서가 다시 나타나면서 같은 대화인데도 메시지 순서가 달라지는 문제가 발생한 것이었습니다.

코드를 읽는 것만으로는 쉽게 발견하기 어려운 문제였습니다. 실제 사용자처럼 메시지를 빠르게 여러 개 보내고 페이지를 새로고침해보면서 비로소 확인할 수 있었습니다.

4. 해결과 재검증

문제의 원인은 고객이 여러 메시지를 빠르게 보내면 서버에서 요청이 병렬로 처리될 수 있다는 것이었습니다.

그렇다면 클라이언트에서부터 메시지를 순차적으로 보내면 됩니다. 그래서 메시지 전송 큐를 도입했습니다.

여러 메시지를 빠르게 입력하더라도 서버에는 한 번에 하나씩 전송하고, 앞선 메시지의 처리가 끝난 뒤 다음 메시지를 전송하도록 변경했습니다.

msg1 → 처리 완료
          ↓
       msg2 → 처리 완료
                  ↓
               msg3 → 처리 완료

이제 고객이 msg1 → msg2 → msg3 순서로 메시지를 보내면 서버에서도 같은 순서로 처리할 수 있습니다.

수정 후 동일한 E2E 테스트를 다시 실행했습니다.

메시지를 빠르게 여러 개 보내고 페이지를 새로고침하는 상황까지 다시 재현했습니다. 이번에는 새로고침 이후에도 메시지가 처음과 동일한 순서로 표시됐습니다.

문제를 발견한 테스트를 그대로 다시 실행해 문제가 사라졌는지 확인하는 것.

제가 생각한 E2E 테스트의 가장 중요한 역할은 바로 이것이었습니다.

5. 검증만으로는 부족한 것

1장에서 인용했던 웹소켓 재연결 코드로 다시 돌아가 보겠습니다.

// 지터가 없으면 서버가 살아날 때 모든 클라이언트가 같은 순간에 몰린다
const wait = Math.min(1000 * 2 ** attempt++, BACKOFF_MAX_MS) * (0.8 + Math.random() * 0.4);

저 한 줄을 에이전트에게 설명해 달라고 했더니 이런 답이 왔습니다.

지터가 없으면 백오프만으로는 재시도가 동기화되어…

앞에서 말씀드렸듯 저는 지터도, 백오프도 모르는 단어였습니다. 그래서 다시 물었습니다.

백오프가 무엇인가.

답을 받았는데, 그 안에 또 모르는 단어가 있었습니다.

지터가 무엇인가.

여기서 조금 이상하다는 생각이 들었습니다.

모르는 상태에서 질문하면 질문이 줄어드는 게 아니라 오히려 갈라집니다. 답 하나에 모르는 단어가 두 개 들어 있으면 질문도 두 개가 됩니다. 아는 것이 적을수록 이 과정은 끝나지 않고, 답은 계속 받는데 정작 이해한 것은 많지 않은 상태가 쌓입니다.

그런데 진짜 문제는 그다음이었습니다.

지터가 무엇인지 이해하고 나서야 이런 질문이 생겼습니다.

그런데 지터라는 거, 정말 우리 서비스에 필요한 것 일까?

저희 서비스에 CS 문의를 남기는 고객은 많아야 하루 10명 정도입니다. 같은 시간대에 CS 채널에 접속해 있는 클라이언트는 많아봤자 한두 명이 전부입니다.

지터는 수많은 클라이언트의 재시도 시점을 분산시켜 특정 순간에 요청이 몰리는 것을 완화하기 위한 기법입니다. 코드 자체가 틀린 것은 아니지만, 이 규모에서는 분산시킬 몰림 자체가 생기지 않습니다.

이건 에이전트가 먼저 말해주지 않았습니다. 말해줄 수도 없습니다. 동시 접속자가 몇 명인지, 트래픽이 어느 정도인지 같은 정보는 코드가 아니라 서비스의 맥락에 있기 때문입니다.

그리고 앞에서 그렇게 공들여 만든 E2E 테스트도 이 문제는 잡아내지 못합니다. 지터가 있든 없든 웹소켓 재연결이라는 동작 자체는 정상적으로 이루어지기 때문입니다.

결국 AI가 만든 코드에는 서로 다른 종류의 문제가 섞여 들어옵니다.

동작이 깨지는 문제는 E2E 테스트로 잡을 수 있습니다. 이 글 앞부분에서 발견했던 메시지 순서 문제가 그랬습니다. 반면 동작은 정상인데 우리 상황에 맞지 않는 문제는 검증만으로 잡기 어렵습니다. 결국 사람이 읽고 판단해야 합니다. 그리고 읽으려면 그 코드가 무엇을 의미하는지도 알아야 합니다.

AI가 대신 쳐주는 건 코드이지, 판단이 아닙니다.

그래서 AI 시대에도 학습은 필요하다고 생각합니다. AI를 잘 활용하기 위해서라도, AI가 만들어낸 코드를 이해하고 그게 우리 서비스에 정말 필요한지 판단할 수 있을 만큼은 계속 배워야 합니다.

마치며

아직 추가해야 할 테스트도 많습니다. 이번에 발견한 문제 외에도 실제 사용자 흐름에서 발생할 수 있는 예외 상황들을 계속 찾아보고, 필요한 테스트를 하나씩 추가해나갈 예정입니다.

결론은 처음 마음먹은 그대로입니다.

AI가 쓴 코드를 다 읽는 것은 이제 현실적으로 어렵습니다. 이것을 인정하지 않으면 "리뷰했다"는 말 자체가 거짓말이 될 수 있습니다.

대신 바꿀 수 있는 것은 검증의 단위입니다. 리뷰의 단위를 diff에서 관측 가능한 동작으로 옮기는 것입니다.

코드 수백 줄을 읽고 "이게 맞다"고 판단하는 대신, 그 코드가 만들어낸 동작을 통해 "고객 10명분의 메시지가 상담원 화면에 빠짐없이 표시된다"고 확인할 수 있다면, 읽지 못한 수천 줄에 대해서도 적어도 그 동작만큼은 확실하게 말할 수 있습니다.

물론 이것만으로 충분한 것은 아닙니다. 어떤 부분을 검증해야 하는지, 무엇을 테스트해야 의미가 있는지, 그리고 테스트로 잡히지 않는 것은 무엇인지 판단하려면 결국 사람이 알아야 합니다.

AI가 코드를 대신 작성해주는 시대일수록, 개발자의 역할은 코드를 직접 작성하는 것에서 끝나지 않습니다. 그 코드가 무엇을 의미하는지 이해하고, 필요한 것을 판단하고, 결과를 검증할 수 있어야 합니다.

그래서 다 읽는 것은 포기하되, 적어도 어디를 읽어야 할지는 스스로 판단할 수 있는 개발자가 되려고 합니다.

NAVER D2 - AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기 https://youtu.be/wo0Rsh9hlTo?si=yi8hSl5UcFD1PtGJ 미드나잇 로그 Midnight Log - 노션 개발자는 코드를 이렇게 읽습니다 https://youtu.be/iv60GIHpijE?si=Pr1GgLpBsQaCd6la

1. 아니 PCB는 Process의 상태를 저장하고 복원하는데 쓰이는 자료구조인데, 만약에 같은 Process에 존재하는 Thread간에 Context Switching이 발생하는 경우에는 어떻게 상태를 추적할 것인가?
   
2. 실행되는 작업의 최소 단위는 Process가 아니라 Thread라는 것을 보면 Context Switching의 실질적인 기준이 되는 것도 Thread 여야 되는 것 아닌가?
   
3. 근데 PCB가 이러한 것들을 다 감당하는 자료구조인가?

그래서 검색해본 결과 TCB라는 새로운 자료구조를 알게되었음

TCB - Thread Control Block

Thread의 상태를 저장하는 자료구조 다음과 같이 PCB에 연결된 리스트에 존재함

Thread Context Switching이 발생하면

Thread A가 CPU 사용중 Thread A의 상태 정보를 TCB A에 저장 Thread A가 속한 Process A의 상태 정보 PCB A에 저장 Thread B가 속한 Process B의 상태 정보 PCB B 로드 Thread B의 TCB B 로드 Thread B가 CPU 사용

과 같은 과정이 실행된다고 한다 그리고 gpt한테 물어봤는데 Context Switching의 실질적인 기준이 되는것도 Thread가 맞다 함 아 근데 먼가 확실ㄹ하지 않고 애매한거 같아서 더 찾아보고 공부해바야 될듯

방문 상태를 저장 할 경우 배열로 선언하는 것보다 비트마스킹 형태의 정수로 저장하면 공간복잡도 측면에서 효율적으로 코드 작성 가능

• 추가 파이썬에서 딕셔너리의 특정 키 존재 유무 파악할 때 그냥 in 연산자 적어주면 된다. 시간복잡도 o(1)

비트스트림에서 i번째 인덱스의 값을 딕셔너리의 키가 i일때 value 값을 구하는 방식으로 구현

훨씬 직관적인듯

mtbf = 고장률의 역수

• 고장률 = 고장건수 / 총가동시간

mttf = 총가동시간 / 고장시간

mttr = 총고장시간 / 고장건수

가용도 = mttf / mtbf

cpm 네트워크

타당성 3가지

기술적 타당성 = 프로젝트가 기술적으로 가능한지 경제적 타당성 = 프로젝트가 경제적으로 가능한지 (이익을 창출할 수 있을지) 운영적 타당성 = 프로젝트가 실제로 사용 가능한지 (조직과 잘 맞음? 클라이언트가 사용 가능?)

유스케이스 다이어그램

통신 다이어그램

• 직사각형 : 객체
• 선 : 관계
• 화살표 : 메세지가 흐르는 방향
• 번호 : 메세지 전송 순서

순차 다이어그램

비용 산정 기법

• 상향식
  • loc = 라인 / (생산성 * 프로그래머)
  • cocomo
    • 조직형 = 조직형 (소규모 소프트웨어, 비즈니스 로직)
    • 반분리형 = 30만 라인 이하
    • 내장형 = 30만 라인 이상 (운영체제, 대규모 트랜잭션)

    ---

    • 기본형 = 라인 수와 개발 유형 사용해서 비용 산정
    • 중간형 = 제품, 컴퓨터, 개발자 특성 고려해 비용 산정
    • 발전형 = 개발 공정별로 더욱 자세하게 비용 산정

    ---

    • 보정 후 기능 점수 = 기본 점수 * 보정 인자
• 하향식 (전문가들)

dfd

• data store = db테이블
• terminator = 대상
• process = 수행
• data flow = 데이터 이동

bisect 라이브러리 추가 공부 ㄱ

https://school.programmers.co.kr/learn/courses/30/lessons/258709

이벤트 루프

자바 스크립트 코드 실행은 스레드에서 담당하고 비동기작업은 이벤트 루프에 등록되어 백그라운드엣에서 실행됨 이벤트 루프는 요청을 처리하면서 블로킹 작업을 피하고 (non-blocking), 작업이 완료될 때까지 기다리는 대신 다른 작업을 계속 진행할 수 있게 함. 콜 스택 과 태스크 큐를 사용

콜 스택 (call stack)

자바스크립트 코드가 실행되는 공간. 코드가 동기적이면 콜 스택에서 순차적으로 처리됨

태스크 큐 (task queue)

비동기 작업(예: 네트워크 요청, 파일 읽기, 데이터베이스 접근 등)은 콜 스택에서 바로 처리되지 않고 백그라운드에서 실행. 백그라운드에서 실행된 작업이 완료되면 그 결과가 태스크 큐에 담김 *태스크 큐에 쌓인 작업은 콜 스택이 비어 있을 때 이벤트 루프가 이를 콜 스택으로 다시 가져와 실행함 *

소켓 통신은 서로 다른 컴퓨터에 있는 프로세스 사이에 데이터를 주고 받기위해 사용되는 기술이다. 소켓 통신은 클라이언트와 서버가 실시간으로 데이터를 주고 받을 수 있는 양방향 통신으로 채팅, 실시간 스트리밍 등에 사용된다. 소켓 통신은 IP와 포트번호를 통해 어떤 컴퓨터의 어떤 프로세스와 통신할지 구별한다

근데 갑자기 다음과 같은 궁금증이 생겨버림

아니 근데 내가 알기로는 HTTP 통신도 서버랑 클라이언트가 실시간으로 데이터 주고 받는 기술이고, HTTP 통신도 IP와 포트번호를 통해 어떤 컴퓨터의 어떤 프로세스와 통신할지 구별하는데, 둘이 같은거 아님?

그래서 찾아보니까 HTTP 통신은 소켓 통신이 맞음. TCP 계층에 올라간 HTTP 또한 소켓 통신과 같은 방식을 사용함. 즉 HTTP 통신은 소켓 통신에 일종이라고 볼 수 있으나, 소켓 통신은 HTTP 통신이 아님

추가

• HTTP 통신은 클라이언트의 요청이 들어왔을 때 서버가 응답하는 단방향 통신, 서버는 응답하면 클라이언트와 커넥션을 끊어버림. 즉 *실시간 통신이 아님 * -> 그러나 현재는 Keep Alive 옵션을 통해 커넥션 유지 가능 즉 근본자체는 실시간 통신이 아니기 때문에 내가 기존에 알고있던 내용은 틀린 내용
• 초기에는 HTML 파일만 전송하였으나, 현재는 JSON, 이미지 파일 등도 전송 가능

아 퇴사하고 오랜만에 공부하니까 개재밌네 ㅎ

접근

사각형을 하나씩 순회하면서 모서리 부분은 1, 안쪽 부분이거나 다른 사각형의 안쪽부분이라면 0으로 그래프 초기화

코드

from collections import deque


def solution(rectangle, characterX, characterY, itemX, itemY):

    leng=max(list(map(max, rectangle)))*2
    graph=[[5 for i in range(leng+1)] for j in range(leng+1)]
    visited=[[0 for i in range(leng+1)] for j in range(leng+1)]
    answer=10000
    movelist=[[1,0],[-1,0],[0,-1],[0,1]]
    for re in rectangle:
        re=list(map(lambda x:x*2,re))
        for i in range(re[1],re[3]+1):
            for j in range(re[0],re[2]+1):
                if graph[i][j]!=0 and (i==re[1] or i==re[3] or j==re[0] or j==re[2]):
                    graph[i][j]=1
                else:
                    graph[i][j]=0

    curx,cury=characterX*2, characterY*2
    visited[cury][curx]=1
    itemx,itemy=itemX*2, itemY*2
    queue=deque()
    queue.append([curx,cury,0])

    while queue:
        curx,cury,curd=queue.popleft()
        if curx==itemx and cury==itemy:
            answer=min(answer,curd//2)

        for mo in movelist:
            nx,ny=curx+mo[0],cury+mo[1]
            if 0<=nx<leng+1 and 0<=ny<leng+1 and visited[ny][nx]==0 and graph[ny][nx]==1:
                queue.append([nx,ny,curd+1])
                visited[ny][nx]=1

    return answer

참고

실제 문제의 좌표평면을 그래프상의 숫자 0과1로 옮길떄 주의해야 할 점은 다음과 같다

좌표평면의 ㄷ자 모양과 ㅁ자 모양을 그래프로 옮길 경우 두 그래프의 형태 모두 1 1 1 1 로 표현된다. 그렇기 떄문에 위와같은 문제를 해결할 떄는 그래프의 좌표를 2배로 늘려주는 방식 또한 고려해야한다. 만약 위 경우를 그래프를 두배로 늘렸을 경우로 표현한다면

1 1 1 0 0 1 0 0 0 과 1 1 1 1 1 1 1 1 1로 정상적으로 구별이 가능해진다.

Security Config

Success handler 추가

Session Management

• 최대 로그인 세션 1개로 제한 -> 중복 로그인 제한

  formLogin

• defaultsuccessurl 방식에서 successHandler 방식으로 변경, 이게 인증,인가 다룰때 더 좋은듯

  oauth login 속성 추가

• 사실 이번 리팩토링의 가장 큰 이유인 부분. 구글 로그인 연동 기능 추가 , ->DB에도 정상적으로 연동된것 확인

  logout handler 추가

Controller

Main

• 메인 컨트롤러에서 authenticated 또는 authorized된사용자 정보 1차적으로 불러오게끔 변경

Member

• authenticated 유무에 따라서 redirect 되는 결과 변경

route

• 이번 리팩토링의 핵심 2, 이제 매 실행마다 이전 데이터 clear하고 실행되기 때문에 연속된 서비스 실행 가능

DTO

• 이건 별거 없음 그냥 oauth 종속성 추가함에 따라 기존 DTO에 column 추가하고 oauth속성이랑 세션멤버 dto 생성한거?

Entity

• 이것도 마찬가지

Service

• 이거 진짜 개 큰일날뻔 한게 전체 프로젝트의 가장 중요한 부분 담당하는 service 두개가 bean으로 등록이 안되어있었음... 바로 어노테이션 추가함...지금까지 어떻게 정상적으로 실행되었는지는 잘 모르겠으나 되게 기특하다ㅠ

추가

이번에는 감사하게도 로컬상에서 커밋한 내용 그대로 배포단에서 정상적으로 실행이 됐다.. 잠깐 구글oauth 측에서 redirect uri mismatch 에러가 나긴 했는데 이것도 리디렉션 uri 조금 조물조물 거리니까 되었음. 아마 자바스크립트 원본에 ec2주소 안넣고 배포 주소 넣어서 그런듯?

프론트는 변경한거 작성안함

접근

기둥배열과 보 배열을 각 각 따로 이차원 배열로 생성해주었고. 기둥과 보의 시작점과 끝점을 각각 1로 설정해준후 구현하였음.

1차 수정

0ㅡ0ㅡ0 보가 이렇게 지어져있을 때나, 0ㅡxㅡ0 이렇게 지어져있을 때나 이차원 배열의 값은 같기 떄문에 구별이 안된다. 그리하여 시작점만 1로 설정해주는 식으로 변경하였다

처음 코드

def solution(n, build_frame):
    # 기둥은 바닥위에 있거나 보의 한 쪽 끝 부분 위에 있거나 다른 기둥위
    # 보는 한쪽 끝이 기둥 위 or 양쪽 끝부분이 다른 보
    gi=[[0 for i in range(n+1)] for j in range(n+1)]
    bo=[[0 for i in range(n+1)] for j in range(n+1)]

    for bu in build_frame:
        x,y,a,b=bu
        # x y는 교차점 좌표고 교차점 기준으로 보는 오른쪽 기둥은 위쪽
        if a==0:
            # 기둥
            if b==0:
                flag=True
                # first 위에 기둥
                if gi[y+1][x]==1:
                    if not (bo[y+1][x]==1 or bo[y+1][x-1]==1):
                        flag=False

                # second 오른쪽에 보
                if bo[y+1][x]==1:
                    if not(gi[y][x+1]==1 or (bo[y+1][x-1]==1 and bo[y+1][x+1]==1)):
                        flag=False

                # third 왼쪽에 보
                if bo[y+1][x-1]==1:
                    if not(gi[y][x]==1 or (bo[y+1][x-2]==1 and bo[y+1][x]==1)):
                        flag=False

                if flag:
                    gi[y][x]=0

            else:
                # 설치
                if y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1:
                    # 바닥이거나 기둥위거나 보 위에
                    gi[y][x]=1
        else:
            if b==0:
                flag=True
                # 삭제
                # first 왼쪽에 기둥
                if gi[y][x]==1:
                    if not(bo[y][x]==1 or bo[y][x-1]==1 or y==0):
                        flag=False

                # second 오른쪽에 기둥
                if gi[y][x+1]==1:
                    if not(bo[y][x+1]==1 or bo[y][x]==1 or y==0):
                        flag=False

                # third 오른쪽에 보
                if bo[y][x+1]==1:
                    if not(gi[y-1][x+1]==1 or gi[y-1][x+2]==1):
                        flag=False

                # fourth 왼쪽에 보
                if bo[y][x-1]==1:
                    if not(gi[y-1][x-1]==1 or gi[y-1][x]==1):
                        flag=False
                if flag:
                    bo[y][x]=0
            else:
                if (bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1:
                    # 다른 기둥의 한 쪽 위거나 양쪽이 보
                    bo[y][x]=1



    answer = []

    for i in  range(n+1):
        for j in range(n+1):
            if gi[i][j]==1:
                answer.append([j,i,0])
            if bo[i][j]==1:
                answer.append([j,i,1])
    answer.sort()
    return answer

예제는 모두 통과하였으나 실 테스트 케이스는 반타작

2차 수정

초기코드에는 기둥 혹은 보를 삭제해줄때 해당 보 혹은 기둥많이 영향을 끼치는 부분만 고려하여 코드를 구현하였으나, 이부분에서 문제가 있었다.

인접 보와 기둥은 유지가 가능하더라도, 연쇄적으로 확장해봤을때 조건에 부합하지 않는 보와 기둥이 생길 수 도 있기때문에, 삭제 연산이 들어올 때마다 전체 기둥과 보의 적합성을 판단해야함

수정된 코드

def delete(i,j,gb,gi,bo,n):
    if gb==0:
        # 기둥
        gi[i][j]=0
    else:
        # 보
        bo[i][j]=0
    count=0
    for y in range(n+1):
        for x in range(n+1):
            if gi[y][x]==1:
                if not(y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1):
                    return False
            if bo[y][x]==1:
                if not((bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1):
                    return False


    return True



def solution(n, build_frame):
    # 기둥은 바닥위에 있거나 보의 한 쪽 끝 부분 위에 있거나 다른 기둥위
    # 보는 한쪽 끝이 기둥 위 or 양쪽 끝부분이 다른 보
    gi=[[0 for i in range(n+1)] for j in range(n+1)]
    bo=[[0 for i in range(n+1)] for j in range(n+1)]

    for bu in build_frame:
        x,y,a,b=bu
        # x y는 교차점 좌표고 교차점 기준으로 보는 오른쪽 기둥은 위쪽
        if a==0:
            # 기둥
            if b==0:
                # 기둥 삭제
                if not delete(y,x,a,gi,bo,n):
                    gi[y][x]=1

            else:
                # 설치
                if y==0 or gi[y-1][x]==1 or bo[y][x]==1 or bo[y][x-1]==1:
                    # 바닥이거나 기둥위거나 보 위에
                    gi[y][x]=1
        else:
            if b==0:
                if not delete(y,x,a,gi,bo,n):
                    bo[y][x]=1
            else:
                if (bo[y][x+1]==1 and bo[y][x-1]==1) or gi[y-1][x+1]==1 or gi[y-1][x]==1:
                    # 다른 기둥의 한 쪽 위거나 양쪽이 보
                    bo[y][x]=1



    answer = []

    for i in  range(n+1):
        for j in range(n+1):
            if gi[i][j]==1:
                answer.append([j,i,0])
            if bo[i][j]==1:
                answer.append([j,i,1])
    answer.sort()
    return answer

참고

사고 확장하기 데이터 그래프로 표현할때는 정확하게 되었는지 확인

이것들 왜씀?

http는 기본적으로 통신이 완료되면 클라이언트와 관계를 냅다 끊어버림. 즉 데이터가 유지되지 않는다. 그래서 웹에서 뭐 작성하다 새로고침하면 다 날라가는거임ㅋㅋ.

그러나, 어떤 데이터들은 유지되어야 할 필요가 있다.

예를들어, 우리가 특정 사이트에 로그인을 했는데, 새로고침 한번 했다고 로그아웃이 된다면 굉장히 어처구니가 없을것

그래서 이러한 데이터들을 브라우저등에 "임시로 저장" 하기 위해 사용되는 것이 바로 쿠키/세션/캐시/토큰이라고 할 수 있다~

쿠키

쿠키는 웹사이트 접속시 내 컴퓨터 혹은 웹 브라우저에 저장되는 작은 텍스트 조각이다. (크롬일 경우 브라우저에, IE일 경우 내컴퓨터에 저장됨)

쿠키에는 서버에서 유저를 식별할 수 있는 데이터들이 저장되며, 지정된 만료일이 지나면 삭제된다.

쿠키는 사용자가 수정및 삭제할 수 있고, 제 3자가 조회할 수 있기 때문에 가벼운 정보들이 저장되며 보안상 민감한 정보는 저장되지 않는다. 예를 들어 검색내역, 장바구니 내역등은 제3자에게 보여져도 보안상 큰 타격이 없지만, 사용자의 개인정보 내용등은 타인에게 보여지면 안된다.

캐시

캐시란 자주 사용하는 데이터나 값을 미리 복사해놓는 임시 장소

• (캐시는 인터넷 환경 뿐만 아니라 다양한 곳에서 사용되는 개념. 컴퓨터 하드웨어 안에서도 정보를 더 빨리 가져오기 위한 cpu캐시등이 있음)

데이터를 서버에 요청하는 과정에는 시간 및 자원이 소모된다. 그러므로 반복적으로 쓰이는 데이터는 매번 서버에 요청하는 것 보다 저장해놨다가 쓰는 것이 효율적. 이때 쓰이는 것이 캐시. 예를 들어 프로필 사진같은 경우는 짧은 시간 단위로 변화하지 않기 때문에, (여기서 짧은 시간은 밀리초 혹은 초 단위) 매번 서버에 요청하는 것 보다는 캐시에서 가져오는 것이 더 효율적임. 그래서 가끔 프로필 사진 바꿔도 새로고침 광클해야 변하는 경우 있는데 그게 프로필 사진이 캐싱돼서 그런거임 ㅇㅇ

세션

세션은 서버가 유저를 구분하기 위해 사용되는 방법이다.

우리가 특정 사이트에 접속하여 글을 쓰기 위해 로그인을 하였다고 가정하자. 그러나 기본적으로 사이트는 로그인을 하기 이전의 사용자와 로그인을 한 이후의 사용자가 동일 인물이라는 것을 알지 못한다.

그렇기 때문에 새로은 글을 작성할 때마다 로그인을 해야한다. 하지만 실제로 우리가 사이트를 이용할때 그런 번거로운 과정을 다 거치지 않는다. 그이유가 바로 "세션"때문이다.

유저가 로그인에 성공하면 서버는 세션 아이디를 사용자에게 전달하고, 사용자는 세션아이디를 쿠키에 저장한다.(그래서 크롬 종료해도 로그인 유지되는거) 서버가 유저로부터 요청을 받을 때 마다 이 세션아이디를 통해 누구의 계정인지 확인하고 요청을 수행함. (영화관에서 티켓내면 보관용만 찢어서 다시 주는거처럼)

토큰

이건 나중에 JWT하면서 ㄱ

참고

https://hongong.hanbit.co.kr/ https://devbirdfeet.tistory.com/203

접근

각각의 데이터의 크기가 크지 않아 완전탐색 알고리즘으로 접근하였다. n짜리의 원형의 외벽을 크기 2n짜리 배열을 생성하고, range(0,n)까의 반복문을 돌면서 i~i+n부분을 파싱하고 dist배열을 permutaations 한 값을 하나씩 순회하면서 최소갯수를 갱신해주었으나 몇몇 테스트 케이스에서 시간초과가 발생하였다.

수정

외벽이 원형의 형태로 주어졌기 때문에 이를 두배로 늘려 배열 형태로 변환하는 것은 맞다. 그러나 기준이 잘못되었음.

굳이 크기가 2n짜리인 배열을 선언하는 것이 아니라, weak의 크기 *2 만큼만 선언하여도 충분하다. 어차피 중요한것은 weak의 위치 보다는, 각 weak사이의 거리가 더 중요하기 때문에,

    for we in weak:
        newweak.append(we)
        newweak.append(we+n)
    newweak.sort()

전체 코드

from itertools import permutations
from collections import deque
def solution(n, weak, dist):
    minlength=100000
    newweak=[]
    check=len(weak)
    for we in weak:
        newweak.append(we)
        newweak.append(we+n)
    newweak.sort()
    dist_permu=list(permutations(dist,len(dist)))

    for i in range(check):
        for dist in dist_permu:
            cur_newweak=deque(newweak[i:i+check])
            dist=deque(dist)
            count=1
            curweak=cur_newweak.popleft()
            curdist=dist.popleft()
            flag=False
            while len(cur_newweak)>0:
                if cur_newweak[0]-curweak<=curdist:
                    cur_newweak.popleft()
                else:
                    curweak=cur_newweak.popleft()
                    if dist:
                        curdist=dist.popleft()
                        count+=1
                    else:
                        flag=True
                        break
            if flag:
                continue
            else:
                minlength=min(minlength,count)
    if minlength==100000:
        return -1
    return minlength

참고

원형은 배열로 변환, 데이터 적으면 완탐 먼저 생각