나는 현재 3개월 체험형 인턴으로, 백엔드 엔지니어 직무를 수행하고 있다.

🌱 인턴 합격부터 첫 출근까지

인턴에 지원할 때부터의 기억을 더듬어 본다.

처음 이 인턴 공고를 발견했을 당시에 대부분의 들어봤다 싶은 기업의 공고에는 모두 지원을 하고 있었던 상태였기도 하고 여기는 평소 애용하는 서비스인데다가 여러 경험으로 이 기업 개발자에게도 좋은 인상을 가지고 있었기에 당연히 지원했다. 그치만 기대는 전혀 안했다. 소위 말하는 네카라쿠배당토 계열의 기업이니까. 대단한 사람들이 많이 지원할 테니까..

그런데 서류가 붙었다. 웬걸 실수로 합격시킨거 아니야? 라고 생각했지만 그래도 좋았다. 그런데 면접 일자가 다가오면 다가올 수록 점점 무서워졌다. 진짜 실수로 합격 시킨 것 아닐까? 면접에서 너무 한심하게 쉬운 질문에 대답을 못하면 어떡하지? 라이브코테에서 너무 쉬운 문제인데 못 풀면 어떡하지? 설날도 껴있어서 면접 준비를 할 시간이 많았지만 오히려 불안감에 제대로 준비를 하지 못했다. 그래서 면접 전날까지 고민하다가 그냥 면접을 취소할까 계획도 짰다. 그러다 개발자 커뮤니티 같은 곳에 진심을 담아 면접을 취소할지 고민이라고 털어놓았는데 모든 사람들이 무조건 갔다 오라고 했다. 경험은 돈 주고도 못 산다고. 이 말이 정말 큰 원동력이 됐다. 경험은 돈 주고 못 사고 나는 그 경험을 할 수 있는 기회를 얻은 사람인데 왜 이 기회를 발로 차려고 하지? 그때부터는 마음을 다잡았다. 모든 걸 보여주고 오자고.

결국 다음날 면접을 보러갔다. 긴장돼서 오후 면접인데도 아침 10시부터 회사 근처 카페에 있었다. 카페에 있는 동안 정말 많은 생각이 들었는데 뭔가 부정적이고 자신감이 떨어지는 생각이 들 때마다 난 그냥 경험을 하러 온거고 면접 떨어지면 다신 볼 일도 없는 사람들이다 그냥 나를 보여주고 오자. 라고 계속 되뇌었다. (실제 효과 좋음)

그렇게 불안했고 걱정됐던 면접이 사실 너무 좋았다. 면접관은 인사팀이 아니라 내가 1순위로 적은 팀의 백엔드 개발자 두 분이었고, 딱딱한 면접 분위기가 아니라 마치 처음 보는 개발자들과 대화를 나누는 느낌이었다. 뭔가 중간중간 두 분이 티키타카도 하면서 면접을 진행했던게 이 회사의 분위기를 말해주는 듯했다. 역경 없이(?) 순탄하게 면접을 마치고 마지막에 질문이 있다면 편하게 물어보라고 하셔서 물어봤다. 두 분께서 생각하는 오래 일할 수 있는 개발자의 자세나 장점이 뭐라고 생각하냐고. 왜냐하면 평소에 많이 고민했던 것이기 때문에 언제 이런 유능한 개발자들에게 물어볼 수 있겠나 싶어서 물어봤다. 한 분은 개발을 하는 과정에 하나라도 재미 요소가 있는 사람. 뭐 문제 해결하는 과정이 재밌다던지 이런게 하나라도 있어야 오래 할 수 있는 것 같다고. 한 분은 개발자도 결국 누군가와 함께 무언가를 만들어내는 사람이기 때문에 소통을 힘들어하지 않고 소통을 하려고 하는 사람이라고 했다. 이것도 정말 물어보기 잘했다고 생각한다. 지금까지도 계속 되뇌이고 있으니. 주저리주저리 말이 길어졌지만 암튼 정말 좋게 면접을 마쳤다. (근데 면접이 정말 좋았지만 붙을 거라는 기대를 정말 .. 안했다. 못한 대답도 많고 내 실력이 턱없이 부족하다고 생각했기 때문에. 그래서 실제 붙으면 입사할 첫째 주에 여행 일정까지 잡아버렸다..)

근데 진짜 웬걸이다. 합격했다. 당장 다음주부터 출근해야 했다. 진짜 얼떨떨한 상태로 일주일을 지냈고 그렇게 나는 인턴으로 출근하게 됐다.

첫 실무, 그리고 고민들

이 글을 쓰는 지금은 이렇게 입사를 해서 출근한지 딱 2주가 지났다. 첫 직장이고 첫 실무다. 모든 것이 신기하고, 모든 것이 새롭고, 모든 것이 낯설다. 사실 아직도 적응 중이다. 분위기, 커뮤니케이션, 업무툴 등 새로운게 너무 많다! 일단 인턴에게 주어지는 아주 가벼운 업무 프로세스가 있는데 그걸 수행하고 있다. 정말 쉬운 작업인 것 같은데 이것저것 모르는게 너무 많고 해서 속도가 안나니까 조금 답답하기도 하다. (백엔드 엔지니어지만 우리 팀에는 프론트 엔지니어가 따로 없어서 프론트 작업을 하고 있다는 것도 이유라면 이유겠지!)

사실 1주차 출근을 하고 맞이한 주말에는 정~말 생각이 많았다 ㅋㅋㅋ 고민도 많고 너무 내가 팀원들에 비해 부족한 것 같았기 때문이다. 질문을 편하게 하라시는데 너무 유능하신 분들에게 나의 하찮은 질문을 하기란 쉽지 않더라. 또, 우리 팀에는 나 빼고 같이 입사한 인턴 두 분이 더 계시다. 두 분 모두 너무 친절하고 좋으시다. 그런데 두 분 모두 여기 들어오기 전에 인턴 경험이나 회사 경험이 있으시다고 하고 일주일 동안 너무 잘 적응하시는 것 같았다. 나만 부족한 것 같았다. (그런데 사실 팀원 두 분도 주말에 나와 비슷한 고민을 하셨다고 했다 ㅋㅋㅋ) 동기 두 분과 저녁 자리를 가지면서 많은 이야기를 했다. 모두 같은 상황이고 낯선 환경에서 동지(?)애 덕에 공감이 많이 가는 시간이었다. 이때 나는 이런 낯선 환경에 심지어 인턴으로 들어왔는데 부족한 건 당연하잖아! 라는 걸 깨닫게 되는 귀중한 시간이었달까.

2주 차를 마치며, 앞으로의 방향

2주차 출근을 마친 지금은 1주차 주말과 다른 고민들과 생각들이 꽃피워 있다. 솔직히 여기서 3개월을 그냥 생각 없이 일하면 내 능력이 폭발적으로 늘지는 않을 것 같다는 생각을 했다. 이 3개월이라는 시간, 기회에서 내 성장을 뽑아낼 대로 뽑아내야(?) 될 것 같았고 그러기 위한 방법을 고민하고 있다.. 구체적인 솔루션이라기 보다 뭔가 새로운 마음가짐을 가지면 그로 인해 행동은 따라 올 것이기 때문에 적절한 마음가짐을 찾고 있다.

그래서 이번 주말동안은 내가 가진 생각을 정리해 보는 시간을 가졌다. 내가 이 기업에서 일하면서 이루고 싶은 것, 나의 개발자로서의 강점이 될 수 있는 것과 단점을 고민해 봤다. 고민하는 과정에서 나에 대해 더 잘 알게 되긴 했지만 새로운 마음가짐은 찾지 못했다. 3주차때는 감을 잡으려나.

암튼 이번주는 고민 끝에 나온 결정은 이거다.

1. 미팅, 논의 등에서 나의 주장을 말하는 연습을 하자.
2. 한 가지 생각에 너무 매몰되지 말고 필요하면 세수라도 하며 환기하자.
3. 궁금한 건 적극적으로 물어보자. cc.뻔뻔해지자
4. 나태해지지 않게 조심하자. 그렇지만 너무 긴장해 있지도 말자.
5. 내 일을 열심히 하면 인간관계는 자연스럽게 형성될 것.

TMI

질문을 편하게 해주세요. 저희는 답할 준비가 되어 있으니 팀 리더 분과 1on1 중 해주셨던 말인데 뭐랄까... 인상 깊고 감동이었기에 계속 생각난다.

내 면접을 봤던 개발자 두 분이 우리 팀, 파트의 개발자 두 분이시다. 면접을 봐주신 분들과 함께 일을 하고 있다는게 뭔가 신기하다.

고작 인턴 가지고 뭘 이렇게 장황하게 글을 쓰나 싶을 수도 있겠다. 그치만 나에겐 이 인턴 일이 이 정도로 크고 새롭고 소중한 경험이다 😁

식대 제한이 없어서 맛있는 걸 너무 많이 먹는다. 살이 찔 듯.

크루스칼 알고리즘은 최소 신장 트리(MST, Minimum Spanning Tree)를 찾는 대표적인 알고리즘 중 하나로, 다음과 같은 특징이 있다.

• 간선을 하나씩 추가하면서 MST를 만들어 간다.
• 탐욕적 기법(Greedy Algorithm)을 사용한다.
• 시간 복잡도는 O(E log V)

크루스칼 알고리즘 과정

초기 상태로 정점는 서로 연결되어 있지 않다. 간선을 하나씩 추가하면서 최소 신장 트리(MST)를 만든다. 크루스칼 알고리즘을 수행하고 완성된 그래프는 최소 신장 트리이다.

간선을 추가하는 방식은 다음과 같다.

1. 모든 간선을 가중치 기준으로 오름차순 정렬한다.
2. 가중치가 작은 간선부터 하나씩 선택하여 MST에 추가한다.
3. 사이클이 발생하는지 확인한다.
   • 사이클이 생기지 않으면 해당 간선을 MST에 포함한다.
   • 사이클이 발생하면 해당 간선을 제외한다.
4. 모든 정점이 연결될 때까지 위 과정을 반복한다.

👉 여기서, 사이클 판별을 위해 유니온 파인드(Union-Find) 알고리즘을 사용한다.

정점 V와 정점 W를 연결하는 간선 E를 선택할 때, V와 W의 루트 노드가 같다면(이미 같은 집합에 속해 있다면) 사이클 발생 → 간선 추가 X 루트 노드가 다르면 서로 다른 집합 → 간선 추가 O

유니온 파인드 알고리즘 알아보기 🔗 https://wikidocs.net/206632

크루스칼 알고리즘 예제 문제

📌 프로그래머스 섬 연결하기 [level 3]

문제 설명 여러 개의 섬이 주어지고, 각 섬을 연결하는 다리를 건설하는 비용이 주어진다. 모든 섬을 연결하는 데 필요한 최소 비용을 구하는 문제이다.

✨ 크루스칼 알고리즘 적용 과정

1. 다리 건설 비용을 기준으로 간선들을 오름차순 정렬한다.
2. 사이클이 발생하지 않도록 하나씩 간선을 추가한다.
3. (정점 개수 - 1)개의 간선을 선택하면 종료한다.

풀이 코드 (JAVA)

import java.util.*;

class Solution {
    public void union(int[] parent, int x, int y) {
        x = find(parent, x);
        y = find(parent, y);

        if (x < y) {
            parent[y] = x;
        } else {
            parent[x] = y;
        }
    }

    public int find(int[] parent, int x) {
        if (parent[x] == x) {
            return x;
        } else {
            return find(parent, parent[x]);
        }
    }

    public int solution(int n, int[][] costs) {
        int answer = 0;
        Arrays.sort(costs, (o1, o2) -> o1[2] - o2[2]);

        // 부모노드 초기화
        int[] parent = new int[n];
        for (int i = 0; i < n; i++) {
            parent[i] = i;
        }

        // 크루스칼 알고리즘
        for (int i = 0; i < costs.length; i++) {
            // 부모가 같지 않으면. 즉, 사이클이 생기지 않으면 간선 선택
            if (find(parent, costs[i][0]) != find(parent, costs[i][1])) {
                answer += costs[i][2];
                union(parent, costs[i][0], costs[i][1]);
            }
        }

        return answer;
    }
}

✅ 코드 설명

• find() : 특정 노드의 부모(루트 노드)를 찾는 함수
• union() : 두 노드를 같은 집합으로 합치는 함수
• costs 배열을 가중치 기준으로 정렬하고, 가중치가 작은 간선부터 추가
• 사이클이 발생하는지 체크 후, MST에 포함 여부 결정

캡슐화(encapsulation)는 객체 지향 프로그래밍에서 다음 2가지 측면이 있다.

• 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고,
• 실제 구현 내용 일부를 외부에 감추어 은닉한다.

우리는 캡슐 약 내부에 무엇이 들어있는지 알 수 없다.

그런데 분명 캡슐 약 안에는 여러 가지 성분들이 들어있는 것을 알고, 캡슐의 용도 또한 알고 있다. 약 먹으면 몸이 나아지는 것!!

그런데 알약 껍질에 의해 물리적으로 접근할 수 없기 때문에 캡슐에 무엇이 들어있는지 우리는 모른다.

자바의 캡슐화

자바의 캡슐화는 알약 껍질처럼 외부 접근에 대한 차단이고, 차단의 방법은 접근 제어자를 사용한다.

간단한 소스코드로 알아보자.

class Capsule {
    private int number;

    public Capsule(int number) {
        this.number = number;
    }

    public double getHalf() {
        return number / 2;
    }
}

class Main {
    public static void main(String[] args) {
        Capsule capsule = new Capsule(10);
        System.out.println(capsule.getHalf());
    }
}

👉 int값을 초기값으로 갖는 객체가 있고, 그 값의 절반을 반환하는 getHalf() 라는 메소드가 존재한다.

❓ 여기서 캡슐화는 바로 Capsule 클래스 자체를 의미한다.

위 코드가 캡슐화의 정의를 만족하는지 보자.

객체 지향 캡슐화 : 데이터와, 데이터를 처리하는 행위를 묶고, 외부에는 그 행위를 보여주지 않는 것.

Capsule 클래스는

• int 값의 데이터를 가지고 있다.
• 그리고 getHalf 라는 데이터를 처리하는 행위 또한 가지고 있다.
• 마지막으로 Main메소드의 입장에서 Capsule 클래스의 getHalf() 를 사용할 수는 있지만, 구현이 어떻게 되어 있는지는 알 수 없다.

즉, 캡슐화되어 있다고 말할 수 있다!

여기서 드는 의문은?

데이터와, 행위를 하나로 묶고, 그걸 외부에 노출시키지 않는 캡슐화를 왜 하는가?

잘 된 캡슐화를 통해 얻을 수 있는 가장 큰 이점은

• 코드의 중복을 피할 수 있다는 점
• 데이터를 처리하는 동작 방식을 외부에서 알 필요가 없다는 점

이 이점들이 왜 필요한지 코드로 알아보자!

class Product {
    int price = 10000;

    public Product(int price) {
        this.price = price;
    }
}

• 만약 어떤 제품의 10% 할인된 금액을 구해서 다른 로직으로 넘겨야 한다면 다음과 같은 코드를 추가하게 될 것이다.

class Product {
    private int price = 10000;

    public Product(int price) {
        this.price = price;
    }

    public int getPrice() { // getter 추가
        return price;
    }
}

public void first(Product product) {
    double discountedPrice = product.getPrice() * 0.9;
    show(discountedPrice);
}

상품의 가격을 가지고 와서 10프로 할인된 가격을 구하고, 다른 로직으로 넘겼다.

• 그렇다면, 만약 10프로 할인된 금액을 다른 로직에서도 사용하게 된다면 어떻게 될까?

public void first(Product product) {
    double discountedPrice = product.getPrice() * 0.9; // 중복
    show(discountedPrice);
}

