ZIP files created with GUI have more bytes than ZIP files created in a shell

Zipping from the Finder adds a folder __MACOSX, invisible on Macs, that contains OS X resource forks like custom icons and such. From Wikipedia:

The resource fork is a fork or section of a file on the Apple Mac OS operating system used to store structured data along with the unstructured data stored within the data fork. A resource fork stores information in a specific form, containing details such as icon bitmaps, the shapes of windows, definitions of menus and their contents, and application code (machine code). For example, a word processing file might store its text in the data fork, while storing any embedded images in the same file's resource fork. The resource fork is used mostly by executables, but every file is able to have a resource fork.

Even apart from the main cause in this case (Finder adding extra hidden stuff, as empedocle says), different sizes for ZIPs of the same data doesn't indicate a problem, when the size difference is a fraction of a percent.

Different ZIP implementations might have a different default compression level (tradeoff between CPU time and size saved), or just have different code that saves more or fewer matches, saving more or fewer bytes at the default compression level.

For example, 7-Zip usually makes smaller .zip files than other ZIP programs. (And no, I'm not talking about its own .7z file format. It has a better plain-ZIP compressor, too.)

zipcmp is a cmdline program that can compare ZIP files. It defaults to comparing just the ZIP directory, to check that all files are the same name, size, and CRC. If this is the case, both ZIP files are almost certain to have the same contents, but just compressed differently (if the compressed size differs.) As long as the ZIP files aren't damaged, of course. Use unzip -t foo.zip to test a ZIP file for decompression errors, non-matching CRCs, etc.