공유 참조와 소유권

앞 글에서는 변수 두 개가 같은 객체를 가리킬 때, 한 변수로 바꾼 값이 다른 변수에서도 보인다는 것을 확인했습니다. 실제 프로그램에서는 이런 공유가 변수 두 개가 아니라 객체 두 개 사이에서 일어나는 경우가 많습니다. 보고서 객체와 미리보기 객체가 같은 게시글을 필드로 들고 있으면, 미리보기가 게시글을 고치는 순간 보고서가 읽는 값도 함께 바뀝니다.

이렇게 어떤 코드가 자기 일을 하면서 다른 곳에서 보이는 상태까지 바꾸는 것을 부수 효과(side effect)라고 합니다. 함께 쓰는 객체를 바꾸는 것이 협력의 목적이라면 부수 효과는 원하는 동작입니다. 문제는 한쪽이 혼자만 쓰려고 고친 값이 다른 쪽의 결과까지 바꿀 때입니다. 이때 핵심은 참조를 공유했다는 사실보다, 그 객체를 누가 바꿀 수 있는지가 코드에 드러나지 않는다는 데 있습니다. 이 글에서는 이런 부수 효과를 재현한 뒤 세 가지 해결책을 차례로 살펴봅니다.

미리보기에서 고친 조회 수가 보고서에도 보입니다

다음 프로그램에서 일간 보고서 DailyReport는 저장된 게시글의 조회 수를 보여 줘야 하고, 미리보기 PreviewService는 순위 미리보기를 위해 조회 수에 5를 더해 봅니다. 두 객체는 같은 MutableEntry를 생성자로 받습니다. 두 클래스는 캡슐화로 회원 저장소 완성하기에서 본 record로 선언했습니다. record는 구성 요소를 다시 대입할 수 없을 뿐이고, 구성 요소가 가리키는 객체의 상태는 얼마든지 바뀔 수 있습니다.

public final class SharedEntrySideEffect {
    public static void main(String[] args) {
        MutableEntry entry = new MutableEntry("object", 40);
        DailyReport report = new DailyReport(entry);
        PreviewService preview = new PreviewService(entry);

        preview.applyPreviewBoost(5);

        System.out.println("stored=" + report.totalViewCount());
        System.out.println("preview=" + preview.previewViewCount());
    }

    private static final class MutableEntry {
        private final String title;
        private int viewCount;

        MutableEntry(String title, int viewCount) {
            this.title = title;
            this.viewCount = viewCount;
        }

        void addViewCount(int extra) { viewCount += extra; }
        int viewCount() { return viewCount; }
    }

    private record DailyReport(MutableEntry entry) {
        int totalViewCount() { return entry.viewCount(); }
    }

    private record PreviewService(MutableEntry entry) {
        void applyPreviewBoost(int extra) { entry.addViewCount(extra); }
        int previewViewCount() { return entry.viewCount(); }
    }
}

stored=45
preview=45

보고서는 저장된 조회 수 40을 보여 줘야 했지만 45가 나왔습니다. main이 같은 entry를 두 생성자에 넘겼으므로 report와 preview의 필드는 같은 MutableEntry 하나를 가리킵니다. 그래서 applyPreviewBoost(5)가 그 객체의 조회 수를 45로 바꾸면, 보고서가 읽는 값도 45가 됩니다.

applyPreviewBoost라는 이름만 보면 미리보기 안에서만 계산하는 것 같지만, 실제로는 밖에서 넘겨받은 객체를 고칩니다. 이런 숨은 변경이 있으면 호출 순서에 따라 결과가 달라집니다. 이 프로그램에서도 applyPreviewBoost를 호출하기 전에 보고서를 출력하면 40이 나오고, 호출한 뒤에 출력하면 45가 나옵니다. 테스트에서도 같은 일이 생겨서, 한 테스트가 고친 객체 때문에 다른 테스트가 실패하는 일이 벌어집니다.

첫 번째 방법: 복사해서 넘기기

미리보기가 게시글을 독립적으로 고쳐야 한다면 값이 같은 새 객체를 넘기면 됩니다. 다음 프로그램은 MutableEntry에 자기 사본을 만드는 copy()를 추가하고, 미리보기에는 사본을 넘깁니다.

public final class SeparatedMutableEntries {
    public static void main(String[] args) {
        MutableEntry stored = new MutableEntry("object", 40);
        MutableEntry previewEntry = stored.copy();

        DailyReport report = new DailyReport(stored);
        PreviewService preview = new PreviewService(previewEntry);
        preview.applyPreviewBoost(5);

        System.out.println("stored=" + report.totalViewCount());
        System.out.println("preview=" + preview.previewViewCount());
    }

    private static final class MutableEntry {
        private final String title;
        private int viewCount;

        MutableEntry(String title, int viewCount) {
            this.title = title;
            this.viewCount = viewCount;
        }

        MutableEntry copy() { return new MutableEntry(title, viewCount); }
        void addViewCount(int extra) { viewCount += extra; }
        int viewCount() { return viewCount; }
    }

    private record DailyReport(MutableEntry entry) {
        int totalViewCount() { return entry.viewCount(); }
    }

    private record PreviewService(MutableEntry entry) {
        void applyPreviewBoost(int extra) { entry.addViewCount(extra); }
        int previewViewCount() { return entry.viewCount(); }
    }
}

stored=40
preview=45

stored.copy()가 new로 새 객체를 만들므로 이제 게시글 객체가 두 개입니다. 보고서는 stored를, 미리보기는 previewEntry를 가리키므로 미리보기가 조회 수를 45로 바꿔도 보고서는 40을 읽습니다. 복사하는 코드를 객체들을 만들어 연결하는 main에 두었기 때문에, 어디서 두 객체가 갈라지는지 한눈에 보인다는 장점도 있습니다. 아래 그림에서 공유하는 경우와 복사하는 경우를 단계별로 비교해 보세요. 두 행은 서로 다른 실행입니다.

stored=45
preview=45

stored=40
preview=45

stored=45
preview=45

stored=40
preview=45

하지만 이 방법에는 약점이 있습니다. 게시글을 넘기는 모든 곳에서 복사를 기억해야 하고, 한 곳만 빠뜨려도 처음 문제가 다시 생깁니다. 받는 쪽인 PreviewService의 생성자에서 entry.copy()를 저장하도록 바꾸면 호출하는 쪽이 잊을 걱정은 줄어듭니다. 그래도 게시글을 받는 다른 모든 클래스가 같은 일을 해야 한다는 점은 변하지 않습니다.

복사의 깊이도 문제입니다. copy()는 필드를 그대로 옮기는 얕은 복사라서, 게시글이 태그 목록 같은 가변 객체를 필드로 가지면 사본과 원본이 그 목록을 함께 쓰게 됩니다. 게다가 나중에 MutableEntry에 필드가 추가되면 copy()도 함께 고쳐야 하는데, 복사하는 코드가 여러 곳에 흩어져 있으면 그중 일부를 빠뜨리기 쉽습니다.

언어가 공유를 막아 주지는 않습니다

복사를 빠뜨리지 않도록 자바가 대신 막아 줄 수는 없을까요? 자바에는 '이 클래스의 객체는 한 곳에서만 참조할 수 있다'고 선언하는 문법이 없습니다. 객체 참조는 언제든 다른 변수에 대입하거나 여러 생성자에 넘길 수 있습니다. 호출하는 쪽이 같은 객체를 두 번 넘길 수도 있고, 배열의 여러 칸에 같은 객체를 넣을 수도 있습니다. 그래서 공유 문제는 클래스를 설계하는 방식으로 막아야 하고, 방법은 크게 세 가지입니다.

1. 독립적으로 고쳐야 하는 곳에 넘길 때 명시적으로 복사합니다. 앞 절에서 본 방법입니다.
2. 가변 객체를 바꿀 수 있는 곳을 한 객체로 정하고, 밖에는 바꿀 수 없는 값만 내보냅니다. 이렇게 어떤 객체만 다른 객체를 바꿀 수 있게 하는 관계를 이 글에서는 소유권(ownership)이라고 부르겠습니다.
3. 객체를 불변으로 만들어, 공유해도 아무도 바꿀 수 없게 합니다.

무조건 복사하는 것도 정답은 아닙니다. 회원이나 주문처럼 하나의 실체를 나타내는 객체는 모든 곳에서 같은 최신 상태를 봐야 하는데, 복사하면 오히려 사본마다 상태가 달라집니다. 이런 객체는 두 번째 방법처럼 한 객체가 변경을 맡는 편이 낫습니다. 반대로 날짜, 금액, 게시글 스냅샷처럼 값 자체가 의미인 객체는 세 번째 방법인 불변 설계가 자연스럽습니다. 다음 절에서는 두 번째 방법을 코드로 확인합니다.

두 번째 방법: 변경은 Board만 할 수 있게 하기

이번에는 게시판 Board가 게시글을 내부 배열에 보관하고, 게시글을 바꾸는 일도 Board만 하게 만들어 보겠습니다. 바깥 코드는 게시글 객체를 직접 받지 않고, '이 id의 조회 수를 55로 바꿔 달라'는 명령을 Board의 메서드로 보냅니다. 조회할 때는 내부 MutableEntry 대신 바꿀 수 없는 record EntryView를 새로 만들어 돌려줍니다.

public final class OwnedBoard {
    public static void main(String[] args) {
        Board board = new Board();
        long id = board.add("references", 40);
        board.reviseViewCount(id, 55);

        EntryView[] snapshot = board.snapshot();
        for (EntryView entry : snapshot) System.out.println(entry);
        System.out.println("total=" + board.totalViewCount());
    }

    private record EntryView(long id, String title, int viewCount) { }

    private static final class MutableEntry {
        private final long id;
        private final String title;
        private int viewCount;

        MutableEntry(long id, String title, int viewCount) {
            this.id = id;
            this.title = title;
            this.viewCount = viewCount;
        }
    }

    private static final class Board {
        private final MutableEntry[] entries = new MutableEntry[10];
        private int size;
        private long nextId = 1;

        long add(String title, int viewCount) {
            validateViewCount(viewCount);
            if (size == entries.length) throw new IllegalStateException("full");
            long id = nextId++;
            entries[size++] = new MutableEntry(id, title, viewCount);
            return id;
        }

        void reviseViewCount(long id, int viewCount) {
            validateViewCount(viewCount);
            for (int index = 0; index < size; index++) {
                MutableEntry entry = entries[index];
                if (entry.id == id) {
                    entry.viewCount = viewCount;
                    return;
                }
            }
            throw new IllegalArgumentException("id=" + id);
        }

        EntryView[] snapshot() {
            EntryView[] result = new EntryView[size];
            for (int index = 0; index < size; index++) {
                MutableEntry entry = entries[index];
                result[index] = new EntryView(entry.id, entry.title, entry.viewCount);
            }
            return result;
        }

        long totalViewCount() {
            long total = 0;
            for (int index = 0; index < size; index++) {
                total += entries[index].viewCount;
            }
            return total;
        }

        private static void validateViewCount(int viewCount) {
            if (viewCount <= 0) throw new IllegalArgumentException("viewCount");
        }
    }
}

EntryView[id=1, title=references, viewCount=55]
total=55

main은 add로 조회 수 40인 게시글을 등록하고, 돌려받은 id 1로 reviseViewCount를 호출해 조회 수를 55로 바꿉니다. 게시글 객체는 Board 안에서 만들어지고 밖으로 나가지 않으므로, 조회 수를 바꾸는 길은 Board의 메서드뿐입니다. 그 메서드가 validateViewCount로 값을 먼저 검사하므로 0 이하의 조회 수는 처음부터 들어갈 수 없습니다. 출력의 첫 줄은 snapshot()이 돌려준 EntryView를 record의 toString()으로 출력한 것이고, 둘째 줄은 Board가 계산한 조회 수 합계입니다.

Board 바깥의 main이 entry.viewCount 같은 private 필드를 읽지 않는다는 점도 눈여겨보세요. 모든 클래스가 OwnedBoard 안에 중첩되어 있어서 문법상으로는 main도 private 필드에 접근할 수 있지만, 이 예제는 일부러 Board의 메서드만 사용합니다. 이 글에서 말하는 소유권은 이렇게 설계로 정한 약속이지, 자바가 강제하는 별도의 기능이 아닙니다.

snapshot()은 호출한 시점의 상태를 새 배열과 새 EntryView들에 복사해 돌려줍니다. id와 조회 수는 기본형이라 값 자체가 복사되고, 제목은 불변인 String이라 같은 문자열을 함께 가리켜도 안전합니다. 그래서 받은 배열의 칸에 다른 EntryView를 넣어도 Board의 entries 배열은 바뀌지 않습니다. 또 이후에 Board의 상태가 바뀌어도 이미 받은 결과는 그대로 남습니다. 아래 그림에서 명령으로 등록하고, 승인된 변경을 거쳐, 조회 사본을 만드는 과정을 따라가 보세요.

내부 객체를 그대로 돌려주면 생기는 일

MutableEntry에 조회 수를 바꾸는 setViewCount가 있고, Board에는 snapshot() 대신 id로 게시글을 찾아 내부 MutableEntry를 그대로 돌려주는 find(id)가 있다고 해 봅시다. 그러면 board.find(id).setViewCount(-100)처럼 바깥 코드가 Board를 거치지 않고 게시글을 고칠 수 있습니다. 실제로 이렇게 바꿔 실행하면 스냅샷에는 viewCount=-100, 합계에는 total=-100이 나옵니다. reviseViewCount의 검사를 우회해 Board가 막으려던 음수 조회 수가 들어간 것입니다. 이처럼 필드를 private으로 숨겨도 내부의 가변 객체를 그대로 돌려주면 소유권은 무너집니다. 그래서 조회 메서드는 내부 객체 대신 바꿀 수 없는 값이나 사본을 돌려줘야 합니다.

더 깊이: 실패한 add와 합계의 자료형

만약 add가 long id = nextId++;를 용량 검사보다 먼저 실행한다면, 배열이 가득 찬 상태에서 add를 호출할 때 full 예외가 나는데도 nextId는 이미 1 늘어나 실패한 호출 때문에 id 하나가 건너뛰어집니다. 그래서 위 코드는 검사를 모두 통과한 뒤에 id를 발급합니다. 메서드가 예외로 끝날 때는 객체의 상태를 하나도 바꾸지 않는 것이 좋습니다. 그래야 호출한 쪽이 예외를 잡은 뒤에도 객체를 믿고 계속 쓸 수 있습니다.

합계를 int로 더한다면 어떻게 될까요? 조회 수가 각각 Integer.MAX_VALUE(2147483647)인 게시글 두 개를 int로 더하면 범위를 넘쳐 -2가 됩니다. 위 코드처럼 long으로 더하면 4294967294가 나옵니다. 게시글은 최대 10개이고 각 조회 수는 int 범위 안에 있으므로, 합계는 많아야 21474836470이라 long 범위 안에 충분히 들어갑니다.

세 번째 방법: 바꿀 수 없는 객체로 만들기

불변 객체는 공유해도 아무도 바꿀 수 없으므로, 복사를 기억할 필요도 변경 창구를 한 곳으로 모을 필요도 없습니다. 위 예제의 EntryView가 바로 그런 객체입니다. record이고 구성 요소가 기본형과 String뿐이어서, 어디에 넘겨도 받은 쪽이 값을 바꿀 수 없습니다. Board가 조회 결과를 불변 객체로 돌려준 것도 그 때문입니다. 불변 클래스를 직접 설계하는 방법은 불변 객체와 안전한 공유에서 자세히 다룹니다.

어떤 방법을 고를까

부수 효과가 보인다고 해서 모든 클래스를 불변으로 바꿀 필요는 없습니다. 먼저 그 객체의 상태가 왜 바뀌는지, 그리고 바뀐 상태를 누가 봐야 하는지를 따져 봅니다.

• 여러 기능이 같은 실체의 최신 상태를 봐야 하는가? 그렇다면 공유하되, 변경은 한 소유 객체에 모읍니다.
• 지나간 시점의 상태를 보관해야 하는가? 그렇다면 불변 값이나 사본으로 넘깁니다.
• 객체 안에 배열이나 목록 같은 가변 객체가 있는가? 그렇다면 복사할 때 그 객체까지 복사할지 정해야 합니다.
• 복사 비용과 예측 가능성 중 무엇이 더 중요한가? 아주 큰 객체를 자주 복사해야 한다면 변경 창구를 모으는 편이 나을 수 있습니다.

실제 프로그램에서는 이 방법들을 섞어 씁니다. 스냅샷과 설정 값은 불변 객체로, 계속 바뀌는 게시판 상태는 Board 같은 단일 소유 객체로, 잠깐 쓰는 편집본은 명시적 복사로 다루는 식입니다. 판단의 중심은 객체를 공유하느냐가 아니라, 공유한 객체를 누가 바꿀 수 있느냐입니다.

정리

• 객체 두 개가 같은 가변 객체를 필드로 들고 있으면, 한쪽의 변경이 다른 쪽의 결과를 바꾸는 부수 효과가 생깁니다.
• 자바에는 공유를 막는 문법이 없으므로 설계로 막아야 합니다. 방법은 복사해서 넘기기, 변경을 한 객체에 맡기기, 불변 객체 만들기의 세 가지입니다.
• 복사는 간단하지만 넘기는 모든 곳에서 기억해야 하고, 얕은 복사는 안쪽의 가변 객체를 공유합니다.
• 변경을 한 객체에 맡길 때는 내부 가변 객체를 밖으로 돌려주지 않고, 명령은 메서드로 받고 조회 결과는 불변 값이나 사본으로 돌려줍니다.

연습 문제

1. 위 OwnedBoard의 main을 바꿔, add 직후 reviseViewCount를 호출하기 전에 첫 스냅샷 before를 받아 두세요. 조회 수를 55로 바꾼 뒤 두 번째 스냅샷 after를 받아 before[0]과 after[0]의 조회 수를 출력하고, after[0]에 조회 수가 999인 새 EntryView를 넣은 다음 board.snapshot()을 다시 호출해 조회 수를 출력하세요. 세 값을 먼저 예상한 뒤 실행해 보세요.
2. 생성자에 넘긴 String[]을 나중에 바꾸거나, 조회 메서드가 돌려준 배열을 바꿔도 내부 태그가 바뀌지 않는 BoardNote를 만드세요.
3. 2번의 해설 코드에서 tags()가 return tags;로 내부 배열을 그대로 돌려준다면 출력이 어떻게 바뀔까요? 반대로 생성자가 this.tags = tags;로 복사 없이 저장한다면 어떻게 바뀔까요?

public static void main(String[] args) {
    Board board = new Board();
    long id = board.add("references", 40);
    EntryView[] before = board.snapshot();

    board.reviseViewCount(id, 55);
    EntryView[] after = board.snapshot();
    System.out.println("before=" + before[0].viewCount());
    System.out.println("after=" + after[0].viewCount());

    after[0] = new EntryView(id, "references", 999);
    System.out.println("board=" + board.snapshot()[0].viewCount());
}

before=40
after=55
board=55

public final class DefensiveTagCopyExercise {
    public static void main(String[] args) {
        String[] source = {"java", "object"};
        BoardNote note = new BoardNote("sharing", source);

        source[0] = "leak";
        String[] view = note.tags();
        view[1] = "changed";

        String[] safe = note.tags();
        System.out.println("source=" + source[0] + "," + source[1]);
        System.out.println("note=" + safe[0] + "," + safe[1]);
    }

    private static final class BoardNote {
        private final String text;
        private final String[] tags;

        BoardNote(String text, String[] tags) {
            this.text = text;
            this.tags = tags.clone();
        }

        String[] tags() {
            return tags.clone();
        }
    }
}

source=leak,object
note=java,object

source=leak,object
note=java,object

source=leak,object
note=java,object

다음 글

불변 객체와 안전한 공유에서는 세 번째 방법을 다룹니다. setter를 없애고 필드를 final로 만드는 것에서 시작해, 생성자에서 값을 검사하고 배열 필드를 복사해 공유해도 안전한 불변 객체를 완성합니다.