public void second(Product product) {
    double discountedPrice = product.getPrice() * 0.9;  // 중복
    secondShow(discountedPrice); // 할인된 금액을 show와 다르게 사용하는 메서드
}

코드에서 중복이 일어났다.

한 줄짜리 코드 중복 좀 되면 어때??? 할 수 있지만, 이러한 로직이 수십 개,, 수백 개 더 필요하면 일일이 타이핑하는 것은 정말 힘들 것이다.

🤔 코드의 중복은 좀 별로군?

다음으로는 데이터를 처리하는 방식이 외부에 드러나지 않는 것은 어떤 이점이 있는지 알아보자.

• 요구사항이 변경되어 10프로 할인된 금액이 아니라 20프로 할인된 금액으로 로직을 바꿔야 하는 상황이다.

• 위와 같이 코드가 작성되었다면, 엄청난 양의 코드를 아래와 같이 고쳐야 한다.

    public void first(Product product) {
        double discountedPrice = product.getPrice() * 0.8; // 20프로 할인
        show(discountedPrice);
    }

• 그러다가 10프로 할인 로직을 20프로 할인 로직으로 변경하지 못한 코드가 하나라도 존재한다면, 서비스에 큰 타격을 입게 될 것이다.

🤔 캡슐화를 지키기 위한 규칙 중에는 Tell, Don't Ask 라는 원칙이 있다. 객체 내부의 데이터를 꺼내와서 처리하는 게 아닌, 객체에게 처리할 행위를 요청하라는 행위이다. 이러한 행위를 우리는 "객체에 메세지를 보낸다" 라고 말한다.

데이터를 객체로부터 받아오는 것이 아닌, 객체에게 처리를 요청하는 방식의 코드를 작성해 보자.

class Product {
    private int price = 10000;

    public Product(int price) {
        this.price = price;
    }

    public int getDiscountedPrice() { // 할인된 금액을 반환하도록
        return price * 0.9;
    }
}

public void first(Product product) {
    double discountedPrice = getDiscountedPrice(); // 할인된 금액을 알려줘!
    show(discountedPrice);
}

이렇게 하면 위에서 생겼던 문제들이 다 해결된다.

• 할인된 금액을 사용하는 로직이 수백 개가 있고, 요구사항이 20프로를 할인하도록 변경됐다면?

public int getDiscountedPrice() {
    return price * 0.8; // 20프로 할인
}

Product 클래스의 getDiscountedPrice() 로직만 수정하면 끝이다.

캡슐화가 왜 중요한가?

객체지향 프로그래밍에서 캡슐화는 단순히 데이터를 숨기는 개념을 넘어서, 코드를 더 안정적이고 유지보수하기 쉽게 만들어주는 핵심 원칙이다.

캡슐화를 잘 활용하면

• 유지보수성이 높고
• 변경에 유연하며
• 객체가 스스로 책임을 가지는

탄탄한 코드 구조를 만들 수 있다.

앞으로 코드를 작성할 때 "이 객체가 스스로 처리하도록 만들 수 있을까?" "외부에서 직접 데이터를 조작하지 않도록 보호할 수 있을까?" 이런 질문을 스스로에게 계속해서 던지면서 캡슐화를 적용할 수 있도록 노력해 봐야겠다! 🚀

이 책은 프로그래머뿐만 아니라 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가 등 소프트웨어 개발과 관련된 다양한 역할의 사람들에게 도움이 되는 책이라고 한다.

교보문고에서는 이 책을 다음과 같이 소개하고 있다.

『Clean Code(클린 코드)』는 오브젝트 멘토(Object Mentor)의 동료들과 함께 클린 코드를 만드는 최상의 애자일 기법을 소개하는 책이다. 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여준다. 여러분이 노력만 한다면. 어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 그 코드의 무엇이 옳은지, 그른지 생각해야 한다. 더 나아가, 전문가로서 자신이 지닌 가치와 장인으로서 자신의 작품에 대한 헌신을 돌아보게 된다.

아직 책을 완독하지는 못했지만, 절반 정도 읽으면서 깨달았던 것들이 많다. 그런 깨달음을 잊지 않고 기록으로 남기기 위해 블로그에 정리해본다. 이 기록은 단순히 내용을 정리하는 것뿐만 아니라, 내가 느낀 점을 바탕으로 실천하고 싶은 부분을 되새기기 위함이다.

Clean Code에서 배운 것

보이스카우트 규칙ㅤㅤ

#지속적인 개선

• 잘 짠 코드가 전부가 아니라, 시간이 지나도 언제나 깨끗하게 유지해야 한다.

• *미국 보이스카우트가 따르는 규칙 : 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

• 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.

• 한꺼번에 많은 시간과 노력을투자해 코드를 정리할 필요는 없다.

• 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

이 부분을 보고 지난 내 개발 과정을 떠올려보니, 한 번에 코드를 개선하려다가 점점 복잡해지고 원래 형태를 알아보기 어려워져서 테스트도 힘들어졌던 적이 많았던 것 같다. 결국 깃에서 로컬 변경사항을 버렸던 일도 종종 있었다. 어차피 하루 개발하고 끝낼 코드도 아닌데 왜 그렇게 한 번에 하려고 했는지 모르겠다. 이 단락을 읽고 나서야, 전보다 조금 더 깨끗하게 만드는 게 결국 지속적인 개선으로 이어진다는 것을 깨달았다.

이름을 의미있게 구분하라

#읽는 사람이 차이를 알도록 이름을 지어라

• 불용어를 추가한 이름 역시 아무런 정보도 제공하지 못한다.

• Product 클래스가 있을 때 다른 클래스를 ProductInfo, ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리하는 경우다.

실제로 이렇게 사용했던 적이 있어서 찔렸다. 그러다 보니 매번 "이게 무슨 클래스였더라?" 하고 헷갈리곤 했었다. 시간이 조금 더 걸리더라도, 클래스 이름을 다른 사람이 봤을 때도 바로 이해할 수 있을지 가정해보고 신중하게 지어야겠다는 생각이 들었다.

의미 있는 맥락을 추가하라, 불필요한 맥락을 없애라

• 일반적으로 짧은 이름이 긴 이름보다 좋다. (단, 의미가 분명한 경우에 한해서)

• 아니라면 길더라도 서술적인 이름을 사용하라! 그게 낫다.

• 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

• accountAddress, customerAddress는 Address 클래스 인스턴스로는 좋은 이름이나, 클래스 이름으로는 적합하지 못하다.

  • 차라리 포트 주소, Mac주소, 웹 주소를 구분해야 한다면 PostalAddress, Mac, URI라는 이름이 더 괜찮다.

나도 클래스명을 accountAddress, customerAddress처럼 사용하고 있었다. (이게 맞는 줄 알았다.) 하지만 의미를 명확하게 하고, 불필요한 맥락은 추가하지 않는 게 더 낫다는 것을 이번에 깨달았다.

함수 인수는 적을 수록 좋다.

• 함수 인수는 0개가 이상적인 개수이며, 그 다음은 1개, 2개이고 3개는 가능한 피하는 편이 좋다.

• 4개부터는 특별한 이유가 필요하다. (특별한 이유가 있어도 사용하지마라)

• StringBuffer를 인자로 넘겨줬다고 생각하면 코드를 읽는 사람은 매 함수에서 StringBuffer를 발견할 때마다 이 StringBuffer의 의미를 해석해야 한다.

• 플래그(Flag) 인수는 추하다.

  • 함수는 하나의 작업만 해야한다고 했는데, 플래그 인수를 사용하면 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까.
  • 플래그가 참이면 이걸 하고거짓이면 저걸 한다는 말이니까.

• 이항 함수도 되도록이면 단항 함수로 바꾸려 노력해라.

디미터 법칙

• 잘 알려진 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙

• 즉, 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다. 예)

  // 여러 객체를 한 번에 호출하며 의존성을 노출함
  final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

• 위 같은 코드를 기차 충돌이라고 부른다.

  • 여러 객차가 한 줄로 이어진 기차처럼 보이기 때문 (조잡함)
  • 아래처럼 나누는 편이 좋다. ctxt 객체가 Options을 포함하며, options가 ScratchDir을 포함하고 ScratchDir이 AbsolutePath를 포함한다는 사실을 안다. (그치만 이 예제도 디미터 법칙을 위반하는지 여부는 저것들이 객체인지 자료구조인지에 달렸다)

    // 각 객체가 자신만의 책임을 가지며 유지보수가 용이해짐
    Options opts = ctxt.getOptions();
    File scratchDir = opts.getScratchDir();
    final String outputDir = scratchDir.getAbsolutePath();

코드의 길이를 줄이고 "이렇게 해도 직관적이고 충분히 괜찮지 않나?" 싶어서 어쩔 때는 줄줄 호출하곤 했다. 하지만 각자의 책임을 분리하는 방식이 훨씬 더 좋은 접근이라는 것을 위 내용을 읽고 알게 됐다.

클래스는 작게

• 함수는 작게, 매개변수 목록을 짧게 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 많아진다. 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다.

• 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

• 클래스가 응집력을 잃으면 쪼개라!

• 클래스에 있는 큰 함수를 작은 함수 여러 개로 쪼개다 보면 몇몇 함수가 몇몇 변수만 사용한다? → 독자적인 클래스로 분리해도 되지 않는가! ⇒ 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.

항상 코드를 짜면서 "이럴 땐 어떻게 해야 옳은 걸까? 더 나은 방향은 뭘까?"라는 고민을 많이 했지만, 답을 잘 찾지 못할 때가 많았다. 인터넷에서 검색해도 뭔가 명쾌한 답을 얻기가 어려웠다. 그런데 이런 개발 서적을 읽으니 가려운 곳을 시원하게 긁어주는 기분이다. 왜 진작에 책을 읽지 않았는지 후회가 된다. 물론, 여기 적힌 내용이 항상 정답은 아니겠지만, 내 사고를 확장하는 데에는 충분히 큰 도움이 된다. 이제 다음에 읽을 책은 또 어떤 깨달음을 줄지 기대가 된다.

문제 링크: https://www.acmicpc.net/problem/13164

이 문제는 그리디 알고리즘을 사용하여 풀 수 있는 문제다. 처음부터 그리디 문제라는 것을 알고 접근했지만, 생각보다 최적의 선택을 정하는 과정이 쉽지 않았다.

문제 요약

• 총 N명의 유치원생을 키 기준 오름차순으로 세워논 상태에서 원생들을 K개의 조로 나눈다. ➡️ 이때, 각 조마다 가장 키가 작은 원생과 가장 키가 큰 원생의 키 차이를 구하고 조마다의 키 차이를 합산했을 때 최소가 되도록 조를 나눠야 한다.

• 위처럼 조를 나눈 뒤, 최소 키차이 합을 출력

문제 접근

처음엔 그리디 알고리즘의 원리인 단계마다 최적의 선택을 한다는 큰 틀로 접근했다.

어떤 단계에서 최적의 선택을 해야 할까? 라는 고민에 유치원생 키가 오름차순 정렬된 상태이니, 맨 처음부터 차례대로 최적의 선택을 하면 되지 않을까? 라고 생각했다.

하지만 이렇게 접근하니 문제가 해결되지 않았다. 조의 개수인 K가 정해져 있기도 하고, 단순히 앞에서부터 차례대로 조를 나누는 방식으로는 최적의 결과에 도달할 수가 없었다.

며칠째 시도해보다가 도저히 안되겠어서 푸신 분이 올려준 힌트를 봤다. 힌트를 보고 조금 충격을 받았는데, 그리디에서 중요한 점은 최적의 선택을 어느 순간에서 할지를 알아내는 것임을 깨달았다.

풀이 아이디어

힌트를 바탕으로 내가 이 문제를 풀어낸 방법은 아래와 같다.

K개의 조를 나눌 위치를 찾는 방식에서 최적의 선택을 하고자 했다.

1. 원생들이 나열되어 있을 때 뒤 원생과 키 차이와 해당 원생의 위치를 함께 기록한다.
2. 우선순위 큐를 사용해서 키 차이가 가장 큰 위치가 어딘지 K-1개만큼 알아낸다.

(키 차이가 가장 큰 원생끼리 다른 조로 배치해버리면 최소합을 이룰 수 있기 때문!!) (K-1개인 이유는, 파티션 K-1개를 놓아야 K개의 조가 완성되기 때문) 3. 해당 파티션 위치를 기준으로 조를 이루고 가장 작은 원생과 큰 원생의 키 차이를 계산함. (예를 들어, 파티션 위치가 {3,5}면, → {0,1,2,3}, {4, 5}, {6, 7, ...} 이렇게 3개의 조로 나눔)

최종 풀이 코드 (Java)

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

class Main {
    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int N = Integer.parseInt(st.nextToken());
        int K = Integer.parseInt(st.nextToken());

        int[] array = Arrays.stream(br.readLine().split(" "))
                .mapToInt(Integer::parseInt)
                .toArray();

        PriorityQueue<int[]> q = new PriorityQueue<>(((o1, o2) -> o2[0] - o1[0]));

        for (int i = 0; i < N - 1; i++) {
            q.add(new int[]{array[i + 1] - array[i], i}); // 키 차이가 큰 순으로 내림차순
        }

        int[] partitions = new int[K - 1]; // 차이가 제일 큰 곳부터 다른 조로 쪼개기 위한 파티션 인덱스를 구함.

        for (int i = 0; i < K - 1; i++) {
            partitions[i] = q.poll()[1];
        }

        Arrays.sort(partitions);

        int start = array[0];
        int result = 0;
        for (int i = 0; i < K; i++) {
            if (i == K - 1) { // 마지막일 경우 분기처리
                result += array[N - 1] - start;
                break;
            }
            result += (array[partitions[i]] - start);
            start = array[partitions[i] + 1];
        }

        System.out.print(result);
    }
}

그리디는 쉬운 알고리즘이라고 생각했는데, 이번 문제를 풀면서 생각이 바뀌었다. 그리디 알고리즘의 핵심은 '최적의 선택을 어디에서 할지 정하는 것' 임을 알게 되었고, 그리디 문제를 잘 풀기 위해서는 문제 상황에 따라 최적의 선택 기준을 새롭게 세우는 사고가 중요함을 깨달았다. 더 다양한 유형의 그리디 문제를 풀어보면서 감을 익혀봐야겠다. 😅

우선순위 큐를 사용하는 코딩테스트 문제 여러개를 풀면서 공부하게 된 내용을 적어본다~! (｡◝‿◜｡)

1. 우선순위 큐(PriorityQueue)란?

• 일반적인 큐 : 먼저 들어간 데이터가 먼저 나가는 구조인 FIFO(First-In, First-Out) 형식의 자료구조
• 우선순위 큐 : 들어가는 순서와는 상관없이 우선순위가 높은 데이터가 먼저 나가는 자료구조

자바의 우선순위 큐는 내부적으로 힙(Heap) 자료구조를 사용해 구현되어 있다.

2. PriorityQueue 선언 방법

// 우선순위가 낮은 수가 먼저 나옴, 즉 오름차순
PriorityQueue<Integer> queue = new PriorityQueue<>();

// 우선순위가 높은 수가 먼저 나옴, 즉 내림차순 
// Collections.reverseOrder()는 우선순위를 반대로 뒤집어주는 역할
PriorityQueue<Integer> queue = new PriorityQueue<>(Collections.reverseOrder());

사용 예시

import java.util.PriorityQueue; // 우선순위 큐 사용 시
import java.util.Collections;  // 우선순위 반대로 원할 시

public class A {
    public static void main(String[] args) {
        // 큐1 : 낮은 수부터 나옴 (오름차순)
        PriorityQueue<Integer> queue1 = new PriorityQueue<>();

        // 큐2 : 큰 수부터 나옴 (내림차순)
        PriorityQueue<Integer> queue2 = new PriorityQueue<>(Collections.reverseOrder());

        queue1.offer(1);    // 큐1에 원소 1 추가
        queue1.offer(10);   // 큐1에 원소 10 추가
        queue1.offer(100);  // 큐1에 원소 100 추가

        queue2.offer(1);    // 큐2에 원소 1 추가
        queue2.offer(10);   // 큐2에 원소 10 추가
        queue2.offer(100);  // 큐2에 원소 100 추가

         System.out.println("<큐1 예상결과 : 낮은 수부터 오름차순으로 나옴>");

        while(!queue1.isEmpty()) { // 큐1이 빌 때까지 반복
            // queue1의 첫 번째 값을 꺼냄
            System.out.println("queue1.poll() = " + queue1.poll());
        }

        System.out.println("<큐2 예상결과 : 높은 수부터 내림차순으로 나옴>");

        while(!queue2.isEmpty()) { // 큐2가 빌 때까지 반복
            // queue2의 첫 번째 값을 꺼냄
            System.out.println("queue2.poll() = " + queue2.poll());
        }
    }
}

결과

<큐1 예상결과 : 낮은 수부터 오름차순으로 나옴>
queue1.poll() = 1
queue1.poll() = 10
queue1.poll() = 100
<큐2 예상결과 : 높은 수부터 내림차순으로 나옴>
queue1.poll() = 100
queue1.poll() = 10
queue1.poll() = 1

3. PriorityQueue 기본적인 메서드

• add() : 우선순위 큐에 원소를 추가. 큐가 꽉 찬 경우 에러 발생
• offer() : 우선순위 큐에 원소를 추가. 값 추가 실패 시 false 반환
• remove() : 우선순위 큐에서 첫 번째 값을 반환하고 제거, 비어있으면 에러 발생
• poll() : 우선순위 큐에서 첫 번째 값을 반환하고 제거, 비어있으면 null 반환
• isEmpty() : 우선순위 큐가 비어있는지 확인. 비어있다면 true, 값이 하나라도 있으면 false 반환
• clear() : 우선순위 큐를 초기화
• size() : 우선순위 큐에 포함되어 있는 원소의 수를 반환

4. 우선순위 커스텀하기

코딩테스트를 풀다 보면 이 우선순위를 커스텀하는 부분을 잘 사용할 줄 알아야 한다!

위처럼 일반 정수나 문자열같은 건 기본적으로 정의된 우선순위에 따라서 값이 잘 나온다.

그치만 우선순위를 내 멋대로 커스텀해서 사용할 줄 알아야 한다.

🤔 why? 이차원 배열이나 사용자 정의 객체와 같은건 비교 기준이 없기 때문에 우선순위 큐에 넣으면 우선순위에 따라 정렬하려고 할 때 ClassCastException 에러가 발생한다. 따라서 이러한 데이터를 사용할 때는 정렬 기준을 직접 정의해야 한다.

커스텀 예시

import java.util.PriorityQueue;
import java.util.Comparator;

class Student {
    private int id;       // 학생 ID
    private double grade; // 성적 평균

    public Student(int id, double grade) {
        this.id = id;
        this.grade = grade;
    }

    public double getGrade() {
        return this.grade;
    }

    @Override
    public String toString() {
        return "ID : " + this.id + ", grade : " + this.grade;
    }
}

// 클래스 객체의 우선순위를 위한 클래스
class StudentComparator implements Comparator<Student> {
    @Override
    public int compare(Student s1, Student s2) {
        return Double.compare(s2.getGrade(), s1.getGrade()); // 내림차순
    }
}

public class Main {
    public static void main(String[] args) {
        // 방법 1 : 클래스 정의
        // StudentComparator 클래스에서 비교 기준을 정의하여 사용
        PriorityQueue<Student> queue = new PriorityQueue<>(new StudentComparator());

        // 방법 2 : 익명 클래스 활용
        // 바로 Comparator의 compare 메서드를 오버라이드하여 기준 작성
        PriorityQueue<Student> queue = new PriorityQueue<>(new Comparator<Student>() {
            @Override
            public int compare(Student s1, Student s2) {
                return Double.compare(s2.getGrade(), s1.getGrade()); // 내림차순
            }
        });

        // 방법 3 : 람다식 사용 (가장 간단한 방식)
        // 람다식을 사용해 compare 메서드를 간결히 작성
        PriorityQueue<Student> queue = new PriorityQueue<>((s1, s2) -> Double.compare(s2.getGrade(), s1.getGrade())); // 내림차순

        // 학생 객체 추가
        queue.offer(new Student(1, 88.5));
        queue.offer(new Student(2, 95.2));
        queue.offer(new Student(3, 91.3));

        System.out.println("<예상 결과: 성적 평균이 높은 순으로 출력>");
        while (!queue.isEmpty()) {
            System.out.println(queue.poll());
        }
    }
}

결과

<예상 결과: 성적 평균이 높은 순으로 출력>
ID : 2, grade : 95.2
ID : 3, grade : 91.3
ID : 1, grade : 88.5

예시 설명

• Double.compre(d1, d2) 메서드는 d1과 d2를 비교하여 다음 값을 반환한다. 0 : 두 값이 같음. 1 : d1이 d2보다 큼. -1 : d1이 d2보다 작음.

• 우선순위 큐는 내부적으로 두 요소를 비교할 때 Comparator.compare() 메서드를 사용한다.

• compare() 메서드는 반환값에 따라 요소의 순서를 결정한다. 1 : 순서를 바꿈 → 뒤 요소가 앞에 온다. -1 : 순서를 유지함 → 앞 요소가 그대로 남는다. 0 : 순서를 바꾸지 않음.

  public int compare(Student s1, Student s2) {
      return Double.compare(s2.getGrade(), s1.getGrade()); // 내림차순
   }

  • 위 코드에서 Double.compare(s2.getGrade(), s1.getGrade())는 s2의 성적이 s1보다 클 경우 1을 반환하여 순서를 바꾼다. 결과적으로 성적이 높은 학생이 먼저 나오도록 내림차순 정렬을 정의한 것이다. 👉 즉, 큰 값이 먼저 오도록 우선순위를 설정한 것!

• 람다식 사용

  • 람다식을 사용하게 되면 코드를 간결하게 줄일 수 있다.

    PriorityQueue<Student> queue = new PriorityQueue<>((s1, s2) -> Double.compare(s2.getGrade(), s1.getGrade())); // 내림차순

우선순위 큐가 없었으면 직접 힙을 구현해야 했을 텐데, 생각만 해도 너무 복잡하고 아찔하다. 😅 이렇게 좋은 우선순위 큐를 제공하고 있으니, 제대로 익혀두고 코딩 테스트나 프로젝트에서 잘 써먹어보아야지~ 이번에 제대로 공부한 덕분에 우선순위 큐를 내 마음대로 자유롭게 정의해서 잘 활용할 수 있을 것 같다!

그런데… 새해가 밝은 1월 1일, 릴리즈 이후 처음으로 꽤 심각한 이슈가 발생했다.

🛠️ 이슈 발생 상황

운영 서버와 별개로 테스트용으로 분리해둔 개발 서버에 새로운 글들이 올라오고 있는 것을 발견했다! 확인해보니 안드로이드 앱 업데이트 시 개발 서버의 URL로 API 요청이 가도록 설정되어 있었던 것이 원인이었다. 😱

이로 인해 12월 29일부터 1월 1일까지 총 23명의 유저가 개발 서버에서 회원가입 및 활동을 진행한 사실을 로그를 통해 확인했다. 게다가 문제를 더 심각해진건, 현재 서비스 런칭 기념으로 글 작성자 대상으로 경품 이벤트를 진행하고 있었다는 점이었다..

🚨 긴급 대응 과정

1. 문제 해결 즉시 클라이언트 API URL을 운영 서버로 복구하고 문제를 해결했다.

2. 데이터 정리 개발 서버의 데이터베이스를 확인해 유저들의 이메일을 확보한 후, 이메일로 사과와 재가입 요청을 드렸다. 새로 가입한 유저를 식별하며, 그들이 개발 서버에 등록했던 글과 작품 등 활동 데이터를 운영 서버로 이전하고 있다.

어쨌든 큰 탈 없이 (?) 문제가 해결되는 듯 하고 있는데, 확실히 사람은 큰 일 나봐야 정신 차린다고 .... 백엔드쪽에 개선할 것이 많다고 느껴졌다.

💡 이번 이슈에서 느낀 개선점

1️⃣ 유저 가입 일시 미저장 문제

현재 서비스의 User 테이블에는 유저의 가입 일시를 저장하지 않고 있었다. 초기 설계 당시, "유저 가입 일시는 쓸 일이 없을 것 같다"는 판단 하에 제외했던 것인데, 이번 사건으로 그 판단이 얼마나 잘못되었는지를 뼈저리게 깨달았다.

왜냐하면 개발 서버 DB만으로는 12월 29일부터 가입한 유저를 정확히 식별할 방법이 없었기 때문이다. 결국 이를 계기로 유저 가입 일시를 저장하도록 데이터베이스 구조를 변경했다.

2️⃣ 신규 유저 모니터링 부족

이번 이슈에서 이 문제가 4일 동안 (12/29~1/1) 발견되지 않은 점이 특히 아쉬웠다. 신규 유저 가입 이벤트를 실시간으로 확인할 방법이 없었던 것이 문제였다. 그래서 신규 유저 가입 알림 기능을 디스코드 알람으로 구축하기로 했다.

🛠️ 알람 시스템 개편 기존의 디스코드 알람은 글 신고와 회원 탈퇴 관련 알람만 존재했고, 개발 서버와 운영 서버의 알람이 혼재되어 있었다. 이번 기회에 알람 시스템을 전면 개편했다!

1. 서버별 알람 공간 분리 운영 서버와 개발 서버 각각의 디스코드 채널을 별도로 설정.

2. 이벤트별 알람 채널 분리 신규 유저 가입, 글 신고, 회원 탈퇴 등 이벤트별 채널을 나눠 알람 발생.

3. 웹훅 URL 자동화 설정 CI/CD 과정에서 배포 서버에 따라 적합한 디스코드 웹훅 URL을 설정하도록 yml 파일을 활용해 자동화.

이로써 유저 가입 알람을 통해 신규 사용자 가입 추이를 실시간으로 확인할 수 있게 되었고, 이번과 같은 이슈가 발생하더라도 빠르게 대처할 수 있는 환경을 만들었다.

✨ 이번 경험의 교훈

처음 개발 서버에서 유저 데이터가 쌓이고 있는 걸 확인했을 때는 정말 머리가 하얘졌다. 하지만 결국 문제는 해결할 방법이 있다는 사실을 다시금 깨달았다. 이번 일을 계기로 서비스의 안정성과 관리 효율성을 한 단계 끌어올릴 수 있었고, 앞으로 더 나은 서비스를 위해 고민해야 할 점들도 명확히 알게 되었다.

서비스 운영에서 실수는 피할 수 없지만, 그 실수를 통해 배우고 성장하는 것이 진정한 발전이 아닐까? 💪

이번 글에서는 애플 소셜 로그인 백엔드 부분을 구현하면서 겪었던 시행착오와 해결 과정을 공유하려고 한다!

2024년 3월 이후, iOS 앱이 타사 소셜 로그인 서비스를 이용하는 경우 필수였던 애플 소셜 로그인 요건이 해제되었지만, 여전히 데이터 수집 범위는 이메일 주소로 제한되어야 한다는 새로운 조건이 추가됨. - Apple 앱 심사지침 공식문서

애플의 정책 변화로 인해 기존에는 필수였던 애플 소셜 로그인 요건이 완화되었지만, 사용자 경험 향상을 위해 서비스에 애플 소셜 로그인 기능을 도입하기로 결정했다.

겪은 시행착오

1. 로컬 환경에서 테스트가 불가능하여, ngrok을 활용한 애플 소셜 로그인 작동 테스트

2. 애플 소셜 유저가 탈퇴 시 해당 토큰을 어떻게 취소할지에 대한 문제 (탈퇴 직전 재로그인 처리 vs 유효기간이 없는 리프레시 토큰을 DB에 저장하여 관리)

3. 자꾸 발생하는 client_id 오류

1. 로컬 환경에서 테스트가 불가한 애플 소셜 로그인

애플 공식문서

애플이 제공하는 소셜 로그인 REST API는 로컬 환경에서 테스트가 불가능하도록 설계되어 있다.

코드 구현은 완료했지만 로컬 환경에서 테스트할 수 없었기 때문에, 방법을 모색하던 중 외부 네트워크에서 로컬 환경으로 접근할 수 있는 터널링 프로그램인 ngrok을 알게 되었다. ngrok은 HTTPS로 연결할 수 있는 기능도 제공하기 때문에 이 문제를 해결하는 데 적합하다고 판단했다.

ngrok을 활용한 애플 소셜 로그인 작동 테스트

% brew install ngrok

위 명령어를 통해 ngrok을 설치한다.

로컬 환경에서 ngrok을 실행시키면 세션 유지 시간이 기본적으로 2시간으로 제한되기 때문에, 세션이 만료되면 명령어를 통해 포워딩을 다시 시작해야 한다.

이때, 다시 시작된 포워딩 URI가 변경되어 기존에 설정해 둔 경로를 사용할 수 없게 되므로, Redirect URI 값이 고정되어야 하는 애플 소셜 로그인에는 사용하기 어렵다.

다행히도, ngrok에서 회원가입을 하면 URI를 고정시킬 수 있는 기능을 제공한다. 회원가입 후 아래 명령어를 터미널에 입력하여 고정된 URI를 사용할 수 있다.

이제 아래 명령어로 ngrok을 실행시켜주면 끝이다!

% ngrok http localhost:8080

ngrok을 실행하면 위와 같은 화면이 나타나고, 애플 개발자 계정에 이 포워딩 주소를 이용하여 Redirect URI를 설정한 후 테스트를 진행하면 된다.

하단에는 어떤 요청이 들어왔고, 어떤 상태 코드를 반환했는지 실시간으로 기록된다. (에러가 난게 찍혔다 하하)

ngrok의 자세한 사용법은 ngrok 공식문서에서 확인할 수 있다.

이 방법으로 애플 소셜 로그인 테스트를 마치고 1차 배포를 무사히 완료했다. 😃

2. 애플 탈퇴 토큰 관리

두 번째로 문제가 되었던 부분이다.

애플 소셜 로그인을 통해 서비스에 가입한 사용자가 탈퇴를 원할 경우, 애플 서버에서 사용자의 연결을 끊는 과정이 필요하다. 이는 애플에서 제공하는 (공식문서)에 설명되어 있다.

이 과정에서 보이는 것처럼, token 값이 필요하다.

이 token 값은 사용자가 로그인할 때 발급받을 수 있는 정보이며, 토큰의 종류는 총 두 가지로 나뉜다.

• 만료 기간이 1시간인 access_token
• 만료 기간이 없는 refresh_token이다.

처음 구현 방식에서는 사용자가 탈퇴 직전에 클라이언트 측에서 재로그인을 통해 access_token 과 refresh_token을 다시 발급받고, 서버가 이 정보를 받아 애플 서버에 토큰 취소 요청을 보내도록 했다.

이 방식 자체에는 문제가 없었으나, 클라이언트 측에서 플로우가 다소 불편한 부분이 있었고, 사용자가 탈퇴하려면 재로그인하는 부분이 어색하게 느껴질 수 있었다.

이에 따라, 사용자가 탈퇴 직전에 재로그인하지 않고, 최초 로그인 시 발급받은 정보를 저장해 두었다가 탈퇴 시 사용하는 것이 더 나을 것이라는 제안을 받았다.

하지만, 아래와 같은 우려가 따라왔다. '탈퇴할지 모르는 사용자의 탈퇴를 위한 정보를 데이터베이스에 저장해 둔다는 것이 과연 적절한가? 이는 성능 저하를 불러오지 않을까?'

그러나 Apple 토큰의 값은 JWT 형식의 일반 문자열이다. 이러한 토큰 정보를 사용자마다 하나씩 저장한다고 해서 성능에 미치는 영향은 매우 미미할 것이라고 판단했고, 서비스 자체가 아주 많은 고객을 거느리고 있지 않기 때문에 성능 우려는 크지 않았다.

또한, 새로운 방식의 경우 처음 로그인 시 발급받은 refresh_token은 만료 기간이 없고, 이 토큰을 사용해 탈퇴를 처리할 수 있어 재로그인 및 추가적인 토큰 발급 과정이 필요 없다는 점에서 훨씬 간편하다는 이점이 있었다. 이러한 이유로 새로운 방식을 채택하기로 결정했다.

따라서 애플 사용자 탈퇴 로직은 아래와 같이 최종적으로 선정했다.

1. 탈퇴 API 호출
2. DB에서 해당 사용자의 Apple refresh_token 값 조회
3. Apple 서버에 refresh_token으로 해당 사용자 토큰 취소 요청
4. DB에서 사용자 삭제

3. 자꾸 발생하는 client_id 오류

애플 서버에 소셜 로그인 요청을 보낼 때, 500 에러가 발생하여 로그를 확인해본 결과, 아래와 같은 에러 메시지가 나타났다.

400 Bad Request: {"error":"invalid_grant","error_description":"client_id mismatch. The code was not issued to {client_id값}."}

해당 에러는 토큰 발급 요청 시 전달된 client_id 값이 애플 서버에서 기대하는 값과 일치하지 않는 경우 발생한다.

문제를 확인해본 결과, 애플 로그인에서 client_id 값은 특정 상황에 따라 서로 다른 두 가지 ID를 사용해야 하며, 이를 잘못 지정한 것이 원인이었다.

애플 로그인을 구현할 때, 아래와 같이 App IDs와 Service IDs라는 두 가지 ID를 생성하게 된다. 이 두 ID는 로그인 방식에 따라 다르게 사용해야 하고, 잘못된 ID를 사용하면 인증 요청이 실패하게 된다.

1. App IDs 사용 시점: iOS 앱 내에서 로그인 연동을 진행하는 경우. 설명: iOS 앱의 Bundle ID를 기반으로 생성되며, 애플 앱 생태계에서 인증 요청을 처리할 때 사용된다.

2. Service IDs 사용 시점: 웹사이트 또는 웹뷰 환경에서 로그인 연동을 진행하는 경우. 설명: 웹 기반 서비스에서 애플 로그인을 처리하기 위해 별도로 생성한 ID로, 애플 Developer Console에서 설정한 Service ID와 일치해야 한다.

우리 서비스에서는 앱 내부에서 로그인을 진행하고 있었지만, 잘못된 ID(Service IDs)를 client_id로 전달하고 있었다. 이를 앱 환경에 맞는 App IDs로 변경한 후, 애플 서버와의 인증이 정상적으로 이루어졌다!

애플 소셜 로그인은 다른 소셜 로그인보다 더 까다로운 점이 많아 처음 도입할 때 시행착오를 많이 겪었다. 특히 테스트 환경의 제약이나 탈퇴 토큰 관리 같은 부분은 예상치 못했던 도전 과제였다. 이번 글을 통해 내가 겪은 문제와 해결 과정을 공유하면서, 비슷한 어려움을 겪고 있는 사람들에게 조금이라도 도움이 되었으면 한다. 😊

디스코드 설정

웹훅(webhook)은 Discord 채널에 메시지를 게시하는 간편한 방법입니다. - Discord webhook 공식 문서

먼저 사용 중인 팀 디스코드 서버에 웹훅을 생성해 줘야 한다.

별다른 과정 없이 바로 생성이 가능하다. 생성 후 사진처럼 이름과 알림을 받을 채널을 등록해 줘야 한다. 그리고 저 웹후크 URL을 복사해두면 된다!

Spring 프로젝트에 웹훅 연동하기

Discord가 제공하는 웹훅 공식 문서에 따르면 다양한 옵션들을 사용할 수 있는데, 우리는 간단한 알림만 받아보면 됐었기에 내용(content) 파라미터만 사용했다.

public record DiscordWebhookMessage(
        String content
) {
    public static DiscordWebhookMessage of(String content) {
        if (content.length() >= 2000) {
            content = content.substring(0, 1993) + "\n...```";
        }
        return new DiscordWebhookMessage(content);
    }
}

메세지를 담을 클래스를 만들어줬다. 신고 내용이 너무 길면 가독성이 떨어질 수 있어서, 메시지 길이를 2000자 이하로 제한하는 코드를 추가해주었다.

import static org.websoso.WSSServer.domain.common.ReportedType.IMPERTINENCE;
import static org.websoso.WSSServer.domain.common.ReportedType.SPOILER;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import org.websoso.WSSServer.domain.Comment;
import org.websoso.WSSServer.domain.Feed;
import org.websoso.WSSServer.domain.User;
import org.websoso.WSSServer.domain.common.ReportedType;

public class MessageFormatter {

    private static final String DATE_TIME_FORMAT = "yyyy-MM-dd HH:mm";

    private static final String FEED_REPORT_MESSAGE =
            "```[%s] 피드 %s 신고가 접수되었습니다.\n\n" +
                    "[신고된 피드 작성자]\n" +
                    "유저 아이디 : %d\n" +
                    "유저 닉네임 : %s\n\n" +
                    "[신고된 피드 내용]\n%s\n\n" +
                    "[신고 횟수]\n총 신고 횟수 %d회.\n" +
                    "%s\n```";

    private static final String COMMENT_REPORT_MESSAGE =
            "```[%s] 피드 댓글 %s 신고가 접수되었습니다.\n\n" +
                    "[신고된 댓글 작성자]\n" +
                    "유저 아이디 : %d\n" +
                    "유저 닉네임 : %s\n\n" +
                    "[신고된 댓글 내용]\n%s\n\n" +
                    "[신고 횟수]\n총 신고 횟수 %d회.\n" +
                    "%s\n```";

    public static String formatFeedReportMessage(Feed feed, ReportedType reportedType, int reportedCount,
                                                 boolean isHidden) {
        String hiddenMessage = isHidden ? "해당 피드는 숨김 처리되었습니다." : "해당 피드는 숨김 처리되지 않았습니다.";

        return String.format(
                FEED_REPORT_MESSAGE,
                LocalDateTime.now().format(DateTimeFormatter.ofPattern(DATE_TIME_FORMAT)),
                reportedType.getDescription(),
                feed.getUser().getUserId(),
                feed.getUser().getNickname(),
                feed.getFeedContent(),
                reportedCount,
                hiddenMessage
        );
    }

    public static String formatCommentReportMessage(Comment comment, ReportedType reportedType, User user,
                                                    int reportedCount, boolean isHidden) {
        String hiddenMessage = "해당 댓글은 현재 숨김 처리되지 않은 상태입니다.";
        if (isHidden) {
            if (reportedType.equals(SPOILER)) {
                hiddenMessage = "해당 댓글은 스포일러 댓글로 지정되었습니다.";
            } else if (reportedType.equals(IMPERTINENCE)) {
                hiddenMessage = "해당 댓글은 부적절한 내용으로 인해 숨김 처리되었습니다.";
            }
        }

        return String.format(
                COMMENT_REPORT_MESSAGE,
                LocalDateTime.now().format(DateTimeFormatter.ofPattern(DATE_TIME_FORMAT)),
                reportedType.getDescription(),
                user.getUserId(),
                user.getNickname(),
                comment.getCommentContent(),
                reportedCount,
                hiddenMessage
        );
    }
}

그리고 알림의 내용 포맷을 정의할 클래스를 만들어줬다. 피드와 댓글 신고 알림 메시지는 서로 다른 양식을 사용하기 때문에 신고된 콘텐츠의 종류와 상태에 따라 자동으로 알맞은 메시지를 포맷팅하도록 했다.

import static org.springframework.http.HttpMethod.POST;
import static org.springframework.http.HttpStatus.NO_CONTENT;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import org.websoso.WSSServer.domain.common.DiscordWebhookMessage;

@Service
@Slf4j
public class MessageService {

    @Value("${logging.discord.webhook-url}")
    String discordWebhookUrl;

    public void sendDiscordWebhookMessage(DiscordWebhookMessage message) {
        try {
            HttpHeaders httpHeaders = new HttpHeaders();
            httpHeaders.add("Content-Type", "application/json; utf-8");
            HttpEntity<DiscordWebhookMessage> messageEntity = new HttpEntity<>(message, httpHeaders);

            RestTemplate template = new RestTemplate();
            ResponseEntity<String> response = template.exchange(
                    discordWebhookUrl,
                    POST,
                    messageEntity,
                    String.class
            );

            if (response.getStatusCode().value() != NO_CONTENT.value()) {
                log.error("메시지 전송 이후 에러 발생");
            }

        } catch (Exception e) {
            log.error("에러 발생 :: " + e);
        }
    }
}

이제 마지막으로 실제로 디스코드와 통신해 메세지를 전송할 서비스 클래스를 만들어준다. 디스코드 웹훅 URL은 복사해두었던 것을 그대로 사용하되, 주소가 공개되면 안되기 때문에 yml 파일에 등록해주었다. RestTemplate를 이용하여 POST로 디스코드 웹훅에게 알림을 요청하고 있는 것을 확인할 수 있다.

실제로 신고가 발생하면 알림이 잘 발송되었다 🙌

이렇게 디스코드 웹훅을 사용해서 신고 발생 시 디스코드 채널에 실시간으로 알림을 전송해, 팀원들이 바로 신고 내용을 확인할 수 있도록 구현했다. 비교적 간편하게 구현이 가능해서 간단한 로그를 확인하는 데 유용하게 사용이 가능할 것 같다!

크게 3개의 요소로 구성되어 있다.

• JUnit 플랫폼
  • 테스팅 프레임워크를 구동하기 위한 런처와 테스트 엔진을 위한 API를 제공한다.
• JUnit 주피터
  • JUnit 5를 위한 테스트 API와 실행 엔진을 제공한다.
• JUnit 빈티지
  • JUnit 3과 4로 작성된 테스트를 JUnit 5 플랫폼에서 실행하기 위한 모듈을 제공한다.

JUnit 5 build.gradle 설정

dependencies {
    testImplementation('org.junit.jupiter:junit-jupiter:5.5.0')
}
test {
    useJUnitPlatform()
}

• junit-jupiter 의존 추가
• test 태스크 JUnit 5 플랫폼 사용하도록 설정

Test 어노테이션과 테스트 메서드

JUnit을 이용해서 테스트 코드 만드는 법

• 테스트로 사용할 클래스를 만들고 @Test 어노테이션을 메서드에 붙이기만 하면 된다.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class SumTest {

    @Test
    void sum() {
        int result = 2 + 3;
        assertEquals(5, result);
    }
}

• 테스트 클래스의 이름은 보통 다른 클래스와 구분을 쉽게 하기 위해 ‘Test’를 접미사로 붙인다.
• @Test 어노테이션을 붙인 메서드는 private이면 안 된다.

주요 단언 메서드

Assertions 클래스는 여러 단언 메서드를 제공한다.

assertEquals() 메서드

• 주요 타입별로 존재한다.
  • int 타입을 위한 assertEquals() 메서드, Long 타입을 위한 assertEquals() 메서드 등
• assertEquals(expected, actual)
  • 첫 번째 인자가 기대하는 값이고 두 번째 인자가 검사하려는 값이다.

fail() 메서드

• 테스트에 실패했음을 알리고 싶을 때 사용한다.
• e.g) 파라미터 값이 null이면 IllegalArgumentException이 발생하도록 구현한 상태에서 null을 전달했는데, 익셉션이 발생하지 않으면 테스트에 실패했다고 볼 수 있다.

try {
    AuthService authService = new AuthService();
    authService.authenticate(null, null);
    fail(); // 이 지점에 다다르면 fail()메서드는 테스트 실패 에러를 발생
} catch(IllegalArgumentException e) {
}

but, 익셉션 발생 유무가 검증 대상이라면 fail() 메서드를 사용하는 것보다 따로 제공하는 익셉션 발생 유무 검사 메서드를 사용하는 것이 더욱 명시적이다.

assertThrows()

assertThrows() 을 이용해서 지정한 익셉션이 발생하는지 검사하는 코드

assertThrows(IllegalArgumentException.class,
    () -> {
        AuthService authService = new AuthService();
        authService.authenticate(null, null);
    });

• assertThrows() 메서드는 발생한 익셉션 객체를 리턴한다.
• 발생한 익셉션을 이용해서 추가로 검증이 필요하다면 assertThrows() 메서드가 리턴한 익셉션 객체를 사용하면 된다.

assertThrows(IllegalArgumentException.class,
    () -> {
        AuthService authService = new AuthService();
        authService.authenticate(null, null);
    });
assertTure(thrown.getMessage().contains("id"));

assertAll()

• assert 메서드는 실패하면 다음 코드를 실행하지 않고 바로 익셉션을 발생한다.
• 하지만, 경우에 따라 일단 모든 검증을 실행하고 그중에 실패한 것이 있는지 확인하고 싶을 때, assertAll() 메서드를 사용할 수 있다.

assertAll(
        () -> assertEquals(3, 5/2),
        () -> assertEquals(4, 2*2),
        () -> assertEquals(6, 11/2)
);

• assertAll() 메서드는 실행 결과로 검증에 실패한 코드가 있으면 그 목록을 모아서 에러 메세지로 보여준다.

테스트 라이프사이클

• 간단한 테스트 코드 예

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class LifecycleTest {
    public LifecycleTest() {
        System.out.println("new LifecycleTest");
    }

    @BeforeEach
    void setUp() {
        System.out.println("setUp");
    }

    @Test
    void a() {
        System.out.println("A");
    }

    @Test
    void b() {
        System.out.println("B");
    }

    @AfterEach
    void tearDown() {
        System.out.println("tearDown");
    }
}

• 실행 결과

~ 결과를 보고 알 수 있는 사실 ~

• @Test 메서드를 실행할 때마다 객체를 새로 생성한다.
• 테스트 메서드를 실행 하기 전과 후에 @BeforeEach 어노테이션과 @AfterEach 어노테이션을 붙인 메서드를 실행한다.

@BeforeEach 어노테이션

• 테스트를 실행하는데 필요한 준비 작업을 할 때 사용한다.
  • 테스트에서 사용할 임시 파일, 객체 등을 생성

@AfterEach 어노테이션

• 테스트를 실행한 후에 정리할 것이 있을 때 사용한다.
  • 테스트에서 사용한 임시 파일을 삭제해야 할 때 등

💡 @BeforeEach, @AfterEach 어노테이션을 붙인 메서드는 @Test 어노테이션과 마찬가지로 private면 안 된다.

@BeforeAll 어노테이션

• 한 클래스의 모든 테스트 메서드가 실행되기 전에 특정 작업을 수행해야 할 때 사용한다.
• 정적 메서드에 붙여서 사용하는데, 이 메서드는 클래스의 모든 테스트 메서드를 실행하기 전에 한 번 실행된다.

@AfterAll 어노테이션

• 클래스의 모든 테스트 메서드를 실행한 뒤에 실행된다.
• 정적 메서드에 적용한다.

테스트 메서드 간 실행 순서 의존과 필드 공유하지 않기

• 테스트 메서드가 특정 순서대로 실행된다는 가정하에 테스트 메서드를 작성하면 안 된다.
• 테스트 메서드를 작성한 순서에 상관 없이 테스트 순서가 결정된다.
  • 메서드간의 순서가 의존되어 있다면 순서가 달라졌을 때 테스트는 실패한다.

