답변.

Go 언어에서 코드는 패키지와 가시성 시스템을 통해 모듈성, 재사용성 및 논리의 캡슐화에서 중요한 역할을 합니다.

배경

많은 전통적인 객체 지향 상속 언어와는 달리 Go는 간단한 모듈 — 명확한 내보내기 및 가져오기 규칙을 가진 패키지 중심으로 설계되었습니다. 이는 최소주의, 단순성 및 엄격한 종속성 제어 철학에서 기원합니다.

문제

구성 요소에 명확한 가시성이 없다면 이름에 혼란이 생기고, 파일 간 종속성을 추적하기 어렵고, 개인 구현 세부사항을 우연히 사용할 위험이 증가합니다. 내보내기 조직에서의 오류는 디버깅하기 어려운 버그와 캡슐화 위반으로 이어질 수 있습니다.

해결책

Go에서는 모든 파일이 반드시 특정 패키지에 속해야 합니다 (package 이름). Go의 모든 가시성은 다음과 같이 정의됩니다:

대문자로 시작 (내보내기/공개)
소문자로 시작 (개인적/비공식)

이름이 대문자로 시작하는 모든 함수, 유형, 변수, 상수 및 메서드는 패키지에서 내보내져 다른 패키지에서 가져온 후 사용할 수 있습니다. 나머지는 패키지 내부에서만 사용할 수 있습니다.

구조 예시:

project/
│
├── main.go          // package main
└── mathutil/
    └── mathutil.go  // package mathutil

코드 예시:

// mathutil/mathutil.go
package mathutil

// Public - 내보내기 함수
func Sum(a, b int) int {
    return a + b
}

// private - 내보내지 않는 함수
func subtract(a, b int) int {
    return a - b
}

// main.go
package main

import (
    "fmt"
    "project/mathutil"
)

func main() {
    fmt.Println(mathutil.Sum(2, 3))      // 5
    // fmt.Println(mathutil.subtract(3,2)) // 컴파일 오류! subtract는 내보내지 않음
}

주요 특징:

간단하고 투명한 내보내기/가져오기 모델
내보내기는 이름의 첫 글자에 의해 결정 — 어떤 키워드도 필요하지 않음
각 디렉토리는 정확히 하나의 패키지를 구현

트릭 질문.

소문자로 선언된 변수 또는 함수를 다른 메커니즘을 통해 내보낼 수 있습니까?

아니요. Go에는 public, private와 같은 키워드가 없으며, 모든 것은 이름의 첫 글자에 의해 결정됩니다 (unicode 카테고리 — 대문자).

패키지의 한 파일에 있는 함수가 동일 패키지의 다른 파일에서 개인 함수를 사용할 수 있습니까?

예, 가시성은 파일이 아니라 패키지 수준에서 제한됩니다. 모든 개인 요소는 동일 패키지의 모든 파일에서 사용 가능합니다.

코드 예시:

// mathutil/helpers.go
package mathutil

func hiddenHelper() int { return 42 }

// mathutil/mathutil.go
package mathutil

func UseHelper() int {
    return hiddenHelper() // 접근 가능!
}

같은 패키지 내에서 다른 파일에 동일한 이름의 함수나 타입을 만들 수 있습니까?

아니요, 컴파일 오류가 발생합니다 — 패키지 내에서 이름은 고유해야 하며, 다른 파일에 선언된 경우에도 마찬가지입니다.

일반적인 실수 및 안티 패턴

우연히 구현 세부 사항을 내보내는 경우, 이름을 대문자로 시작
같은 이름의 타입을 가진 파일로 패키지를 나누는 경우
main 패키지에 너무 많은 논리를 집어넣는 경우 (모듈성 위반)
테스트를 위해서만 내보내기를 사용하는 경우 (동일 패키지에서 xxx_test.go 파일을 사용하는 것이 더 좋음)

실생활 예시

부정적 사례

대규모 팀에서 모든 보조 함수 및 타입을 util 패키지에 넣고 모든 것을 내보낸 경우:

장점:

별다른 고민 없이 어떤 함수든 빠르게 사용할 수 있음

단점:

캡슐화 손실 (구현 세부사항이 다른 패키지의 의존성이 될 수 있음)
리팩토링 및 테스트의 복잡성

긍정적 사례

팀에서 코드를 비즈니스 영역에 따라 모듈로 철저히 분리하고, API만 내보내는 경우: