Table of contents
인터페이스라는 약속
다른 언어에서 인터페이스를 써본 적 있다면, Go의 인터페이스를 처음 만났을 때 뭔가 빠진 느낌을 받을 수 있다. implements 키워드가 없기 때문이다. Java나 C#에서는 “이 타입은 이 인터페이스를 구현합니다”라고 명시적으로 선언해야 하지만, Go는 그런 선언 없이도 인터페이스가 작동한다.
인터페이스를 하나 정의해보자.
package main
import "fmt"
type Speaker interface {
Speak() string
}Speaker는 Speak() 메서드를 가진 모든 타입과 호환된다. 이제 이 인터페이스를 “구현”하는 타입을 만들어 보겠다.
type Dog struct {
Name string
}
func (d Dog) Speak() string {
return d.Name + ": 멍멍!"
}
type Cat struct {
Name string
}
func (c Cat) Speak() string {
return c.Name + ": 야옹~"
}
func greet(s Speaker) {
fmt.Println(s.Speak())
}
func main() {
greet(Dog{Name: "초코"})
greet(Cat{Name: "나비"})
}Dog도 Cat도 어디에서도 Speaker를 구현한다고 선언하지 않았다. 그저 Speak() string 메서드를 가지고 있을 뿐이고, 그것만으로 Speaker 인터페이스를 만족시킨다. 이걸 **암묵적 구현(implicit implementation)**이라고 부른다.
구조체와 인터페이스 사이의 암묵적 구현 관계를 그림으로 보면 더 직관적이다.
flowchart LR
subgraph Interface
Speaker["Speaker\n─────────\n+ Speak() string"]
end
subgraph Structs
Dog["Dog\n─────────\n+ Name string\n+ Speak() string"]
Cat["Cat\n─────────\n+ Name string\n+ Speak() string"]
end
Dog -. "암묵적 구현\n(implements 없이)" .-> Speaker
Cat -. "암묵적 구현\n(implements 없이)" .-> Speaker
greet["greet(s Speaker)"]
Speaker --> greet왜 암묵적으로 만들었을까
이 설계에는 꽤 실용적인 이유가 있다. 내가 만든 타입이 다른 사람이 정의한 인터페이스를 자동으로 충족할 수 있기 때문이다. 라이브러리 A가 인터페이스를 정의하고, 라이브러리 B가 그 인터페이스를 모르는 채로 타입을 만들었어도, 메서드 시그니처만 맞으면 둘은 연결된다.
Java에서는 이런 게 불가능하다. 반드시 소스 코드에서 implements를 써야 하니까, 내가 수정할 수 없는 외부 라이브러리 타입에 인터페이스를 붙이려면 어댑터 패턴 같은 우회로가 필요하다. Go는 그런 우회가 필요 없다.
결합도를 낮추는 데도 효과적이다. 인터페이스를 정의하는 쪽과 구현하는 쪽이 서로를 전혀 모르는 상태에서도 협력할 수 있으니, 코드의 의존 방향이 자연스럽게 정리된다.
빈 인터페이스 — any
Go에는 메서드가 하나도 없는 인터페이스가 있다. 모든 타입이 이를 만족하므로, 어떤 값이든 담을 수 있는 그릇이 된다.
package main
import "fmt"
func printAnything(v any) {
fmt.Println(v)
}
func main() {
printAnything(42)
printAnything("hello")
printAnything(true)
printAnything([]int{1, 2, 3})
}any는 Go 1.18에서 도입된 interface{}의 별칭이다. 예전 코드에서는 interface{}로 되어 있는 걸 자주 볼 수 있고, 둘은 완전히 같은 의미다.
편리하지만 남용하면 안 된다. any로 받은 값은 타입 정보가 사라지기 때문에, 꺼내 쓸 때 반드시 타입을 확인하는 과정이 필요해진다. 컴파일러의 도움을 받을 수 없으니 런타임 에러의 가능성이 열리는 셈이다.
타입 단언
any나 인터페이스 타입으로 받은 값의 실제 타입을 확인하고 꺼내는 방법이 타입 단언(type assertion)이다.
package main
import "fmt"
func describe(v any) {
// 기본 형태: 실패하면 panic
s := v.(string)
fmt.Println("문자열:", s)
}
func describeSafe(v any) {
// 안전한 형태: ok 패턴
s, ok := v.(string)
if ok {
fmt.Println("문자열:", s)
} else {
fmt.Println("문자열이 아님")
}
}
func main() {
describeSafe("hello")
describeSafe(42)
// describe(42) // panic: interface conversion 에러
}v.(string)은 “v가 실제로 string이라면 그 값을 꺼내라”는 뜻이다. 한 가지 값만 받으면 실패 시 panic이 발생하고, 두 번째 반환값 ok를 함께 받으면 안전하게 처리할 수 있다.
실무에서는 거의 항상 ok 패턴을 쓴다. panic은 프로그램을 죽이기 때문에, 타입이 확실하지 않은 상황에서 단일 반환 형태를 쓰는 건 위험하다.
타입 스위치
타입 단언이 하나의 타입만 확인한다면, 타입 스위치는 여러 타입을 한꺼번에 분기할 수 있다.
package main
import "fmt"
func classify(v any) string {
switch val := v.(type) {
case int:
return fmt.Sprintf("정수: %d", val)
case string:
return fmt.Sprintf("문자열: %q (길이 %d)", val, len(val))
case bool:
if val {
return "참"
}
return "거짓"
case nil:
return "nil"
default:
return fmt.Sprintf("알 수 없는 타입: %T", val)
}
}
func main() {
fmt.Println(classify(42))
fmt.Println(classify("Go"))
fmt.Println(classify(true))
fmt.Println(classify(nil))
fmt.Println(classify(3.14))
}v.(type)은 일반 타입 단언과 생김새가 비슷하지만, switch 문 안에서만 사용할 수 있는 특수한 문법이다. 각 case에서 val은 이미 해당 타입으로 변환된 상태이므로, 추가 단언 없이 바로 쓸 수 있다.
JSON 파싱 결과를 다룰 때 특히 유용한 패턴이다. json.Unmarshal로 map[string]any에 담긴 값을 꺼낼 때 타입 스위치가 자주 등장한다.
인터페이스 조합
Go의 인터페이스는 다른 인터페이스를 임베딩해서 조합할 수 있다. 작은 인터페이스를 합쳐서 더 큰 계약을 만드는 방식이다.
package main
import "fmt"
type Reader interface {
Read() string
}
type Writer interface {
Write(data string)
}
type ReadWriter interface {
Reader
Writer
}
type File struct {
content string
}
func (f *File) Read() string {
return f.content
}
func (f *File) Write(data string) {
f.content = data
}
func process(rw ReadWriter) {
rw.Write("hello, Go")
fmt.Println(rw.Read())
}
func main() {
f := &File{}
process(f)
}ReadWriter는 Reader와 Writer를 모두 포함한다. 이 패턴은 Go 표준 라이브러리 곳곳에서 쓰인다. io.ReadWriter, io.ReadCloser, io.ReadWriteCloser 같은 타입이 전부 이런 조합으로 만들어진 것이다.
Go 커뮤니티에서는 “인터페이스는 작게 만들어라”라는 격언이 있다. 메서드 하나짜리 인터페이스가 가장 재사용성이 높고, 필요할 때 조합하면 되기 때문이다.
io.Reader와 io.Writer
Go 표준 라이브러리에서 가장 중요한 인터페이스 둘을 꼽으라면 단연 io.Reader와 io.Writer다.
type Reader interface {
Read(p []byte) (n int, err error)
}
type Writer interface {
Write(p []byte) (n int, err error)
}메서드가 딱 하나씩이다. 이 단순한 인터페이스가 파일 입출력, 네트워크 통신, 압축, 암호화, HTTP 요청/응답을 전부 관통한다. 파일도 Reader이고, HTTP 응답 본문도 Reader이며, 압축 스트림도 Reader다.
직접 구현해보면 감이 온다.
package main
import (
"fmt"
"io"
"strings"
)
type UpperReader struct {
src io.Reader
}
func (u *UpperReader) Read(p []byte) (int, error) {
n, err := u.src.Read(p)
for i := 0; i < n; i++ {
if p[i] >= 'a' && p[i] <= 'z' {
p[i] -= 32 // 소문자 → 대문자
}
}
return n, err
}
func main() {
original := strings.NewReader("hello, go interfaces!")
upper := &UpperReader{src: original}
data, _ := io.ReadAll(upper)
fmt.Println(string(data)) // HELLO, GO INTERFACES!
}UpperReader는 내부 Reader에서 읽은 데이터를 대문자로 변환한다. 기존 Reader를 감싸서 새로운 동작을 추가하는 이 패턴을 데코레이터 패턴이라고 부르는데, Go에서는 인터페이스 덕분에 이런 조합이 매우 자연스럽다.
strings.NewReader, bufio.NewReader, gzip.NewReader — 이름에 Reader가 들어간 타입은 전부 io.Reader를 구현하고 있으며, 서로 체이닝할 수 있다. 이 일관성이 Go의 강력한 장점 중 하나다.
인터페이스의 nil 함정
인터페이스와 관련해서 한 가지 주의할 점이 있다. 인터페이스 값은 내부적으로 (타입, 값) 쌍으로 저장되는데, 이 때문에 직관과 다른 결과가 나올 수 있다.
package main
import "fmt"
type MyError struct {
Message string
}
func (e *MyError) Error() string {
return e.Message
}
func mayFail(fail bool) error {
var err *MyError = nil
if fail {
err = &MyError{Message: "실패!"}
}
return err // 여기가 함정
}
func main() {
err := mayFail(false)
if err != nil {
fmt.Println("에러 발생:", err) // 이 줄이 실행된다!
} else {
fmt.Println("성공")
}
// 왜? 인터페이스 내부를 들여다보면:
fmt.Printf("타입: %T, 값: %v, nil?: %v\n", err, err, err == nil)
// 타입: *main.MyError, 값: <nil>, nil?: false
}mayFail(false)는 *MyError 타입의 nil 포인터를 반환한다. 하지만 이 값이 error 인터페이스로 변환되면, 인터페이스 내부에는 (타입: *MyError, 값: nil)이 담긴다. 타입 정보가 있으니 인터페이스 자체는 nil이 아닌 것으로 판정되는 거다.
올바른 해결 방법은 인터페이스 타입으로 직접 nil을 반환하는 것이다.
func mayFailFixed(fail bool) error {
if fail {
return &MyError{Message: "실패!"}
}
return nil // error 인터페이스의 진짜 nil
}이건 Go를 쓰다 보면 한 번쯤 반드시 만나는 함정이니, 미리 알아두면 디버깅 시간을 크게 줄일 수 있다.
인터페이스는 Go의 다형성을 지탱하는 핵심 장치다. 암묵적 구현 덕분에 코드 간 결합이 느슨해지고, 작은 인터페이스의 조합으로 복잡한 동작을 표현할 수 있다. 특히 io.Reader와 io.Writer 패턴은 Go 생태계 전반에 깊이 박혀 있으므로, 이 둘에 익숙해지면 표준 라이브러리를 다루는 게 한결 편해진다.
다음 편에서는 포인터를 다룬다. &와 *의 의미, 값 전달과 포인터 전달의 차이, 그리고 nil 포인터까지 살펴보자.
-> 8편: 포인터
Loading comments...