즉, 각 테스트 메서드는 서로 독립적으로 동작해야 하고, 한 테스트 메서드의 결과에 따라 다른 테스트 메서드의 실행 결과가 달라지면 안 된다.

→ 테스트 메서드가 서로 필드를 공유하거나 실행 순서를 가정하고 테스트를 작성하지 말아야 한다!

@DisplayName 어노테이션

자바는 메서드 이름에 공백이나 특수 문자를 사용할 수 없기 때문에 메서드 이름만으로 테스트 내용을 설명하기가 부족할 수 있기에 @DisplayName 어노테이션을 사용해서 테스트에 표시 이름을 붙인다.

@DisplayName("라이프사이클 테스트")
public class LifecycleTest {
    @DisplayName("에이!")
    @Test
    void a() {
        System.out.println("A");
    }

    @Test
    void b() {
        System.out.println("B");
    }
}

@Disabled 어노테이션

• 특정 테스트를 실행하지 않고 싶을 때 사용한다.
• @Disabled 어노테이션이 붙은 클래스나 메서드는 테스트 실행 대상에서 제외한다.
• 아직 테스트 코드가 완성되지 않았거나 잠시 동안 테스트를 실행하지 말아야 할 때 이 어노테이션을 사용한다.

모든 테스트 실행하기

src/test/java 폴더에서 테스트를 실행하면 된다.

초반에 복잡한 테스트부터 시작하면 안되는 이유

• 초반부터 다양한 조합을 검사하는 복잡한 상황을 테스트로 추가하면 해당 테스트를 통과시키기 위해 한 번에 구현해야 할 코드가 많아진다.

e.g. 비밀번호 검사 테스트

👉 다음과 같은 순서로 테스트를 만들어보자.

1. 대문자 포함 규칙만 충족하는 경우
2. 모든 규칙을 충족하는 경우
3. 숫자를 포함하지 않고 나머지 규칙은 충족하는 경우
   

1. 대문자 포함 규칙만 충족하는 경우 테스트

• 테스트 코드 작성

@Test
void 대문자_포함_규칙만_충족() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("abcDef");
    assertEquals(PasswordStrength.WEAK, result);
}

• 구현

public class PasswordStrengthMeter {
    public PasswordStrength meter(String s) {
        return PasswordStrength.WEAK;
    }
}

2. 모든 규칙을 충족하는 경우 테스트

• 테스트 코드

@Test
void 모든_규칙_충족() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("abcDef12");
    assertEquals(PasswordStrength.STRONG, result);
}

• 구현 - 가장 간편한 구현을 함.

public class PasswordStrengthMeter {
    public PasswordStrength meter(String s) {
        if("abcDef12".equals(s)) return PasswordStrength.STRONG;
        return PasswordStrength.WEAK;
    }
}

🤔 이 때, 새로운 테스트 케이스를 추가한다면?

• 테스트 케이스 추가

@Test
void 모든_규칙_충족() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("abcDef12");
    assertEquals(PasswordStrength.STRONG, result);
    PasswordStrength result2 = meter.meter("aZcDef12");
    assertEquals(PasswordStrength.STRONG, result2);**
}

어떻게 해야 테스트를 통과할 수 있을까 ? …

👉 문자열이 "abcDef12" 나 "aZcDef12" 면 STRONG을 리턴하고 나머지는 WEAK를 리턴하게 구현할까?

그러면 케이스를 추가할 때마다 if 절이 늘어나겠네..

😬 모든 케이스를 이렇게 구현할 수는 없다!!

두번째 테스트를 통과시키려면 모든 규칙을 확인하는 코드를 벌써 구현해야 할 것 같다.

→ 막막하다.

• 이런 상황이 오지 않으려면?

구현하기 쉬운 테스트부터 시작하기

첫 번째 선택

• 모든 조건을 충족하는 경우
• 모든 조건을 충족하지 않는 경우

이 두 가지 경우는 모두 그냥 해당 값인 STRONG 또는 WEAK를 리턴하면 된다.

아무거나 선택한다.

<테스트 순서>

1. 모든 조건을 충족하는 경우

두 번째 선택

• 모든 규칙을 충족하지 않는 경우
• 한 규칙만 충족하는 경우
• 두 규칙을 충족하는 경우

모든 규칙을 충족하지 않는 경우는 난감하다.

첫 번째 테스트를 모든 조건을 충족하는 경우를 선택했기 때문이다.

나머지 두 경우는 난이도가 비슷할 것 같다.

<테스트 순서>

1. 모든 조건을 충족하는 경우
2. 한 규칙만 충족하는 경우
3. 두 규칙을 충족하는 경우

그리고 마지막에 모든 조건을 충족하지 않는 경우를 테스트 해주면 된다.

최종 테스트 순서

<테스트 순서>

1. 모든 조건을 충족하는 경우
2. 한 규칙만 충족하는 경우
3. 두 규칙을 충족하는 경우
4. 모든 조건을 충족하지 않는 경우

예외 상황을 먼저 테스트 해라

• 예외 상황을 전혀 고려하지 않은 코드에 예외 상황을 반영하려면?

  • 코드의 구조를 뒤집거나,

  • 코드 중간에 예외 상황을 처리하기 위해 조건문을 중복해서 추가해야 함.

    ⇒ 코드를 복잡하게 만들어 버그 발생 가능성 ⬆

초반에 예외 상황을 테스트하면 얻는 이점

• 예외 상황에 따른 코드의 구조가 미리 만들어짐.
  • 코드 구조의 변경이 줄어듬.
• 개발을 하는 동안의 예외 상황을 처리하지 않아 발생하는 버그를 줄여줌.
  • 사전에 예외 상황을 찾고 테스트하면 예외 상황으로 인한 곤란을 겪지 않을 수 있음!

~ TDD 시 얻는 이점 ~

완급 조절

• TDD가 익숙해지면 상황에 따라 구현 속도를 조절할 수 있게 된다.

한 번에 기능 구현을 시도했는데 잘 안된다면 한발 물러서서 천천히 아래 단계를 밟아가면 된다.

1. 정해진 값을 리턴
2. 값 비교를 이용해서 정해진 값을 리턴
3. 다양한 테스트를 추가하면서 구현을 일반화

지속적인 리팩토링

• TDD 에서는 테스트를 통과한 뒤에는 리팩토링을 진행한다.

  • 매번 해야 하는 것은 아님.
  • 적당한 후보가 보이면 진행

• TDD를 진행하는 과정에서 지속적으로 리팩토링을 진행하면 코드 가독성이 높아진다.

  • 코드 가독성이 높아지면 개발자는 더욱 빠르게 코드 분석 가능

  • 수정 요청이 있을 때 변경할 코드 빠르게 찾을 수 있음.

  • ⇒ 코드 변경의 어려움을 줄여주어 향후 유지보수에 도움이 된다.*

    
    

TDD · 기능 명세 · 설계

기능 명세

• 크게 입력과 결과로 나눌 수 있다.
  • 입력은 기능을 실행하는데 필요한 값
  • 결과는 기능을 실행했을 때 얻는 값

e.g) 로그인 기능

• 입력
  • 아이디와 암호
• 결과
  • 아이디와 암호가 일치하면 성공
  • 아이디와 암호가 일치하지 않으면 실패

public String login(String id, String pw) {
    User user = getUser(id);
    if (!user.matchPassword(pw)) {
        throw new IdPwNotMatchException();
    }
    return "로그인 되었습니다.";
}

• 입력

  • 입력은 보통 메서드의 파라미터로 전달한다.
    • id
    • pw

• 결과

  • 결과 형식은 여러 형식으로 정의할 수 있다.
  • 리턴값과 익셉션을 결과로 사용했다.
    • "로그인 되었습니다."
    • IdPwNotMatchException

• ‘결과’ 에는 변경도 포함한다.

  • e.g) 회원 가입 기능
    • 실행 결과 : DB에 회원 정보 추가 ← 리턴값이 없는 ‘변경’

기능 명세로부터 설계가 시작되는 과정

스토리보드를 포함한 다양한 형태의 요구사항 문서를 이용해, 기능 명세 구체화

➡ 기능 명세를 구체화하는 동안 입력과 결과를 도출하고, 도출한 기능 명세를 코드에 반영

➡ 기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정됨.

➡ 이는 곧 기능에 대한 설계 과정과 연결됨.

설계 과정을 지원하는 TDD

• TDD는 테스트를 만드는 것부터 시작.
• 테스트 코드를 먼저 만들기 위해 필요한 것
  • 테스트할 기능을 실행
  • 실행 결과를 검증

테스트할 기능을 실행

• 기능을 실행할 수 없으면 테스트를 할 수 없다.
  • 즉, 테스트에서 실행할 수 있는 객체나 함수가 존재해야 한다.
    • e.g) 테스트 대상이 되는 클래스와 메서드 이름 결정
    • e.g) 메서드를 실행할 때 사용할 인자의 타입, 개수 결정

실행 결과를 검증

• 실행 결과를 어떻게 검증할지 고민한다.
  • e.g) 리턴 값을 이용해서 검증하는 테스트
    • 리턴 타입을 결정

⇒ 이렇게 TDD에서 테스트를 작성할 때 고민하는 부분은 곧 설계 과정과 유사하다.

💡 즉, TDD 자체가 설계는 아니지만, TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계를 진행하게 된다!

필요한 만큼 설계하기

• TDD는 테스트를 통과할 만큼만 코드를 작성한다.
  • 즉, TDD로 개발을 진행하면 현시점에서 테스트를 통과시키는데 필요한 만큼의 코드만 만들게 된다.
• 필요할 것으로 예측해서 미리 설계를 유연하게 만들지 않는다.

👉 이를 통해 설계가 불필요하게 복잡해지는 것을 방지할 수 있으며, 요구사항이 바뀌더라도 TDD는 미리 앞서서 코드를 만들지 않으므로 불필요한 구성 요소를 덜 만들게 된다.

기능 명세 구체화

• 개발자는 보통 기획자가 작성한 스토리보드나 와이어프레임과 같은 형태로 요구사항 명세를 전달 받는다.
  • 이런 문서는 사용자나 기획자가 보기에는 적당할지 모르나 개발자가 기능을 구현하기에는 생략된 내용이 많다.
• 테스트 코드를 작성하려면 파라미터와 결과 값을 정해야 하므로 개발자는 요구사항 문서에서 기능의 입력과 결과를 도출해야 한다.

⇒ 테스트 코드를 통해 개발자는 기능 명세를 구체화할 수 있다.

• 모호한 상황을 만나면 이를 구체적인 예로 바꾸어 테스트 코드에 반영한다.

• 예

  요구사항 : 서비스를 사용하려면 매달 1만원을 선불로 납부한다. 납부일 기준으로 한 달 뒤가 서비스 만료일이 된다.

  • 4월 1일에 만원을 납부하면 만료일은 4월 30일? 5월 1일?

  • 1월 31일에 만원을 납부하면 만료일은 2월 28일? 3월 2일?

    위와 같이 모호한 상황이 생긴다면 기획자와의 소통으로 답을 얻은 뒤, 이를 구체적인 예로 바꾸어 테스트에 구현한다.

  • 이는 예를 이용한 구체적인 명세가 된다.

    • 구체적인 예는 개발자가 요구사항을 더 잘 이해할 수 있게 만들고,

      모호함을 없애 주어 개발자가 올바르게 동작하는 기능을 만들 수 있게 한다.

👉 TDD는 처음 접하는 보드게임을 익히는 과정과 유사하다.

처음 접하는 보드게임을 하려면 게임 규칙을 배운다. 하지만 규칙을 들었다고 해서 바로 완벽하게 이해를 하는 것은 어렵고 실제 게임을 진행하면서 다양한 상황에 규칙을 적용하다 보면 규칙을 점차 이해하게 된다. TDD도 이와 유사하게 구체적인 예를 이용해서 테스트 코드를 추가하다 보면 기능 명세를 보다 잘 이해하고 모호함을 없앨 수 있다!

이 글을 읽는 모두, 좋은 하루 되세요. 😸

1. 생성하기 : 스트림 인스턴스 생성
2. 가공하기 : 필터링 및 맵핑 등 원하는 결과를 만들어가는 중간 작업
3. 결과 만들기 : 최종적으로 결과를 만들어내는 작업

전체 -> 맵핑 -> 필터링 1 -> 필터링 2 -> 결과 만들기 -> 결과물

스트림 특징

• 데이터를 변경하지 않는다.
  • 원본 데이터로부터 데이터를 읽기만 할 뿐, 원본 데이터 자체를 변경하지 않는다.
• 일회용이다.
  • 한 번 사용하면 닫혀서 재사용이 불가능하다.
• 작업을 내부 반복으로 처리한다.
  • 반복문을 메서드의 내부에 숨길 수 있다는 것 (반복문이 코드 상에 노출되지 않는다.)
    

일반 스트림과 특화 스트림

일반스트림?

Stream, Stream 과 같은 것들

특화 스트림?

자바 스트림 API는 숫자 스트림을 효율적으로 처리할 수 있도록 세 가지 기본형 특화 스트림을 제공한다.

IntStream, DoubleStream, LongStream

• 기본형 종류

이러한 특화 스트림은 숫자 스트림의 합계를 계산하는 sum, 최댓값 요소를 검색하는 max 같이 자주 사용하는 숫자 관련 리듀싱 연산 수행 메서드를 제공한다!

특화 스트림으로 변환

mapToInt, mapToDouble, mapToLong 메서드를 이용하면 일반 스트림을 특화 스트림으로 변환할 수 있다.

int totalPayPrice = pays.stream()
    .mapToInt(Pay::getPayPrice)
    .sum();

💡 저 :: 은 도대체 뭘까? 자바의 메소드 레퍼런스라는 것으로, 람다식을 다른 방식으로 표현한 것이다. 예 람다식 (text)-> System.out.println(text) 메소드 레퍼런스 System.out :: println

메소드 레퍼런스는 [ClassName] :: [MethodName] 형식으로 입력하고, 메소드를 호출하는 것이지만 괄호()는 써주지 않고 생략한다!

.mapToInt(Pay::getPayPrice) 람다식로 변환하면? .mapToInt(onePay → onePay.getPayPrice)

List를 int[]로 변환하고 싶다면?

mapToInt이용!

int[] arr = list.stream()
                .mapToInt(i -> i) // == mapToInt(Integer::intValue)
                .toArray();

boxed 메서드

boxed() 메서드는 IntStream 같이 원시 타입에 대한 스트림 지원을 클래스 타입(예: IntStream -> Stream<Integer>) 으로 전환해준다.

사용 예: int 자체로는 Collection에 못 담기 때문에 Integer 클래스로 변환하여 List<Integer> 로 담기 위해 사용한다.

List<Integer> list1 = Arrays.stream(arr) // == IntStream.of(arr)
                                                        .boxed()
                                                        .collect(Collectors.toList());

유용하고 중요한 메서드! (주관적)

filter

if문이라고 생각하면 편하다.

일치하는 모든 요소를 포함하는 스트림으로 반환한다.

메뉴 List에서 베지테리안 메뉴만 찾아서 리스트로 저장하고 싶다면?

List<Dish> vegetarianMenu = menu.stream()
  .filter(Dish::isVegetarian) // 리턴값이 true면 다음 단계 진행, false면 버려짐!
  .collect(Collectors.toList());

collect

스트림의 요소들을 우리가 원하는 자료형으로 변환할 수 있다. toList(), toSet(), toMap(), toCollection()

stream.collect(Collectors.toSet()); //set으로 변환
stream.collect(Collectors.toList()); //list 변환
stream.collect(Collectors.joining()); //요소를 다 이어붙여서 하나의 string으로 변환
stream.collect(Collectors.joining(", ")); //요소들 사이에 ","을 넣어서 한개의 string 반환

List나 Set이 아닌 특정 컬렉션을 지정하려면 toCollection() 에 해당 컬렉션의 생성자 참조를 매개변수로 넣어주면 된다.

ArrayList<String> list = names.stream()
  .collect(Collectors.toCollection(ArrayList::new));

• collect()는 아니지만, 배열로 변환하고 싶다면 stream.toArray() 사용!

Person[] personArray1 = personStream1.toArray(Person[]::new);

map

스트림을 우리가 원하는 모양의 새로운 스트림으로 변환할 수 있다.

스트림 내 문자열을 모두 대문자로 변경한 스트림 만들기?

Stream<String> stream = names.stream()
  .map(String::toUpperCase);

~~Match

• 하나라도 조건을 만족하는 요소가 있는지 anyMatch
• 모두 조건을 만족하는지 allMatch
• 모두 조건을 만족하지 않는지 noneMatch

List<String> names = Arrays.asList("Eric", "Elena", "Java");

boolean anyMatch = names.stream()
  .anyMatch(name -> name.contains("a"));
boolean allMatch = names.stream()
  .allMatch(name -> name.length() > 3);
boolean noneMatch = names.stream()
  .noneMatch(name -> name.endsWith("s"));

결과는 모두 true!

스트림 활용 예제

1.int[] numbers = {1, 2, 3, 4, 5}; 위와 같은 배열이 있을 때, 스트림을 활용해서 아래와 같은 동작을 수행하자!

1. 홀수만 골라서, → filter() 2. 2를 곱한 뒤, → map() 3. 배열에 저장한다. → toArray

int[] result = Arrays.stream(numbers)
                                   .filter(num -> num % 2 == 1)
                                   .map(num-> num * 2) -> 스트림
                                   .toArray(); 

2.int[] data = {5, 6, 4, 2, 3, 1, 1, 2, 2, 4, 8}; 위와 같은 배열이 있을 때, 스트림을 활용해서 아래와 같은 동작을 수행하자!

1. 짝수만 뽑은 뒤, → filter 2. 중복을 제거하고, → 3. 역순으로 정렬해서 → 4. 출력한다. → foreach

Arrays.stream(data)
      .boxed() // IntStream에서 -> Stream<Integer>로 변환
      .filter(n -> n % 2 == 0)
      .distinct() // 중복 제거
      .sorted(Comparator.reverseOrder())
      .forEach(System.out :: println); //  == .forEach((num) -> System.out.println(num))

• boxed 하는 이유?
  • sorted(Comparator.reverseOrder())를 하기 위함. IntStream이 제공하는 sorted()는 내림차순이 불가능!!

3.프로그래머스 음양 더하기

class Solution {
    public int solution(int[] absolutes, boolean[] signs) {
        int sum = 0;
        for(int i=0; i<absolutes.length; i++) {
            if(!signs[i]) {
                absolutes[i] *= -1;
            }
            sum +=  absolutes[i];
        }
        return sum;
    }
}

스트림 활용 리팩토링

import java.util.stream.IntStream;
class Solution {
    public int solution(int[] absolutes, boolean[] signs) {
        int sum = IntStream.range(0, absolutes.length)
                            .map(i -> !signs[i] ? -absolutes[i] : absolutes[i])
                            .sum();
        return sum;
    }
}                                         

서로 연관된 상수들의 집합으로, 서로 관련된 상수를 편하게 선언하기 위해 사용하며, 상수를 여러개 정의해야할 때 사용한다.

수 많은 언어에서 이처럼 새로운 열거형을 정의할 수 있게 하고 있지만, 이번에는 자바의 enum 클래스에 대해서 알아보겠다.

상수란?

자바에서는 final로 문자열이나 숫자들을 나타내는 기본 자료형의 값을 고정할 수 있다. 이렇게 고정된 값을 상수라고 한다.

enum을 사용하지 않고 상수를 선언하는 법

pubilc class EnumExample {

    private final static int JANUARY = 1;
    private final static int FEBRUARY = 2;
    private final static int MARCH = 3;
    private final static int APRIL = 4;
    private final static int MAY = 5;
    private final static int JUNE = 6;

    public static void main(String[] args) {

    }
}

위 코드처럼 final을 사용하여 한 번 지정하면 바뀌지 않게 설정하면서 동시에 static을 사용하여 메모리에 한 번만 할당 되게 설정하여 변수를 상수로 만들었다. 이렇게 선언하는 방법도 좋지만, 사용해야 하는 상수가 많아지게 된다면 코드 상위에 계속해서 상수를 선언해줘야 하고, 그렇게 되면 상수가 너무 많아지고 상수들이 어떤 것에 관련된 것인지 한 눈에 알기 힘들다.

enum을 사용하여 상수를 선언하는 법

enum Month {
    JANUARY,
    FEBRUARY,
    MARCH,
    APRIL,
    MAY,
    JUNE
}

위에서 선언했던 상수를 그대로 enum클래스를 사용해서 선언한 것이다. enum을 사용해 상수를 정의하게 되면, 여러 장점을 얻을 수 있다.

enum 사용 장점

• 코드가 단순해지며, 가독성이 좋다.

• 상수와 값이 논리적인 연관이 없는 문제를 해결할 수 있다.

  private static final int CAT = 1;
  private static final int DOG = 2;
  private static final int PANDA = 3;

  CAT이라는 상수와 값인 1은 전혀 논리적인 연관이 없다.

• 서로 다른 개념끼리 이름이 충돌할 수 있는 문제를 해결할 수 있다. 예를 들어, 중학교의 1학년과 고등학교 1학년은 다른 의미를 가진다. middleSchool.FIRST_GRADE highSchool.FIRST_GRADE과 같이 enum으로 정의할 경우 완전히 구분이 가능하다.

• 리팩토링 변경 범위가 최소화된다. 내용의 추가나 수정이 필요하더라도, enum 코드만 건들면 된다.

• 여러 메서드를 제공한다.

  • values() : 해당 enum 타입에 정의된 상수 배열을 반환하는 메서드
  • valueOf() : 지정된 열거형에서 name과 일치하는 열거형 상수를 반환하는 메서드
  • ordinal() : 열거형 상수가 정의된 순서를 반환하는 메서드
  • name() : 열거형 상수의 이름을 문자열로 반환하는 메서드
  • getDeclaringClass() : 열거형의 클래스 객체를 반환하는 메서드

enum의 추가 속성 부여

enum클래스는 위에서 말한 장점 외에도 유용한 옵션을 제공하는데, 바로 열거형 상수에 추가 속성을 부여할 수 있다.

enum Month {
    JANUARY("1월"),
    FEBRUARY("2월"),
    MARCH("3월"),
    APRIL("4월"),
    MAY("5월"),
    JUNE("6월")

    private String monthName;
}

여러개의 속성을 부여할 수도 있다.

enum Month {
    JANUARY("1월", "겨울"),
    FEBRUARY("2월", "겨울"),
    MARCH("3월", "봄"),
    APRIL("4월", "봄"),
    MAY("5월", "봄"),
    JUNE("6월", "여름")

    private String month;
    private String seasons;
}

앞으로는 연관된 상수를 선언할 때 enum을 활용해보자!

이 글을 읽는 모두, 좋은 하루 되세요. 💗

배열이란?

• 같은 데이터 타입의 변수들로 이루어진 자료구조
• 자바에서 기본적으로 지원하는 자료구조
  

배열의 장점

• index는 값에 대한 유일무이한 식별자 → 인덱스를 통한 검색이 용이하다.
• 연속된 메모리의 공간으로 이루어져 있다. → 연속적이므로 메모리 관리가 편하다.
  

배열의 단점

• 정적이므로 배열의 크기를 컴파일 이전에 정해주어야 한다.

  → 컴파일 이후 배열의 크기를 변동 할 수 없다. → 메모리가 낭비됨.

🪐 2. List (리스트)

리스트란?

• 배열과 유사하게, 같은 데이터 타입의 변수들로 이루어진 자료구조
• 순서가 있는 데이터의 집합이며, 데이터의 중복을 허용한다.
• 자바에서 기본적으로 지원하는 자료구조
• 배열과 달리 크기가 가변적이다.
• 중간의 빈 공간을 허용하지 않는다.
  

리스트의 장점

• 포인터를 통하여 다음 데이터의 위치를 가리키고 있어 삽입 삭제의 용이.

  → 추가/삭제 성능이 좋다.

• 불연속적으로 메모리 공간을 차지. → 불연속적이므로 메모리 관리가 편리하다.

  
  

리스트의 단점

• 검색 성능이 좋지 않다.
• 포인터를 통해 다음 데이터를 가리키므로 추가적인 메모리 공간이 발생한다.

🌟 3. ArrayList (배열리스트)

ArrayList란?

• List 인터페이스를 상속받은 여러 클래스 중 하나이다.
  

ArrayList 특징

• 배열과 유사하게 index 식별자 활용이 가능하다.
• 리스트의 특성인 동적 할당 가능하다. → 크기가 가변적이다.
• 타입 안정성을 보장해주는 제네릭 사용이 가능하다.
  

🌌 Array와 ArrayList는 어떤 경우에 사용하면 좋을까?

Array

• 데이터 개수가 고정적이고 삽입, 삭제가 빈번하지 않은 경우
• 데이터 접근이 빈번한 경우
• 기본 자료형(int, char, double..) 사용하고 싶은 경우
  

ArrayList

• 데이터 개수가 고정적이지 않고, 삽입, 삭제가 빈번할 경우
• 데이터 접근이 드물 경우
  

이 글을 읽는 모두, 좋은 하루 되세요. 😄

• Test Driven Development의 약자. 우리말로 테스트 주도 개발

• 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

• 이 기법을 개발했거나 ‘재발견’한 것으로 인정되는 켄트 벡(Kent Beck)은 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 말하였다.

• 최근에는 테스트 코드가 동작을 테스트하기 위해 사용될 뿐 아니라, jenkins 등의 ci 도구를 사용할 때 테스트 코드의 성공 여부를 확인해 전부 성공한 경우에만 pr을 통과시키거나 운영브랜치로 merge시키는 등의 추가 동작을 하는데도 많이 사용된다고 한다.

  
  

TDD 순서

1단계 🔴) 기능을 검증하는 테스트 코드 작성 2단계 🟢) 테스트를 통과하는 기능 개발 3단계 🔵) 작성한 코드 리팩토링

TDD는 기본적으로 위 3단계의 반복으로 진행하며 점진적으로 코드를 개선해나가며 개발이 진행된다.

왜 1단계가 Write a failing test (실패한 테스트 작성)일까?

기능을 개발하기 전, 테스트 코드를 우선으로 작성하기 때문에 당연히 그 테스트는 실패하는 테스트일 것이다. 2단계에서 이 실패하는 테스트를 성공시키기 위한 기능 개발을 하면 된다.

간단한 TDD 예제

숫자로 구성된 문자열을 입력받아 기본적인 더하기와 빼기 연산을 수행하는 계산기 프로그램을 만들려고 한다. 기능을 개발하기 전, 기능을 검증할 수 있는 테스트 코드를 작성해 본다.

import static org.assertj.core.api.Assertions.*;
import org.junit.jupiter.api.Test;

public class StringCalculatorTest {

    @Test
    public void testAdd() {
        StringCalculator calculator = new StringCalculator();
        assertThat(calculator.add("")).isEqualTo(0);
        assertThat(calculator.add("1,2")).isEqualTo(3);
        assertThat(calculator.add("2,3")).isEqualTo(5);
        assertThat(calculator.add("4,5")).isEqualTo(9);
    }

    @Test
    public void testSubtract() {
        StringCalculator calculator = new StringCalculator();
        assertThat(calculator.subtract("")).isEqualTo(0);
        assertThat(calculator.subtract("3,2")).isEqualTo(1);
        assertThat(calculator.subtract("4,3")).isEqualTo(1);
        assertThat(calculator.subtract("5,3")).isEqualTo(2);
    }
}

테스트 코드를 작성하면 아래와 같이 코드가 빨갛게 물들 것이다. Why? 기능 개발을 하기 전이기 때문이다. 이 상태로 테스트를 실행시키면 아주 친절하게 StringCalculator가 없다고 알려준다. 이게 바로 위에서 설명했던 1단계 '실패한 테스트 작성'이다. 그럼 이제 2단계로 넘어가서 '테스트를 통과하는 기능 개발'을 하면 된다. 우리는 StringCalculator 클래스를 만들어주면 되는 것이다.

public class StringCalculator {

    public int add(String input) {
        // 아무것도 입력하지 않았을 때
        if (input.isEmpty()) {
            return 0;
        }

        String[] numbers = input.split(",");
        int sum = 0;
        for (String number : numbers) {
            sum += Integer.parseInt(number);
        }
        return sum;
    }

    public int subtract(String input) {
        // 아무것도 입력하지 않았을 때
        if (input.isEmpty()) {
            return 0;
        }

        String[] numbers = input.split(",");
        int result = Integer.parseInt(numbers[0]);
        for (int i = 1; i < numbers.length; i++) {
            result -= Integer.parseInt(numbers[i]);
        }
        return result;
    }
}

StringCalculator를 만들고 작성했던 테스트 코드에 다시 돌아와보자. 무진장 붉었던 테스트 코드들이 정상으로 돌아왔고 테스트를 실행시켜보면 초록초록하게 테스트가 성공하는 것을 볼 수 있다. 아, 여기서 DIsplayName()은 위처럼 테스트명을 지정해 줄 수 있는 어노테이션이다.

테스트가 성공했으니 이제 더 좋게 코드를 리팩토링해주면 된다. 입력값으로 null이 입력된 경우를 추가하거나 for문을 없애거나 하면 더 효율 높은 코드가 될 것이다. 이렇게 코드를 리팩토링하고 테스트하는 과정을 반복하여 보다 효율적이고 깔끔한 코드를 작성하는 것이 TDD의 목적이다.

TDD 예제 : 암호 검사기

• 규칙 세 가지
  • 길이가 8글자 이상
  • 0부터 9 사이의 숫자를 포함
  • 대문자 포함
• 세 규칙을 모두 충족하면 암호는 강함이다.
• 2개의 규칙을 충족하면 암호는 보통이다.
• 1개 이하의 규칙을 충족하면 암호는 약함이다.

책에서는 junit의 assertEquals를 사용했지만 나는 assertj의 assertThat을 사용해서 만들어보겠다.

첫 번째 테스트 : 모든 규칙을 충족하는 경우

#가장 쉽거나 가장 예외적인 상황을 선택

→ 모든 조건을 충족하지 않는 경우 ← 는 한번에 만들어야 할 코드가 많기 때문에 모든 규칙을 충족하는 경우를 택함.

• 테스트 작성

import org.junit.jupiter.api.Test;

// assertj의 Assertions 임포트
import static org.assertj.core.api.Assertions.*;

public class PasswordStrengthMeterTest {
@Test
    void meetsAllCriteria_Then_Strong() {
        PasswordStrengthMeter meter = new PasswordStrengthMeter();

        PasswordStrength result1 = meter.meter("ab12!@AB");
                // result1의 값이 PasswordStrength.STRONG와 동일한지 검증하는 코드
        **assertThat(PasswordStrength.STRONG).isEqualTo(result1);**

        PasswordStrength result2 = meter.meter("abc1!Add");
       **/assertThat(PasswordStrength.STRONG).isEqualTo(result2);**
}

• 기능 작성

public calss PasswordStrengthMeter {
    public PasswordStrength meter(String s) {
        return PasswordStrength.STRONG;
    }
}

💡 기능을 작성할 때는 단순히 테스트가 통과하도록 기능을 최소한으로 구현한다!

두 번째 테스트 : 길이만 8글자 미만이고 나머지 조건은 충족하는 경우

• 테스트 작성

@Test
void meetsAllCriteria_Then_Strong() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("ab12!@A");
    **assertThat(PasswordStrength.NOMAL).isEqualTo(result);**
  PasswordStrength result2 = meter.meter("abc1!Add");
  **assertThat(PasswordStrength.STRONG).isEqualTo(result2);**
}

• 기능 작성

**if(s.length() < 8) {
    return PasswordStrength.NORMAL;
}**

세 번째 테스트 : 숫자를 포함하지 않고 나머지 조건은 충족하는 경우

• 테스트 작성

@Test
void meetsOtherCriteria_except_for_Length_Then_Normal() {
    PasswordStrengthMeter meter = new PasswordStrengthMeter();
    PasswordStrength result = meter.meter("ab12!@A");
    assertThat(PasswordStrength.NOMAL).isEqualTo(result);
}

• 기능 작성

// 암호가 숫자를 포함했는지 판단해서 포함하지 않은 경우 NORMAL을 리턴한다.
**boolean containsNum = false;
    for(char c : s.toCharArray()) {
      if(c >= '0' && c <= '9') {
        containsNum = true;
            break;
    }
  }
if(!containsNum) return PasswordStrength.NORMAL;**

• 코드의 가독성을 개선하기 위해 리팩토링 진행!

    public calss PasswordStrengthMeter {
        public PasswordStrength meter(String s) {
            if(s.length() < 8) {
                return PasswordStrength.NORMAL;
            }
            boolean containsNum = **meetsContainingNumberCriteria(s);**
            if(!containsNum) return PasswordStrength.NORMAL;
    ****        return PasswordStrength.STRONG;
        }
  
        // 숫자 포함 여부 확인 코드를 메서드로 분리한다.
        **private boolean meetsContainingNumberCriteria(String s) {
        for(char c : s.toCharArray()) {
            if(c >= '0' && c <= '9') {
                return true;
            }
        }
        return false;
      }**
    }

코드 정리 : 테스트 코드 정리

#코드의 중복 제거

→ PasswordStrengthMeter 객체 생성을 필드에서!

public class PasswordStrengthMeterTest {
    private PasswordStrengthMeter meter = new PasswordStrengthMeter();

    private void assertStrength(String password, PasswordStrength expStr) {
      PasswordStrength result = meter.meter(password);
      assertThat(expStr).isEqualTo(result);
  }

    @Test
  void meetsAllCriteria_Then_Strong() {
      assertStrength("ab12!@AB", PasswordStrength.STRONG);
      assertStrength("abc1!Add", PasswordStrength.STRONG);
    }

  @Test
  void meetsOtherCriteria_except_for_Length_Then_Normal() {
      assertStrength("ab12!@A", PasswordStrength.NOMAL);
  }

  @Test
  void meetsOtherCriteria_except_for_number_Then_Normal() {
      assertStrength("abc!@ABC", PasswordStrength.NOMAL);
  }
}

✅ 테스트 코드를 수정 후 실패하는 곳이 없는지 확인 후 다음 테스트 진행

네 번째 테스트 : 값이 없는 경우

#값이 없을 때는 NullPointerException 이 발생한다.

→ 유효하지 않는 암호가 입력되면 PasswordStrength.INVALID를 리턴하도록 설계하자.

• 테스트 작성

@Test
void nullInput_Then_Invalid() {
    assertStrength(null, PasswordStrength.INVALID);
}

• 기능 작성

// 암호가 null이라면 INVALID를 리턴한다.
**if(s == null) return PasswordStrength.INVALID;**

*→ 암호가 빈 문자열일 때의 예외상황도 고려해보자! *

• 테스트 작성

@Test
void emptyInput_Then_Invalid() {
  assertStrength("", PasswordStrength.INVALID);
}

• 기능 작성

// 암호가 빈 문자열이라면 INVALID를 리턴한다.
if(s == null **|| s.isEmpty()**) return PasswordStrength.INVALID;

다섯 번째 테스트 : 대문자를 포함하지 않고 나머지 조건을 충족하는 경우

• 테스트 작성

@Test
void emptyInput_Then_Invalid() {
  assertStrength("", PasswordStrength.INVALID);
}

• 기능 작성

boolean containsNum = meetsContainingNumberCriteria(s);
****if(!containsNum) return PasswordStrength.NORMAL;

// 암호가 대문자를 포함하지 않은 경우를 판별한다.
**boolean containsUpp = false;
for(char ch : s.toCharArray()) {
    if(Character.isUpperCase(ch)) {
      containsUpp = true;
        break;
  }
}
if (!containsUpp) PasswordStrength.NORMAL;**

→ 코드의 가독성을 개선하기 위해 리팩토링 진행!

// 대문자 포함 여부 확인 코드를 메서드로 분리한다.
**private boolean meetsContainingUppercaseCriteria(String s) {
  for(char c : s.toCharArray()) {
    if(Character.isUpperCase(c)) {
        return true;
    }
  }
  return false;
}**

여섯 번째 테스트 : 길이가 8글자 이상인 조건만 충족하는 경우

• 테스트 작성

@Test
void 길이가_8글자_이상인_조건만_충족() {
  assertStrength("abcdefghi", PasswordStrength.WEAK);
}

→ 테스트 이름은 한글로 작성해도 된다!

• 기능 작성

// 이전 코드 삭제
**~~if(s.length() < 8) {
    return PasswordStrength.NORMAL;
}~~**

// 암호의 길이가 8 이상인지 검증한다.
**boolean lengthEnough = s.length() >= 8;**
boolean containsNum = meetsContainingNumberCriteria(s);
boolean containsUpp = meetsContainingUppercaseCriteria(s);

**if(lengthEnough && containsNum && containsUpp) {
    return PasswordStrength.WEAK;
}**

**if(!lengthEnough) {
    return PasswordStrength.NORMAL;
}**
if(!containsNum) return PasswordStrength.NORMAL;
if(!containsUpp) return PasswordStrength.NORMAL;
return PasswordStrength.STRONG;

****

일곱 번째 테스트 : 숫자 포함 조건만 충족하는 경우

• 테스트 작성

@Test
void 숫자_포함_조건만_충족() {
  assertStrength("12345", PasswordStrength.WEAK);
}

• 기능 작성

**if(!lengthEnough && containsNum && !containsUpp) {
    return PasswordStrength.WEAK;
}**

여덟 번째 테스트 : 대문자 포함 조건만 충족하는 경우

• 테스트 작성

@Test
void 대문자_포함_조건만_충족() {
  assertStrength("ABCEF", PasswordStrength.WEAK);
}

• 기능 작성

**if(!lengthEnough && !containsNum && containsUpp) {
    return PasswordStrength.WEAK;
}**

• 지금까지 작성한 코드 리팩토링 진행

    public class PasswordStrengthMeter {
        public PasswordStrength meter (String s) {
            if(s == null || s.isEmpty()) return PasswordStrength.INVALID;
            int metCounts = 0;
            if(s.length() >= 8) metCounts++;
            if(meetsContainingNumberCriteria(s)) metCounts++;
            if(meetsContainingUppercaseCriteria(s)) metCounts++;
  
            if(metCounts == 1) return PasswordStrength.WEAK;
            if(metCounts == 2) return PasswordStrength.NOMAL;
  
            return PasswordStrength.STRONG;
        }
  
            // 숫자 포함 여부 검증 메서드
        private boolean meetsContainingNumberCriteria(String s) {
            for(char c : s.toCharArray()) {
                if(c >= '0' && c <= '9') {
                    return true;
                }
            }
            return false;
        }
            // 대문자 포함 여부 검증 메서드
        private boolean meetsContainingUppercaseCriteria(String s) {
            for(char c : s.toCharArray()) {
                if(Character.isUpperCase(c)) {
                    return true;
                }
            }
            return false;
        }
    }

아홉 번째 테스트 : 아무 조건도 충족하지 않은 경우

#모든 상황을 다 테스트 했으니, 마지막으로 아무 조건도 충족하지 않은 경우를 검증한다.

• 테스트 작성

@Test
void 아무조건도_충족하지_않음() {
  assertStrength("abc", PasswordStrength.WEAK);
}

• 기능 작성

// 비교 조건 수정
~~if(metCounts == 1) return PasswordStrength.WEAK;~~
if(metCounts <= 1) return PasswordStrength.WEAK;

✅ 암호 검사기 프로그램의 모든 기능이 완성되었다~! 얏호

• 마지막으로 코드의 가독성을 조금 더 높여보자 (리팩토링)

    public class PasswordStrengthMeter {
        public PasswordStrength meter (String s) {
            if(s == null || s.isEmpty()) return PasswordStrength.INVALID;
                    **int metCounts = getMetCriteriaCounts(s);**
            if(metCounts == 1) return PasswordStrength.WEAK;
            if(metCounts == 2) return PasswordStrength.NOMAL;
  
            return PasswordStrength.STRONG;
        }
  
            // metCounts를 계산하는 메서드
            **private int getMetCriteriaCounts(String s) {
            int metCounts = 0;
            if(s.length() >= 8) metCounts++;
            if(meetsContainingNumberCriteria(s)) metCounts++;
            if(meetsContainingUppercaseCriteria(s)) metCounts++;
            return metCounts;
        }**
  
            // 숫자 포함 여부 검증 메서드
        private boolean meetsContainingNumberCriteria(String s) {
            for(char c : s.toCharArray()) {
                if(c >= '0' && c <= '9') {
                    return true;
                }
            }
            return false;
        }
            // 대문자 포함 여부 검증 메서드
        private boolean meetsContainingUppercaseCriteria(String s) {
            for(char c : s.toCharArray()) {
                if(Character.isUpperCase(c)) {
                    return true;
                }
            }
            return false;
        }
    }

TDD의 장점

1. 기능 단위로 테스트하기 때문에 문제의 원인을 알기 쉽다.

보통 개발을 다 해놓고 나서 테스트를 하는 ATDD(인수테스트 주도 개발)를 하는데, 테스트 중 혹여나 문제를 발견한다면 정확하게 문제의 원인이 무엇인지 진단하기 힘들다.

하지만 TDD를 사용하면 기능 단위로 테스트하기 때문에 문제의 원인을 알기 쉽다.

2. 변화에 대한 두려움 해소

테스트 코드를 먼저 작성하고 기능 개발을 하기 때문에 개발한 기능이 잘 동작할지에 대한 불안감을 없앨 수 있다.

3. 프로그래머의 오버 엔지니어링을 방지한다.

개발을 하다 보면 간혹 계획하지 않았던 코드를 추가하여 오버 엔지니어링하는 경우가 있다. 하지만 TDD의 원칙 중 하나는, 테스트를 통과하기 위한 최소한의 코드만 작성 및 개선해야 한다는 것이다. 기능 단위로 테스트를 진행하기 때문에, 문제가 발견되지 않은 코드에 영향을 줄 수 있는 오버 코딩은 하지 않는다.

TDD의 단점

TDD를 익히는 데 많은 시간이 걸린다.

TDD는 마치 운동과 같다. 
운동을 꾸준히 하면 건강해지고 체력이 좋아지는 것처럼 
TDD도 꾸준히 연습하고 적용해야 실력이 늘고 효과를 볼 수 있다.
-저자 최범균 [테스트 주도 개발 시작하기] 255p

TDD를 효과적으로 사용하기까지는 많은 시간이 필요하다고 한다.

생산성 저하

TDD에 대한 프로그래머들의 의견은 늘 엇갈리는데, 그 이유 중 가장 큰 것이 이 생산성 저하 문제 때문일 것이다. TDD를 지키면서 개발하려면 처음부터 2개의 코드를 짜야 하고, 중간중간 테스트를 하면서 고쳐나가야 한다. -> 개발 속도가 느려지기 때문에 생산성이 저하된다.

이 글은 최범균 저 '테스트 주도 개발 시작하기' 를 읽고 작성한 글입니다.

참고 TDD란? 테스트주도개발에 대한 편견과 실상, 방법론 테스트 주도 개발 [개발상식] tdd란 (tdd 예제, tdd하는법)

이 글을 읽는 모두, 좋은 하루 되세요. 🙂

4주차 회고

마지막,, 회고? 😯

❔ 이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

👍 Good

토요일 오프라인 행사에서 처음으로 팀원 전체가 모여 작업을 했는데, 너무너무 좋았고 행복하고 재미있었다,, 😊

👎 Bad

** 나쁜게 없었던 일주일! **

📖 이번주 진행했던 학습/개발 내용은 무엇이었나요?

👩‍💻 아래와 같은 개발을 진행했습니다.

   1) 24시간 서버를 돌리면서 프론트분들의 요구사항이나, 오류가 발견되거나 하면 그때그때 필요한 기능들을 제작하여 추가했다!
   2) 배포 자동화 !!!!!!🙉

✍ 아래와 같은 내용을 학습했습니다.

   1) Github Actions를 활용한 CI/CD 구축법

실제 구축한 과정을 담은 글 ,, (보러 와주십사🤤) Spring Boot + GitHub Actions + AWS CodeDeploy를 사용하여 CI/CD 구축하기

💭 가장 고민을 했던 부분은 무엇이었나요?

CI/CD를 구축하려 했을 때, 혹시나 정체모를 오류라도 나서 서버를 켤 수 없는 상황이 올까봐 고민을 많이 했다..

▶ 그래도 혼자 작업하는게 아닌, 다른 백엔드 팀원분도 계시기 때문에 서로 편하게 빌드하고 배포하기 위해서는 꼭 필요한 작업이라고 생각했다. 그래서 결국 아무도 서버를 사용하지 않을 것 같은 새벽에 작업을 진행..! 결과는 수많은 에러들을 해결하고 성공적으로 구축 완료했다! 😁

🤔 아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

• 개발을 진행하면서 기능을 계속 수정해야 하는 상황이 발생하고, 때로는 팀원들 간에 요구사항을 다르게 이해하는 경우도 있었다. 괜히 제품을 만들기 전 문서 작성이 중요하다고 하는 것이 아니구나 하며 깨달았다. 이를 계기로 문서를 작성하는 습관을 길러야 할 것 같다.
  

🕒 다음주는 어떻게 보낼 예정인가요?

• 마지막까지 수정이 필요한 부분을 계속해서 손보고, 후회없는 결과물을 만들어 내기!

4주차 회고를 마칩니다. 💚

0. 개발환경

• Spring Boot
• GitHub Actions
• AWS CodeDeploy
• AWS EC2
• AWS S3
  

전체적인 흐름

1. S3 생성

1.1 S3 버킷 생성

aws S3 ➡ 버킷 ➡ 버킷 만들기 나는 이미 버킷을 생성해둔 상태다.

버킷 생성 시 리전은 꼭 EC2 인스턴스와 같은 것으로 지정해야 한다. 만약 리전이 다르다면 S3 리전에서 EC2 리전으로 데이터를 옮기는 데에 💸비용이 청구된다. (그게 나야,, 둠빠둠빠두비두밥,,)

나머지는 모두 디폴트 값으로 놔두고 버킷 생성!

2. EC2 설정 추가

1. 태그 추가 2. IAM 역할 추가 3. EC2 서버에 CodeDeploy 에이전트 설치

2.1 인스턴스 태그 추가

CodeDeploy를 생성할 때 수행할 인스턴스를 지정해줘야하기 때문에 인스턴스들을 구분할 태그를 추가해줘야 한다.

인스턴스 선택 ➡ 작업 ➡ 인스턴스 설정 ➡ 태그 관리

• 태그 확인

2.2 IAM 역할 추가

EC2 인스턴스에서 S3에 접근할 수 있도록 AmazonS3FullAccess 권한을 추가한 뒤, 인스턴스에 연결한다.

2.3 CodeDeploy 에이전트 설치

EC2 서버에 접속한 뒤, 똑같이 입력하여 설치해준다.

$ sudo apt update
$ sudo apt install ruby-full
$ sudo apt install wget
$ cd /home/ubuntu
$ wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
$ chmod +x ./install
$ sudo ./install auto > /tmp/logfile
$ sudo service codedeploy-agent status

3. CodeDeploy 생성

1. IAM 역할 추가 2. CodeDeploy 애플리케이션 생성 3. CodeDeploy 배포 그룹 생성

3.1 IAM 역할 추가

AWSCodeDeployRole 권한을 추가하여 역할을 생성한다.

3.2 CodeDeploy 애플리케이션 생성

컴퓨팅 플랫폼은 EC2/온프레미스를 선택하여 생성한다.

3.3 CodeDeploy 배포 그룹 생성

위에서 생성한 CodeDeploy 애플리케이션 이름을 눌러 들어가면 배포 그룹을 생성할 수 있다.

서비스 역할에서는 3.1에서 생성한 AWSCodeDeployRole 권한을 가진 IAM을 선택한다.

다음 환경 구성에서는 Amazon EC2 인스턴스를 선택하고 2.1에서 태그를 추가했다면 아래와 같이 해당 태그의 인스턴스를 선택할 수 있다.

나머지 설정은 아래와 같이 해주고 배포 그룹을 생성한다.

4. Github Actions에서 사용할 IAM 사용자 추가

1. IAM 사용자 생성 2. Access Key, Secret Key 생성 및 확인

4.1 IAM 사용자 생성

IAM ➡ 액세스 관리 ➡ 사용자 ➡ 사용자 생성 직접 정책 연결을 선택하고 AmazonS3FullAccess, AWSCodeDeployRole 권한을 추가하여 사용자를 생성한다.

4.2 Access Key, Secret Key 생성 및 확인

생성한 사용자 이름을 클릭하여 들어가서 아래와 같이 액세스 키 만들기를 클릭한다.

그러면 아래와 같은 화면이 뜨는데, 이 화면에서는 아무거나 선택해도 무방하다.

액세스 키를 생성하게 되면 Access Key, Secret Key가 발급이 되는데

❗ 이때, Secret Key는 이 화면을 나가게 되면 더이상 알 수 있는 방법이 없기 때문에 꼭 csv파일로 가지고 있는 것을 추천한다.

5. Github Repository 의 Secrets 추가

Github Repository ➡ Settings ➡ Secrets and variables ➡ Actions ➡ New repository secret

Access Key, Secret Key를 등록해준다.

❗ 여기서 APPLICATION 키는 뭘까?

APPLICATION 키는 바로 Spring 프로젝트 내의 application.properties 파일의 내용을 가지고 있는 키다.

Spring 프로젝트 내에 있는 application.properties 파일은 각종 민감정보를 담고있는 파일이기 때문에 깃허브에 올릴 때는 .gitignore에 작성해서 깃허브에 올라가지 않도록 설정하는데, github action을 사용해서 깃허브에 푸쉬한 코드로 빌드를 해야하기 때문에 application.properties 파일이 필요하다!

그렇기 때문에 우리는 Screts에 application.properties 파일의 내용을 저장해두고 빌드할 때마다 파일을 생성하여 빌드해주려고 한다.

• 깃허브에 올라가는 것은 아니다!

application.properties 파일의 내용을 모두 복붙하여 키를 생성해두면 된다.

6. appspec.yml 파일 작성

Spring 프로젝트 루트 디렉토리에 appspec.yml 파일을 생성하고 아래와 같이 작성한다.

# appspec.yml

version: 0.0
os: linux

files:
  - source:  /
    destination: /home/ubuntu/app
    overwrite: yes

permissions:
  - object: /
    pattern: "**"
    owner: ubuntu
    group: ubuntu

hooks:
  AfterInstall:
    - location: scripts/stop.sh
      timeout: 60
      runas: ubuntu
  ApplicationStart:
    - location: scripts/start.sh
      timeout: 60
      runas: ubuntu

7. 배포 스크립트 작성

1. start.sh 작성 2. stop.sh 작성 3. build.gradle 파일 수정

아래와 같이 프로젝트 루트 디렉토리 아래 scripts 디렉토리를 만들고 그 안에 start.sh와 stop.sh를 작성했다.

7.1 start.sh 작성

#!/usr/bin/env bash

PROJECT_ROOT="/home/ubuntu/app"
JAR_FILE="$PROJECT_ROOT/spring-webapp.jar"

APP_LOG="$PROJECT_ROOT/application.log"
ERROR_LOG="$PROJECT_ROOT/error.log"
DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# build 파일 복사
echo "$TIME_NOW > $JAR_FILE 파일 복사" >> $DEPLOY_LOG
cp $PROJECT_ROOT/build/libs/*.jar $JAR_FILE

# jar 파일 실행
echo "$TIME_NOW > $JAR_FILE 파일 실행" >> $DEPLOY_LOG
nohup java -jar $JAR_FILE > $APP_LOG 2> $ERROR_LOG &

CURRENT_PID=$(pgrep -f $JAR_FILE)
echo "$TIME_NOW > 실행된 프로세스 아이디 $CURRENT_PID 입니다." >> $DEPLOY_LOG

7.2 stop.sh 작성

#!/usr/bin/env bash

PROJECT_ROOT="/home/ubuntu/app"
JAR_FILE="$PROJECT_ROOT/spring-webapp.jar"

DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# 현재 구동 중인 애플리케이션 pid 확인
CURRENT_PID=$(pgrep -f $JAR_FILE)

# 프로세스가 켜져 있으면 종료
if [ -z $CURRENT_PID ]; then
  echo "$TIME_NOW > 현재 실행중인 애플리케이션이 없습니다" >> $DEPLOY_LOG
else
  echo "$TIME_NOW > 실행중인 $CURRENT_PID 애플리케이션 종료 " >> $DEPLOY_LOG
  kill -15 $CURRENT_PID
fi

7.3 build.gradle 파일 수정

build.gradle에 아래 코드를 추가해준다.

jar {
    enabled = false
}

8. Github Actions Workflow 작성

1. Github Actions Workflow 생성 2. deploy.yml 파일 작성

8.1 Github Actions Workflow 생성

Github Repository ➡ Actions ➡ Simple workflow 선택

8.2 deploy.yml 파일 작성

name: Deploy to Amazon EC2

on:
  push:
    branches:
      - main #브랜치명

# 본인이 설정한 값을 여기서 채워넣는다.
env:
  AWS_REGION: us-east-1 #리전
  S3_BUCKET_NAME: test-bucket #버킷 이름
  CODE_DEPLOY_APPLICATION_NAME: test-app #CodeDeploy 애플리케이션 이름
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: test-deployment-group #CodeDeploy 배포 그룹 이름

permissions:
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    # (1) 기본 체크아웃
    - name: Checkout
      uses: actions/checkout@v3

    # (2) application.properties 설정
    - uses : actions/checkout@v3
    - run: touch ./src/main/resources/application.properties
    - run: echo "${{ secrets.APPLICATION }}" > ./src/main/resources/application.properties
    - run: cat ./src/main/resources/application.properties

    # (3) gradlew 권한 추가
    - name: Run chmod to make gradlew executable
      run: chmod +x ./gradlew

    # (4) JDK 11 세팅
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '11'

    # (5) Gradle build (Test 제외)
    - name: Build with Gradle
      uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
      with:
        arguments: clean build -x test

    # (6) AWS 인증 (IAM 사용자 Access Key, Secret Key 활용)
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    # (7) 빌드 결과물을 S3 버킷에 업로드
    - name: Upload to AWS S3
      run: |
        aws deploy push \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --ignore-hidden-files \
          --s3-location s3://$S3_BUCKET_NAME/$GITHUB_SHA.zip \
          --source .

    # (8) S3 버킷에 있는 파일을 대상으로 CodeDeploy 실행
    - name: Deploy to AWS EC2 from S3
      run: |
        aws deploy create-deployment \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --deployment-config-name CodeDeployDefault.AllAtOnce \
          --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
          --s3-location bucket=$S3_BUCKET_NAME,key=$GITHUB_SHA.zip,bundleType=zip

9. 세팅 끝. 배포 테스트

action이 일어나면 워크 플로우가 동작하도록 설정한 브랜치에 push를 한 뒤, 워크 플로우가 정상적으로 수행이 끝나면 아래와 같이 ✔표시가 뜬다.

Actions 탭에서 보고 싶은 워크 플로우를 클릭하면 아래와 같이 수행 과정을 볼 수 있다. 만약 에러가 난다면 어떤 부분에서 에러가 났는지도 확인이 가능하다.

배포가 완료된 후 AWS S3에는 zip형식의 빌드파일이 저장되어 있고 AWS CodeDeploy에서 배포 내역을 확인할 수 있다.

배포 자동화는 참 힘든거구나 싶었다.. 다음엔 도커를 사용해보고 싶다! 😊

참고한 블로그 https://bcp0109.tistory.com/363 https://velog.io/@sun1203/Github-Action-Spring-Application.properties

이 글을 읽는 모두, 좋은 하루 되세요. 🤗

3주차 회고

시간이 너무 빠르다 !! 😱

❔ 이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

👍 Good

지원했던 연합동아리에 서류 합격을 했다. 🥳

aws에 배포를 해서 24시간 서버를 돌릴 수 있게 되었다!

👎 Bad

** GDG 개발 기간이 별로 남지 않았다는 사실을 알아버린 것.. **

** 학교에서 제공하는 aws 계정으로는 S3를 사용하지 못한다는 사실을 늦게 알아버린 것. 삽질 엄청 했음 💢 **

📖 이번주 진행했던 학습/개발 내용은 무엇이었나요?

👩‍💻 아래와 같은 개발을 진행했습니다.

   1) aws EC2 인스턴스에 스프링 프로젝트를 빌드하여 24시간 사용이 가능한 서버를 구축했다.

   2) aws S3 버킷을 생성한 뒤, 스프링 프로젝트에 연동하여 파일 업로드 기능을 구현했다.

   3) 현재까지 개발된 API의 목록을 테스트해볼 수 있도록 프로젝트에 Swagger를 연동했다.

   4) 백엔드 팀원분과 짜놓은 erd를 다시 한번 수정했다 ^^ (멈춰,,,)

   5) 포즈를 인원수로 필터링 하는 기능과 랜덤으로 하나의 포즈를 제공하는 기능을 구현했다.

✍ 아래와 같은 내용을 학습했습니다.

   1) aws EC2 서버 구축과 백그라운드에서 구동시키는 법

   2) aws S3 Spring으로 사용하는 법

• aws EC2 서버 구축과 백그라운드에서 구동시키는 법 참고한 사이트 https://bcp0109.tistory.com/356

   # 백그라운드 구동시키기
   nohup java -jar {프로젝트명}-0.0.1-SNAPSHOT.jar &

   # 백그라운드에서 구동중인 프로그램 종료하기
   # 실행 중인 서버 PID 확인
   ps -ef
   # 종료
   kill -9 [PID]

• aws S3를 활용한 Spring 이미지 업로드 참고한 사이트 https://studyandwrite.tistory.com/498 https://jforj.tistory.com/261 https://velog.io/@chaeri93/SpringBoot-AWS-S3

💭 가장 고민을 했던 부분은 무엇이었나요?

유저의 사진과 관리자의 사진을 어떤식으로 객체를 구분하여 관리할지?

▶ 백엔드 팀원분과 이야기하여 관리자용 사진첩을 만들고 그 안에 사진을 저장하는 식으로 결정했다.

🤔 아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

• API가 많아지다 보니 코드를 보면 너무 정신없다. 앞으로 개발하는 내용에는 주석을 필히 달고 전체적인 코드 리팩토링이 필요하다.
  

🕒 다음주는 어떻게 보낼 예정인가요?

• 09.18(월) 팀원들과 오프라인 모각작
• 09.20(수)까지 기능 구현을 끝내기
• 기능 구현을 마치고 서버 배포 후 에러 잡기

3주차 회고를 마칩니다. 💚

2주차 회고

힘들지만 즐겁다 즐겁지만 힘들다~..🤤

❔ 이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

가족끼리 캠핑을 가서 힐링하고 왔다

연합동아리 지원 자소서를 쓰느라 정신이 없었다..😨

📖 이번주 진행했던 학습/개발 내용은 무엇이었나요?

👩‍💻 아래와 같은 기능을 구현했습니다.

 - 아카이브 기능
     1) 앨범 생성 시 원하는 유저 초대
    2) 앨범에 포함된 사진 조회

✍ 아래와 같은 내용을 학습했습니다.

- Spring 외래키 연관관계 매핑 방법

💭 가장 고민을 했던 부분은 무엇이었나요?

객체끼리 연관관계 매핑 시 외래키로 특정 개체를 조회하는 것(ex. 특정 사진첩에 들어있는 모든 사진 조회)이 아무리 해도 안돼서 지인한테도 물어보고 GDG 질문방에도 올렸다가 결국 내 힘으로 해결해냈다! 😚

🤔 아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

• 이미지 업로드와 배포를 위해 aws 서버 구동이 필요하다.
  

🕒 다음주는 어떻게 보낼 예정인가요?

• 09.13(수) 팀원들과 오프라인 모각작

• 09.16(토) 리뷰데이 in 구글 스타트업 캠퍼스 (강남)

• aws S3로 파일 업로드, EC2로 배포까지 해내기

  
  

2주차 회고를 마칩니다. 😉

Model이란?

객체지향프로그래밍에서 클래스를 역할에 따라 부르는 이름을 모델(Model)이라고 부른다.

모델의 종류는 크게 메인클래스, DTO, VO, DAO, Utility 등이 있다.

DTO, VO 모델이란?

• 데이터를 하나로 묶어야 될 경우 데이터를 하나로 수집하는 역할을 하는 바구니가 필요. 이 바구니 역할을 하는 것이 DTO, VO 모델
  
• DTO와 VO는 서로 비슷한 개념이지만 DTO는 값을 전달하는 동작을 수행하고 VO는 값 그자체이다. 그렇기 때문에 VO는 setter와 같은 새로운 값 지정 메서드 절대 사용 ❌

해당 메서드에 객체의 정보를 인자로 일일히 넘겨주어야 메인메서드가 아닌 다른 객체의 정보를 출력할 수 있다. 인자가 한두개면 상관 없지만 100개, 1000개처럼 수많은 인자를 다 적기엔 너무 힘들다.

👉 수많은 인자를 가지고 있는 모델을 만들어 사용하자! 그것이 DTO, VO

DTO 클래스를 만든다 ~

메인 클래스와 출력 메서드 부분을 위와 같이 수정하면 처음과 똑같이 작동한다. 처음보다 훨씬 간결해진 것을 확인할 수 있다. 😍 DTO와 VO를 사용하는 이유 증명!

DAO란?

데이터베이스에 데이터를 저장, 수정, 검색, 삭제를 하기 위해서 만들어지는 모델

CRUD 동작을 가지고있는 클래스

비지니스 로직을 처리하는 클래스

🤔 비지니스 로직이란?

홈페이지 회원가입을 예로 들어본다. 유저는 회원가입 폼에 양식을 입력하고 회원가입 버튼을 누르면 회원가입이 진행된다. 개발자는 이 과정들을 구현하기 위해 생각보다 많은 코드를 짜야한다. 이 때 아이디 중복찾기를 예시로 들면 아래와 같다.

1. 회원이 작성한 아이디 값을 저장

2. 회원정보가 있는 데이터베이스 연결

3. 데이터베이스에 회원이 작성한 아이디 값이 있는지 중복검사

4. 회원의 아이디가 이미 있는지 없는지 여부를 데이터화 하여 저장

5. 데이터베이스 연결 끊기

6. View 영역에게 가공된 데이터 전달

이와 같은 과정을 우리는 비지니스 로직이라고 한다.

참고 https://mommoo.tistory.com/67